Configuring sshd

The sshd daemon takes its configurations from the /etc/ssh/sshd_config file. As you can see later, most of the file is commented out. If you read the comments in the configuration file, you'll realize that most of these options are the default-compiled settings, but the settings are left in the file for reference. If you want to change how sshd behaves on your system, just remove the hash marks to uncomment a setting, and then change the setting from its default-compiled setting. Read through the sample file to see some of our suggestions for change:

   $OpenBSD: sshd_confg.v 1.59 2002/09/25 11:17:16 markus Exp $

   # This is the sshd server system_wide configuration file See
   # sshd_config(5) for more information.

   # This sshd was compiled with
   # PATH=/usr/local/bin:/bin:/usr/bin

   # The strategy used for options in the default sshd_config
   # shipped with OpenSSH is to specify options with their
   # default value where possible, but leave them commented.
   # Uncommented options change a default value.

   #Port 22
   #Protocol 2,1

This default setting indicates that when sshd runs, it first offers sessions in SSH v 2 protocol to the connecting client, and then falls back to the SSH v1 protocol if required by the client. SSH 2 is more secure than the older version 1, and v1 has many known vulnerabilities. The only reason to run it is that some older ssh-based commercial packages require it. Don't run SSH v1 on your server. If you uncomment and edit this line, you can force your SSH daemon to offer only SSH v 2 to incoming clients. To do this, remove the hash mark and the trailing ,1 so that the line simply reads Protocol 2.

   #ListenAddress 0.0.0.0
   #ListenAddress   : :

By default, the sshd service binds to all IP addresses associated with your server. If sshd is running on a firewall or on a multi-LAN server, you might choose to remove the hash mark and change the line ListenAddress 0.0.0.0 to something like ListenAddress 10.1.1.1 to restrict SSH logins to a particular side of your network.

   # HostKey  for protocol version 1
   #HostKey /etc/ssh/ssh_host_key
   # HostKeys for protocol version 2
   #HostKey /etc/ssh/ssh_host_rsa_key
   #HostKey /etc/ssh/ssh_host_dsa_key

   # Lifetime and size of ephemeral version 1 server key
   #KeyRegenerationInterval 3600
   #ServerKeyBits 768

   # Logging
   #obsoletes QuietMode and FascistLogging
   #SyslogFacility AUTH
   SyslogFacility AUTHPRIV
   #LogLevel INFO

   # Authentication:

   #LoginGraceTime 120
   #PermitRootLogin yes
   #StrictModes yes

   #RSAAuthentication yes
   #PubkeyAuthentication yes
   #AuthorizedKeysFile         .ssh/authorized_keys

The last two lines in the preceding code block enable key-based authentication. SSL, SSH, and other modern encryption methods use dual-key encryption, a method that requires both a public and a private key to encrypt and decrypt a secure session or data stream. If you turn on key-based authentication in sshd, you remove the username/password authentication step and allow access only with a known set of keys. This is not necessarily more secure, as it now ties security to the remote trusted host's own security. However, this setting is often the only viable solution if you need remote automation scripts and other back-end programs to log into systems without requiring a human to type in a password.

   # 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/ssh_known_hosts
   #RhostsRSAAuthentication no
   # similar for protocol version 2
   #HostbasedAuthentication no
   # Change to yes if you don't trust ~ /.ssh/known_hosts for
   # RhostsRSAAuthentication and HostbasedAuthentication
   #IgnoreUserKnownHosts no

   # To disable tunneled clear text passwords, change to
   #no here!
   #PasswordAuthentication yes
   #PermitEmptyPasswords no

   # Change to no to disable s/key passwords
   #ChallengeResponseAuthentication yes

   # Kerberos options
   #KerberosAuthentication no
   #KerberosOrLocalPasswd yes
   #KerberosTicketCleanup yes

   #AFSTokenPassing no

   # Kerberos TGT Passing only works with the AFS kaserver
   #KerberosTgtPassing no

   # Set this to 'yes' to enable PAM keyboard-interactive
   # authentication
   # Warning: enabling this may bypass the setting of
   # 'PasswordAuthentication'
   #PAMAuthenticationViaKbdInt no

   #X11Forwarding no
   X11Forwarding yes

The X11Forwarding yes setting permits users to tunnel server-side X11 client programs and output over SSH to the local X11 GUI (called the local X11 server). That is, you could ssh into a remote system, start the Mozilla browser from the command line on the server, and get the GUI window for the Mozilla program running on the remote server "painted" on your local desktop X GUI. Imagine being able to run GNOME, KDE, and Linux applications off your Fedora Core machine while sitting in front of a Windows PC in a lab across the country, or running a system load graph for each of your servers on your local desktop. This is a powerful feature. It's safe to leave this function enabled, even if you never use it. Just be aware that you might get an unexpected window on your local machine if you're issuing commands over an ssh session.

   #X11DisplayOffset 10
   #X11UseLocalhost yes
   #PrintMotd yes
   #PrintLastLog yes
   #KeepAlive yes
   #UseLogin no
   #UsePrivilegeSeparation yes
   #PermitUserEnvironment no
   #Compression yes

   #MaxStartups 10
   # no default banner path
   #Banner /some/path
   #VerifyReverseMapping no

   # override default of no subsystems
   Subsystem       sftp    /usr/libexec/openssh/sftp-server

