10

I'm trying to use an ssh tunnel from my office machine to my home machine, and get an error when I try to use it.

What I'm doing is starting one shell like so:

ssh -gL 12345:my.home.domain:22 my.home.domain

This is giving me a proper shell, no problem. What I normally do then is ssh to my home machine through this office machine, like so:

ssh -p 12345 127.0.0.1

This has always worked for me, until last week, when I set up a new system on my home machine (switching from Ubuntu to Debian). Now I get an error. I can still open up my initial ssh connection, but when I try to use that tunnel, I get (on the office machine) this error:

ssh_exchange_identification: Connection closed by remote host

Also, when that happens, the open shell that I have the tunnelling set up through gets this line spat out at it:

channel 3: open failed: connect failed: Connection timed out

At which point, I'm at a loss. If any more info is needed, I'll be happy to post it.

============= further to that ==============

After fiddling around further, I've found that I'm getting a different response from the server (my home machine that is) when I try to telnet in on the various ports. If I try:

telnet my.home.domain 22

I get this back:

Trying <my ip address>...
Connected to <my domain>.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze2

Which is what I would expect. After setting up the tunnel though, and then telnetting to that, I see this response:

Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.

============== and further still ==================

As per kbulgrien's suggestion, here is the output from the client machine with the -v option:

ssh -vp 24600 127.0.0.1
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 24600.
debug1: Connection established.
debug1: identity file /home/jacob/.ssh/id_rsa type -1
debug1: identity file /home/jacob/.ssh/id_rsa-cert type -1
debug1: identity file /home/jacob/.ssh/id_dsa type -1
debug1: identity file /home/jacob/.ssh/id_dsa-cert type -1
debug1: identity file /home/jacob/.ssh/id_ecdsa type -1
debug1: identity file /home/jacob/.ssh/id_ecdsa-cert type -1
ssh_exchange_identification: Connection closed by remote host

Jacob Ewing
  • 201
  • 1
  • 3
  • 6
  • One cause of the `ssh_exchange_identification: Connection closed by remote host` error relates to the connecting host being listed in the `/etc/hosts.deny`. – Zoredache Jan 10 '13 at 17:23
  • Hm - if I cat /ets/hosts.deny on that machine, every line is remarked. – Jacob Ewing Jan 10 '13 at 17:26
  • May I suggest adding `-v` to the ssh command that fails? Does the ensuing output give any other indication of failure (i.e. `channel 1: open failed: administratively prohibited: open failed`). – kbulgrien Jan 10 '13 at 19:41
  • 2
    Sorry, it just occured to me that it is helpful to have `-v` on both the tunnel and failing ssh commands (looking for something more than `channel 3: open failed: connect failed: Connection timed out`). It might be noteworthy to mention that one can add multiple `-v` (up to three) to increase verbosity. I wouldn't necessarily post the whole spew, but it might be worth perusing for words that seem to indicate a problem. – kbulgrien Jan 10 '13 at 20:14

5 Answers5

1

Maybe if you have more then ssh 10 sessions waiting for insert the password, you have that kind of error, i remember that was recent ssh bug, if you would verify this, use the command below

for i in {1..15};do ssh -fNt pippo@remote.server.com & >/dev/null ;done
c4f4t0r
  • 5,301
  • 3
  • 31
  • 42
0

In my Linux, Salix 14.0 (Slackware 14.0), the solution was easy.

The problem was the script /etc/rc.d/rc.sshd, has not permission for execution.

Just chmod +x /etc/rc.d/rc.sshd for run this scrpit at boot.

This script execute sshd-> /usr/local/sbin/sshd (SSH Daemon)

Uwe Keim
  • 2,420
  • 5
  • 30
  • 47
0

Something like this happened on a recent install. In this situation /etc/hosts.deny existed and had no settings that explicity denied access, so the circumstances seem similar. It was necessary to alter /etc/hosts.allow to add something like:

sshd: 192.168.127.0/255.255.255.128

The IP details need to be adjusted to your needs, or are replaced with ALL if there is no concern with allowing ssh from everywhere.

After making the changes, stop and restart sshd.

Upvoted answers to following question provide more examples.

SSH hosts.deny and hosts.allow

Here is someone else's testimony that links the error message with the solution.

How To Fix : ssh_exchange_identification: Connection closed by remote host problem when logging in with SSH

kbulgrien
  • 434
  • 1
  • 7
  • 17
  • Hmm - sadly that didn't fix it for me. I think my situation differs from the ones in the example. I am able to ssh in on port 22 with no trouble. It's only when I try to tunnel through another port that I get the errors mentioned. – Jacob Ewing Jan 10 '13 at 18:27
  • Granted that the tunnel is a distinctive difference. Given that, does this help: https://discussion.dreamhost.com/thread-97951.html ? I have also found references to an indication that uninstalling and re-installing the sshd package on debian-like systems corrects an issue with keys that causes the behavior you describe ( https://discussion.dreamhost.com/thread-97951.html et. al. ). – kbulgrien Jan 10 '13 at 18:59
  • You do have sshd (openssh-server) installed on both systems, right? – kbulgrien Jan 10 '13 at 19:06
  • Yupyup. I've been doing this for quite a long time, and only ran into trouble last week after switching to Debian on my home machine (the server). I'll try your suggestion of un/re-installing sshd when I get home tonight. – Jacob Ewing Jan 10 '13 at 19:53
0

I had the same problem and in the end solved the problem by correcting the /etc/network/interfaces:

auto eth0
iface eth0 inet static

or

auto eth0
iface eth0 inet dhcp

without that config I never get reverse connection to my ssh tunnel.

slm
  • 7,615
  • 16
  • 56
  • 76
dr4ck0
  • 1
0

In my case, I had to insert to /etc/ssh/sshd_config of the gateway machine the following lines:

Match User <username>
   GatewayPorts yes

See more details here

Hope this helps!

floatingpurr
  • 103
  • 1
  • 5