Linux

Specify who can log in via OpenSSH


The OpenSSH suite of tools, developed by the OpenBSD Project, includes popular programs that serve many uses. This popularity combined with ssh availability as both server and client on just about every OS makes it no wonder that ssh has been the target of common attacks; and as a result, many tools have been created to help cope with some of these common brute-force attempts.

Common sense, however, can turn these attacks into nothing more than an annoyance and wasted space in logfiles. For starters, explicitly setting who is able to log in will help defeat 99 percent of these brute-force attacks, regardless of how secure your system really is.

To begin with, never allow root to log in via ssh unless you absolutely must, and in that event, always use ssh keys. Never allow root to log in with a password. To do this, edit /etc/ssh/sshd_config (on some systems it is simply /etc/sshd_config) and add:

PermitRootLogin without-password

This will allow root logins, but only with an appropriate ssh key, the public counterpart of which must be set in /root/.ssh/authorized_keys.

Second, explicitly define which users are able to log in. Again, editing sshd_config, add:

AllowUsers root
AllowUsers joe
This will only allow the users root and joe to log in via ssh. Note that as soon as you enable one AllowUsers option, no users can login unless they are listed. In other words, despite the PermitRootLogin setting, if you do not set "AllowUsers root" and have "AllowUsers joe" in your configuration, root cannot log in even with a proper key. Keep an eye on this list over time and make sure that users who no longer require access to the system are removed from it.

You can further tighten the security here by specifying not only a username that can be permitted, but the originating host they can log in from by specifying a user@host pattern.

In other words, if you specify joe@10.0.5.1 then access to the user account joe will only be granted to connections originating from the IP address 10.0.5.1. You can specify various patterns here, such as joe@10.0.* to allow access from any system in the 10.0.0.0 network range.

The ssh_config(5) manpage has more details on allowable patterns that can be used.

Finally, if you do not require PAM-based authentication, set:

UsePAM no

This is the default and should only be enabled if you need PAM-based authentication that sshd cannot obtain on its own. For example, this would be required if you had a user account that authenticated via LDAP (and thus pam_ldap); without enabling UsePAM, that user could never log in. However, once you enable UsePAM, other options do not work as you may expect. For instance, "PermitRootLogin without-password" will not work properly and if a valid ssh key is not provided, it will fall back to a PAM-based authentication prompt for the root user's password.

At this point, by merely using the AllowUsers keyword, most brute-force attempts are mitigated because the attacker needs not only to guess the correct password, but also the correct account. Any attempts to log in as other users not in the allowed-user list will result in failed login attempts, even if the correct password is provided.

Delivered each Tuesday, TechRepublic's free Linux NetNote 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.

18 comments
anggwaponi
anggwaponi

it is being stated that in order to do this, then edit /etc/ssh/sshd_config (on some systems it is simply /etc/sshd_config). however, i tried to look in my PC and this is only what i found out: hosts, networks, services, lmhosts, and protocols. please advise where in the said file would i edit its parameters? or if i'm right in the stuff i browse? thanks:)

Alfa11
Alfa11

This was a great article. I would add the recommendation if it is possible of changing the default SSH listening port 22 to another one and also using Denyhosts. With this app you can block an IP after it retries logging in with the wrong credentials several times (it's configurable).

mctraxx
mctraxx

Thanks a lot. Very useful.

Jaqui
Jaqui

To limit the ability of users to use su so that only admins, with a previously registered public / private key pair can use su: Compile sshd with the match keyword patch (http://bugzilla.mindrot.org/show_bug.cgi?id=1180), and use it to ensure that members of the admin group can only log in using public/private key authentication. Also make these users a member of the wheel group, and ensure that only they can su - check out /etc/pam.d/su. For example, in /etc/ssh/sshd_config add: Match Group admins PubkeyAuthentication yes PasswordAuthentication no ChallengeResponseAuthentication no In /etc/pam.d/su ensure the following is uncommented: # Uncomment the following line to require a user to be in the "wheel" group. auth required /lib/security/$ISA/pam_wheel.so use_uid I use this method to ensure that admins can only log in using public/private keys and have access to perform admin functions while (hopefully) ensuring that "normal" users cannot mess about. This also has the advantage that if any user uploads their own keys to ~/.ssh that they will not be able to gain admin rights!!! This does not limit the ability of non admin users from doing their work, only stops them from using root access to alter the system. If ssh is exposed to the internet, this is a means of securing it further against crack attempts, protecting the system from exploitation. all of the above was posted: http://techrepublic.com.com/5208-6230-0.html?forumID=102&threadID=210664&messageID=2167382

paul
paul

Thanks for the some good solid tips. Some admins may not be able to lock down SSH access to confined set of users. fail2ban provides a second layer of defense. fail2ban monitors the logs for failed login attempts. After 3 (user defined) consecutive failures your system will deny all requests (FTP, HTTP, SSH etc.) to that host for 30 mins (again user defined). Its a very useful tool that I would strongly recommend to anyone managing SSH to prevent against brute force attacks.

oliver
oliver

Thanks for these nice informations. i didn't know it was possible to restrict users by IP/networks. I usually do this by firewall rules, but adding it into sshd_config is another line of defense. I would like to add the tip that one can usually acieve similar results by adding "PasswordAuthentication no" into sshd_config. That way, anybody who doesn't have his public key placed on the server is not able to connect at all. Needless to say you should enable that AFTER you placed your key on the server and double checked that "PubkeyAuthentication" is set to "yes" :)

Alfa11
Alfa11

Is OpenSSH package installed?

vdanen
vdanen

I think you've severely over-complicated things here. While restricted access via the wheel group is nice, you can use sudo instead. For instance, using sudo, you can grant explicit user access (or wheel group access if you prefer), strip the suid bit from /bin/su completely, and use something like "sudo su -" instead. This also provides the benefit of never exposing root's password to anyone; the user with the privileges to run /bin/su (as root) would just have to use their own password. Provided you enforce the use of pubkeys only, that system password would be just as safe as root's because it's not being used anywhere other than with sudo. One config file, and one less suid file to worry about. You can even then delegate what users can do what as root, with sudo, as well. I.e. if you have a webmaster, you can limit them to editing httpd config files, restarting apache, etc. without letting them have any other root privileges they don't need.

catseverywhere
catseverywhere

Right under my nose all these years. Now, Paul, THAT is a good solid tip... a gold tip dipped in poison! A casualty of the open source "too many packages available" flaw, until you just pointed it out, sitting there on the other edge of the Linux sword all this time. Thanks. Kick Bono in the crotch for me. ;)