The final line in the file turns on the sftp subsystem of sshd. It is enabled by default in most modern Linux distributions. If you can get into your server via ssh, then you can probably access sftp resources with the sftp client as well.

Configuring OpenSSH Services

Once you've determined that all the appropriate packages are on your system and made your basic sshd configuration file changes, it's time to check the server-side service. Everything you need to run OpenSSH services is managed by the sshd daemon. Verify that the daemon is running with the command

   #ps auxw|grep [s]shd
   root 3615   0.0 0.5 5100 1252 ? S 10:37 0:00 /usr/sbin/sshd

or the optional Red Hat command

   #/etc/init.d/sshd status
   sshd (pid 3615) is running...

If the daemon is running, you can use this command to stop and restart it in order to reload the changes in your config file:

   #/etc/init.d/sshd restart
   Stopping sshd:                             [ OK ]
   Starting sshd:                             [ OK ]

In fact, you can do this while connected to the server through an SSH connection, and never lose the session. Just another reason why OpenSSH tools are the new de facto standard for remote Linux/UNIX access.

Finally, you should ensure that sshd will come up when the machine is booted and when runlevels change. The easiest way to do this is with the init script control tool chkconfig. First, check the existing configuration for the sshd service:

   # chkconfig --list sshd
   sshd      0:off   1:off   2:on   3:on   4:on   5:on   6:off

Since most servers boot into runlevels 3 and 5 almost exclusively (on Red Hat-other distributions may use different runlevels), these settings are appropriate for almost all cases.

If you want to configure the server so that it will not run a service such as sshd at boot time, you can turn the service off in all runlevels like this:

   # chkconfig sshd off

Check it again:

   # chkconfig  --list sshd
   sshd      0:off   1:off   2:off   3:off   4:off   5:off   6:off

When you're ready to configure it to be on at boot time again, use chkconfig to turn the service on and verify that the runlevels are correct (most network services are configured to come up in either 2-5 or 3-5):

   # chkconfig sshd on
   # chkconfig --list sshd
   sshd    0:off   1:off   2:on   3:on   4:on   5:on   6:off

   # chkconfig sshd off

which will configure the daemon to be off at boot time or runlevel changes, and then run

   # /etc/init.d/sshd stop

   OR

   # service sshd stop

to gracefully shut down a running daemon, such as sshd, in real time (the latter is the optional Red-Hat-based init script usage). The opposite of these commands would be the usage of "on" and "start" respectively.

Key-Based Authentication for ssh, scp, and sftp

In some cases, you may prefer to enable key-based authentication rather than require users to type username/password pairs at login. As explained above, key-based authentication can be quite handy. If used by itself, it is less secure; however, it is sometimes the only way to automate systems smoothly and remove human intervention from the process.

To turn on key-based authentication, open the /etc/ssh/sshd_config file and locate the line beginning with #RSAAuthentication. Make sure that it is commented out, and that the PubkeyAuthentication line is active and set to yes:

   #RSAAuthentication yes
   PubkeyAuthentication yes
   AuthorizedKeysFile     .ssh/authorized_keys

After you change the configuration file, you'll need to restart sshd:

   # /etc/init.d/sshd restart
   Stopping  sshd:                               [ OK ]
   Starting  sshd:                               [ OK ]
   #

Now, when the user Mike requests ssh access, sshd will look in /home/mike/.ssh /authorized_keys to see whether this person has an authorized public key that can be trusted as Mike's key. How did the key get into his ~/.sshd/authorized_keys file in the first place? Someone put it there, probably either Mike or his root administrator.

Key Pairs

In order to work with key-based authentication, you must follow several steps. First, you need to generate a public/private key pair. Once you have a public key, you can put it into an ~/ .ssh/authorized_keys file (where ~ = /home/username/ ) so that you can access the account. To generate a key pair, follow this command sequence:

   $ ssh-keygen -t dsa -C "mike_home"
   Generating public/private dsa key pair.
   Enter file in which to save the key (/home/mike/.ssh/id_dsa):
   Enter passphrase (empty for no passphrase):
   Enter same passphrase again: <enter>
   Your identification has been saved in /home/mike/.ssh/id_dsa.
   Your public key has been saved in /home/mike/.ssh/id_dsa.pub.
   The key fingerprint is:
   f1:7b:a8:80:ca:6f:12:da:1f:87:e7:f9:6a:ab:98:36 mike_home
   [mike@localhost mike] $
   [mike@localhost mike] $ ls -la .ssh/
   total 20
   drwx------         2 mike     mike    4096 Jan 10 19:04 .
   drwx------         5 mike     mike    4096 Jan 10 18:55 ..
   -rw-------         1 mike     mike     672 Jan 10 19:04 id_dsa
   -rw-r--r--         1 mike     mike     599 Jan 10 19:04 id_dsa.pub
   -rw-r--r--         1 mike     mike     219 Jan 10 18:58 known_hosts

