How to Set Up and Use SSH — Step 1

How to Set Up and Use SSH
Step 1 — Administrative Work

Configure the Server and Client

Configure the service by modifying /etc/ssh/ssh_config and /etc/ssh/sshd_config on all hosts as follows:

/etc/ssh/ssh_config is used by local users connecting from this host to some remote server. Outbound connections. Put the following in that configuration file:

# Only the more secure SSH2 protocol
Protocol 2 
# Allow the user to tunnel X applications
# through SSH.  Read "man ssh_config" first.
# Yes, there is a security issue.  However,
# very carefully read its description.  It is
# an additional problem if the attacker is able
# to subvert Unix file system security on one
# of the hosts.  But if the attacker is able
# to do that, I have far worse problems that
# must be fixed NOW.
ForwardX11 yes

/etc/ssh/sshd_config controls how this server handles connection requests from remote users. Inbound connections. Put the following in that configuration file:

# Only the more secure SSH2 protocol
Protocol 2 
# If you list users allowed to connect via SSH,
# then they will be the only users allowed to
# authenticate to SSH.  THIS IS OPTIONAL, you
# do NOT need to include an AllowUsers line!
# If you do, these will be the only users allowed
# to authenticate.  If you do not include this
# line, then ALL users other than root will be
# allowed to authenticate.  Also see "AllowGroups",
# "DenyUsers", and "DenyGroups" in "man sshd_config".
AllowUsers joe jane ....
# Only accept authentication via cryptographic
# challenge-response.  The remote client must have
# cryptographic keys.
PasswordAuthentication no
# Do not allow root login -- first login as ordinary
# user, then su to root
PermitRootLogin no
# By defaults, SSH servers based on OpenSSH attempt
# a double DNS lookup: from IP to FQDN and then back
# from the resulting FQDN to IP.  If the result differs
# from the original IP address, this might indicate
# possible attack and the connection might be dropped.
# The problem is that this introduces a significant
# delay when you're connecting from an ISP that has
# not fully configured their DNS.  So, you *may* want
# to do this:
UseDNS no
# Specify how to run sftp
Subsystem sftp /usr/libexec/sftp-server

Collect host public keys

You could collect host public keys with the following command on a small network. The parameters need to list every SSH server as both simple hostname and fully-qualified domain name, as well as their IP addresses, so this could quickly lead to a lot of typing:

# ssh-keyscan  host1  host1.example.com  10.0.0.1 \
               host2  host2.example.com  10.0.0.2 \
               [.... and so on ....] \
               hostN  hostN.example.com  10.0.0.N  >  /etc/ssh/ssh_known_hosts

For a solution that scales well to a typical organization, first create a file, let's say /tmp/hostlist, containing all hostnames, all fully-qualified domain names, and all IP addresses, one item per line, for all of your SSH servers. Then run the following command:

# ssh-keyscan -f /tmp/hostlist > /etc/ssh/ssh_known_hosts

Once you have generated /etc/ssh/ssh_known_hosts, securely copy it to every host on which SSH will be used, even the workstations that will only be SSH clients.

You will generate new (and different!) SSH keys if you reinstall the operating system. That means that clients will refuse to connect to that freshly built SSH server, because it will look like it is a different host trying to masquerade. You will need to at least update that host's key. A simple yet safe procedure would be:

On some host, edit /etc/ssh/ssh_known_hosts and remove the entry for the freshly rebuilt server.
Re-run the above ssh-keyscan command to create an updated ssh_known_hosts file with the public key for the newly rebuilt server.
Securely copy the new /etc/ssh/ssh_known_hosts file into place. Note — since we have disabled root login over SSH, we have also disabled root use of scp. You must copy the files to all servers as a user, and then su to root on each server to install them.
At this point you may wish that you had thought to save a backup copy of those key files before starting... If you did, be careful about file permissions! The public keys are in files named *key.pub and must be mode 644 or 444. The private keys are in files named *key and must be mode 600 or 400.

Protect the user accounts

Now would be a good time to disable all unneeded accounts and make sure that all accounts still in use have strong passwords. Attackers are trying constantly to guess passwords.

The patterns of logins and passwords used in these guessing attacks can be interesting. It certainly would be a very bad idea for even an unprivileged user account to have a commonly used password. Extremely bad passwords include:

`password`	The obvious choice....
`admin`	Apparently a lot of people buy a Linksys or DLink or other home DSL/cable modem/firewall, and since `admin` is the default password, they think, "Hey, this is a security device, so `admin` must be a very secure password! So I will use it on every* account I have!"*
Joe Account	The term for when the login is the same as the password: if my login is `cromwell` then my password is also `cromwell.` Another obvious guess is that it's a "Joe+pw Account", the password is the login with `pw` added to the end.
`secret, forgot, iforgot, letmein, ...`	And other obvious choices....

Disable unused accounts

Lock the password, meaning replace the password hash in /etc/shadow with an invalid string so that there is no such thing as a valid password for that user. On Linux:
# passwd -l username
On other Unixes (BSD, Solaris) you may need to carefully edit /etc/shadow (Solaris) or /etc/master.passwd (BSD) and replace the password hash for the user with some other string. Simply inserting LOCKED as the initial part of the string will suffice. From:
cromwell:$2a$06$5Fkvg4EFsRCk8d234s....
to:
cromwell:LOCKED$2a$06$5Fkvg4EFsRCk8d234s....
For defense in depth, also replace that user's login shell with something that exits immediately and is not a shell. On Linux:
# chsh -s /bin/false username
On Solaris:
# chsh -u username
and then specify /bin/false
On BSD:
# chpass -s /bin/false username

