Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I am trying to set up an ssh proxycommand, where the user name at the final host is different from the user name at the original host. I am logged in on firstHost as username and want to effectively run this command:

ssh middle ssh othername@target

I would like to be able to do this with

ssh target

This post suggests using a proxycommand that does an ssh to target to run nc on target. That makes the connection, but does not use the passwordless ssh that I set up. Is there a way to get this to work with passwordless ssh? (And is there a reason to use nc instead of making the proxy command ssh middle ssh othername@target?)

.ssh/config on firstHost looks like this:

Host middle
HostName middle.domain<br/>

Host target
User othername
Proxycommand ssh middle ssh othername@target.domain nc localhost 22

The output of ssh -vv target from firsthost is

debug2: ssh_connect: needpriv 0
debug1: Executing proxy command: exec ssh middle ssh othername@target.domain nc localhost 22
debug1: identity file /home/username/.ssh/identity type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/username/.ssh/id_rsa type 1
debug1: identity file /home/username/.ssh/id_dsa type -1
debug1: loaded 3 keys
login banner from middle
login banner from target
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug2: fd 5 setting O_NONBLOCK
debug2: fd 4 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: 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,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
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-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes256-ctr
debug2: kex_parse_kexinit: aes256-ctr
debug2: kex_parse_kexinit: hmac-sha1
debug2: kex_parse_kexinit: hmac-sha1
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_init: found hmac-sha1
debug1: kex: server->client aes256-ctr hmac-sha1 none
debug2: mac_init: found hmac-sha1
debug1: kex: client->server aes256-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<4096<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 275/512
debug2: bits set: 1987/4096
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'target' is known and matches the RSA host key.
debug1: Found key in /home/username/.ssh/known_hosts:16
debug2: bits set: 2053/4096
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug2: cipher_init: set keylen (16 -> 32)
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug2: cipher_init: set keylen (16 -> 32)
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/username/.ssh/identity ((nil))
debug2: key: /home/username/.ssh/id_rsa (0x2b9c1e95c4d0)
debug2: key: /home/username/.ssh/id_dsa ((nil))
login banner
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: An invalid name was supplied
Hostname cannot be canonicalized

debug1: An invalid name was supplied
Hostname cannot be canonicalized

debug1: An invalid name was supplied
Hostname cannot be canonicalized

debug2: we did not send a packet, disable method
debug1: Next authentication method: publickey
debug1: Trying private key: /home/username/.ssh/identity
debug1: Offering public key: /home/username/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: /home/username/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
share|improve this question
    
So if you followed that post, and it works aside from the authentication, it sure would be nice if you posted the exact config you used and the output of ssh -vv target so we can see the error messages. The examples suggested by that answer should work just fine, and is nearly identical to my working configs. I could answer the why Proxycommand part, but I figure the main part of your question is about the authentication networking in the multi-hop setup. –  Zoredache Nov 14 '12 at 1:58
    
Check superuser.com/a/484979/163736 for an example on how to use an SSH tunnel. You will have to adjust your local SSH config regarding the server (to instead connect to a given localhost port), but as the server is not directly accessible anyways, that shouldn't be a problem. –  Claudius Nov 14 '12 at 18:07

1 Answer 1

alias sshTarget="ssh -tA middle ssh -l othername target"

Update

ssh -N -L 4441:othername:22 middle 
scp -P 4441 /documents/foo localhost:/backup/
share|improve this answer
    
That works fine for ssh to target, but does not allow scp target:file local_file to work. –  Troy Daniels Nov 14 '12 at 17:20
    
I see no mention of scp in your question. Try to ask about the problem rather than the wrong solution you have tried. See update. –  Ярослав Рахматуллин Nov 14 '12 at 23:07

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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