Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Changes sshd port every 30 seconds, using Two Factor Auth to login

github.com

Post reply on HN
Print view View original

71–76 of 76 posts

Re: Changes sshd port every 30 seconds, using Two Factor Auth to login

#71

Post by mancerayder »

niccaluim wrote: post #34
benjojo12 wrote: post #4

Hi, Author of this here! 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 aut…

> a joke for all of the people who say "Changing your port is security by obscurity" 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!

I just use DenyHosts. A few rattling attempts, and the IP won't be able to make another auth attempt again.

Re: Changes sshd port every 30 seconds, using Two Factor Auth to login

#72

Post by jlmorton »

frutiger wrote: post #35
evook wrote: post #14

Earlier quoted context omitted.

> as a joke for all of the people who say "Changing your port is security by obscurity" 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.

It's weird that you trust randomizing the port over a range of [0, 65536) over the trust you have for the cryptographic strength of a 4096-bit RSA key (or equivalent).

While making the port number based on a TOTP token is clearly just for fun, it's not unusual to not entirely trust public key authentication. This is an additional security step.

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.

Re: Changes sshd port every 30 seconds, using Two Factor Auth to login

#73

Post by niccaluim »

mancerayder wrote: post #71
niccaluim wrote: post #34

Earlier quoted context omitted.

> a joke for all of the people who say "Changing your port is security by obscurity" 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!

I just use DenyHosts. A few rattling attempts, and the IP won't be able to make another auth attempt again.

It's very very very rarely the same IP.

Re: Changes sshd port every 30 seconds, using Two Factor Auth to login

#74

Post by oneru »

belorn wrote: post #61
georgeam wrote: post #33

Earlier quoted context omitted.

I recognize that this is a joke, in the words of the OP. However I think SPA-type port knocking is completely legitimate, and I second the use of fwknopd. I depend on fwknopd a lot, so if that is not secure idea, I would like someone to point that out to me. NOTE that fwknopd does not depend on expecting a client to connect to a short sequence of different port numbers. That is not what fwknopd does, at least not the…

Correct me if I am wrong here, but would the following changes to SSH give you the same result: Change protocol from TCP to UPD and port from 22 to 62201. Remove greeting. If first message is not the correct password, do not send a reply. If everyone used this, do you think SSH would become more secure and eliminate password scanners? Personally I think that if ssh took in a fwknopd patch and used that as default, an…

Ssh does a fingerprint verification and establishes a secure channel before it does the password exchange. Avoiding replay attacks can be a challeng as well. Putting strong authentication in a single packet is deceptively nontrivial. It can be done, but at that point you'd be reimplementing Fwknopd. Additionally, Fwknop can protect more than just ssh, and do fancy things like providing access to a machine without a public IP address.

Disclaimer: I'm one of the Fwknop devs. =)

Re: Changes sshd port every 30 seconds, using Two Factor Auth to login

#75

Post by oneru »

daraosn wrote: post #13

Is there a service that wraps/proxies a port with a different or custom protocol? (kind of like SSL for HTTP) Idea: instead of ssh'ing a server, you would run your custom command which communicates to port XXXX, communicate with a custom protocol and then if validation succeeds, would proxy to SSH (or any other internal port/protocol). Why? Because as others suggested you could scan all ports very quickly to break th…

Check out fwknop, https://www.cipherdyne.org/fwknop/ It's one solution to this problem. Instead of answering with garbage, it allows for keeping the firewall closed/default drop stance. It's port knocking, but with real cryptography instead of just relying on hitting port numbers, and does it with just a single packet. Full disclosure: I'm one of the Fwknop devs.

Re: Changes sshd port every 30 seconds, using Two Factor Auth to login

#76

Post by e12e »

andersonmvd wrote: post #69
e12e wrote: post #67

Earlier quoted context omitted.

Fun project. With my more serious hat on, I think what most people are missing about all these port-knocking schemes -- is that they all boil down to poor key based authentication. 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…

Just an observation: 30 seconds should be enough to brute force all ports. It's possible to split the range of the ports by using multiple hosts to perform the scan in case 30 seconds don't be enough.

The obvious next step is ipv6 address hopping in a /64 dedicated to the machine in question I guess...
Post reply on HN