Strict Standards: Declaration of HTML_Menu3::_findNodeType() should be compatible with HTML_Menu::_findNodeType($nodeId, &$nodeUrl, $level) in /var/www/ on line 49 | SSH hopping with the ProxyCommand - Putting the fizzle in Wi-Fi since 2005 .. (yes, this was a poor choice for a domain name)

<div class="news_item">#457<div class="news_title">SSH hopping with the ProxyCommand

Posted by dandriff on Wednesday August 29, 2012@04:18PM

I started off with a basic ProxyCommand configuration, like this:

     ProxyCommand ssh nc %h %p
     IdentityFile ~/.ssh/id_rsa

But I kept getting the following error:

 $ ssh
 Permission denied (publickey).

 $ ssh -v
 OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
 debug1: Reading configuration data /Users/wi-fi/.ssh/config
 debug1: Applying options for *
 debug1: Applying options for api1b
 debug1: Reading configuration data /etc/ssh_config
 debug1: Applying options for *
 debug1: Executing proxy command: exec ssh -C nc 22
 debug1: permanently_drop_suid: 501
 debug1: identity file /Users/wi-fi/.ssh/id_rsa type 1
 debug1: identity file /Users/wi-fi/.ssh/ type -1
 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
 debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
 debug1: Enabling compatibility mode for protocol 2.0
 debug1: Local version string SSH-2.0-OpenSSH_5.6
 debug1: SSH2_MSG_KEXINIT sent
 debug1: SSH2_MSG_KEXINIT received
 debug1: kex: server->client aes128-ctr hmac-md5
 debug1: kex: client->server aes128-ctr hmac-md5
 debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
 debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
 debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
 debug1: Host '' is known and matches the RSA host key.
 debug1: Found key in /Users/wi-fi/.ssh/known_hosts:89637
 debug1: ssh_rsa_verify: signature correct
 debug1: SSH2_MSG_NEWKEYS sent
 debug1: expecting SSH2_MSG_NEWKEYS
 debug1: SSH2_MSG_NEWKEYS received
 debug1: Roaming not allowed by server
 debug1: SSH2_MSG_SERVICE_ACCEPT received
 debug1: Authentications that can continue: publickey
 debug1: Next authentication method: publickey
 debug1: Offering RSA public key: /Users/wi-fi/.ssh/id_rsa
 debug1: Authentications that can continue: publickey
 debug1: No more authentication methods to try.
 Permission denied (publickey).

These wonderful articles all ended up not helping me solve this problem _at all_:

But what each of these publications fails to mention as a possible problem is that if your username doesn't match on both the intermediate and destination hosts, the ProxyCommand won't work until you specify the usernames in your ~/.ssh/config like this:

     User wi-fizzle
     ProxyCommand ssh nc %h %p
     IdentityFile ~/.ssh/id_rsa

Along the way, I found a cool trick to reuse tcp connections:

Reusing Connections

The transparent multi-hop connections can be very useful but you may find that it takes a second or two to establish each connection. This delay can become annoying if it happens a lot (e.g.: every time you save a file from the text editor).

The good news is that if you can configure SSH to reuse an existing connection. This means that for example if you have an SSH shell session running then a new connection for SCP can skip the connection setup phase. Two steps are required:

First, you must create a directory (or 'folder') which SSH will use to keep track of established connections:

 mkdir ~/.ssh/tmp

Next, add these two lines at the start of your ~/.ssh/config (make sure to use your username in place of 'YOUR-NAME'):

 ControlMaster auto
 ControlPath   /home/YOUR-NAME/.ssh/tmp/%h_%p_%r

As you can see, a small investment in time setting up your SSH configuration can pay back dividends in convenience.