SSH Securing

What is SSH.. ?

• Secure Shell or SSH is a network protocol that allows data to be exchanged using a secure channel between two networked devices. Used primarily on Linux and Unix based systems to access shell accounts,
• SSH was designed as a replacement for Telnet and other insecure remote shells, which send information, notably passwords, in plaintext, leaving them open for interception. The encryption used by SSH provides confidentiality and integrity of data over an insecure network, such as the Internet.
• SSH uses public-key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user, if necessary.
• SSH is typically used to log into a remote machine and execute commands, but it also supports tunneling, forwarding TCP ports and X11 connections; it can transfer files using the associated SFTP or SCP protocols.
• SSH uses the client-server model.

The standard TCP port 22 has been assigned for SSH servers to be contacted on.

• A SSH client program is typically used for establishing connections to an SSH daemon accepting remote connections. Both are commonly present on most modern operating systems, including Mac OS X, Linux, FreeBSD, Solaris and OpenVMS. Proprietary, freeware and open source versions of various levels of complexity and completeness exist.

Pros and Cons..

Advantages

• The company Data Fellows have commercialized SSH into a range of products under the F-secure name. Secure VPN tunnels are also on offer.

• Since this software was developed outside the U.S., it does not fall within U.S. Government export restrictions, unless resold by a U.S. vendor.

• Encryption protocols used: RSA public key, Triple DES, IDEA, Blowfish, …

• Tunnelling of static TCP ports works well and can be automated.

• Three types of trust exist: shosts, rhosts compatible and RSA. Use shosts rather than rhosts. RSA authentication is stronger (using a private/public key system to identify peers), bt bypasses the username/password authentication of UNIX.

• Supports strong authentication systems such as SecurID, S/Key and also Kerberos and TIS

• SOCKS5 proxy aware.

Disadvantages

• Port ranges & dynamic ports can’t be forwarded.

• No “scp” on Windows versions.

• SSH1 daemon:

Cannot restrict what ports may or may not be forwarded, per user.

When a user is authenticated by password, the client’s RSA identity is not verified (against ssh_known_hosts). The verification only takes place when hosts trust is used.

 

How do I secure SSH..?

How you secure SSH will depend on your specific needs, so the first step is to consider your current use of SSH. Are you a roadwarrior and connecting to your servers from different computers or IP addresses, do all the users of the system really need SSH?

It is better to make the changes locally, as you might lock yourself out while reconfiguring your network.

Step 1 : Secure the default SSH configuration.

You can find more detailed information on debiansec or OpenSSH, this basic steps are:

a) Don’t allow root to remote login

PermitRootLogin no

It is safer to login as another user and use su.

b) Limit the users or groups that can login in remotely.

AllowUsers me
AllowGroups mygroup
DenyUsers paul
DenyGroups paulsgroup

Unless you are a ISP you can normally limit the users that can login to a few. You can also limit your users to certain machines or hosts.

c) Allow only Protocol 2:

Protocol 2

Protocol 1 is less secure and obsolete.

d) Use PubkeyAuthentication authentication instead of passwords:

PubkeyAuthenticationPasswordAuthentication No
ChallengeResponseAuthentication no

Instead of using a password to login, a keypair is placed on the server and the client. The client can prompt for a paraphrase, but no password is sent over the network. If you connect from several computers, you have to have the key on each one or carry it around in a USB stick.

e) Change the default port 22 to something higher

Port 2899

This makes it only one step “harder” for a determined hacker (all he has to do is scan your ports), but it does help with most automated bot attacks, most scripts check only for port 22 because scanning ports is time consuming. This trick alone will empty most of your logs of attack junk.

f) don’t listen on all addresses if posible:

ListenAddress 192.168.1.5

Step 2: Re-configure your firewall – block those connections in the first place
There are several ways of doing this. The easiest way is to limit connections to certain IP’s or subnets. This may not be practical if you are constantly on the road and need SSH access, more complex set ups like port knocking are also possible.

