Keeping SSH access secure

Posted by Steve on Wed 2 Feb 2005 at 13:13

Tags: , , ,

There are several worms which attempt to exploit vulnerable SSH servers, by logging in to a host with a collection of usernames and passwords such as "admin/admin", "test/test", "root/root", etc. These shouldn't be of much concern if you're keeping good passwords, but there are simple ways to prevent them regardless.

The most obvious way to prevent people connecting to your host is to only allow connections from small number of IP addresses, by the use of a firewall.

If you're currently running a firewall you can add to it to :

  • Accept incoming SSH connections from a trusted address.
  • Drop all other connections.

Using the iptables firewall commands you can do this as follows:

# All connectsion from address 1.2.3.4 to SSH (port 22)
iptables -A INPUT -p tcp -m state --state NEW --source 1.2.3.4 --dport 22 -j ACCEPT

# Deny all other SSH connections
iptables -A INPUT -p tcp --dport 22 -j DROP

If you're not running a firewall, or you don't wish to mess with the setup you can look at another way of restricting access. The Debian packages of openSSH are compiled with tcpwrappers support, which means you can specify which hosts are allowed to connect without touching your firewall.

The two important files are:

/etc/hosts.allow
/etc/hosts.deny

The first can contain entries of hosts which are allowed to connect, the second contains addresses which are blocked.

Assuming that you wish to allow the remote addresses 1.2.3.x, and 192.168.0.x to connect but nothing else you would setup the files as follows. Firstly allow access by placing the following inside /etc/hosts.allow:

# /etc/hosts.allow
sshd: 1.2.3.0/255.255.255.0
sshd: 192.168.0.0/255.255.255.0

Then disallow all further access by placing this in /etc/hosts.deny:

# /etc/hosts.deny
sshd: ALL

Finally you can look at the ssh configuration itself, this has several useful security options you can enable.

The ssh server is configured by the file /etc/ssh/sshd_config. If you wish you can restrict remote access to specific users.

For example to only allow "bob" and "chris" to login add the following:

AllowUsers bob chris

With this setting in place (after the server has been restarted with "/etc/init.d/ssh restart") all other users will be unable to connect via SSH even if they login with the correct username and password.

You can also explicitly deny particular users:

DenyUsers badness paula

Probably the most important setting you can change in the sshd_config file is the following:

PermitRootLogin no

With this setting set to "no" remote root logins are denied.

Add Comment XML logo Printable version

 

<<< Speeding up dynamic websites with caching Monitoring user activity, via snoopy >>>

 

 

#
Re: Keeping SSH access secure
Posted by orchid (64.26.xx.xx) on Wed 2 Feb 2005 at 14:35
[ Send Message | View Weblogs ]
Hi
I have put:
#deny users
DenyUsers admin Admin test root

and also:
# Authentication:
LoginGraceTime 600
PermitRootLogin no
StrictModes yes

into my /etc/ssh/sshd_config on my Woody server.
I also have AllowUsers listing the only four usernames allowed to ssh in.

I will add thier ip address's to hosts.allow, I didnt think of that.

One question...

# Logging
SyslogFacility AUTH
LogLevel INFO

