Or fail2ban which puts in iptables rules to ban IPs that fail to login. The ssh scrapers try a variety of user accounts, and it is pretty easy to spot them (for example root can't login on my system from anywhere except the physical console, so trying to login as root,bin,games,demo,Etc from ssh is an instant ban.

Of course you need to not run an open DNS resolver which means 'don't do recursive lookups for anything except your trusted addresses'. I saw one setup that worked really well which was to only do recursive lookups from loopback, then client would create a vpn tunnel to the dns server, get their dns service that way. Seemed a bit extreme but it allows off site DNS service.

I removed fail2ban after it prevented me from logging in to my server from a Panera cafe. It took me a long time to figure out what was going on after logging in from a second server: someone had been trying to break in some days before from the IP that I happened to be using. So fail2ban could be a problem if you work from the road.

> So fail2ban could be a problem if you work from the road.

Your config is bad. Mine is set up for a 12 hour ban. From my logs, it's perfectly sufficient to drop all scanners (I rarely see an IP banned more than twice, and even twice is not common).

If I were to login from a place where an attacker is trying to log in, I would actually appreciate not being exposed - they might only be using networks, but they might also be using cameras and other stuff that would compromise my info.

I use fail2ban as well. I honestly don't get why people get so worked up about SSH. As long as you have a long, secure password, how is it a security vulnerability?

Because if there is an exploit that allows an attacker to recover your password for instance from a session replay then you're instantly open.

So split the conversation, there are little threats and big threats. I don't have 6 locks on a steel door at my house, the big threats are going to break the picture window and walk in that way. So if you're running one of the 100s of millions of non-descript servers out there then fail2ban and putting ssh on a non-standard port will keep the opportunists out of your server (at least via ssh). If they are using a zero day against you, or are waiting to capture traffic to do a plaintext attack they aren't opportunists, they are gunning for you. That is a different threat model.

Unfortunately I have to deal with both, but you're 100% right, those are definitely different categories.

Looking at it from a defense-in-depth perspective, its another layer of protection. Even if you use fail2ban and mandate key-based logins, it answers questions like "what if there is a 0day for my sshd?"

Its not a bad idea, it just happens that careful sshd practices are good enough that more layers are subject to highly diminished returns.

Having a fake open 22 is actually a great way to build up a blocklist.

I've been running kippo (ssh honeypot) with a really weak root password. It's really entertaining to watch people break in and try to muck around.

For a while I had one of the DEC VAXes in my collection attached to the network identifying itself as KREMVAX (old usenet joke) it was fun watching people try to break into it. (they could as guest, which had the password guest).

It was particularly fun to watch young people who were new to the scene sort of freak out at this weird architecture. Old farts were easy to spot, they would start right away with a 'show dev' or 'set host' to try to move around the network. Kind of like a hacker aquarium.

You could easily do a real hacker aquarium. Simply switch IPs frequently enough and play it back with a weeks delay.

Kudos for having multiple vaxes(n?)!

I was thinking giving any hacking attempt some sort of fake shell access would be a great learning experience, how awesome is it that other people had that thought and made it.

Until you need to login from a different machine, forget the -p flag and get yourself blacklisted. :)

That would never happen to me. Ahem.

I decided to enable port knocking. So SSH is not available on any port, without right kind of packets being sent beforehand.

Security through obscurity.

Obscurity is fine as a layer in your security strategy.

With Moxie Marlinspike's KnockKnock[1] port knocking offers real additional security.

1) http://www.thoughtcrime.org/software/knockknock/

Yes, much like choosing an obscure sequence of bits to function as one half of a public/private keypair during an SSH protocol handshake.

Not quite.

Port Knocking packets can have strong crypto payload. So yes, it's not really any different than using VPN. (Yes it is technically yes, but it allows you to open access from one IP address, using strong authentication for service, which still got strong authenticaiton. TOTP, private key and password.) It's just front blocking access to that tcp port without the right opening packet.

Another solution I like is adding fail2ban. It adds a rule to iptables to block the IP after a set number of incorrect attempts and you can set when to unblock it.

Thanks, that's a good tip, I'll work on that today.

I had considered Route53 but it's actually in the same ballpark as this setup, money wise, and it's less flexible for what I want it to do. I haven't evaluated Cloudflare at all yet.

I'm using CloudFlare (without the proxy/CDN feature) just because of their awesome DNS management. Haven't had any issues and it's got a really neat interface.

How do you change the reported OS/SSH version? I didn't see any obvious lines in sshd_config that do that.

Banner and VersionAddendum. Defaults to "none" for both.

[Later] Actually, those two have no effect on my remote Debian 6 VPS. Possibly a Debian "fine-tuning".

+1.

SendEnv in ssh_config? AcceptEnv in sshd_config? No specifics cited in the man pages.