• Configure your firewall to allow only certain IP’s (or subnets) if possible.
• Install some nice brute force attack detectors – there are several packages that can detect a brute force attack and block those IP’s automatically.

Step 3: Extra security – One time passwords and port knocking

The steps mentioned above will clear up your logs and make your system more secure. But there are certain scenarios that could benefit from some extra security work. If you have many users that must have access from anywhere in the world (including unsecured computers), and having them carry their key in a USB stick is not practical, you can make them use one time passwords, libpam-opie:

Use OPIE one time passwords for PAM authentication. A one time password is useful to avoid having your password sniffed and reused if you log in via an unencrypted channel or from a compromised system. The PAM module enables OPIE for programs such as SSH which use PAM for authentication.

Another very interesting concept is Port Knocking:

port knocking is a method of externally opening ports on a firewall by generating a connection attempt on a set of pre-specified closed ports. Once a correct sequence of connection attempts is received the firewall rules are dynamically modified to allow the host which sent the connection attempts to connect over specified port (s).

In other words, your SSH port is closed, until you send a specific secret combination of packets. So even a hacker would have a hard time finding your SSH port in the first place.

SSH Keygen

How does it work ..?

• ssh-keygen generates, manages and converts authentication keys for ssh.
• ssh-keygen can create RSA keys for use by SSH protocol version 1 and RSA or DSA keys for use by SSH protocol version 2.
• The type of key to be generated is specified with the -t option. ssh-keygen is also used to generate groups for use in Diffie-Hellman group exchange (DH-GEX).
• Each user wishing to use SSH with RSA or DSA authentication runs this once to create the authentication key in $HOME/.ssh/identity, $HOME/.ssh/id_dsa or $HOME/.ssh/id_rsa.
• The system administrator may use this to generate host keys, as seen in /etc/rc.d/sshd. Normally this program generates the key and asks for a file in which to store the private key. The public key is stored in a file with the same name but “.pub” appended.
• The program also asks for a passphrase. The passphrase may be empty to indicate no passphrase (host keys must have an empty passphrase), or it may be a string of arbitrary length.
• A passphrase is similar to a password, except it can be a phrase with a series of words, punctuation, numbers, whitespace, or any string of char- acters you want.
• The passphrase can be changed later by using the -p option. There is no way to recover a lost passphrase. If the passphrase is lost or forgotten, a new key must be generated and copied to the corresponding public key to other machines.

Getting Started.

• First, install OpenSSH on two UNIX machines, hurly and burly. This works best using DSA keys and SSH2 by default . On each machine type ssh somemachine.example.com and make a connection with your regular password. This will create a .ssh dir in your home directory with the proper perms. On your primary machine where you want your secret keys to live (let’s say hurly), type

ssh-keygen -t dsa

• This will prompt you for a secret passphrase. If this is your primary identity key, make sure to use a good passphrase. If this works right you will get two files called id_dsa and id_dsa.pub in your .ssh dir. Note: it is possible to just press the enter key when prompted for a passphrase, which will make a key with no passphrase.

scp ~/.ssh/id_dsa.pub burly:.ssh/authorized_keys2

Copy the id_dsa.pub file to the other host’s .ssh dir with the name authorized_keys2.

Now burly is ready to accept your ssh key. How to tell it which keys to use? The ssh-add command will do it. For a test, type

ssh-agent sh -c ‘ssh-add < /dev/null && bash’

This will start the ssh-agent, add your default identity(prompting you for your passphrase), and spawn a bash shell. From this new shell you should be able to:

ssh burly

This should let you in without typing a password or passphrase. Hooray! You can ssh and scp all you want from this bash shell and not have to type any password or passphrase.

Article Authored by Arun John Varghese

Author, Arun, is a Systems Engineer with SupportPRO. Arun specializes in Level 1 and Level 2 Linux / Windows Administration. SupportPRO offers 24X7 technical support services to Web hosting companies and service providers.

If you require help, contact SupportPRO Server Admin