Hacker News Reader

Comment by petercooper | Hacker News Reader

Even if it didn't, it lowers the number of log entries, failed attempts, and number of connections by several orders of magnitude. I've never regretted doing it though I pick a far more obscure port than this. None of my clients have had issues with me doing this either and sshagent makes it transparent to me.

It's the equivalent of moving your main door to the back of your house. Far fewer people will knock, even though burglars can still get in.

View on HN

For the log file issue I usually recommend using something like fail2ban to start blocking hosts after too many failed logins in a given time period (and unblock them after a while).

If you are running a shared environment the irritation of the log entries (or needing to run something like fail2ban or similar if you don't already) may be small compared to having to explain to your users again and again and again that the reason their SSH/SCP/SFTP client won't connect is that they need to tell it to use a different port (and then have to work out how to set a different port in the client they are using because they'll expect you to know).

The problem with fail2ban is that it's vulnerable to denial of service attacks when the attacker spoofs the source IP address of the failed login attempts.

How do you spoof TCP connections?

http://lmgtfy.com/?q=tcp+connection+spoofing

I'd be amazed if you could show me a TCP spoofing attack that works against a remote host (that you aren't on the same LAN as).

As far as I know (and google shows), they don't exist.

Glad you mentioned choosing a obscure port. Not that 24 is wrong though <1024 are reserved for various protocols so usually I tend to select ports above this reserved range. Never know when you decide to roll out say mail on 25 and sure enough find out your ssh port is running on 25.

Any port not listed in the link below, or listed as "Unassigned", would be fair game.

http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_number...

If you're running a multi-user server, with possibly malicious users, that's not a good idea. Ports <1024 can only be bound to by root; so if a valid user of the server can figure out how to crash sshd, he can run his own version on the same port >1024, and then all your users' password are belong to him.

When I read your comment, I thought "surely you couldn't rig up a fake sshd to steal passwords" thinking the protocol wouldn't send passwords in plaintext but instead some hashing would take place. I read the RFC and, wow, it does send plaintext (though it's over an encrypted transport). Ouch..

Any client that has the server's public key in their known_hosts will throw up a big fat error.

This is mitigated by not allowing password-based logins for SSH. Your point still stands though.

This. Plus installed knockd (http://www.zeroflux.org/projects/knock) of course :)

Check this out: http://www.google.com/search?q=single+packet+authorization

Anyone got this to work? My attempt ended up with an encrypted packet size over the 1500 byte limit.

Reply on news.ycombinator.com