New User? Register here - Existing Users: Username: Password: [Advanced Login]

 

 

Current Poll

Your preferred Interactive shell?









( 1387 votes ~ 15 comments )

 

Weblog entry #1 for technick

Securing SSH
Posted by technick on Fri 2 May 2008 at 19:09
Tags: ,
I'm working on a baseline ssh security white paper for Debian systems and I think i've found a good combination for great security and still ease of use. The servers this white paper will mostly apply to are machines facing the outside world and have static ip addresses from which they are administered from.

<cut>

Starting off, the users i'm allowing in all have valid accounts with ssh key pairing authentication setup already. Each account has no password assigned and is also locked (usermod -L).

This is the run down of the changes that go into sshd_config. The man pages for sshd_config has all the details one could ask for.

PermitRootLogin no
UsePrivilegeSeperation yes
Protocol 2
AllowTcpForwarding no
X11Forwarding no
StrictModes yes
IgnoreRhosts yes
HostbasedAuthentication no
RhostRSAAuthentication no
PasswordAuthentication no
AllowUsers oracle netguardian borderpatrol techgod
Port 5632

Before I restarted SSH I made sure that all of the accounts worked properly with key based authentication.

Next stop is the hosts.deny and hosts.allow files.

In the hosts.deny file I add "sshd: ALL".

In the hosts.allow file I add sshd: .oracle.firekitty.com node1 node2 65.33.2.

The above line will allow all users with a reverse dns lookup under the subdomain oracle.firekitty.com (example: cartman.oracle.firekitty.com) the ability to connect to the ssh daemon. The same for node1 and node2 assuming their is a entry in the /etc/hosts file to resolve them or they are in the same domain as the server. By adding a non-complete ip address, this will allow all users in the ip space of 65.33.2.1 - 254 to connect to the ssh daemon.

Feedback is always welcomed =)

 

Comments on this Entry

Posted by daemon (146.231.xx.xx) on Fri 2 May 2008 at 21:05
[ Send Message | View Weblogs ]

Just one comment, or question I guess.

Why not use AllowGroups instead of AllowUsers, then you just have to make sure that any users that should have ssh access are members of, say, an "sshusers" group? That's the way I do it, and it works nicely for me, and means it's much easier when new users come along -- you just add them to the group, without having to remember to edit any config files.

Cheers.
:wq

[ Parent | Reply to this comment ]

Posted by ajt (85.211.xx.xx) on Sat 3 May 2008 at 21:07
[ Send Message | View Weblogs ]
SSH is one of the most popular topics here, to which your post is the most recent. There have been numerous articles and weblogs on the topic: see http://www.debian-administration.org/tag/ssh for a selection of the tagged ones.

What is interesting is that though SSH is so much more secure than telnet/rlogin out of the box, it's no way near as secure or as convenient as it can be made to be, hence the profusion of posts on the topic.

BTW: Welcome to DA.org, I'd recommend a read around here when you have a few minutes (well hours really), I'm amazed at the quantity and quality of stuff here. It's unusual to not find an article here at the top of any search on Google for any kind of Linux administration type topic.

--
"It's Not Magic, It's Work"
Adam

[ Parent | Reply to this comment ]

Posted by Anonymous (87.177.xx.xx) on Tue 6 May 2008 at 20:42
Make sure you can still access the server if the DNS lookups fail...

[ Parent | Reply to this comment ]

Posted by Anonymous (208.81.xx.xx) on Wed 7 May 2008 at 17:02
I hard code a couple of host names into the /etc/hosts file just in case this happens.

[ Parent | Reply to this comment ]

 

 

Flattr