| Services | Software | Commentary | Design | Astral Musings |
Configuration tips
|
|
||||||||||||
| Secure Shell (SSH)
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.
ssh keys
$ 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
Enter passphrase for key '/home/usracct1/.ssh/id_dsa':
$ 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.
Server you want to connect to:
|
System you want to connect from:
|
|
|
|
ssh - multple keys
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.
$ ssh -l usracct3 192.168.2.23 -i .ssh/id_dsa2
$ cat .ssh/config Host 192.168.2.22 IdentityFile ~/.ssh/id_dsa Host 192.168.2.23 IdentityFile ~/.ssh/id_dsa2
$ ssh-add ~/.ssh/id_dsa2
Enter passphrase for /home/useacct1/.ssh/id_dsa2:
Identity added: /home/usracct3/.ssh/id_dsa2 (/home/usracct1/.ssh/id_dsa2) sshd - Keep alive, allowing session to stay open when inactive.
# 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
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
# cat /etc/ssh/sshd_config | grep KeysFile #AuthorizedKeysFile .ssh/authorized_keys
# 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
# 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% rpm -ivh openssh-server-2.9p2-7.i386.rpm % service sshd status % service start [first start will generate some keys] % service restart