Comments on: Basic SSH server hardening

By: Andrew Waite

Andrew Waite — Sun, 10 Jul 2011 08:59:24 +0000

That’s a good point, always make suer you’ve got multiple points into your server in case something changes. In my standard setup I’ll allow multiple source locations (home/work/etc.). Don’t forget you can (usually) fall back on physical console access as a last resort.

By: Server Hardening

Server Hardening — Sun, 10 Jul 2011 05:45:34 +0000

These are very good tips. If only admins need to login, to get around the issue of having an IP lockdown and then your ISP changes your IP, you could either lockdown the IP to your ISPs local network or better yet have a very cheap VM on standby with a static IP and with access for that IP to your server. This way if your IP all of a sudden changes and you’re locked out all you need to do is daisy chain via your cheap VM’s IP, login and then update your dynamic IP.

By: SSH Tunnelling Example « Infosanity's Blog

SSH Tunnelling Example « Infosanity's Blog — Mon, 09 May 2011 08:26:03 +0000

[...] (and hopefully secured well enough to keep the barbarians from the door, but that’s for different [...]

By: 2010: A Review « Infosanity's Blog

2010: A Review « Infosanity's Blog — Fri, 31 Dec 2010 14:03:13 +0000

[...] grow and mature over the year InfoSanity tried a few different themes and topics, some worked, like basic ssh hardening guidelines (potentially more to come in new year) and some didn’t, like the ‘Infosec [...]

By: SSH hardening with Breakinguard « Infosanity's Blog

SSH hardening with Breakinguard « Infosanity's Blog — Thu, 21 Oct 2010 20:13:50 +0000

[...] sensors have shown, attacks against SSH services are regularly seen in the wild. Even if you follow best practices for securing the service, the malicious scans will utilise resources available to your environment; [...]

By: Daniel

Daniel — Fri, 30 Jul 2010 01:12:33 +0000

I love vectors like these when pen-testing networks. I think root access to SSH, standard port and allow any IP to connect are wonderful for me! Bad for the Network Admins.

Very good report Andrew. I think these are some great starting points, even if its not a fully secure SSH server, changes like these cut down the amount of people that can pull off an attack.

Dan

By: mig5

mig5 — Sat, 24 Jul 2010 12:07:45 +0000

True that – I realised afterwards it may not be considered ‘basic’ – on the other hand, even before making any firewall changes, setting up an ssh keypair and switching to key-based only, could often be enough (arguably harder to spoof a private key than an IP!) and from experience, the afternoon of pain sending a tutorial around to your users and getting them to email you back their public keys, is well worth the effort when securing server you can’t totally firewall off

Sorry for the trigger-happy spam comment

By: Andrew Waite

Andrew Waite — Sat, 24 Jul 2010 11:58:52 +0000

WOW! That was quick off the mark

Yeah, totally agree that key based authentication is the way forward. But I wouldn’t include it under ‘basic’ as it requires a shift in how a user accesses the system from the standard and understand username and password. Not a problem on a single user system, but if a large number of users need shell access then blindly implementing key only authentication is a sure fire way to cause your helpdesk to explode.

To paraphrase Tom, ‘I don’t want a bunch of emails saying “I got in trouble because I did what InfoSanity said…”)’

By: mig5

mig5 — Sat, 24 Jul 2010 11:50:42 +0000

Consider also disallowing Password authentication and using only key-based authentication in ssh (especially if you are unable to lock things down by IP, for instance if your ssh users are restricted to dynamic source IPs) On most modern distributions, key-based auth is already enabled by default, so you may only need to set in /etc/ssh/sshd_config


PasswordAuthentication no

Also, a recent spate of ssh attacks have taken advantage of keyboard-interactive authentication. Again, most modern Linux distros set this by default, but ensure this is on your config


ChallengeResponseAuthentication no