The title "Changes sshd port every 30 seconds, using Two Factor Auth to login"
This isn't what the project is about, It was mainly done as a joke for all of the people who say "Changing your port is security by obscurity", and thus the idea came to make a even more insane/silly version of it.
It's using "two factor" to generate the port to connect, not to login, there are loads of ways to authenticate SSH with TOTP tokens, but this is not that.
This always tickled me. I don't do it for security; I do it because (on public-facing servers) it keeps the constant stream of doorknob-rattling out of the logs!
In the case of TOTP, the key is stored in plain text two places: the server and the TOTP client (or similarly, for other port knocking schemes, on the server to calculate the next port, and on the client to do the same).
Contrast this with disabling password login, and using only key-based authentication: Now the secret key is only stored in one place: on the client (although, to be fair, there's a secret key you can steal on the server too, in order to compromise the system).
The way to improve security beyond simply requiring key-based auth, is to move away from trust-on-first-use to using ssh certificates. To improve on that, require certificates and TOTP. It's still somewhat hard to see how the latter really improves on security - perhaps with some kind of dedicated TOTP hw token. I would guess that compromising the TOTP-key stored on a smartphone is probably one of the easiest attack vectors, so it's unclear how much more secure it is, beyond simply using ssh certificates.
That's simply not true. Changing the sshd safes you a lot of trouble in risky environments. You prevent services which rely on ssh from failing during automated dos/bf attempts.
While I love the ingenuity of the OP's software, I'd have to agree with their own assessment on the Github page "Beware, currently I would not really recommend running this software, it was only written as a joke."
nc -z <host ip> 0-65535
So ultimately, this offers about the same protection against a dedicated attacker that just hosting it on a non-standard port does, with the disadvantage of any clock drift making it much harder to access your own machine.
- I have some kind of SSH-specific DoS and will simply enumerate ports until I find SSH, which readily identifies itself right off the bat by nature of the protocol. (No config for that.) Result: DoS successful.
- You deploy fail2ban because someone told you to do so because it makes you "safer." Now I can DoS you in three ways since I know (a) there's a Python regex running on your log and (b) naughty addresses will add a netfilter rule, gradually slowing down each packet as it traverses INPUT. What's that, Lassie? A /16 fell down the SSH port while I inundated fail2ban with failures? (Why do you think fail2ban doesn't have IPv6 support yet? I'm just waiting for [0] since solving the problem is intractable, despite what is common consensus in that community. Oh, you're flattening prefixes? How cute. Watch me find the corner cases in your flattening algorithm since I have several googols of v6 addresses to play with.) Result: DoS successful.
- I grow bored of your mildly annoying countermeasures and simply fire up a reflection attack that targets you with several gigabit/sec of traffic behind the aft nacelle, not caring where your SSH lives. Result: Vastly more probable DoS super successful once your hosting provider null routes you. Add cron to watch for your return. Repeat. Follow you to the new IP when you try that because I will invariably find it (probably when you get back on IRC). Walk over your cold server's corpse while you panic and email CloudFlare who can't help, and you can't afford who can. The end.
Now, shall we begin?
There is a lot of shitty shaman wisdom, some making an appearance in this thread, around the SSH port and logging and yadda yadda that actually makes things less safe for a lot of people who don't know better. Most people move SSH from 22 to something like 2200, forgetting that <1024 requires root so now they're one sshd listener crash or restart race away from a local user intercepting SSH with a malicious binary. Oops.
Correct, and only correct, answer: leave sshd on 22 and get your squishy services off the public Internet or rotate the logs faster. You are a sysadmin with grep and awk. Deal with failures in your log. They are there for a reason, especially if you are exposing sshd to the Internet, and pulling netfilter in or moving ports around is silly TSA-level security theater.
This is all promulgated by those "do these ten things first when you install Ubuntu" guides which capitalize on folks not knowing any better to identify (often faulty) opinion. If you followed one lately it's probably steered you wrong, much like those Learn Sushi Preparation in 24 Hours books. Take the time to understand the problem if you're going to operate services on the Internet and get away from guides. (And yes, I am indicting you for writing one, iff yours includes anything discussed in this comment. Sorry.)
Knocking is the only truly plausible, though still silly, security idea here but even that betrays itself in an nmap by nature of TCP. Also, hope you don't forget your knock when your machine is on fire. (You will.)
It's too bad I'm on the right side of ethical these days or I'd patch all the common SSH scanners to try every port so people will stop doing stuff like this. Some already do.
https://news.ycombinator.com/item?id=6617312
https://news.ycombinator.com/item?id=6482192
You did it even better than I did, I think.
This really hits people who dabble in operations with a personal server or something. It's probably a failure of operations folks like me to properly reach developers and other groups who simply toy with our dark arts in the pursuit of getting something done. Operating on the Internet is capital H Hazardous, and simply buying a guide wholesale without understanding it even more so.
I am identifying a need.
(The same phenomenon, knee-jerk reactions, could be seen starting in the mid-90s when everybody and their dog had a Solution™ to the e-mail spam problem, leading to canned rebuttals like this: http://craphound.com/spamsolutions.txt)
The proper solution for SSH is probably for the OpenSSH authors to change OpenSSH to no longer log unsuccessful logins (at least by default). If there’s a successful login, the log entry might add how many previous unsuccesful logins there had been within the previous few minutes, but I see no reason at all to log unsuccessful login attempts anymore. The current logging defaults were normal for its time when the code was written, when the internet was very different, but today they are simply scaring people for no reason.
180 seconds is still seconds. Randomizing ports really doesn't buy much.
Once public key authentication is allowed, the mechanism is only as secure as the private key. There is no way to require a password on private keys, and in any event it could be captured with a keylogger. The concern is not the cryptographic strength of the key, it's end-user security.
While randomizing the port is not security, no one would say 2FA is not required because we can trust RSA.