HOWTOlabs  
 Services     Software     Commentary     Design     Astral Musings   
Secure Shell (SSH)
Configuration tips
  printable 
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.
Related


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
  #PermitRootLogin yes
+ PermitRootLogin no
# diff -r1.1 sshd_config
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 explpicit 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
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
news:x:9:13:news:/etc/news:
uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
gopher:x:13:30:gopher:/var/gopher:/sbin/nologin
ftp:x:14:50:FTP User:/public/users/ftp:/sbin/nologin
mysql:x:27:27:MySQL Server:/var/lib/mysql:/bin/bash
nscd:x:28:28:NSCD Daemon:/:/sbin/nologin
apache:x:48:48:Apache:/var/www:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
vcsa:x:69:69:virtual console memory owner:/dev:/sbin/nologin
rpm:x:37:37::/var/lib/rpm:/sbin/nologin
haldaemon:x:68:68:HAL daemon:/:/sbin/nologin
netdump:x:34:34:Network Crash Dump user:/var/crash:/bin/bash
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
rpc:x:32:32:Portmapper RPC user:/:/sbin/nologin
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
mailnull:x:47:47::/var/spool/mqueue:/sbin/nologin
smmsp:x:51:51::/var/spool/mqueue:/sbin/nologin
pcap:x:77:77::/var/arpwatch:/sbin/nologin
# 101 - webteam
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.

[root@calpop home]# ls
admin  dkelly  fredness  jamie  support
[root@calpop home]# 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 ...
zap technologies