Somehow my windows computer doesn't want to fetch the correct time. Would probably be a nightmare.
Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
11–20 of 200 posts
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#12That’s a super cool concept, but doesn’t this fall a bit under “security by obscurity”?
In the same way that passwords, private keys, and safe combinations are security by obscurity, sure.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#13Earlier quoted context omitted.
Yes, but that's only bad if it's your only security.
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.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#14And all you have to do is trust that your client and server will always have synchronized clocks...
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#15That’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.
However, now they only have a small window of opportunity (say, 30 seconds). This does a few things:
- it takes time (money) to attack a target. without access to the OTP secret, randomly assigning ports dramatically increases the cost (time) of attacking you. throw in a tar pit and it's even worse. if you're not a high value target, the attacker moves on.
- now, any failed authentication attempt to your SSH server is a highly credible threat. repeat attempts are even more suspect - you are being targeted, and they probably have the OTP secret. effectively, you are able to resource your team more efficiently, because you can filter out noise.
security is not black and white. if you are a valuable enough target, someone will find a way in. defense in depth helps you manage your defense with limited resources.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#16Somehow my windows computer doesn't want to fetch the correct time. Would probably be a nightmare.
Win10?
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#17And 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
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#18Anyone done TOTP port-knocking to open an SSH listen port with just the originator white-listed for a short window?
I had a port-knocking ssh OpenBSD setup late 90's, did move the port about though, just white listed opened. Used SKEY for port sequence, was easy to run even on a Nokia in Java() in that era.
[EDIT ADD]>Actually was some Symbian and then Java implementation of the skey. Had Psion Series 5 used initially.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#19That’s a super cool concept, but doesn’t this fall a bit under “security by obscurity”?
It's another layer of security. There have been exploits of OpenSSH in past so this may be prudent.
Trouble with extra layers, there's a point where it results in complexity. Which, in my experience, is more likely to be the root cause of a security problem.
I'm not saying this little demo is a disaster or anything. But for example, perhaps it requires an awareness of this scheme in an external firewall's rules, and maybe another machine pops up in the rather large IPv6 range that's now available.
At its extreme, these sorts of approaches can bring a lack of clarity which layer is providing the actual security.