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/ Copy the 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!


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.


But in my ~/.ssh/ folder,I can find out only known_hosts file.


Make your keys: ssh-keygen -t rsa You can leave the password blank for automated log-ins. You'll see a ida_rsa and file in .ssh after running the command. Put other host's files in an authorized_keys file (no extension) in the .ssh folder. Put your (the text therein) in remote host's .ssh/authorized_keys file to be able to log in to them.


No discussion of SSH would be complete with mentioning tunneling. I tunnel EVERYTHING through an SSH session to my home servers, Windows Terminal Services, streaming audio/video, even a ghetto http proxy for sort-of secure browsing on the go. I was also going to mention X forwarding for running X apps locally from your remote box, but NX is so much easier/faster/functional. SSH is awesome.


"PermitRootLogin without-password" "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." That's some terrible advice. You should *never* allow root to log in via SSH, unless you have a *very* good reason to do it. It is always safer to login as a normal user and su or sudo to get root privileges. Simply put, it's better to make someone crack your account and then crack the password for su/sudo (if you have a different password for sudo that is) than to let them try to crack root straight away.


I am on the ssh mailing list and saw something about ssh on windows come across the wire. I had always used ssh for windows, which allows password connectivity into windows but I'd never been able to get keyed access going for some reason. (keys worked when logging in to Linux from windows) Then this message came in explaining that OpenSSH for windows hasn't been maintained for some time and shouldn't be used as there are unpatched security issues. Another option is cygwin, which all I can say is good luck. And talk about bloat... But this messenger suggested copSSH, which I'd never heard of before. Well, it installed flawlessly, made it's own rsa and dsa keys, and it worked like a champ right out of the box. I have full, password-less keyed access both ways, in and out of windows to other windows machines or to/from Linux. Now if I can only get rsync to run on windows... the app I tried to install wanted me to wreck the copSSH installation. =( And Unison... there isn't a pickier application on the planet. It won't work at all unless both ends have the exact same version number. Well, the versions for Linux don't ever jive with the versions for windows. So that's out. For an automated windows backup that gets stashed on a Linux machine I'm still stuck with windows backup, hardly a solution at all, but I can now have Linux machines come by silently in the night and pick up the file.

Editor's Picks