Live data from Hacker News

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

github.com

31–40 of 200 posts

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

#31
post #26
post #2

Really cool idea. If someone is interested further in the general concept it is called ”moving target defense.”

Compared to just deploying totp normally as a PAM module this is a horrible idea. Much harder to ratelimit, much cheaper for the attacker to bruteforce codes. It’s neat for sure, but not a good defense.

Doesnt the TOTP in this case concern the listening port for sshd, so it doesnt actually touch the authentication in any way? Just switches the port in a TOTP’esque manner

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

#32
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

Maybe I'm irrational, but it's one of the things that makes me real hesitant about where I deploy TOTP. Sometimes my cellphones randomly have a wildly wrong time -- a misbehaving (or malicious) cell-tower perhaps? And sometimes my computer gets the wrong time too -- e.g. booting between Windows and Linux screwing up the system timezone setting, or ntp failing to start properly, or when I busted up my CMOS. And I have to wonder, how secure is ntp from someone just spamming a system with the wrong times which can block me out?

I'd almost rather a combined thing where it's HOTP but it also rotates once per day like at midnight? Does anything do that, or does it even make sense? Is there a reasonable alternative -- challenge-response maybe?

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

#33
post #2

Really cool idea. If someone is interested further in the general concept it is called ”moving target defense.”

It's also known as "security audit evasion" and is the kind of thing you might do to hide a hostile system on a network.

You should never intentionally do it to your own systems. If you see something like this deployed assume it's either malice or laziness.

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

#35
post #9

Earlier quoted context omitted.

Layering has additional costs, like requiring additional client configuration and software and (in this case) only working over IPv6. The number one step any public‐facing SSH server should take is to switch from password auth to keys only. Anyone who’s still concerned can put it behind a WireGuard VPN. Layers typically added beyond that (like changing port, etc.) don’t even register on the security scale, so to spea…

The simple fact that ssh is over IPv6 already leaves out 99% of potential hackers aka bots.

I have some "cloud" VMs which have been around several years, they're attacked constantly, I haven't seen a single incoming IPv6 source to date.

I wonder if there's a "missed opportunity" for hackers there given presumably how many forget to configure their IPv6 firewall.

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

#36

Make sure your time servers are configured correctly. My department had several Silicon Graphics workstations. Running IRIX, they machines determine amongst themselves which has the most accurate time and they vote that one as the Timemaster. Any new machines added would take their time from the Timemaster. The oldest machine was Timemaster and 8.5 minutes off. Took me week to figure out why my brand workstation had…

Man. Time based bugs are some of the worst. I spent weeks trying to figure out what was wrong with some of my scripts running under WSL. Apparently wsl Linux kernel had a bug that could cause time to drift by minutes.

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

#40

Make sure your time servers are configured correctly. My department had several Silicon Graphics workstations. Running IRIX, they machines determine amongst themselves which has the most accurate time and they vote that one as the Timemaster. Any new machines added would take their time from the Timemaster. The oldest machine was Timemaster and 8.5 minutes off. Took me week to figure out why my brand workstation had…

Man. Time based bugs are some of the worst. I spent weeks trying to figure out what was wrong with some of my scripts running under WSL. Apparently wsl Linux kernel had a bug that could cause time to drift by minutes.

My most memorable bug (because of how long debugging took) was inconsistent use of local and UTC timezones. Learned to localize timedates as late as possible (or preferably never) and delocalize as early as possible.
Post reply on HN