!!! [SSH]ing to not directly reachable hosts 

  

 Suppose you have a shell account on <tt>safe</tt>, a machine on a [NAT]ted [LAN] without a public [IP] address assigned to it. Let's also suppose you can [SSH] to the publicly visible gateway router of that [LAN], <tt>door</tt>, and that on this machine a copy of nc(1) (aka netcat) is installed. With the aid of a config file alias for the [NAT]ted host and a config directive called <tt>~ProxyCommand</tt>, you can easily set yourself up such that [SSH]ing to <tt>safe</tt> is no different from [SSH]ing to any publicly visible box: 

  

  

 If you have the sshd(8) running on a different port than 22 (the standard [SSH] port) on <tt>safe</tt>, you need to change the argument to nc(1) accordingly, of course. Note the "<tt>-q 0</tt>" argument to netcat – without this, you will likely end up with stale netcat processes on the intermediary machine. Now, you can just <tt>ssh safe</tt> and [SSH] will transparently invoke another copy of itself that connects to <tt>door</tt> and uses the netcat installed there to establish a connection from <tt>door</tt> to <tt>safe</tt>. netcat's STDIN/STDOUT is tunnelled back to your via your slave [SSH] connection to <tt>door</tt>, across which the primary [SSH] process can then communicate with the sshd(8) on <tt>safe</tt>. 

  

 Note that since the master [SSH] process is only communicating with the proxy process, it has no way of knowing the [IP] address of the remote host it is talking to. Since its address is needed to verify its host key's authenticity, it is advisable to use a <tt>~HostName</tt> directive for the proxied host to specify its address. Since the address is not otherwise used, you ''can'' leave it out or even enter something fake – you'll just get a complaint from [SSH].