Section 40.3. Objective 4: Secure Shell (SSH)


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 Configuration

OpenSSH 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 Keys

In 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.

  1. Enable HostbasedAuthentication in /etc/ssh/sshd_config configuration files on all hosts.

    Your client configuration is in /etc/ssh/ssh_config. All hosts should have HostbasedAuthentication yes set there, and if they have a PreferredAuthentications statement, it should list hostbased first.

    The hosts' private keys should be readable only by root (otherwise the key would not be all that secret). Exactly what is needed to get SSH access to the keys depends on the version. If your SSH package includes an executable called ssh-keysign, it must be SUID root (it may not be installed that way, so you must make sure it is manually) and must provide the signing service that proves the host's identity in the key exchange. If the package does not contain ssh-keysign, make sure the ssh executable is SUID root through chmod u+s /usr/bin/ssh.

  2. On each host, create /etc/ssh/shosts.equiv. This file defines the hosts with equivalent security levels. In these files, enter the hostnames of all the hosts as they appear in reverse lookups. You can check that with the command getent hostsip-address. If the names you enter are not the right ones, the command will fail.

  3. On each host, create /etc/ssh/ssh_known_hosts. This file must contain the host key of all the hosts involved, under the names you used in the previous item. The easiest way to do this is to connect to all the hosts using the right names. After doing that, the user account that made the connections will have all the correct entries in his ~/.ssh/known_hosts file. Simply transfer the entries to the system file.

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.


Syntax

 ssh-keygen [-b bits] -t type ssh-keygen -p [ -t type ] ssh-keygen -q -t rsa1 -f /etc/ssh/ssh_host_key -C '' -N '' ssh-keygen -q -t rsa -f /etc/ssh/ssh_host_rsa_key -C '' -N '' ssh-keygen -q -t dsa -f /etc/ssh/ssh_host_rsa_key -C '' -N '' 


Description

ssh-keygen generates keys to identify hosts or users in the SSH protocol, Versions 1 and 2.

The first form creates a key. For Version 1 of the protocol, the type should be rsa1. For Version 2, it can be either rsa or dsa. The -b option sets the number of bits in the keys: 512 is the minimum while 1024 bits is the default and is considered "sufficient" today. In general, you can use as many bits as you like. During key generation, you will be asked to give a passphrase. A passphrase is different from a password in that it is a phrase, not simply a word, and is expected to be long. It is recommended that you pick a good long one.

The second form is used to change your passphrase.

The three last forms are used to generate the three different kinds of host keys. The first is for Version 1 of the protocol, the two others for Version 2. The -f option sets the output filename; if you omit the option, you will be prompted for the name. The -C option sets a comment on the key and -N sets the passphrase.


Examples

Generate a private key and then change its passphrase:

  • $ ssh-keygen -t dsa -b 2048

  • Generating public/private dsa key pair. Enter file in which to save the key (/home/janl/.ssh/id_dsa): Press the Enter key

  • Created directory '/home/janl/.ssh'.Enter passphrase (empty for no passphrase): passphraseEnter same passphrase again: passphrase

  • Your identification has been saved in /home/janl/.ssh/id_dsa.

  • Your public key has been saved in /home/janl/.ssh/id_dsa.pub.

  • The key fingerprint is:

  • c2:be:20:4a:17:2e:3f:b2:73:46:5c:00:ef:38:ca:03 janl@debian

  • $ ssh-keygen -p -t dsaEnter file in which the key is (/home/janl/.ssh/id_dsa): Press the Enter key Enter old passphrase: passphrase

  • Key has comment '/home/janl/.ssh/id_dsa'Enter new passphrase (empty for no passphrase): passphraseEnter same passphrase again: passphrase

  • Your identification has been saved with the new passphrase.

40.3.3. ssh-agent

ssh-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 Tricks

OpenSSH 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.


Syntax

 ssh -R|L port:host:host_port [user@]hostname [command] 


Description

When the main option is -L, ssh redirects traffic from the local port port to the remote machine and port given by host:host_port. The host is resolved by the resolver on the host you connect to. For security reasons, it binds only to the localhost address, not to any Ethernet or other interfaces you may have.

When a program connects to the localhost port, the connection is forwarded to the remote side. A very useful application for this is forwarding local ports to your company's mail server so you can send email as if you were at the office. All you have to do then is to configure your email client to connect to the right port on localhost. This is shown by the example in the following section.

When using -R, the reverse happens. The port port of the remote host's localhost interface is bound to and connections to it will be forwarded to the local machine given by host:host_port.


Example

Log in to login.example.com. Then forward connections to localhost port 2525 to port 25 on mail.example.com, which would otherwise reject relaying for you. The reason for binding to port 2525 is that one needs to be root to bind port 25.

 ssh -L 2525:mail.example.com:25 login.example.com 



LPI Linux Certification in a Nutshell
LPI Linux Certification in a Nutshell (In a Nutshell (OReilly))
ISBN: 0596005288
EAN: 2147483647
Year: 2004
Pages: 257

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net