Imagine the fun you can have with multiple [SSH] forwards! 

  

 If you've set up your <tt>.ssh/config</tt> as in the tip above, you can spare yourself typing the same parameters to set up tunnels in the same manner. <tt>-L 5000:localhost:110</tt> translates to <tt>~LocalForward 5000 localhost:110</tt>. If you'd like to have <tt>-g</tt> taken care of as well, add <tt>~GatewayPorts</tt>. <tt>-f</tt> and <tt>-N</tt> don't have corresponding options, but those wouldn't be very useful anyway. 

  

 !!! [X] Connection Forwarding 

  

 If you use the <tt>-X</tt> option to ssh(1), you will enable [X]-connection forwarding. This is essentially a reverse port forward with a few added effects: for instance it will set your <tt>DISPLAY</tt> EnvironmentVariable on the remote end to something like <tt>localhost:15</tt>. Most of the time you won't need to mess with xhost(1) or xauth(1) either. If you've set up your <tt>.ssh/config</tt> as discussed above, you can spare yourself typing <tt>-X</tt> every time using the <tt>ForwardX11</tt> directive. 

 * <tt>Major opcode of failed request: 20 (X_~GetProperty)</tt> 

  

 In that case you will also find by invoking xdpyinfo(1) from the remote machine that they can only use a fraction of the extensions your [XServer] offers. This is because the new default is to use untrusted [X11] cookies for forwarding connections. You need to invoke ssh(1) with the <tt>-Y</tt> option for [X11] forwarding, or add <tt>ForwardX11Trusted yes</tt> to your configuration. Since one of the affected extensions is <tt>XRENDER</tt>, which greatly reduces the bandwidth required to draw AntiAliasedFonts and accelerates their rendering, it is unclear why anyone would ever use untrusted cookies. 

  

  

 !!! STDIN Forwarding 

  

 [SSH] forwards its standard input to be the standard input of a command executed on the remote machine. You can use this to do some pretty cool things like stream tar(1) archives across a network to eliminate any overhead with copying many small files: 

  

 The possibilities are endless. In the standard case of using a slave [SSH] connection to some gateway, nothing stops you from using a <tt>~ProxyCommand</tt> in the alias configured for the gateway – so you can build an entire cascade of [SSH] tunneled connections from one gateway to the next. Of course eventually the onion of tunnels wrapped around the connection will push the latency up to and the throughput down to unworkable levels. 

  

  

  

 Configure your [SSH] client to keep making sure it can still talk to the remote host if it hasn't received any data in a while. This is done by setting <tt>~ServerAliveInterval</tt> in your <tt>.ssh/config</tt> to how many seconds of silence the client should wait. The <tt>~ServerAliveCountMax</tt> directive defines how many attempts to get a reaction from the remote host may go unanswered before the [SSH] clients decides the connection has been lost. If you specify 5 seconds and 3 tries, a dead connection will be detected in 15 seconds. 

  

 The default values are 0 seconds, which means never, and 3 tries. 

 Cipher blowfish # SSH1 

 Ciphers blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc # SSH2 

 </verbatim> 

  

  

 !!! [SSH] for apt-get(8) 

  

 If you try and run apt-get(8) without a terminal or the right paths, it won't be able to find dpkg(8) or display debconf information. This is the way I've found (useful for remote upgrading of machines – note, only do this off security or your own repository…)