My network layout is something like this:

Now Alice has access to SSH gateway (just gateway from now on) with:

ssh alice@external.ip

and the authorized keys file on the gateway looks like this

command="ssh -t alice@web" ssh-rsa ABCD...E== alice@somehost

so when Alice tries to connect to the Gateway with her private key, she actually gets connected to the Web server (the gateway pc can make a connection to the web server with a passwordless private key, so that stays transparent).

The question

  1. How can I set this up so that Alice will be able to scp things to web server too?

  2. I know this makes a separate connection, but is there any way for this to work as a normal ssh so that even something like -R12345:localhost:22 would work?


If you want to access a ssh server behind another ssh server, simply use "ProxyCommand". Example: add to .ssh/config

Host Alice  
   User myLoginAtAlice # optional 
   ProxyCommand ssh -o Compression=no gateway netcat -w 90 %h %p
   ServerAliveInterval 30
   Compression yes

Host gateway
   HostName gateway.public.ip
   User myLoginAtTheGateway # optional 
   Compression yes

Then, you can simply "ssh Alice" or "rsync" or "scp" directly using "Alice" as hostname. The magic is hidden to the client.

This allows you to quickly reconfigure your ssh in case your network topology/configuration changes, and just change the .ssh/config, instead of changing every script.

Explanation: ssh uses the command given as "proxy command" as transport instead of a direct TCP connection. Netcat is a network tool that (among millions of other features) simply redirects its stdin/stdout to the specified remote host. So, "ssh gateway nc sshserver 22" connects you to the ssh server of that machine. %h is the hostname and %p is the port. Such setup allows you to specify "Port N" to change the port without changing the ProxyCommand line.

I activate compression to the final computer and disable outer compression since compressing encrypted or compressed data does not reduce the data volume any further. Any fiddling with the compression settings is also of course optional.

  • One more question, rysnc doesn't work like that if I have a custom port to the gateway machine. Any thoughts on that. – zidarsk8 Oct 17 '12 at 8:33
  • Add "Port port_number" to the relevant section of the .ssh/config. Please read ssh_config and sshd_config man pages. They are plenty of information and they might bring you a lot of inspiration. – Raúl Salinas-Monteagudo Oct 17 '12 at 8:40
  • I meant, rsync doesn't work if a different port is specified. I have configured the port so that the connection works normally, but rsync is causing me problems. – zidarsk8 Oct 18 '12 at 20:38

I had exactly the same problem as this but I got it to work without radically changing everything.

All I did was add $SSH_ORIGINAL_COMMAND to the gateway authorized_keys to pass through anything down the the chain to the final server.

So this:

command="ssh -t alice@web" ssh-rsa ABCD...E== alice@somehost


command="ssh -q -t alice@web $SSH_ORIGINAL_COMMAND" ssh-rsa ABCD...E== alice@somehost

The -q is used to suppress the connection closed message from the end point machine so it does not end up in the local output if using redirection locally.

You can then use scp like this:

scp localFileName alice@exernal.ip:/path/on/end/point/remoteFileName

This has has the added advantage of letting users pass command through commands to the end point server and get the result back in their local session so they can redirect them into a file or a pipe them to a different program.

For example:

ssh -t alice@external.ip "ls -l" > tmp

This works because it seems sshd populates the environment variable $SSH_ORIGINAL_COMMAND with and command specified by the ssh client but I am not sure why this miraculously allows scp to pass through to the endpoint machine as well as commands.


Unfortunately the port-forwarding would not help to copy files directly from Alice's workstation to the web server using scp. In this SO post I explained why ssh (and scp as it utilizes the same authentication mechanisms) will not work for connections port-forwarded using ssh.

The option would be to set up a VPN server at machine acting now as SSH gateway, connect to it and then yo have direct access any machine behind the firewall.

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.