anggwaponi
anggwaponi

hi:) sorry really but i'm a little bit confuse:( is OpenSSH only about linux (or unix)? i mean what i'm trying to emphasized is on Win XP side. that's why i ask if it can be found on this link: C:\WINDOWS\system32\drivers\etc\....? well, hope u or anyone could enligthen me about this. thanks really:)

apotheon
apotheon

"[i]For instance, using sudo, you can grant explicit user access (or wheel group access if you prefer), strip the suid bit from /bin/su completely, and use something like 'sudo su -' instead. This also provides the benefit of never exposing root's password to anyone[/i]" When you can perform all of root's functions without knowing the root password, the fact the root password is protected reasonably well doesn't really mean much.

paul
paul

No problem!! In fact fail2ban is excellent for everything else besides SSH too. Including your own custom applications.... so long as they have log files that you can parse looking for set string and an IP address, you can deny them service for whatever period of time! Bono - our greatest export!!!

anggwaponi
anggwaponi

thanks really for all the info. its very valuable ideas specially that i thought it could immedaitely apply to win XP:) good luck to all of us:)

apotheon
apotheon

I've written articles about OpenSSH for TechRepublic from my laptop running FreeBSD -- a BSD Unix, not a Linux distribution. OpenSSH also runs on other BSD Unix OSes, including OpenBSD, and it was in fact the OpenBSD project that started the OpenSSH project. OpenSSH will also run on other Unix-like OSes such as Solaris. It will also run on MacOS X. It will also run on Plan 9, an operating system that has less in common with Unix than MacOS X has in common with Unix. There's even a port of OpenSSH to MS Windows, though I hear it's a pain in the butt by comparison. Linux is, if anything, an afterthought for OpenSSH. It was designed for OpenBSD -- not for Linux.

catseverywhere
catseverywhere

cygwin is a nightmare! I have never had more trouble with an app in my life. You cannot shell into a Linux box and run x-forwarded apps on the windows side without a couple of PhDs in advanced programing under your belt. Best I ever go was I could get a remote terminal from windows, and I copied a couple of files from windows to Linux. But the syntax for that is another nightmare, trying to handle the difference in handling of blank spaces between the two systems. That stinks, because we all know the important stuff resides under "Documents and Settings..." I do not utilize cygwin, nor do I experiment much with it anymore.

paul
paul

OpenSSH isn't designed for Windows platforms, but if you install Cygwin (http://www.cygwin.com/) on your Win XP machine, you can use SSH. Cygwin will give you a Linux environment on your Windows machine. Its not the perfect answer, but it will give you an SSH Server on XP. The idea situation would be that you would install a Linux distro on your machine, and use then use OpenSSH on Linux. Hope this helps! Paul

catseverywhere
catseverywhere

Well, I am using fail2ban now and I haven't seen any persistent brute force attacks since. I had written an iptables rule that should have stopped them, but for some reason a few were still getting through, probably because they were "slow" enough they didn't trigger the rule. But fail2ban rocks! BTW I always use ssh keys only, no passwords , no version 1. I also move ssh to a (quite) non-standard port as suggested by a poster below. (only on servers "in the wild," my green zone I don't bother. But this is a false sense of security. Sure, it'll stop automated script-kiddie mayhem from finding the server, but run nmap on the interface and it tells you there's a ssh server sitting on the odd port. fail2ban, one of the bazillion things in the Mandriva repositories I'd never considered before. Great tip. Tech Republic is very helpful...

Editor's Picks