Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have the following ssh hop setup:

    localhost -> hub -> server

hubuser@hub accepts the public key for localuser@localhost.

serveruser@server accepts the public key for hubuser@hub.

So we are issuing ssh -t hubuser@hub ssh serveruser@server for connecting to server.

The problem with this setup is we can not scp directly to the server.

I tried creating .ssh/config file like this:

    Host server
      user serveruser
      port 22
      hostname server
      ProxyCommand ssh -q hubuser@hub 'nc %h %p'

But I am not able to connect (yigit is localuser):

    $ ssh serveruser@server -v
    OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012
    debug1: Reading configuration data /home/yigit/.ssh/config
    debug1: /home/yigit/.ssh/config line 19: Applying options for server        debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Executing proxy command: exec ssh -q hubuser@hub 'nc server 22'
    debug1: permanently_drop_suid: 1000
    debug1: identity file /home/yigit/.ssh/id_rsa type 1000        debug1: identity file /home/yigit/.ssh/id_rsa-cert type -1
    debug1: identity file /home/yigit/.ssh/id_dsa type -1
    debug1: identity file /home/yigit/.ssh/id_dsa-cert type -1
    debug1: identity file /home/yigit/.ssh/id_ecdsa type -1
    debug1: identity file /home/yigit/.ssh/id_ecdsa-cert 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_5*
    debug1: Enabling compatibility mode for protocol 2.0        debug1: Local version string SSH-2.0-OpenSSH_6.1
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug1: kex: server->client aes128-ctr hmac-md5 none
    debug1: kex: client->server aes128-ctr hmac-md5 none        debug1: sending SSH2_MSG_KEX_ECDH_INIT
    debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
    debug1: Server host key: ECDSA cb:ee:1f:78:82:1e:b4:39:c6:67:6f:4d:b4:01:f2:9f
    debug1: Host 'server' is known and matches the ECDSA host key.
    debug1: Found key in /home/yigit/.ssh/known_hosts:33
    debug1: ssh_ecdsa_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_REQUEST sent
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug1: Authentications that can continue: publickey
    debug1: Next authentication method: publickey
    debug1: Offering RSA public key: /home/yigit/.ssh/id_rsa
    debug1: Authentications that can continue: publickey
    debug1: Trying private key: /home/yigit/.ssh/id_dsa
    debug1: Trying private key: /home/yigit/.ssh/id_ecdsa
    debug1: No more authentication methods to try.
    Permission denied (publickey).

Notice that it is trying to use the public key localuser@localhost for authenticating on server and fails since it is not the right one. Is it possible to modify the ProxyCommand so that the key for hubuser@hub is used for authenticating on server?

share|improve this question
1  
Use an SSH agent, add all your keys. –  Zoredache Nov 6 '12 at 16:35
    
@Zoredache not possible with our usage scenario. –  yigit Nov 6 '12 at 16:37
    
Why is that not possible? AFAIK, that is the only solution. –  Zoredache Nov 6 '12 at 18:14

1 Answer 1

You can use -i in the ProxyCommand to specify a keyfile to use for the connection from localhost to hub. You can use IdentityFile to specify a keyfile to use for the connection from localhost to server

Both keyfiles need to be located on localhost. This setup will not need any of the two keyfiles to be located on hub.

share|improve this answer
    
sorry but we didn't want to distribute the key for each server to users. –  yigit Dec 8 at 12:02
    
@yigit Do you want the keys to be stored on hub? If you do that, you could easily end up with a setup where any of the users could copy the files from hub to their client machine. In that case you would gain no security compared to putting the keys on the client machines in the first place. Also, by placing the keys on hub, it would mean that any attacker somehow managing to take control of hub would have easy access to server as well. –  kasperd Dec 8 at 15:18

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.