Set file permissions, especially in NFS situations

At some point, SSH started refusing to work if the user's SSH key storage area was not securely configured. That's a good idea, although it tends not to explain just why it's failing and can be frustrating to debug.

The directory ~/.ssh should be mode 700, and the files in there containing private keys (id_dsa, id_rsa, identity) should be mode 600. Also, all these files must not be group-writeable. You may need to do something like this:
# chmod g-w /home/*/.ssh/*

The SSH daemon must be able to read those files, and since it is owned by root that normally is no problem. However, root is "squashed" to nobody by default on NFS mounts. So, make sure that NFS exports of user home directories are shared with the no_root_squash option.

Start an SSH agent at login time

Start an SSH agent at login time if your display manager does not already do this. Some, like Gnome's gdm display manager, tend to do this. Others, like KDE's kdm display manager, tend not to.

To test if this is needed, login to the graphical desktop as a user and run this command:

$ ssh-add -l

If an SSH agent is running, you will see the following and you don't need to do anything additional to start an agent for the user:

The agent has no identities.

However, if you see the following, you need to make a change to get an agent started for the users:

Could not open a connection to your authentication agent.

If you need to make a change to get an SSH agent running at login time, modify your display manager configuration. Depending on the display manager, this may take some investigation and experimentation.

For example, on Linux with KDE's display manager, the configuration is stored in /usr/share/config/kdm/. On OpenBSD, it is /usr/local/share/config/kdm/. The file Xsession originally contains a block reading as follows:

case $session in
  "")
    exec xmessage -center -buttons OK:0 -default OK "Sorry, $DESKTOP_SESSION is no valid session."
    ;;
  failsafe)
    exec xterm -geometry 80x24-0-0
    ;;
  custom)
    exec $HOME/.xsession
    ;;
  default)
    exec /usr/bin/startkde
    ;;
  *)
    eval exec "$session"
    ;;
esac

Change that code to the following, with the change highlighted:

case $session in
  "")
    exec xmessage -center -buttons OK:0 -default OK "Sorry, $DESKTOP_SESSION is no valid session."
    ;;
  failsafe)
    exec xterm -geometry 80x24-0-0
    ;;
  custom)
    exec $HOME/.xsession
    ;;
  default)
    exec ssh-agent /usr/bin/startkde 
    ;;
  *)
    eval exec "$session"
    ;;
esac

KDE may be changing its logic, at least in Mandriva's Cooker experimental distribution. I had to instead modify /etc/X11/wmsession.d/01KDE to refer to a simple shell script wrapper. For some reason I was unable to put the exec ssh-agent startkde line directly in that file:

NAME=KDE3
ICON=kde-wmsession.xpm
DESC=The K Desktop Environment
# EXEC = /usr/bin/startkde
EXEC = /usr/local/bin/start-kde
SCRIPT:
# exec /usr/bin/startkde
exec /usr/local/bin/start-kde

The script /usr/local/bin/start-kde looks like this:

#!/bin/sh
/usr/bin/ssh-agent  /usr/bin/startkde

If you are stuck with CDE and its dtlogin interface (decent technology for about 1990), you need to make a change within the large and complicated file /usr/dt/bin/Xsession. Look for a block like the below, and insert the highlighted code. Yes, you will probably have to specify the full path, and you very likely will have to do some research and experimentation to figure out just exactly where this goes. Hint: look for the reference(s) to dtsession

# 
# Session startup clients and args
# 
if [ "$SESSIONTYPE" = "altDt" ]; then
      dtstart_session[0]="/usr/bin/ssh-agent $SDT_ALT_SESSION"
      dtstart_hello[0]="$SDT_ALT_HELLO"
else
      dtstart_session[0]="/usr/bin/ssh-agent $DT_BINPATH/dtsession"
      dtstart_hello[0]="$DT_BINPATH/dthello &"
fi
dtstart_session[1]="$HOME/.xsession"
dtstart_session[2]="$HOME/.x11start"

Log out, log back in, and run this command:

$ ssh-add -l

You should see a message that the SSH agent has no identities. That's fine, that's what we were looking for. If you instead see a message that the SSH agent cannot be contacted, then you got something wrong. Either you didn't really log all the way out and back in again, or (more likely, I would hope) you didn't get things set up correctly.

Re-start the SSH service

Re-start the SSH service however your version of *nix does this. You may find that the following signals your SSH daemon to re-read its configuration while continuing to run:

# pkill -HUP sshd

If not, consult the below table or your system documentation. If you reconfigured your display manager, also restart that.

Linux	`# /etc/init.d/sshd restart`
Solaris and similar	`# /etc/init.d/sshd stop` `# /etc/init.d/sshd start`
BSD	`# pkill -TERM sshd` `# /usr/sbin/sshd`

Be careful — some of the above commands may terminate existing SSH connections. If you are trying to do this work remotely, it may leave you locked out of the system!

Now your system is considerably more secure.

It only uses the more secure SSH2 protocol.
If users had been asked, "Is the following the correct fingerprint for the server's public key?", they would have had no idea and simply answered "Yes". You have enabled the hosts to make the correct and cautious decision, so users are not asked a question they cannot really answer.
Even someone who knows your root password cannot authenticate as root. You must first authenticate as some user and then transition to root with the su command.
And even if someone knew both your UNIX login password and your root password, they still could not become root remotely! Password authentication is disabled for SSH. So, we need to set up public-key cryptographic authentication for every user. That's done in a later step, first we need to consider access control.