Differences between current version and revision by previous author of SSHNotes.
Other diffs: Previous Major Revision, Previous Revision, 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 79 | Last edited on Sunday, August 10, 2008 9:41:08 pm | by JohnMcPherson | 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 cms-r7-113.cs.waikato.ac.nz
-add the following to /etc/hosts
-
-127.0.0.1 cms-r7-113.cs.waikato.ac.nz
-
-and construct your tunnel thus
-
-ssh -2 -q -f -N -g -L 80:cms-r7-113.cs.waikato.ac.nz:80 <username>@cms-r7-113.cs.waikato.ac.nz
-
-You will now be able to connect to
-<verbatim>
-cms-r7-113.cs.waikato.ac.nz/~username
-</verbatim>
!!! [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.
@@ -191,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.
