SSH (Secure Shell) is an industry standard protocol for creating a secure connection between two systems using a client server architecture. SSH provides mutual authentication, data encryption and data integrity. SSH is a secure replacement for telnet, rlogin, rsh, and rcp. SSH can also be used to tunnel other non encrypted applications.

More and more servers as well as workstation (in the Linux and MacOSX realms) now have SSH servers built in to them. This has caused a few problems in that the default setup of many of these reference implimentations is not configured to be very secure. While SSH is a very secure protocol it does require some changes to be made to increase it's security.

The reference implimentation of ssh is the OpenSSH open source suite developed by the OpenBSD Project.

There are two SSH protocols. The first is now referred to as SSH version 1 and is the original SSH protocol. A new version referred to as SSH2 (version 2) depricated the first. SSH version 1 is known to have a number of problems including the dreaded "man in the middle" attack (which allows a hacker to subvert it's secure communication channel).

A number of tools are based on the SSH protocol and are used to replace other common non secure tools

SCP (Secure Copy) is used to copy files securely over the network. It uses SSH for data transfer and authentication, and provides the same level of security as ssh2. SCP can be used with passwords or public key authentication. Also referred to as SCP2 (version 2)

SFTP is an FTP-like client that can be used for secure file transfer over the network. SFTP uses SSH to secure traffic. Even though SFTP works like ftp, it does not use the FTP daemon. Also referred to as SFTP2 (version 2)

SSH server configurations differ slightly based on the platform (Linux, Windows, MacOSX, BSD) but most require some form of hardening

A few typical problems with default SSH configurations.

• Allowing SSH version 1 access
• Allowing legacy support
• Allowing SSH as root (administrative) or other privileged user
• Low key strength
• Poor logging

The first step to configuring a SSH server to be more secure is to locate the configuration file

SUSE Linux
/etc/ssh/sshd_config

Fedora
/etc/ssh/sshd_config

OpenBSD
/etc/ssh/sshd_config

Hand compiled versions of the OpenSSH server will typically have the sshd_config file in the base install path. The config file is typically called "sshd_config". If you cannot locate it try searching the file system for it (find / -name sshd_config)

Once you have located the configuration file for the server you will want to open it with a text editor.

It is very important to restrict the use of protocol version 1. Almost every SSH client in the world support version 2 which is more secure. Remember that if you use protocol version 1 there is a significant problem with it that many consider is not fixable (thus the new version). SSH v1 also does not support many of the functions that SSH v2 does (such as environment passing, banner passing, multiple cipher types etc).

To restrict the SSH server to only allow protocol 2 find the following line in the configuration file:
Protocol: and make sure it reads Protocol 2 (remove any other protocols from the list)

This is critical. Many linux boxes are exploited today by allowing a remote user to attempt to "brute force" the root password by trying passwords over and over again. Typically if a user needs to SSH to the root account it is best to SSH in as a local user and issue the su command.

To restrict the SSH server disallow root logins locate the following line in the configuration file:
PermitRootLogin: and make sure it reads PermitRootLogin no (remove any # symbols in front and set the value to no)

By default any user that can have an interactive login (a shell) will be allowed to SSH. All typical user accounts and some system accounts fall in this catagory. Typically all users do not need SSH access and daemon/system accounts with shells should typically not be allows to SSH.

To restrict the SSH access to set users you can either Allow everyone and deny the specific account or deny all and allow only specific accounts. This can be done per user or per group

The following changes can be made to the default config to restrict user access.

• AllowUsers: a list of allowed users seperated by spaces (example: AllowUsers bob mary joe
• AllowGroups: a list of allowed user groups seperated by spaces (example: AllowGroups admins webadmins
• DenyUsers: a list of denied users seperated by spaces (example: DenyUsers oracle
• DenyGroups: a list of denied user groups seperated by spaces (example: DenyGroups users

  Any of the above settings can be made more advanced by restricting them to certain hosts or by using wildcards. (example: AllowUsers oracle@*.ku.edu restricting logins to the Oracle account to particular that particular user from a computer with an on campus DNS name.

  Additional Hardening

  There are additional steps that can be taken to harden access to your system.

  • Using TCPwrappers or IPChains/Tables to restrict what IP's can access your SSH port
    This will significantly cut down on the number of attacks against your system by only allowing users from known netblocks to attempt to connect
  • Run the SSH server on a non standard port
    While this won't help you very much it may cut down on the number of scripted brute force attacks on your system
  • Make users relay their connections
    Many sysadmins only allow SSH access from outside their network to one specific host that has been heavily secured. They then require users to SSH to that server and "bounce" to other servers from it
  Source
  Jeff Perry
  KU IT Security Office
  http://www.security.ku.edu