Centos – SSH works but tunneling or SFTP doesn’t. Why

centosiptablesselinuxsshtunneling

since 2014 I've got a server from SoYouStart, with Centos 7. It worked perfectly, but now I had to install again the OS.
Now I'm configuring all the services to work again.
I need to connect to the server with SSH tunneling to Mysql (now MariaDB) and transfer files with SFTP.
The problem is that I can successfully connect with SSH to the server (from any host) but when I try to use Cyberduck or Navicat to connect to the server using SSH tunneling I get an error ("Server unexpectedly closed network connection" or "There was a problem while connecting to the server on port 22.").
I tried from iPhone with a SSH shell, and I can connect successfully both with SSH and SFTP, but non to the DB with SSH tunneling.
I cannot understand where is the problem.
I already disabled iptables, firewalld (I replaced it with iptables) and selinux
Connecting directly to the DB allowing remote connection works.
The server has a static ip address, from the provider, and my homework netwkor didn't change during last hours so I don't think the problem is here.

Can anyone help me? Thank you very much

Andrea

edit @TheCompWiz

sshd_config already allows Tcp Forwarding. These are the uncommented lines: 

PermitRootLogin yes
PasswordAuthentication yes
ChallengeResponseAuthentication no
AllowTcpForwarding yes
X11Forwarding yes
UsePrivilegeSeparation sandbox
PermitTunnel yes
Subsystem       sftp    /usr/libexec/openssh/sftp-server

And it's strange that I can do sftp from a mobile app but I can't do from the computer.. Mysql SSH tunneling still doesn't work

Thank you very much

Best Answer

ssh tunneling is configured by the ssh-daemon itself. If the SSH daemon does not permit tunneling, you'll need to re-configure it. Typically, it's just running openssh server... and you can edit the /etc/ssh/sshd_config and add AllowTcpForwarding yes (remove AllowTcpForwarding no) and reload sshd config.

As far as sftp goes, this is a slightly different animal. Essentially, when you want to sftp, the connection starts as a ssh session with a flag that says you want to start the sftp subsystem. This starts the ssh session as you would expect, but instead of starting a command interpreter, it starts the sftp server, and input/output is directed through the ssh session to/from the sftp-server process. If no sftp subsystem is configured, or no sftp-server exists, or even if the sftp server isn't configured to permit the user... the whole thing can fail. Alternatively, you could try scp instead, which does not rely on a separate sftp-server subsystem.

Related Topic