SSH notes
Contents
- 1 SSH Config
- 2 RSA versus DSA keys
- 3 SSH Chaining
- 4 share an existing open SSH session with other SSH tools
- 5 Share X11 desktops
- 6 Using `dd` and `ssh` to copy a disk image over a network
- 7 VPN over SSH
- 8 Remote Server Security Enhancement with SSH Keys
- 9 Turn off remote host identity check of known_hosts
- 10 regain terminal control from a locked SSH session
- 11 SSH for Windows
- 12 MindTerm SSH client Java Applet
SSH Config
See SSH config for information on configuring the ssh client and sshd server.
RSA versus DSA keys
Use RSA
- There are not current patents for either RSA or DSA.
- RSA is the default for OpenSSH.
- The default RSA key length of 2048 bits is much longer than the maximum key length of 1024 bits for DSA.
SSH Chaining
SSH Chaining allows you to create a chain SSH logins through an intermediate gateway. You can do it all in one line if you specify the -t option. The following example connects to a server at 192.168.1.100, which is accessable only from example.com.
ssh -t noah@example.com "ssh noah@192.168.1.100"
This speeds up additional connections to the same host because the client does not have to create a new socket connection and it does not have authenticate to the remote host.
WARNING! There is a dangerous side effect to using this. If you 'exit' from the first shell (master) it will hang until all the other shells have also exited. If you force the shell to exit by killing it with `kill -9` or by closing its xterm window then it will kill every other shell that was using the shared connection.
Add these lines to your local client ~/.ssh/config to enable connection sharing:
Host * ControlMaster auto ControlPath ~/.ssh/master-%r@%h:%p
You can share a single mouse and keyboard seamlessly between two X11 servers. You must have `x2x` installed on the remote machine. This example lets you access a monitor located to the left (west) of your main monitor. When you move the mouse to the left edge of the main screen if will show up on the right edge of the remote X11 server.
ssh -f -Y noah@server.example.org x2x -west -to :0.0
You may need to specify the full path to x2x as /usr/bin/x2x or /usr/bin/X11/x2x.
Using `dd` and `ssh` to copy a disk image over a network
dd if=/dev/sdb0 | ssh noah@server.example.org "dd of=ops-tools.img"
Using `ssh` to copy files through a DMZ gateway to a machine behind a firewall
This example copies a directory, pictures/ to a tarball on the remote server.
tar c pictures/ | gzip -c - | ssh user@192.168.1.100 "dd of=pictures.tar.gz"
This makes use of `ssh` chaining to copy a file. This doesn't require a tunnel, but it requires that keys be setup between the DMZ gateway and the server on the remote LAN.
This example copies a file called pictures.tar.gz and requires a key between 208.77.188.166 and 192.168.1.100:
dd if=pictures.tar.gz | ssh user@208.77.188.166 "ssh user@192.168.1.100 \"dd of=pictures.tar.gz\""
You can't use the '-t' option for chaining `ssh` commands because this will cause one of the `ssh` commands to attempt to read the password from the output of `dd`. As far as I can tell there is no way to handle this situation with password authentication. Only public keys work in this situation. For example, this will not work:
dd if=pictures.tar.gz | ssh -t user@208.77.188.166 "ssh user@192.168.1.100 \"dd of=pictures.tar.gz\""
VPN over SSH
OpenSSH versions starting with v4.3 have a built-in VPN feature.
# cat /proc/sys/net/ipv4/ip_forward 0 # echo 1 > /proc/sys/net/ipv4/ip_forward # cat /proc/sys/net/ipv4/ip_forward 1
remote server sshd_config
Check the settings on the remote server in /etc/ssh/sshd_config. If you change any settings be sure to reload the config settings by running `/etc/init.d/sshd reload`. The sshd_config file should have these settings:
# Allow either layer 2 or layer 3 (point-to-point ''tun'' or ethernet ''tap''). PermitTunnel yes
remote server bridge setup
# tunctl -b -t tap_vpn_0 tap_vpn_0 # brctl addbr br_vpn_0 # brctl addif br_vpn_0 eth0 # brctl addif br_vpn_0 tap_vpn_0 # brctl show bridge name bridge id STP enabled interfaces br_vpn_0 8000.0016366db84d no eth0 tap_vpn_0 # ifconfig tap_vpn_0 up # ifconfig br_vpn_0 up
local client bridge setup
# tunctl -b -t tap_vpn_c0 tap_vpn_c0 # brctl addbr br_vpn_c0 # brctl addif br_vpn_c0 eth0 # brctl addif br_vpn_c0 tap_vpn_c0 # brctl show bridge name bridge id STP enabled interfaces br_vpn_c0 8000.0016cbaa352a no eth0 tap_vpn_c0 # ifconfig tap_vpn_c0 up # ifconfig br_vpn_c0 up
Remote Server Security Enhancement with SSH Keys
You can make port forwarding even more secure by limiting what a privileged account can do. When you add a key to authorized_key you may pass parameters to fine tune the connection. This can be used to restrict what the client is allowed to do. On the remote server, add the following to ~username/.ssh/authorized_keys:
from="192.168.1.69",command="/bin/false",no-pty,no-X11-forwarding,no-agent-forwarding,no-port-forwarding,permitopen="localhost:143" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA8XIr8LEXdvc4VZEvNenWkJrerTzNhqTT7QvCD+Y2EjCUPQwfBcSnvhY3oasNigNonghQFqm7/HqWBLpcN+4mqDUrXrEdj6HQmHvCV6WozNUVb5jjiyQ/JF4hqcQd6oelCkVw8wD32I2jlYqydpqOGY4xqakWDAfm3SOx5il3Kl49mKCg5B3GQPexhTujaTT3y/Q1eeT3zGpHE9Mp7k20X8rMxSjp5ncLAmdf42fRh05HY5f1GrupQIEdi0/TDcPNWL1ml89zttrDOLgDnwny7P0x2jmcX41cSxL/8svER7BAk2sroyQe6L21pJ7o2MYz1IwnsQgji/GjJoaA7hTNCQ== username@client.example.com
- from="192.168.1.69": accept connection only from the given IP address
- command="/bin/false": forces this command to be run no matter what is passed via ssh from the client
- no-pty: never allocate a PTY for interactivity
- no-X11-forwarding: No X11
- no-agent-forwarding: we don't want or need ssh-agent
- no-port-forwarding: prevent ssh -R ...
- permitopen="localhost:143": allow only localhost connections to port 143 for `ssh -L` requests
Turn off remote host identity check of known_hosts
WARNING! This totally defeats detection of man-in-the-middle attacks.
You want to not be bothered by error messages like this:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)!
Sometimes you want to connect to a remote host where you do not care about the host identification. This note shows how to automatically ignore the identity checks that the SSH client normally enforces.
One common situation where identity checks will make your life miserable is when connecting to a host that is running multiple SSH services on different ports. SSH only stores the remote host's name and identity key in ~/.ssh/known_hosts. It does not store which port number an identity key is associated with. SSH will complain about a remote host's identification changing even though it might be a different service on a different port. Another common situation where identity checks become tiresome is when working with a vitualization system that frequently destroys hosts and rebuilds them from scratch.
There are, of course, ways to get around these tricky situations without completely defeating the identification safety checks, but this note is about the dumb way to do things. The trick is to tell SSH not to ask to store the remote host's identity key and to use an empty known_hosts file. The two options to override are StrictHostKeyChecking and UserKnownHostsFile. The following example shows how to connect to a remote host while ignoring host identification:
ssh -o "StrictHostKeyChecking no" -o "UserKnownHostsFile /dev/null" noah@192.168.1.100 ssh -p 2222 -o "StrictHostKeyChecking no" -o "UserKnownHostsFile /dev/null" noah@192.168.1.100
If you want to live dangerously you can put these options in your SSH client config ~/.ssh/config.
StrictHostKeyChecking no UserKnownHostsFile /dev/null
You may want to put them under a specific Host section so that these options are only disabled for specific hosts. For example, you may want to disable host key checks only for virtual machine guests that you frequently rebuild. In the next example I assume that the 192.168.100.0/24 network is where I assign virtual machines.
Host 192.168.100.* StrictHostKeyChecking no UserKnownHostsFile /dev/null
Finally, nobody told you to do this, and don't say I didn't warn you.
regain terminal control from a locked SSH session
Press Enter then type '~.'. In other words:
<ENTER>~.
SSH for Windows
Putty is the best free SSH client for Windows. You can also use Cygwin, but the ANSI terminal emulation isn't as good unless you start the X11 server and run xterm.
MindTerm SSH client Java Applet
MindTerm_2.1 (non-commercial). This was the last free version of MindTerm.
mindterm.jar
Put this applet on a web page and point the <applet> "archive" attribute to the URL of the JAR file:
<applet archive="mindterm.jar" code="com.mindbright.application.MindTerm.class" width="620" height="440"> <param name="te" value="xterm-color"> <!-- "vt102" --> <param name="fs" value="18"> <param name="gm" value="80x32+0+0"> <param name="port" value="22"> <param name="cipher" value="blowfish"> <!-- "des" --> <param name="usrname" value=""> <param name="sepframe" value="false"> <param name="quiet" value="false"> <param name="cmdsh" value="false"> <param name="verbose" value="true"> <pa ram name="autoprops" value="none"> <param name="idhost" value="false"> <param name="alive" value="10"> <param name="appletbg" value="white"> </applet>
<include iframe src="http://www.noah.org/engineering/mindterm/mindterm_iframe.html" width="660" height="480px" />