The output of ls --la.ssh/ shows the user Mike's private and public (.pub) dsa-based key files on his home machine. Assume that Mike needs to log into the remote system at work mydomain.com, and do so without a password. In order to do this, Mike's home public key needs to be placed in his ~/.ssh/authorized - keys file on the remote machine at work. First, from home, Mike prints his home dsa public key file to the screen:

   [mike@localhost mike]$ cat .ssh/id_dsa.pub
   ssh-dss
   AAAAB3NzaC1kc3MAAACBAPW0CP1/hI2gE/2Uk1lcaFPIvGC3DfCwHTP0x0NRJv5u
   Aws6W29pFp6yZc91vnBbnBbC0aN33DCZkMwfpFp08Y0QB0fpR8SRTXhTIVuC+Z2bTBM
   RZoWkEo9ZSA0ZG4Ro02fm21Mr6ez2b6/NXoyp4CzZeDgreC7IWTNv0qWLjD+yiUr
   AAAAFQDvC1cZ5P/i8g3cGEUqNEMxuif4JQAAAIBGBshp6bsM1be3VsTlDmBiCH+s
   XH6l1HSufcaflIL2GtQUyoTp8DGX0+JP7Uhk0XVlTBZfj6dx5h5GBQTzvbpUWafW
   UkVxad/ahS6mg1YQASgjUgI3rulz93xQoT6hkgEt90dIA1i6Axt/ajHK2E+wGsia
   S6CC876aQUTF5GUP1gAAAIEA8asyusN+QdTtjbEnCjtKkHEFZ2h+SDex6i4I+VUc
   XNCa7gILLj303N28WNz3fCDxDi0gr6wTlGD2Edm/1nfQ+IAzN+McRQupLjVM02MK
   e09XqeIw/+6XH8UDW4J/dFVq7eKaSTZt3mr92XdG5xipU/VddA4k2qKwq6m8UpxA
   knI= mike_home

Mike then highlights the public key with his mouse and copies the text. Next, Mike uses ssh to log into his remote account at work (a password is still required at this point):

   [mike@localhost mike]$ ssh mike@mydomain.com
   bob@mydomain.com's password:

Next, Mike edits his remote ~ /.ssh/authorized_keys file, or creates it if it does not exist:

   [mike@mydomain.com mike]$ vi .ssh/authorized_keys

Mike now pastes the copied text of his public key, saves the file, and exits the text editor. His account now looks as follows:

   [mike@mydomain.com mike]$  ls -la  .ssh/
   total 24
   drwx------     2 mike   mike    4096 Jan 10 19:35 .
   drwx-----x     6 mike   mike    4096 Jan 10 19:35 ..
   -rw-rw-r--     1 mike   mike     602 Jan 10 19:35 authorized_keys
   -rw-------     1 mike   mike     668 Jan 10 19:34 id_dsa
   -rw-r--r--     1 mike   mike     603 Jan 10 19:34 id_dsa.pub
   -rw-r--r--     1 mike   mike     223 Jan 10 18:36 known_hosts

The files look right, but the permissions are wrong. Both the authorized_keys file and the id_dsa (private key) should be readable only by the user who owns them. Use chmod authorized_keys to fix this:

   [mike@mydomain.com mike]$ chmod 700 .ssh/authorized_keys
   [mike@mydomain.com mike]$ Is   -la   .ssh/
   total 24
   drwx------     2 mike     mike         4096 Jan 10 19:35 .
   drwx-----x     6 mike     mike         4096 Jan 10 19:46 ..
   -rwx------     1 mike     mike         602 Jan 10 19:35 authorized_keys
   -rw-------     1 mike     mike         668 Jan 10 19:34 id_dsa
   -rw-r--r--     1 mike     mike         603 Jan 10 19:34 id_dsa.pub
   -rw-r--r--     1 mike     mike         223 Jan 10 18:36 known_hosts

Mike logs out of his remote work machine and then logs back in to see if the authorized_keys entry worked. If login no longer requires a password, then the key-based ssh authentication is working:

   [mike@mydomain.com mike]$ exit
   [mike@localhost mike]$
   [mike@localhost mike]$ ssh mike@mydomain.com
   [mike@mydomain.com mike]$

With this in place, Mike can now automate almost anything between his home and work account, whether it's pushing web content, bookmark files, or daily logs.

For example, Mike might set up a regular job that copies web content from his home machine to his work machine. The following crontab entry will tar-gzip Mike's home web content

every Sunday at 1:37 A.M. and scp it to his work's ~/BACKUPS/ directory:

   37 1 * * 1 tar czvf ~ /mike-web_backup_$(date +%Y-%m-%d).tgz ~ /web
         && scp -p ~ /mike-web_backup_$(date +%Y-%m-%d).tgz
         bob@mydomain.com:~ /BACKUPS/