Penguin
Recent Changes
Annotated edit history of SSHNotes version 81, including all changes. View license author blame.
Rev Author # Line
74 AristotlePagaltzis 1 See the [SSHErrors] page for resolving [SSH] related errors, and [SSHKeys] for information about setting up [SSH] key logins.
69 MattBrown 2
3
74 AristotlePagaltzis 4 !!! Config file aliases
69 MattBrown 5
74 AristotlePagaltzis 6 To ease your life, you can put all settings for a particular host in your <tt>.ssh/config</tt>. Say you would normally use the following command to connect to somewhere:
69 MattBrown 7
74 AristotlePagaltzis 8 <verbatim>
9 ssh me@some.long.winded.fqdn.name.here.com
10 </verbatim>
69 MattBrown 11
74 AristotlePagaltzis 12 That's a lot to type. If you spell this out in configuration directives (see ssh_config(5)) it looks like this:
69 MattBrown 13
74 AristotlePagaltzis 14 <verbatim>
15 Host foo
16 User me
17 HostName some.long.winded.fqdn.name.here.com
18 </verbatim>
69 MattBrown 19
74 AristotlePagaltzis 20 From then on it's enough to simply say this:
69 MattBrown 21
74 AristotlePagaltzis 22 <verbatim>
23 ssh foo
24 </verbatim>
69 MattBrown 25
74 AristotlePagaltzis 26 Much better! You can also use wildcards for the hostname. A <tt>Host *</tt> stanza defines directives that should be in effect for ''all'' [SSH] connections.
69 MattBrown 27
28
74 AristotlePagaltzis 29 !!! Control character
69 MattBrown 30
74 AristotlePagaltzis 31 <tt>~~</tt> is the control character for [SSH]. Once you get into control mode there are a few things you can do – exit the current ssh session (use <tt>~~.</tt>) or background it (<tt>~~^Z</tt>). <tt>~~?</tt> will give you a list of control sequences. This is discussed in ssh(1), of course.
69 MattBrown 32
74 AristotlePagaltzis 33 <tt>~~</tt> is only special if it is pressed after a newline, otherwise a literal "~~" character is sent (as it is if the following character is not one of the meaningful ssh commands). <tt>~~~~</tt> after a newline will also force a "~~" char to be sent. If you are [SSH]ed from another [SSH] connection, you can do <tt>~~^Z</tt> after a newline to make the remote ssh client get the background command, instead of your local client.
69 MattBrown 34
35
74 AristotlePagaltzis 36 !!! Virtual Terminal
69 MattBrown 37
74 AristotlePagaltzis 38 Ever tried to do reconnect a [Screen] session over [SSH]?
69 MattBrown 39
74 AristotlePagaltzis 40 <verbatim>
41 ssh joe@home.sweet.home screen -rx
42 Must be connected to a terminal.
43 </verbatim>
44
45 This is [Screen] complaining, not [SSH]. Well, you can provide a terminal easily by using the <tt>-t</tt> switch: <tt>ssh -t user@host screen -rx</tt>
69 MattBrown 46
47 Combined with [SSHKeys] it's excellent for reconnecting those [IRC] sessions with a single key/buttonpress.
48
49 Unfortunately this option cannot be set from your ssh_config(5).
70 AlastairPorter 50
51
74 AristotlePagaltzis 52 !!! Connecting to two hosts behind one [IP] address
53
54 You may connect directly to a number of machines [NAT]ted behind a single [IP] address using different ports.
70 AlastairPorter 55
56 After the first host has been connected to, subsequent hosts will give a warning:
57
74 AristotlePagaltzis 58 <verbatim>
59 Warning: the RSA host key for 'example.com' differs from the key for the IP address '1.1.1.1'
60 Offending key for IP in /home/joerandom/.ssh/known_hosts:2
61 Matching host key in /home/joerandom/.ssh/known_hosts:7
62 Are you sure you want to continue connecting (yes/no)?
63 </verbatim>
70 AlastairPorter 64
74 AristotlePagaltzis 65 To avoid this, use the <tt>~HostKeyAlias</tt> keyword to specify an alternative name rather than the hostname to use for finding the host key in your <tt>known_hosts</tt> file. Set up aliases for each host/port combination in your <tt>ssh_config</tt> as explained above in <i>Config file aliases</i>, then assign them each unique key aliases:
72 LawrenceDoliveiro 66
74 AristotlePagaltzis 67 <verbatim>
68 Host foo
69 HostKeyAlias example_com_9622
70 HostName example.com
71 Port 9622
76 BrianSzymanski 72 CheckHostIP no
74 AristotlePagaltzis 73 Host bar
74 HostKeyAlias example_com_9623
75 HostName example.com
76 Port 9623
76 BrianSzymanski 77 CheckHostIP no
74 AristotlePagaltzis 78 </verbatim>
76 BrianSzymanski 79
77 AristotlePagaltzis 80 Note that your system's configuration (in <tt>ssh_config</tt>) might default to <tt>CheckHostIP</tt> being off, which means you can safely omit those lines from your configuration. [YMMV].
72 LawrenceDoliveiro 81
74 AristotlePagaltzis 82 Now instead of typing <tt>ssh -p 9622 example.com</tt>, you say <tt>ssh foo</tt> and ssh(1) will figure things out correctly.
69 MattBrown 83
74 AristotlePagaltzis 84 A clumsier workaround is to add <tt>~UserKnownHostsFile ~~/.ssh/known_hosts_<i>hostname</i></tt> to each ssh_config(5) stanza, so a different list of known hosts is used for each host.
69 MattBrown 85
74 AristotlePagaltzis 86 If you just need a quick and dirty workaround, add <tt>~StrictHostKeyChecking no</tt> to each stanza in your ssh_config(5). This will still produce a warning, but will connect without any input needed, while decreasing your security.
69 MattBrown 87
88
74 AristotlePagaltzis 89 !!! Port Forwarding
69 MattBrown 90
74 AristotlePagaltzis 91 [SSH] can forward ports across its encrypted tunnel. F.ex., if you issue <tt>ssh -L 5000:very.remote:80 user@host.remote</tt> [SSH] will be listening on port 5000 on <tt>localhost</tt>. By connecting to this port you get a connection tunneled to <tt>host.remote</tt>, which will then establish a connection to port 80 on <tt>very.remote</tt>. This is very helpful if <tt>very.remote</tt> lives behind a FireWall that blocks direct traffic, but will let you [SSH] to <tt>host.remote</tt>.
69 MattBrown 92
74 AristotlePagaltzis 93 By the same token, using <tt>ssh -L 5000:localhost:80 user@host.remote</tt> you can tunnel a connection from port 5000 on your own host to port 80 on <tt>host.remote</tt>, which for the purposes of the webserver on the other end will appear to come from that <tt>localhost</tt>.
69 MattBrown 94
74 AristotlePagaltzis 95 If you don't need the shell, and just want the tunnel, you can add options <tt>-f</tt> (go to background before command execution) and <tt>-N</tt> (don't execute remote command): <tt>ssh -f -N -L 5000:localhost:80 user@host.remote</tt> [SSH] will then effectively run as a daemon.
69 MattBrown 96
74 AristotlePagaltzis 97 If you add <tt>-g</tt>, your local end of the [SSH] tunnel will accept connections from anyone, not just <tt>localhost</tt>. Say there are two machines called <tt>host1.lan</tt> and <tt>host2.lan</tt> on a [LAN]. By doing
78 ShaneHowearth 98
69 MattBrown 99
74 AristotlePagaltzis 100 <verbatim>
101 host1$ ssh -f -g -N -L 5000:localhost:80 user@host.remote
102 host2$ lynx host1:5000
103 </verbatim>
69 MattBrown 104
74 AristotlePagaltzis 105 you have opened a connection from <tt>host2.lan</tt> to the webserver on <tt>host.remote</tt> without, in fact, connecting from <tt>host2.lan</tt> to <tt>host.remote</tt>.
69 MattBrown 106
107 Imagine the fun you can have with multiple [SSH] forwards!
108
74 AristotlePagaltzis 109 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.
69 MattBrown 110
74 AristotlePagaltzis 111 !!! [X] Connection Forwarding
69 MattBrown 112
74 AristotlePagaltzis 113 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.
69 MattBrown 114
74 AristotlePagaltzis 115 The [SSH] daemon on the remote machine must be configured to allow X11 forwarding. If it is disabled, you have to edit <tt>/etc/ssh/sshd_config</tt> and then restart sshd(8).
69 MattBrown 116
74 AristotlePagaltzis 117 Be aware that you will need the [X] libraries and utilites installed on the server even if you're forwarding clients from a headless server. On [Debian], you need the <tt>xbase-clients</tt> [Package]; on [FreeBSD], it’s <tt>xorg-clients</tt>. In general, you need whatever packages will give you the xhost(1) binary.
69 MattBrown 118
74 AristotlePagaltzis 119 If you are running OpenSSH 3.8 or newer, some [X] applications may give you one of these errors:
69 MattBrown 120
74 AristotlePagaltzis 121 * <tt>~BadWindow (invalid Window parameter)</tt>
122 * <tt>~BadAccess (attempt to access private resource denied)</tt>
123 * <tt>X Error of failed request: ~BadAtom (invalid Atom parameter)</tt>
124 * <tt>Major opcode of failed request: 20 (X_~GetProperty)</tt>
69 MattBrown 125
74 AristotlePagaltzis 126 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.
69 MattBrown 127
79 JohnMcPherson 128 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.
69 MattBrown 129
130 !!! STDIN Forwarding
131
132 [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:
133
74 AristotlePagaltzis 134 <verbatim>
135 tar c sourcedir | ssh user@host tar xf -
136 </verbatim>
69 MattBrown 137
138 There are many other neat tricks that can be perfomed using this technique as well. The feature was inherited from rsh(1). If you are having problems with corruption when piping data via [SSH], you may find a solution on the [SSHErrors] page.
139
74 AristotlePagaltzis 140 In a rudimentary test involving about 200MB of variously sized files, the tar(1) stream finished in about 4:00 minutes, where <tt>scp -R</tt> took about 5:40 minutes. (That is even though it doesn't seem to establish a new connection for each file as ftp(1) does, nor have much overhead at all. So tar(1) could just be better at doing this than scp(1).)
141
69 MattBrown 142
143 !!! Executing the same command on multiple machines
144
74 AristotlePagaltzis 145 Check out the distributed shell, dsh(1). It lets you [SSH] to a set of drones and execute the same series of commands on all of them, watching the output as you go.
146
69 MattBrown 147
148 !!! [SSH]ing to not directly reachable hosts
149
74 AristotlePagaltzis 150 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:
69 MattBrown 151
75 AristotlePagaltzis 152 <pre>
153 # this stanza isn't necessary of course
154 Host door
155 Protocol 2
156 User me
157 ~HostName homelan.at.dsl.my.isp.com
158 # but this one is
159 Host safe
160 Protocol 2
161 User me
162 ~HostName 192.168.0.42
163 <b>~ProxyCommand ssh door nc -q 0 safe 22</b>
164 </pre>
69 MattBrown 165
74 AristotlePagaltzis 166 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>.
69 MattBrown 167
74 AristotlePagaltzis 168 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].
69 MattBrown 169
74 AristotlePagaltzis 170 Finally, remember that <tt>ssh foo nc bar 1234</tt> is just one example of what the proxy command could be. The only requirement is that it forward the traffic, whether that be a [TCP] connection or even anything else, to and from [SSH] over STDIN/STDOUT. You might even use something like <tt>~ProxyCommand pppd nodetach call <i>foo</i></tt> and have the remote getty(8) launch <tt>sshd -i</tt> on the incoming line, thus logging into a machine that's not even connected to the InterNet.
69 MattBrown 171
74 AristotlePagaltzis 172 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.
69 MattBrown 173
174
81 AristotlePagaltzis 175 !!! Improving the detection of lost connections / coping with flaky net links
69 MattBrown 176
74 AristotlePagaltzis 177 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.
69 MattBrown 178
179 The default values are 0 seconds, which means never, and 3 tries.
180
181 Pick these according to bandwidth, ping time to the server, and packet loss on your link.
74 AristotlePagaltzis 182
69 MattBrown 183
184 !!! Speeding up transfer rates
185
74 AristotlePagaltzis 186 [SSH] can use [gzip] compression on any connection, and will use a modest level by default. Compression is a great idea if you are forwarding [X] sessions on a dial-up or slow network. It can be turned on using the <tt>-C</tt> switch, or using <tt>Compression yes</tt> in your <tt>.ssh/config</tt>.
187
188 Changing your encryption cipher from the common default of DES or 3DES can speed things up as well. BlowFish and [AES] are faster, and new versions of [OpenSSH] default to BlowFish. The CommandLine switch to change the cipher is <tt>-c blowfish</tt>. For <tt>.ssh/config</tt> it depends on whether you are connecting with SSH1 or SSH2.
69 MattBrown 189
74 AristotlePagaltzis 190 <verbatim>
191 Cipher blowfish # SSH1
192 Ciphers blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc # SSH2
193 </verbatim>
69 MattBrown 194
79 JohnMcPherson 195 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 http://www.psc.edu/networking/projects/hpn-ssh/
69 MattBrown 196
74 AristotlePagaltzis 197 !!! [SSH] for apt-get(8)
69 MattBrown 198
74 AristotlePagaltzis 199 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…)
69 MattBrown 200
74 AristotlePagaltzis 201 <pre>
202 ssh root@<i>hostname</i> -t "su - -c 'apt-get update && apt-get upgrade'"
203 </pre>
69 MattBrown 204
205 ----
206 Part of CategorySecurity and CategoryNetworking

PHP Warning

lib/blame.php:177: Warning: Invalid argument supplied for foreach() (...repeated 11 times)