Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

A fix for RSA hostkey warning with multiple tunnels UNIX
I use ssh tunnels to access multiple servers at different hosts with sshkeychain. With sshkeychain active, I typically run ssh localhost -oPort=1024 to access the various servers that I administer. So I typically end up with something like ports 1024 and 1025 tunneling ports from one server, and 1026 and 1027 tunneling ports from another.

The problem is that with multiple hosts being accessed through localhost, my known_hosts file always has the wrong host in it. As a result, I get the following message (call me paranoid, but I usually keep my ssh host checking strict):
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
... etc.
... etc.
This continues for many lines, and is somewhat annoying. So this is what I did. I made a little perl script (rsa_remove) that removes any line with localhost in it from my known_hosts file. I then use aliases such as the following to call the script and then the ssh command with the new port:
alias alias_name='rsa_remove;ssh localhost -oPort=1024'
Here is the rsa_remove perl script (barely a script, I know):
perl -e "s/^localhost.*n//g;" -pi ~/.ssh/known_hosts
Hope this helps someone...

[robg adds: I haven't tested this one...]
    •    
  • Currently 2.20 / 5
  You rated: 3 / 5 (5 votes cast)
 
[9,970 views]  

A fix for RSA hostkey warning with multiple tunnels | 5 comments | Create New Account
Click here to return to the 'A fix for RSA hostkey warning with multiple tunnels' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Ignore host authentication for localhost
Authored by: thrig on Sep 29, '05 07:13:40AM

Why not use the NoHostAuthenticationForLocalhost option to ssh in your ~/.ssh/config file?

Host localhost
  NoHostAuthenticationForLocalhost yes

For more information, peruse ssh_config(5).



[ Reply to This | # ]
A fix for RSA hostkey warning with multiple tunnels
Authored by: acet on Sep 29, '05 11:38:58AM

This is fine and good except for the fact that it effectively disables host key checking, thus leaving you wide open to man-in-the-middle attacks.

There's a better way.

For each host that you tunnel to, create a host entry in ~/.ssh/config similar to the following example:

        Host server1
               User root
               HostName 127.0.0.1
               Port 1024
               HostKeyAlias server1

The 'HostKeyAlias' directive sets the name in known-hosts that the host key will be saved as. Thus, every time you 'ssh server1', it'll check the proper host key. You won't get the RSA key warnings any more and you'll still maintain the protection of host key checking. Also, it has the nice benefit of saving you from having to use -oPort=1024 (which btw can be simplified as -p 1024)



[ Reply to This | # ]
A fix for RSA hostkey warning with multiple tunnels
Authored by: Gerk on Sep 29, '05 11:39:13AM

Exactly ... as posted above just disable host checking :)



[ Reply to This | # ]
A better solution (I think)
Authored by: cuberoot on Sep 29, '05 12:46:42PM

Dispensing with rsa verification is a bad idea at best, and dangerous at worst. The comment about using HostKeyAlias is definitely a better way to go but is also a bit of a pain to manage.

However, with modern ssh clients there is no need to set up a bunch of local port fowards to access hosts through the other end of an ssh connection. Enter DynamicForward.

Instead of using something like this in your config plus some set of workarounds for the resultant ssh host key mismatches:

Host remotetunnelmachine
   Localforward 1234 remotehost1:22
   Localforward 1234 remotehost2:22

Just use one:

Host remotetunnelmachine
   DynamicForward 1080

The above will set up a localhost listener on port 1080 that is in fact a SOCKS server that forwards all connection requests through remotetunnelmachine. This means you can also set your web browser proxy config to SOCKS on localhost:1080 and browse websites on the other end.

The only additional piece you need to make the magic happen is a command line SOCKS tool. I use connect.c because it's very lightweight, but socat (sysutils/socat) from darwinports works just as well.

My config for various endpoints looks something like this:

Host remotehost1 remotehost2
  ProxyCommand ~/bin/connect -4 -S 127.0.0.1:1080 %h %p

If you're using socat use this ProxyCommand instead:

  ProxyCommand socat - socks4:127.0.0.1:%h:%p,socksport=1080,nodelay

Of course, this assumes you'll always be using the ssh port foward to connect to the listed hosts; Either live with that, use the FQDN for one place and the short name for another, or do what I do:

ProxyCommand can easily be a shell script that autodetects if the appropriate DynamicForward listener is up, uses it if so, and otherwise connects directly.

The above lets you type 'ssh remotehost1' no matter where you are, avoids key mismatch problems, and generally makes life good. I use some PAC (proxy autoconfig) magic to do automatic detection for the webbrowser too. This works so well I don't use the company VPN client any more. O.K. it was actually the company VPN client that ... *cough* encouraged me to do this in the first place, but hey. ;)

For those interested, the autodetecting ProxyCommand script is just a simple:


#!/bin/sh
if connect -n 127.0.0.1 1080 >/dev/null 2>&1 </dev/null; then
    exec connect -4 -S 127.0.0.1:1080 "$@"
else
    exec connect -n "$@"
fi

Happy ssh'ing!

No purchase necessary. Offer not valid with all ssh client versions. Void where prohibited by security policy or AllowTcpForwarding. See DynamicForward entry in ssh(1) for details.



[ Reply to This | # ]
A better solution (I think)
Authored by: jweber on Sep 30, '05 04:42:39PM

I usually just put a bunch of entries in my /etc/hosts file, e.g.
127.0.0.1 host1.localhost
127.0.0.1 host2.localhost
...

Then I can ssh to host1.localhost instead of just localhost. This keeps the names separate so known_hosts doesn't get confused, and has the added benefit that it's always clear which host I'm connecting to.



[ Reply to This | # ]