Live data from Hacker News

Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

github.com

61–70 of 200 posts

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#61
post #15

That’s a super cool concept, but doesn’t this fall a bit under “security by obscurity”?

The "security by obscurity" one-liner is one of my favorite examples of the sort of black-and-white thinking that is harmful to software engineering. The truth is that playing defense is as much an exercise of technical design as it is economics. Yes - if someone finds the SSH port, they have a window of opportunity, and you will be owned if you are not properly securing your server through the normal channels. Howev…

> The "security by obscurity" one-liner is one of my favorite examples of the sort of black-and-white thinking that is harmful to software engineering.

My primary problem with people going for "security through obscurity" is that very often there are things which are intentionally obfuscated or obscured, in such a way that the implementer thinks that their method of hiding things will provide a significant measure of security. But then all of the other more common sense security precautions that should be implemented before the obscurity are ignored.

If I had a dollar for every industrial/embedded/M2M/IOT type thing that tries to be secure through obscurity but has other gaping holes in it, once you're familiar with the technical workings of the product...

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#62

There should be no need to do this if you have a properly configured public/private key auth setup and disable password based login. And of course keep up to date on openssh patches and security advisories. I worry that something like this will provide a false sense of security for people who might ignore other more common-sense, fundamental precautions first. Before doing something like this I would worry a lot more…

Avoiding something like this because the possibility exists that someone will do something else wrong is just silly.

Also, the amount of CPU taken by brute force ssh is not zero. There are plenty of good reasons for this. Even if this by itself isn't the best implementation, it's an example of how to make things much, much harder on attackers.

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#63

There should be no need to do this if you have a properly configured public/private key auth setup and disable password based login. And of course keep up to date on openssh patches and security advisories. I worry that something like this will provide a false sense of security for people who might ignore other more common-sense, fundamental precautions first. Before doing something like this I would worry a lot more…

Avoiding something like this because the possibility exists that someone will do something else wrong is just silly. Also, the amount of CPU taken by brute force ssh is not zero. There are plenty of good reasons for this. Even if this by itself isn't the best implementation, it's an example of how to make things much, much harder on attackers.

The amount of CPU taken by brute force SSH on any modern system is negligible - unless we're talking about traffic levels that would qualify as a DDoS. Maybe 0.02 points on a standard unix load scale. In any case you should have something like fail2ban or its equivalent that blackholes traffic from repeated failed attempts to authenticate, not just to your public facing ssh daemon, but lots of other things. The default debian fail2ban daemon configurations, easily toggled on or off to watch various log files, are quite sensible.

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#64
post #14

And all you have to do is trust that your client and server will always have synchronized clocks...

... like you need to when using TOTP for anything

It's one thing to lock yourself out of your application or admin interface when NTP breaks. It's another thing entirely to lock yourself out of recovering the server entirely when clock skew inevitably hits you.

If you really want 2FA for SSH, use something like Yubikeys that increment a counter and generate tokens based on that counter. And use it during the actual authentication session, not for figuring out which magic port the server will be listening on. You never have to worry about synchronized clocks, just a database tracking the highest counter value ever seen, so that previous values can't be reused.

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#65

Stop it with this cloak and dagger BS. Just set a shared secret on it: https://github.com/google/tcpauth (Yes, MD5 is safe for this use) With tcp MD5 your connection is even secured against an active attacker who can sniff. They can't inject, or even RST the connection. Even if they can sniff and spoof everything.

If this is a joke, it is very well executed.

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#67
post #60

It all depends on your constraints and who needs SSH access, but if you're like me, you (1) have a number of personal VM instances on major cloud providers and (2) don't want to deal with anything but 'vanilla' Linux and sshd. No customizing kernels, no portknocking, no TCP wrappers, no fail2ban, no VPNs (not even tailscale which is very nice). The approach that I've been using for about a decade is a script that get…

Can I ask why you don't trust running fail2ban on 'cloud' based VMs? The defaults for how long it will ban failed ssh attempts are quite sensible, and short enough to prevent you from accidentally locking yourself out for a very long period of time (automatic unban time to remove iptables rules).

If nothing else, it serves the useful purpose of stopping the log files from being cluttered up with various botnets' fully automated ssh username/password attempts that are out there, trying to gain access via well known factory default credentials.

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#68
post #22
post #14

And all you have to do is trust that your client and server will always have synchronized clocks...

Your server has NTP. Your client likely, too, if it has enough network to connect to the server. If it does not use NTP, it's easy to set the time within the minute or so required manually.

Hardware clocks are famously unreliable and inaccurate. NTP has failure modes that can result in servers being wildly out of sync with reality. Letting either one of those hose your ability to log in and diagnose/recover the system is a mistake.

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#69

Stop it with this cloak and dagger BS. Just set a shared secret on it: https://github.com/google/tcpauth (Yes, MD5 is safe for this use) With tcp MD5 your connection is even secured against an active attacker who can sniff. They can't inject, or even RST the connection. Even if they can sniff and spoof everything.

Heh guess I can cross this off my ideas list. 100% this is the way to go.

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#70
I have taken a different approach to remote access in limited scenarios:

gofwd: A cross-platform TCP port forwarder with Duo 2FA and Geo-IP integration. Its use case is to help protect services when using a VPN is not possible. Before a connection is forwarded, the remote IP address is geographically checked against city, region (state), and/or country. Distance (in miles) can also be used. If this condition is satisfied, a Duo 2FA request can then be sent to a mobile device. The connection is only forwarded after Duo has verified the user.

https://github.com/jftuga/gofwd

Post reply on HN