40.3. Objective 4: Secure Shell (SSH)SSH, also known as Secure Shell, is an encrypting version of the old rsh/rlogin/rcp suite. The primary use for SSH is encrypted shell sessions to remote hosts, but it can also be used to copy files and to tunnel other protocols. SSH is a server/client protocol offering sshd as the server and the ssh command as the client. The client connects to the server, they establish an encrypted session, and then the server demands authentication before finally logging in the client. For file copying in the manner of RCP, the secure replacement is the scp command. In addition to simple login sessions and file copying, SSH can also provide transparent port forwarding, and as an extension of this, X authentication and forwarding. When you have an SSH session , you can start an X client on the remote machine, and the X Window System protocol will travel encrypted over your connection and display on your local machine without the need for settings such as DISPLAY=foo:0 or the xhost or xauth commands. The implementation of SSH generally used on Linux systems is OpenSSH. 40.3.1. Installation and ConfigurationOpenSSH may or may not be installed on your system by default. When it is installed, it generates a host key for your machine. This key will serve to authenticate your host in subsequent SSH sessions. Then you will typically want to create SSH authentication keys for your own personal account, as well as the root account. After that, you as the administrator should review the configuration of sshd, to see that you are comfortable with it. The standard place for the central configuration of OpenSSH is the /etc/ssh directory. Here you will find the server configuration in sshd_config and default client configuration in ssh_config. Here are some highlights from the server configuration as installed on Debian: # What ports, IPs and protocols we listen for Port 22 Protocol 2 Port 22 is the standard port for the SSH protocol. Version 2 of the protocol is the most secure, whereas Version 1 has some flaws that were hard to overcome. It is recommended to accept only Version 2 now. To support both versions, put 2, 1 on the Protocol line. # Authentication: PermitRootLogin yes PubkeyAuthentication yes # rhosts authentication should not be used RhostsAuthentication no # Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh_known_hosts # (for protocol version 2) HostbasedAuthentication no # To disable tunneled clear text passwords, change to no here! PasswordAuthentication yes OpenSSH ignores the host operating system setting for permitting root logins on nonconsole terminals. Instead, OpenSSH has its own setting in PermitRootLogin. The PubkeyAuthentication setting allows or denies login authentication based purely on public-key cryptography. You can trust this as far as you can trust the host on which the private parts of those keys are stored (unless they are protected by passphrases, in which case you can trust them a bit further). IgnoreRhosts allows or denies the old-fashionedand very insecurerhosts authentication, used by the rsh/rlogin/rcp suite. This way of authenticating connections is not only insecure, but also made obsolete by public-key authentication. If you combine rhosts authentication with public-key authentication of the connecting host, on the other hand, it's immediately a lot more securebut host keys cannot be protected by passphrases. That is what HostbasedAuthentication is for. It is still not recommended, but in some settings it is appropriate. PasswordAuthentication allows or denies authentication by those old-fashioned passwords. You can trust this if you can trust your users to not use silly passwords and to not jot them on Post-it notes and hang them on their screens. X11Forwarding yes If X11 forwarding is enabled on the server and your client requests it (using the -X option), the client and server will forward traffic from a port on the server side to your DISPLAY. The server sets the remote DISPLAY to the local port that sshd forwards to your local screen. To make this secure, the server will install an xauth authentication token that it will enforce for all new connections. This, in addition to port forwarding, which we'll return to, makes OpenSSH a very versatile remote terminal program. 40.3.2. Generating and Using KeysIn most cases, you will want to generate SSH keys for your own accounts and perhaps your root account. Use ssh-keygen for this. A reference for the needed commands is at the end of this section (the short of it is: run ssh-keygen -t dsa and press the Enter key at all the prompts). This key allows passwordless remote logins, as long as PubkeyAuthentication is enabled. In ~/.ssh/id_dsa.pub you can find the public key you've generated through ssh-keygen. You need to transport this key to the remote machine. Because it's a public key, it does not need to be secure. On the remote machine, put the key into ~/.ssh/authorized_keys. Once the key is in that file, all users who have the private-key counterpart will be able to log in to that remote account without a password. Sometimes it makes sense to let users log in to other machines without having to set up authentication themselves. The easiest way to do this is to create and modify all the files on one machine, as described in the following procedure, and then use tar and ssh in a pipe to transfer them to the other hosts.
After the previous steps are carried out on all the hosts, all ordinary users should be able to use ssh back and forth between all the nodes with no other authentication. However, this is not true for the root user; she still needs user key or password authentication. Trusting a remote root is far more serious than trusting a mundane remote user.
40.3.3. ssh-agentssh-agent makes it practical to use passphrases on your private keys. The principle is to use ssh-agent to add your keys to a background agent on the system that will hold them in escrow. You give your passphrase only once: when you add the key. The agent will give the keys out to other processes owned by you that request the keys. You should be aware that the root user can also request the keys without your noticing, so you must trust the root user. The process is quite simple; start the agent and then add the passphrase you used to create the key: $ eval 'ssh-agent' Agent pid 11487 $ ssh-add Enter passphrase for /home/janl/.ssh/id_dsa: passphrase Identity added: /home/janl/.ssh/id_dsa (/home/janl/.ssh/id_dsa) By default, all your keys will be added. If several of your keys have the same passphrase, they will all be added without further questions. If they have different passphrases, ssh-add will be prompted for them. If you include a file on the ssh-add command line, the key in that file will be added and the command will not prompt for keys. ssh-agent works by setting two environment variables: SSH_AUTH_SOCK, which names the socket on which to communicate with the agent, and SSH_AGENT_PID, which makes it easy to kill the agent. That is also why the PID shows up in the previous listing. The agent emits a shell script which, when evaluated, sets those variables correctly. Since using passphrases makes remote logins immeasurably more convenient, it may be a good idea to make it simple for your users to use passphrases by starting ssh-agent in their login scripts. It is probably not a good idea to put it in users' .bashrc or .login scripts, nor in the system /etc/profile. A good place to put it is in the systemwide Xsession scripts. Exactly which script is used to start an X session depends on which distribution and which desktop people use (KDE, GNOME, classical X, their own custom session). But on Debian and Red Hat, there are standard ways to do it. On Debian, if you put use-ssh-agent on a line by itself in /etc/X11/xdm/xdm.options, then when you log in with the X Window System, the script /etc/X11/Xsession.d/90xfree86-common_ssh-agent is run. It is reproduced here for convenience: STARTSSH= SSHAGENT=/usr/bin/ssh-agent SSHAGENTARGS= if grep -qs ^use-ssh-agent "$OPTIONFILE"; then if [ -x "$SSHAGENT" -a -z "$SSH_AUTH_SOCK" -a -z "$SSH2_AUTH_SOCK" ]; then STARTSSH=yes if [ -f /usr/bin/ssh-add1 ] && cmp -s $SSHAGENT /usr/bin/ssh-agent2; then # use ssh-agent2's ssh-agent1 compatibility mode SSHAGENTARGS=-1 fi fi fi if [ -n "$STARTSSH" ]; then REALSTARTUP="$SSHAGENT $SSHAGENTARGS $REALSTARTUP" fi This script first looks for the systemwide use-ssh-agent setting, then very carefully checks whether any of the ssh-agent-related variables are set already, because if they are set, an agent should already be running. Finally, it redefines REALSTARTUP so that the agent will be started later in the Debian scripts. The script could just as well have run eval 'ssh-agent' directly. On Red Hat, you can do the same by adding the preceding script to /etc/X11/xinit/xinitrc.d, but it should be changed to run the agent directly, and Red Hat does not set up all those environment variables. In Fedora Core 1, the agent is started automatically. But none of these automated systems adds any keys to the agent. That means that users will still be prompted for a passphrase. Users can run ssh-add (perhaps in their .bashrc files) and enter their passphrases once into a shell terminal, each time X starts. It may be a good idea to doctor the automated X setup further with an ssh-add command. If run without a terminal, ssh-add pops up a graphical passphrase input box. 40.3.4. Other ssh TricksOpenSSH respects TCP wrapper configurations, described in the following Objective. sshd, like the Linux login program, denies logins when the file /etc/nologin exists. When remotely maintaining hosts in a way that may disrupt user activities, you should create this file with a helpful explanation of what is happening. This will stop all nonroot logins, by whichever method, so you can do your maintenance undisturbed. The file is usually created by the shutdown command as well, to keep users from logging in while the machine is shutting down. The file is removed after a complete boot. # cat >/etc/nologin If there is any reason to suspect that your maintenance work can disconnect you or break the login mechanism, you should keep multiple login sessions open while doing the work. Test logging in again before closing them. Otherwise, doing a tiny PAM change that breaks all authentication could force you to reboot the machine into single-user mode to recover. Consider scheduling an at job to remove /etc/nologin at a particular time, in the event you log yourself out. Such a job can be handy when restarting sshd from a remote location as well. The only thing left in this Objective is one of the handiest features of SSH: port forwarding.
|