Open Source

Realize the flexibility of OpenSSH

Vincent Danen explains the flexibility and power of OpenSSH. With it, you can access systems remotely and securely; transfer files securely (using scp, sftp, or even rsync over ssh); execute single commands on remote systems; secure normally insecure services; and much more.

OpenSSH is one of the most useful tools available. With it, you can access systems remotely and securely, transfer files securely (using scp, sftp, or even rsync over ssh), execute single commands on remote systems, secure normally insecure services, and much more.

Most people make use of OpenSSH without realizing how much flexibility and power it has. This makes revisiting configurations a worthwhile exercise when new versions are made available.

Because of OpenSSH's popularity and the fact that it's shipped with most modern operating systems out-of-the-box, it is also a frequent target for attack. Many bots exist simply to attempt brute-force attacks on ssh accounts; however, there are a few very simple things that can be done to reduce the effectiveness of these attacks. The first is to enable key-based authentication and completely disable password-based authentication. This means using private/public keys to authenticate with. Creating an ssh key is simple:

$ ssh-keygen -t dsa

This will create a new 1024-bit DSA key, stored in ~/.ssh/id_dsa; the public key will be stored in ~/.ssh/id_dsa.pub. Copy the id_dsa.pub to any remote systems you connect to and add it to the ~/.ssh/authorized_keys file on the remote system. From that point forward, you must provide only the passphrase used when you created the ssh key as you log into a remote system, not your password on the remote system.

Once keys are made and in place, edit /etc/ssh/sshd_config (sometimes /etc/sshd_config) and set the following options:

Protocol 2
PermitRootLogin without-password
PasswordAuthentication no

This will enforce protocol 2 connections only; protocol 1 is not nearly as secure as protocol 2 and should not be used. It will also only permit root logins with ssh keys; set this to no if root logins are not required or if using su or sudo to become root is sufficient. Finally, password authentication is no longer permitted; users can log in only with ssh keys.

You can also enable or disable other features, some on a user-by-user basis. You can also selectively allow users. For instance:

AllowUsers joe

This will allow user joe to access the system, and no one else. If you wish to have a number of people use the system, you can use multiple AllowUsers commands, or use AllowGroups:

AllowGroups sshers

This adds users to the sshers group to allow them access to the system. Any user not in the sshers group will not be permitted access.

Because OpenSSH has so many powerful options, you may not wish to allow port forwarding or X11 forwarding for all users. To that end, you can disable these features and then allow them on a per-user-basis. For instance:

X11Forwarding no
AllowTcpForwarding no

Match User joe
    X11Forwarding yes
    AllowTcpForwarding yes

This will disable both TCP port forwarding and X11 forwarding for all users, except for joe due to the Match User directive.

The sshd_config(5) manpage provides a lot of information on the various directives and is well worth reading. The sshd_config file governs the sshd daemon itself and other configuration files, such as ssh_config or ~/.ssh/config, control the ssh client. Information on configuring the ssh client can be found in the ssh_config(5) manpage.

Get the PDF version of this tip.

Delivered each Tuesday, TechRepublic's free Linux and Open Source newsletter provides tips, articles, and other resources to help you hone your Linux skills. Automatically sign up today!

About

Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.

Editor's Picks