Despite trying to log in with a bad username or password, I cannot find a "failed login" attempt in any of my /var/log/*
files, what file is this logged to?

Is it possible to have ssh log all of its activity to /var/log/sssd.log?

This would be much easier for me.

Thanks for the great site btw :P

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Steve (82.41.xx.xx) on Wed 2 Feb 2005 at 14:54
[ Send Message | View Steve's Scratchpad | View Weblogs ]
# Logging
SyslogFacility AUTH
LogLevel INFO

Despite trying to log in with a bad username or password, I cannot find a "failed login" attempt in any of my /var/log/* files, what file is this logged to?

The logging is handled by syslog, so by default I'd expect you to find your information in /var/log/auth.*.

For a bad logins you should see something like this:

Failed password for root from x.x.x.x port 4204 ssh2

Is it possible to have ssh log all of its activity to /var/log/sssd.log?

If you dont want to use syslog you can modify the startup script for sshd. The "-e" flag will make it write all it's output messages to STDOUT, which you can redirect to a logfile of your own. I must admit I've not tried this though. ("man sshd" describes this and other sshd options:)

Thanks for the great site btw :P

Thanks :)

Steve
-- Steve.org.uk

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Anonymous (202.149.xx.xx) on Tue 11 Apr 2006 at 11:34

Hi Mr./Miss. Anonymous,
Whatever u r doing with SSH,a log of the same is getting created in /var/log/messages.

So,please go thru that file.

Hitesh

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Anonymous (71.236.xx.xx) on Tue 6 Mar 2012 at 19:04
When the sshd_config file is configured to LogLevel VERBOSE, the info is logged to /var/log/auth.log

The above is true for Ubuntu. It may be logged to a different location on other distros..I'm not sure.

More information on LogLevel VERBOSE: https://help.ubuntu.com/community/SSH/OpenSSH/Configuring#Log_Mor e_Information

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by grimoire (82.70.xx.xx) on Fri 4 Feb 2005 at 10:48
[ Send Message ]
Other, more obscurity-oriented ways to keep your SSH server secure include running it on a different port and implementing portknocking. You can also only permit logins with keys rather than passwords, though this represents significantly more hassle.

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Steve (82.41.xx.xx) on Sun 6 Feb 2005 at 12:43
[ Send Message | View Steve's Scratchpad | View Weblogs ]

Running on a different port will stop you from receiving connections which just blindly connect to port 22 - but it will do nothing to protect you from somebody running a complete nmap scan - as that will recognise the service by the banner regardless of the port.

Port-knocking I'm still in two minds about ..

Steve
-- Steve.org.uk

[ Parent | Reply to this comment ]

#
firewall firewall
Posted by ptecza (83.31.xx.xx) on Sat 5 Feb 2005 at 17:19
[ Send Message ]
Hello!

Thanks for nice article! :) Probably "firewall firewall" is a slight mistake.

Regards!

P.

[ Parent | Reply to this comment ]

#
Re: firewall firewall
Posted by Steve (82.41.xx.xx) on Sun 6 Feb 2005 at 12:41
[ Send Message | View Steve's Scratchpad | View Weblogs ]

Thanks, I've corrected that now.

Steve
-- Steve.org.uk

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Anonymous (220.245.xx.xx) on Tue 15 Feb 2005 at 01:43
Another useful restriction is to limit the access to members of a specific group with AllowGroups rather than AllowUsers.

You can lock off all system access to anyone not defined as an end-user, and don't have to fiddle with the configuration each time you add a new customer/client to the system to specifically permit them access as all they need is group membership of the permitted end-user group.

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Anonymous (64.236.xx.xx) on Mon 30 Jan 2006 at 16:34
I've tried to AllowGroup groupname into sshd_config, though this is not working. Can you pls. be more explicit?

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Anonymous (207.170.xx.xx) on Tue 31 Jan 2006 at 03:00
I am pretty sure it's "AllowGroups" *with* the *s* just like AllowUsers.

GermanyZulu

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Anonymous (64.236.xx.xx) on Tue 31 Jan 2006 at 09:52
Worked this time!
Thx. for replying .:-)

[ Parent | Reply to this comment ]

#
Polish translation
Posted by ptecza (193.0.xx.xx) on Thu 24 Feb 2005 at 08:16
[ Send Message ]
is available now at http://www.debianusers.pl/article.php?aid=71

P.

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Anonymous (24.93.xx.xx) on Thu 3 Mar 2005 at 01:59
If you check your log files, you may note that access attempts appear over and over and over. Why not just drop them if they try?

Blocking repeat SSH attacks with IPTables

I did notice though, since I'm running IPV6 that I see the IPV6 address, and that of course doesn't appear to block real well... I've been remiss in not rebooting my toy server since I was playing with IPV6 tunneling.

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Anonymous (83.76.xx.xx) on Sun 6 Mar 2005 at 01:26
another way : http://fail2ban.sourceforge.net/ It is a small tool in Python that automatically bans IP (for a configurable amount of minutes) that unsuccessfully try to log on your computer.

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Anonymous (128.171.xx.xx) on Sun 10 Jul 2005 at 23:39
I've packaged fail2ban for debian (0.4.x version)... I believe soon it will be in unstable - so you're welcome to testdrive it. Some Debian package version is available from the authors website :-)
Enjoy
--
yarikoptic

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Anonymous (68.166.xx.xx) on Wed 10 Aug 2005 at 00:38
I installed Fail2Ban and it seems to work really well. -Jim

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Anonymous (152.71.xx.xx) on Wed 4 May 2005 at 22:39
I use this little perl script (a daemon) that monitors the "who" command.

It sends an email when anyone logs in.

Can be easyly changed to detect a specific user login.


Marcelo Correa

#!/usr/bin/perl
# user_monitor.pl v0.4 :: keep track on who's logged in
# Written by Stephan Schmieder - http://www.unix-geek.info, 2003
# Usage: ./user-monitor.pl&

use strict;
use warnings;
use diagnostics;
use Net::SMTP;

#configuration
my $server =`uname -a|cut -d" " -f2`;
my $smtp_server ='localhost';
my $mail_to     ='all_logins@gmail.com';
my $mail_from   ='root@' . $server;
my $subject     ="$server :: User login monitor";
#configuration

my @old_users=split(/\n/, qx/who/);
while(sleep(60))
{
        my @users=split(/\n/, qx/who/);
        if(@users ne @old_users)
        {
                my $smtp = Net::SMTP->new($smtp_server);
                die "Couldn't connect to server" unless $smtp;
                $smtp->mail( $mail_from );
                $smtp->to( $mail_to );
                $smtp->data();
                $smtp->datasend("Subject: $subject\n\n");
                foreach my $user (@users)
                {
                        $smtp->datasend("$user\n");
                }
                $smtp->dataend();
                $smtp->quit();
        }
        @old_users=@users;
}

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Anonymous (83.98.xx.xx) on Thu 24 Nov 2005 at 16:04
What is did was add the entry

AllowGroups sshgroup

addgroup --gid 250 sshgroup

adduser username sshgroup

restart ssh

now only the users listed in sshgroup can login

very simpel, works good.

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by AndrewBlack (81.2.xx.xx) on Mon 18 Jul 2005 at 08:08
[ Send Message ]
> /etc/init.d/sshd restart

On my system the file is ssh (not sshd).
Is there are difference between versions of debian?

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Steve (82.41.xx.xx) on Mon 18 Jul 2005 at 08:15
[ Send Message | View Steve's Scratchpad | View Weblogs ]

Nope, my mistake.

Steve
-- Steve.org.uk

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Anonymous (209.189.xx.xx) on Fri 21 Oct 2005 at 04:59
hi, i'm using debian linux (stable) when i restart ssh none of the changes i made in the config file seem to take effect. i.e, denied users still have access, the port hasn't changed, root still can log in.. am i editing the wrong config file (/etc/ssh/sshd_config) or restarting the wrong ssh daemon (/etc/init.d/ssh restart)?

thanks

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Steve (82.41.xx.xx) on Fri 21 Oct 2005 at 05:15
[ Send Message | View Steve's Scratchpad | View Weblogs ]

Looks like you're editing the right file /etc/ssh/sshd_config, and restarting it properly "/etc/init.d/ssh restart".

Why it is failing is hard to guess without seeing the changes you've made ..

Steve
--

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by zig2101 (203.125.xx.xx) on Fri 21 Oct 2005 at 10:29
[ Send Message ]
hi,
i rebooted the system and my ssh settings changed, but still don't know why restarting from the command line didn't work.

i basically took the default config file and added/modified these lines:

Port 2222
PermitRootLogin no
AllowUsers user

thanks again,

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Anonymous (219.236.xx.xx) on Fri 24 Feb 2006 at 11:10
while fail2ban modifies firewall rules, there's another Debian package, denyhosts, that tackles this problem by automatically adding IP addresses to /etc/hosts.deny There's even an option to sync offending IPs with a central server

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Anonymous (83.91.xx.xx) on Wed 15 Mar 2006 at 12:35
Excellent information, thanks buddy!

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by laussy (150.244.xx.xx) on Fri 16 Mar 2007 at 12:18
[ Send Message ]
I guess that instead of "logging in to a host with a collection of usernames and passwords", the attack progresses in two steps, first trying to guess the login, then carrying a brute-force dictionary attack. logs read as follow, reporting an invalid user:

Mar 10 14:20:00 orso sshd[20106]: Invalid user monica from 202.62.73.20
Mar 10 14:20:05 orso sshd[20121]: Invalid user moni from 202.62.73.20
Mar 10 14:20:09 orso sshd[20127]: Invalid user molly from 202.62.73.20

etc. However when an existing user is hit, the error reads differently, namely reporting an "Authentication failure for ..." So common logins with weak passwords are assured to yield!

Fabrice.

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Anonymous (195.110.xx.xx) on Sun 15 Jul 2007 at 20:01

# All connectsion from address 1.2.3.4 to SSH (port 22)

iptables -A INPUT -p tcp -m state --state NEW --source 1.2.3.4 --dport 22 -j ACCEPT

Why does this rule has ``--state NEW''? Don't we need to also allow ESTABLISHED packets? Without ESTABLISHED the rule didn't work for me -- when trying to login, I was seeing "Connection established" message, and then the client "froze", no password prompt.

BTW, there's a typo -- connectsions -> connections.

Thanks for the nice article,

Oleg

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Anonymous (154.5.xx.xx) on Fri 20 Feb 2009 at 02:27
I tried to put the ip restriction on my server (allow 192.168.1.100-150 and deny ALL) but it wouldn't let my desktop connect through putty any more so i deleted it by going onto the server.
then i tried again without the restrictions and i can get to the place where it asks me to logon and i can type the user name but then it tells me that the server unexpectedly closed the connection.
any solution?
-btw im running an ubuntu server

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Anonymous (164.164.xx.xx) on Tue 29 Nov 2011 at 11:28
Hi,

Thanks a lot for posting 'keeping SSH access secure' this was very useful in configuring a critical production server using Red Hat Enterprise Linux.

Your article helped us in restricting SSH access for users which was not required.

Regards,
Manjunath Mariyappa

[ Parent | Reply to this comment ]

#
Re: Keeping SSH access secure
Posted by Anonymous (59.167.xx.xx) on Tue 26 Mar 2013 at 03:35
Hi,

For the benefit of others, I found these instructions and used them to restrict ssh logons to my ISP's IP range. The first thing that you should know is that changes to hosts.deny and allow are immediate. You don't need to restart ssh.

That is a good thing, because you can check if you still have access before closing your current ssh session. In my case this was a life saver because the syntax for specifying a range here (1.2.3.4/255.255.255.0) didn't work. I was locked out. I eventually found that using the syntax:
sshd : ALL Except 1.2.3.*
in hosts.deny and nothing in hosts.allow worked for me.

[ Parent | Reply to this comment ]

Sign In

Username:

Password:

[Register|Advanced]

 

Flattr

 

Current Poll

Your version control software of choice is




( 833 votes ~ 9 comments )

 

 

Related Links