HOWTOlabs.net - Secure Shell Configuration Tips

Secure shell (ssh) allows remote terminal sessions using secure encryption. ssh requires a target host machine to be running a service (sshd) that listens for incoming ssh connections. Beyond remote terminal functions, ssh and a family of similar commands offer secure file transfer (scp, sftp), and connection tunneling features.

Traditional telnet doesn't encrypt sessions which is fine for routine tasks. System administrators are encourgaed to use ssh for sensitive tasks instead of telnet. Systems that run particularly critical services are often configured to block unnecesary ports except that used by ssh (typically port 22) to further harden a system's security.

Elsewhere

First decide if you want to provide a passphrase. For command shell operations a passpharase is wise. If unattended background tasks are to be performed then use an empty passphrase.

$ ssh-keygen -t dsa

  Generating public/private dsa key pair.
  Enter file in which to save the key (/home/usracct1/.ssh/id_dsa): 
  Enter passphrase (empty for no passphrase): 
  Enter same passphrase again: 
  Your identification has been saved in /home/usracct1/.ssh/id_dsa.
  Your public key has been saved in /home/usracct/.ssh/id_dsa.pub.
  The key fingerprint is:
  9c:e4:de:38:38:cb:a2:b2:63:8f:19:71:1b:fa:a4:81 usracct1@c5ip21.sf.zaptech.org

$ scp .ssh/id_dsa.pub usracct2@192.168.2.22:.ssh/authorized_keys

  usracct2@192.168.2.22's password: 
  id_dsa.pub  100%  621  0.6KB/s  00:00    

$ ssh -l usracct2 192.168.2.22

If you supplied no passphrase, that's it - you should be at usracct2's remote shell. Otherwise you get a prompt for passphrase ...

  Enter passphrase for key '/home/usracct1/.ssh/id_dsa':

If passphrase was used, it can be temporarily 'remembered' during an interactive shell session using ssh-agent / ssh-add.

$ exec /usr/bin/ssh-agent $SHELL

  [ this will create a new shell process ]

$ ssh-add

  [ default, this will scour your default key file names and prompt for any passwords they require ] 

$ ssh -l usracct2 192.168.2.22

Shell session now has cached keys for automatic use until you exit session.

It is possible to use multiple keys but it is tricky. Remote login and other commands expect keys to be in files with default names. With multiple keys typically other file names are used which means extra parameters need to be specified to use the additional keys for remote commands.

On server, just add new files like ~/.ssh/authorized_keys2, ~/.ssh.authorized_keys3, ...

With client you will need to specify which key to apply to connection. For example, if you had a server at 192.168.2.23 with usracct3, the client should use the following assuming a key was generated in ~/.ssh/id_dsa2 file.

Elsewhere

Eddie On Everything

# diff -r1.1 sshd_config

  101c101
  < #TCPKeepAlive yes
  ---
  > TCPKeepAlive yes
  106c106
  < #ClientAliveInterval 0
  ---
  > ClientAliveInterval 300

sshd - Disabling remote root access, allowing less encryption

Unlike telnet, which historically never allows remote root login, ssh typically comes pre-installed with remote root access enabled (1). In some trusted environments relaxing the protocal to allow the older less secure protocal 1 may be helpful (1). Directives in sshd.config control these.

# diff -c -r1.1 /etc/ssh/sshd_config

  39c39
  < PermitRootLogin no
  ---
  > PermitRootLogin no
  ---
  14,15c14
  < #Protocol 2,1
  < Protocol 2
  ---
  > Protocol 2,1

1) remote root access and protocal 1 should NOT be enabled in insecure environments.

sshd - limiting access by IP address

# ls -l /etc/host*

  -rw-r--r--  1 root root  17 Jul 23  2000 host.conf
  -rw-r--r--  1 root root 177 Aug 12 09:23 hosts
  -rw-r--r--  1 root root 194 Aug 18 18:39 hosts.allow
  -rw-r--r--  1 root root 357 Aug 18 18:38 hosts.deny

# cat hosts.allow

  # hosts.allow   This file describes the names of the hosts which are
  #               allowed to use the local INET services, as decided
  #               by the '/usr/sbin/tcpd' server.

  sshd: 172.16.4.0/255.255.255.128

# cat hosts.deny

  # hosts.deny    This file describes the names of the hosts which are
  #               *not* allowed to use the local INET services, as decided
  #               by the '/usr/sbin/tcpd' server.
  #
  # The portmap line is redundant, but it is left to remind you that
  # the new secure portmap uses hosts.deny and hosts.allow.  In particular
  # you should know that NFS uses portmap!

  sshd: ALL

Note the file name for authorized keys. If not explicitly set it is usually .ssh/authorized_keys

# cat /etc/ssh/sshd_config | grep KeysFile

  #AuthorizedKeysFile     .ssh/authorized_keys

Look for user accounts, typically those with UID 5XX

# cat /etc/passwd

  root:x:0:0:root:/root:/bin/bash
  bin:x:1:1:bin:/bin:/sbin/nologin
  daemon:x:2:2:daemon:/sbin:/sbin/nologin
  ...
  fredness:x:500:500::/home/fredness:/bin/bash
  admin:x:501:501::/home/admin:/bin/bash
  jamie:x:502:502:Jamie Wieferman:/home/jamie:/bin/bash
  upload:x:503:503:Support Uploads:/public/users/ftp:/bin/bash
  dkelly:x:504:504::/home/dkelly:/bin/bash
  ntp:x:38:38::/etc/ntp:/sbin/nologin
  support:x:505:505::/home/support:/bin/bash

Now check the likly folders of these for .ssh directory.

# cd /home; ls

  admin  dkelly  fredness  jamie  support

# find . -iname ".ssh*"

  ./support/.ssh
  ./fredness/.ssh

Now check any found .ssh directory for presence of file authorized_keys. Users with this file are able to login without using a password if they also have matching keys configured on their client. Note: chicken and the egg, must have access to host without keys to set it up to allow access with keys. Beware, if you are on a fresh system without keys you won't be able to login! Also, if you client is compromised (you lost it, or left it on over lunch) someone can gain access to remote host without needing a password! Consider simply limiting IP addresses allowed to connect via SSH only to known secure locations. Passwords is turns out are a GOOD thing.

sshd - Legacy

Install ssh servce

% rpm -ivh openssh-server-2.9p2-7.i386.rpm

% service sshd status

% service start

  [first start will generate some keys]

% service restart

Recent Linux distros (e.g. RH 7.X) are increasingly including ssh terminal in their default installs. Other platforms are just now being provisioned with ssh tools ... :w