1

I would like to login to a remote server by executing sth. like ssh remoteServer. The remote server can only be reached via a login server (which there are two of).

There are two routes I would like to be able to take (in case one login server cannot be used):

  1. ABD
  2. ACD

Some info:

  • A: my local computer
  • B: login server; only allows usernameB/password login (no key file); I cannot make changes (save key file etc.)
  • C: login server; allows key file login; I can make some changes (not a superuser though)
  • D: target server; can only be reached from B or C; allows key file login

I'm using a password protected private key file (on A and C; the same one) which I can use to log in to C and D. Here's what I want:

  1. ssh B_D: Prompt for password of usernameB@B and then for the password of the private key file for usernameD@D. Since I cannot save the private key on B it has to be forwarded somehow. In case I have loaded it with ssh-agent it shouldn't ask for the password again.
  2. ssh C_D: Prompt for password of the private key once and then use it to login to usernameC@C and then usernameD@D. Again, if the key was loaded with ssh-agent beforehand, it shouldn't prompt for a password.

Partly I'm able to use the following command to achieve the above (but only if the key was loaded with ssh-agent):

ssh -A -t usernameB@B ssh usernameD@D
ssh -A -t usernameC@C ssh usernameD@D

Is there perhaps a modification that loads the key file first but only for this session? If I log out the key file should then be unloaded.

The above command has two problems:

  1. I don't want to manually load the key first with ssh-agent. This defeats the purpose of having to enter only one command.
  2. I want to place this or an equivalent command into the ssh config file. If there is a different way to achieve what I want, that would be fine as well (as long as I don't need to modify anything on B or need superuser rights on C).

I was able to achieve sth. similar using the ssh config file:

Host C
    HostName addressOfC
    User usernameC
    IdentityFile ~/.ssh/id_rsa
    ForwardAgent yes

Host C_D
    HostName addressD
    User usernameD
    IdentityFile ~/.ssh/id_rsa
    Port 22
    ProxyCommand ssh -A -W %h:%p C

Again, two problems:

  1. I need to load the key with ssh-agent first. Otherwise it prompts twice for the password.
  2. It takes ages (24 seconds) to connect. I should mention here, that I'm on Windows using mobaXterm, in case this is responsible for the 24 seconds.

There is one final catch: Forwarding the Agent does not seem to be safe according to https://heipei.github.io/2015/02/26/SSH-Agent-Forwarding-considered-harmful/. So a solution which avoids forwarding the agent would be nice.

Edit:

After the remarks from @jakuje I've modified the config file to:

Host C
    HostName addressOfC
    User usernameC
    IdentityFile ~/.ssh/id_rsa

Host C_D
    HostName addressD
    User usernameD
    IdentityFile ~/.ssh/id_rsa
    Port 22
    ProxyCommand ssh -W %h:%p C

Running ssh -vvv C_D i get the following log (MobaXterm 7.4):

OpenSSH_6.2p2, OpenSSL 1.0.1g 7 Apr 2014
debug1: Reading configuration data /home/mobaxterm/.ssh/config
debug1: /home/mobaxterm/.ssh/config line 24: Applying options for C_D
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Executing proxy command: exec ssh -W addressOfD:22 C
debug1: permanently_drop_suid: 1000
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/mobaxterm/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/mobaxterm/.ssh/id_rsa type 1
debug1: identity file /home/mobaxterm/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5*
debug2: fd 5 setting O_NONBLOCK
debug2: fd 4 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "addressOfD" from file "/home/mobaxterm/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/mobaxterm/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: zlib@openssh.com,zlib,none
debug2: kex_parse_kexinit: zlib@openssh.com,zlib,none
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 zlib@openssh.com
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 zlib@openssh.com
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 135/256
debug2: bits set: 533/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA [...]
debug3: load_hostkeys: loading entries for host "addressOfD" from file "/home/mobaxterm/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/mobaxterm/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'addressOfD' is known and matches the RSA host key.
debug1: Found key in /home/mobaxterm/.ssh/known_hosts:1
debug2: bits set: 515/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/mobaxterm/.ssh/id_rsa (0x20072e98), explicit
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred hostbased,publickey,password,keyboard-interactive
debug3: authmethod_lookup publickey
debug3: remaining preferred: password,keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/mobaxterm/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp [...]
debug3: sign_and_send_pubkey: RSA [...]
debug1: Enabling compression at level 6.

Here it pauses for about 22 seconds.

debug1: Authentication succeeded (publickey).
Authenticated to addressOfD (via proxy).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: x11_get_proto: /bin/xauth  list :0.0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 1
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: X11 forwarding request accepted on channel 0
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0

Edit 2:

I tried the ssh config setup under Ubuntu 16.04 and did not get the 24 second delay (the connection was established in under 2 seconds). I downloaded the latest version of MobaXterm (v9.1) and only the first connection establishment was slow. I also tested MobaXterm on Windows 10 (before: Windows 7), same result. So I guess this is a problem with Windows/MobaXterm or whatever it is using under the hood.

Conclusion:

It seems the best I can do is to move to Linux (bit overkill) or forward the ssh agent (if I'm feeling lucky) or sit back and wait a bit. In both cases I have to load the ssh key in advance to avoid having to enter its password twice.

  • can you use localcommand to open a port-forwarded connection to D after connecting to C to set up the tunnel. – Jasen Jul 16 '16 at 11:06
  • hmm "It should not be used for interactive commands." I guess not a solution. – Jasen Jul 16 '16 at 11:09
2
  1. I need to load the key with ssh-agent first. Otherwise it prompts twice for the password.

You don't need it. If your key does have passphrase, it is useful.

  1. It takes ages (24 seconds) to connect. I should mention here, that I'm on Windows using mobaXterm, in case this is responsible for the 24 seconds.

Connecting takes some time. If you want to get it faster (for separate connections, use ControlMaster option).

 ProxyCommand ssh -A -W %h:%p C

You don't need the agent forwarding here. The authentication is always done from your local computer.

 ForwardAgent yes

Neither here, unless you want to use your keys from the server C.

  • I don't understand your first remark. Although, perhaps I wasn't clear: I can use the same key to log in to C and D. Using the mentioned config file entry, I am prompted twice to enter the same password. This shouldn't be necessary. Concerning the 24s for connecting: If I connect via the first method "ssh -A -t usernameC@C ssh usernameD@D" (having loaded the key beforehand) it takes less than 2 seconds. So 24 seconds are just too much. Thanks for the rest of the corrections. Tested and confirmed. – nx105 Jul 16 '16 at 14:18
  • 1
    1) You mean passphrase for a key? You have two possibilities. Start the agent with your system and add the key there (once a boot) or remove the passphrase from the key (lower security). 2) So check the debug log (ssh -vvv for both proxy command and your command) with time marks. – Jakuje Jul 16 '16 at 14:24
  • 1) Pity there isn't a third solution. I guess I'll opt for the first one (mobaXterm has an option for this). 2) It gets stuck between debug1: Enabling compression at level 6. and debug1: Authentication succeeded (publickey). The rest runs through very quickly. I will edit my question post and add the full log. – nx105 Jul 16 '16 at 16:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.