[SOLVED] SSH port forwarding: connection closed by remote host

m_yates · 05-07-2014, 08:03 PM

I have a vpn server set up as a relay to allow me to access my home computer (that is behind an ISP firewall that I can't do anything about). It was working great until recently. I am hoping someone here can help me troubleshoot.

On my home computer, I issue the following command:

Code:

autossh -M 20000 -N -R 10000:localhost:10000 matt@relayserver.com &

Note: "relayserver.com" is not the real host name.

If I log in to my relay server, the output of:

Code:

netstat -tunelp | grep 10000

is:

Code:

tcp        0      0 0.0.0.0:10000           0.0.0.0:*               LISTEN      1000       19496       3929/sshd: matt 
tcp6       0      0 :::10000                :::*                    LISTEN      1000       19497       3929/sshd: matt

So, it appears that the server is listening on the forwarded port. On my home computer, I have the fowarded port in /etc/ssh/sshd_config, and I was connecting to it before.

Now, when I try connecting with:

Code:

ssh matt@relayserver.com -p 10000 -v

I get this output:

Code:

OpenSSH_6.0p1 Debian-4+deb7u1, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to relayserver.com [84.xxx.xxx.xxx] port 10000.
debug1: Connection established.
debug1: identity file /home/matt/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/matt/.ssh/id_rsa-cert type -1
debug1: identity file /home/matt/.ssh/id_dsa type -1
debug1: identity file /home/matt/.ssh/id_dsa-cert type -1
debug1: identity file /home/matt/.ssh/id_ecdsa type -1
debug1: identity file /home/matt/.ssh/id_ecdsa-cert type -1
connect_to localhost port 10000: failed.
ssh_exchange_identification: Connection closed by remote host

It says "connection established", but then fails. Any idea how to troubleshoot? I am not very skilled with openssh. I did upgrade everything recently with the heartbleed fix, so I wonder if that has anything to do with it. My work, home, and relay servers are all running Debian Wheezy with all the latest updates applied.

lleb · 05-08-2014, 12:49 PM

fast question, have you port forwareded 10000 via your router to your computer? if you have not setup port forwarding in your router you are connecting to your router and it is dropping the connection as it should.

m_yates · 05-08-2014, 01:19 PM

Quote:

Originally Posted by lleb

fast question, have you port forwareded 10000 via your router to your computer? if you have not setup port forwarding in your router you are connecting to your router and it is dropping the connection as it should.

The relay server is not blocked. I can log in to it via ssh using the standard ssh port from home or work.

The autossh command that I posted above is used to make a connection via ssh from my home computer to the relay and set up forwarding of port 10000 back to my home computer. That autossh command is working (I think), because the relay server shows that it starts listening on port 10000. It is the same autossh command that worked previously.

I am using the relay server so I don't have to do anything with port forwarding on my home router. The reason for that is because my router (and home computer connected to it) is behind a cable modem that blocks incoming connections and my ISP does not offer any way to un-block incoming connections without upgrading to a business-class connection. The autossh command is to set up a tunnel to my home computer. It worked previously, and I haven't changed anything to my knowledge with the router or modem.

What I am doing is this:

https://stackoverflow.com/questions/...rse-ssh-tunnel

(The green check marked answer to the question)

lleb · 05-09-2014, 08:21 PM

ok, sorry i read your OP wrong. also check out my link for reverse ssh for remote access to see if it has any hints that might help.

m_yates · 05-16-2014, 10:24 AM

I solved it, but I am still not exactly sure of the original source of the problem. I deleted the .ssh directories in my user account on the relay server, work, and home. From both home and work, I generated new keys using the command as non-root user:

Code:

ssh-keygen -t rsa -b 4096

I then logged into the relay server using a password, and created a file at ~/.ssh/authorized_keys on the relay server. On both home and work computers, I opened the file ~/.ssh/id_rsa.pub in gedit and copied the contents to ~/.ssh/authorized_keys on the remote relay server. I then made sure that I could log in to the relay server from both home and work without a password. Then I issued the autossh command from my home computer to set up remote port forwarding:

Code:

autossh -M 20000 -N -R 10000:localhost:10000 matt@relayserver.com &

From work, I can now log into my home computer using the command:

Code:

ssh matt@relayserver.com -p 10000

I have a script that does incremental backups nightly from my work computer to my home computer using ssh and rsync. I made a test run of the script from a terminal at work and it works as expected.

If anyone else reads this thread for similar problems with ssh keys, there are two issues that I should point out. First, the autossh command:

Code:

autossh -M 20000 -N -R 10000:localhost:10000 matt@relayserver.com &

will give no indication in the terminal that it failed to establish a connection. If ssh requires a password, the above autossh command will not prompt you for one, it will just return the terminal prompt. The other issue is that an old autossh process may be running in the background and it won't die. That is the point of autossh I guess. You can find the pid of autossh with the command:

Code:

pidof autossh

If you try to kill the process with:

Code:

kill <pid>

where <pid> is the pid of the autossh process, it won't die. To kill autossh, you have to issue the SIGKILL signal:

Code:

kill -9 <pid>

The above command does kill autossh, then you can reestablish a new connection with autossh.