Hacker News new | past | comments | ask | show | jobs | submit login

If you are using the default config the chances are you are using passwords to login? This is bad because unless you are using something like fail2ban you are leaving yourself open to brute force attacks.

Rough best practice is, 1) Use SSH keys to login 2) Enforce SSH to login (no password) 3) Disable Root Logins (login then elevate permissions not logging in as root) 4) Move from port 22 to something else (if you do 1-3 this shouldn't matter I do it mostly to keep the crap out my logs) 5) install something like fail2ban to automatically blacklist IP addresses.




As an alternative to ( 4 ), only expose your SSH servers over IPv6.

Initially I thought this worked because the overwhelmingly huge address space, but even when I published come-get-me DNS records ( ssh.example.com ) there was not a single IPv6 attempt versus hundreds of IPv4 attempts every day on the same host.

Edit: there is plenty ( ~ 8% ) of inbound IPv6 web traffic to my hosts, so it's not a case of IPv6 being obscure. It just seems that none of the bad guys are interested.


I'd add setting these too:

  LoginGraceTime 30
  MaxAuthTries 3
Also consider using AllowUsers to govern from where a valid connection can originate if you know that in advance.


I change my login grace time to 3 seconds, you either have the key or you don't :) No password entering


Nice idea until you're logging in from a slow/overloaded connection, or your ssh host is being flooded with traffic, or has a runaway process that's causing it to thrash, or lots of other reasons you might want to use ssh.

I can't think of a scenario where a really short login grace time would protect you from an attacker, either. What's the motivation?


Hmm, good point, with keys, 30 is a bit long these days.


In #1, use keys at least 2048 bits long.

Last time I talked about the subject, I didn't think it was worthwhile to point that. Now it clearly is.

Also, I don't see much advantage in #4.


There is no security advantage to #4 (security through obscurity is no security) other than it prevents anyone getting a ping by sweeping Port 22, they actively have to look for an SSH port which will trip fail2ban.


Moving SSH off port 22 has no security benefits. Anyone can still easily track down if you have SSH running and on what port.

The only benefit moving SSH has is to reduce the reporting (as you also mentioned).

I just wanted to make that clear in case someone mistook your post to assume that switching SSHs default port made them more secure


Not entirely true. Moving your SSH port will not prevent a targeted attacker from finding it, it'll barely slow them down.

What it will do however is prevent automated script-kiddy scanning tools from seeing port 22 open, scraping the banner, and adding your IP to a list of target to brute force/exploit. That's a good thing, and is absolutely, by any definition, a security benefit.


Automated tools already won't get into your machine if you disable passwords. And they can easily adapt to non standard ports if the authors see any worth in doing that.

Setting a non-standard port to ssh is akin to adding a wood plank to the door of a safe with state of the art locks and 20" steel walls. A very annoying wood plank, by the way.


No it's like hiding the safe so that 99.99% of attackers don't know you have it and break into your neighbors instead.


No, it's like hiding your cash under your mattress expecting people not to look there.

Real security doesn't rely on obscurity.


Wrong. That's how NOT to set up SSH. Use keys and / or log scanning to auto firewall failed login attempts. I recommend fail2ban, but there's a few daemons that do the same thing.


A friend of mine runs ssh on 443, because if he's at a hotel with a restrictive outbound firewall, he'll still be able to get into his machines...


That's fine because it's a not for security reasons. In fact I've been known to do the same myself (tunnel web traffic over an SSH server running on 443 to circumvent firewalls on public WiFi hotspots)




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: