6 ms·

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 do

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 authenticate SSH with TOTP tokens, but this is not that.

camperman 10y ago
Aren't you worried that systemd won't silently kill the background process? :)
- danieldk 10y ago
  I know that you are probably joking, but you'd launch such a thing from a unit file. Hence, no silent killing.
- akshatpradhan 10y ago
  How would that even be possible?
  - TheCoreh 10y ago
    A new change in systemd made it so that nohup'd processes are killed by systemd after you log out.
    - milankragujevic 10y ago
      I'm not really linux-savvy, but if it's true and it does what I think it does, it's really stupid. A lot of my scripts rely on nohup to send something to background, and I often logout after running the script, so this would break my whole workflow.
    - stordoff 10y ago
      Does that mean that something like "wget URL &" would be killed if I log out of SSH?
    - MereInterest 10y ago
      Why would they change that? Isn't that exactly why you would ever nohup a process?
  - morb 10y ago
    He's referring to https://news.ycombinator.com/item?id=11782364 https://news.ycombinator.com/item?id=11782364
evook 10y ago
> 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.
- danesparza 10y ago
  Hmmm ... wouldn't it be possible to use a distrubuted portscanner to find the current port? Or simply DDOS the switch that the box is attached to? Or the router? Or another downstream connection point? 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."
  - djrogers 10y ago
    Needing distributed port scanner adds a huge barrier to entry over that needed for a simple ssh brute force script. Not to mention that once you find the port you have at most 30s to brute force it before it moves again...
    - falcolas 10y ago
      Not so huge. nc -z <host ip> 0-65535 This runs pretty quickly, and if you're co-located with your attacker (i.e. aws), you're not going to be in great shape. 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.
- frutiger 10y ago
  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).
  - 10y ago
niccaluim 10y ago
> 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!
- ultramancool 10y ago
  Failed auths are generally boring and rarely worth looking at. Look at the successes instead.
- mancerayder 10y ago
  I just use DenyHosts. A few rattling attempts, and the IP won't be able to make another auth attempt again.
  - niccaluim 10y ago
    It's very very very rarely the same IP.
venomsnake 10y ago
Couple of enhancements - there should be port map for ports which not to connect to. Also - you will have a hell of a time with synchronization, timezone etc.
e12e 10y ago
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 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.
- andersonmvd 10y ago
  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.
  - e12e 10y ago
    The obvious next step is ipv6 address hopping in a /64 dedicated to the machine in question I guess...

camperman 10y ago

Aren't you worried that systemd won't silently kill the background process? :)

danieldk 10y ago
I know that you are probably joking, but you'd launch such a thing from a unit file. Hence, no silent killing.
akshatpradhan 10y ago
How would that even be possible?
- TheCoreh 10y ago
  A new change in systemd made it so that nohup'd processes are killed by systemd after you log out.
  - milankragujevic 10y ago
    I'm not really linux-savvy, but if it's true and it does what I think it does, it's really stupid. A lot of my scripts rely on nohup to send something to background, and I often logout after running the script, so this would break my whole workflow.
  - stordoff 10y ago
    Does that mean that something like "wget URL &" would be killed if I log out of SSH?
  - MereInterest 10y ago
    Why would they change that? Isn't that exactly why you would ever nohup a process?
- morb 10y ago
  He's referring to https://news.ycombinator.com/item?id=11782364 https://news.ycombinator.com/item?id=11782364

evook 10y ago

> 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.

danesparza 10y ago
Hmmm ... wouldn't it be possible to use a distrubuted portscanner to find the current port? Or simply DDOS the switch that the box is attached to? Or the router? Or another downstream connection point? 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."
- djrogers 10y ago
  Needing distributed port scanner adds a huge barrier to entry over that needed for a simple ssh brute force script. Not to mention that once you find the port you have at most 30s to brute force it before it moves again...
  - falcolas 10y ago
    Not so huge. nc -z <host ip> 0-65535 This runs pretty quickly, and if you're co-located with your attacker (i.e. aws), you're not going to be in great shape. 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.
frutiger 10y ago
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).
- 10y ago

niccaluim 10y ago

> 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!

ultramancool 10y ago
Failed auths are generally boring and rarely worth looking at. Look at the successes instead.
mancerayder 10y ago
I just use DenyHosts. A few rattling attempts, and the IP won't be able to make another auth attempt again.
- niccaluim 10y ago
  It's very very very rarely the same IP.

venomsnake 10y ago

Couple of enhancements - there should be port map for ports which not to connect to. Also - you will have a hell of a time with synchronization, timezone etc.

e12e 10y ago

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 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.

andersonmvd 10y ago
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.
- e12e 10y ago
  The obvious next step is ipv6 address hopping in a /64 dedicated to the machine in question I guess...