Differences between current version and predecessor to the previous major change of SSHNotes.

Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History

Newer page: version 81 Last edited on Sunday, April 3, 2011 2:22:11 am by AristotlePagaltzis
Older page: version 78 Last edited on Tuesday, May 13, 2008 5:09:43 pm by ShaneHowearth Revert
@@ -106,28 +106,8 @@
 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. 
-!! vhost workaround  
-When trying to connect to an apache server (through a firewall) that has multiple vhosts, you may be able to get the default page apache has been configured to serve, but nothing else.  
-On your localhost edit your /etc/hosts file and add the name of the machine you are trying to connect to over the tunnel.  
-eg. If you were trying to connect to  
-add the following to /etc/hosts  
-and construct your tunnel thus  
-ssh -2 -q -f -N -g -L <username>  
-You will now be able to connect to  
 !!! [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. 
@@ -144,8 +124,9 @@
 * <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. 
+If you are forwarding an X11 connection over a link with relatively high latency (such as [ADSL] rather than over a [LAN]), then you will also get a performance improvement by enabling compression (either Compression=yes in your config file, or the -C command-line option). See the section below for more on compression/transfer rates.  
 !!! 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: 
@@ -190,9 +171,9 @@
 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. 
-!!! Improving loss of connection detection / coping with flaky net links 
+!!! Improving the detection of lost connections / coping with flaky net links 
 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. 
@@ -210,8 +191,9 @@
 Cipher blowfish # SSH1 
 Ciphers blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc # SSH2 
+If you are transferring large files across a GigE [LAN], you will probably be limited by small buffers inside ssh preventing you from reaching anywhere close to line speed. There are patches available for improving performance on such LANs in several different ways (eg increasing these buffer sizes, disabling encryption if you trust the LAN, multi-threaded encryption) - see  
 !!! [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…)