3 ms·

I definitely agree with much of what you've pointed out. > * Use a non-standard ssh port <= not security. plus i bet you're on 2222. Right, marginally better

I definitely agree with much of what you've pointed out. > * Use a non-standard ssh port <= not security. plus i bet you're on 2222. Right, marginally better than using port 22, but it's still something (better than non-action, if you will). I do hope one takes the vigilance to set a port number sufficiently high up, and sufficiently random looking. I recall something about nmap, that it scans only up to 1023 by default or something. > * Fail2ban: useless for key auth, you don't remote brute keys like that Still set it up -- for http and other services. > If your comp can log directly without any authentication that is terrible practice. Your comp will eventually get compromised, stolen, etc and then its game over. The passphrase is no silver bullet but it helps a lot. I agree... I emphasized seamless logging in because that seems to be a big point that Mosh is apparently selling itself on. I do have stronger authentication methods set up for the production machine. :)

cd34 15y ago
> I do hope one takes the vigilance to set a port number sufficiently high up, and sufficiently random looking Hopefully not over port 1023. If a user gets on the system and crashes your ssh daemon through OOM killer or one of many other methods, that non-root user can then restart its own daemon and listen to that port that you put >1023 'for security reasons'. Accidentally answering yes when it says a new key was detected is all it takes to get keylogged.
- Dylan16807 15y ago
  I don't see how you could answer yes to that prompt without realizing it was the 'key has changed' prompt. Especially when half the ssh clients I've seen abort entirely when the key changes.
slug 15y ago
The issue of using ports above 1024 is that unless you redirect it to <1024 through the kernel firewall, if the ssh daemon crashes, a local user can run a daemon and compromise your keys/passwords. If you trust all your users, it should be fine though, but still...
- tedunangst 15y ago
  That's why the server has a private key, too, to identify itself to the user.
  - dspillett 15y ago
    You can't rely on that if you have other users connecting though. Too many people ignore even the starkest of warning messages. While that problem will not go away, keeping SSH on a port below 1024 is slightly safer and has no disadvantage other than it isn't as catchy as 2222 (and if you are using 2222, be aware that automated attacks often check that as well as 22 because of how common an alternative it is, so you might as well just use 22 and be done with it).

cd34 15y ago

> I do hope one takes the vigilance to set a port number sufficiently high up, and sufficiently random looking Hopefully not over port 1023. If a user gets on the system and crashes your ssh daemon through OOM killer or one of many other methods, that non-root user can then restart its own daemon and listen to that port that you put >1023 'for security reasons'. Accidentally answering yes when it says a new key was detected is all it takes to get keylogged.

Dylan16807 15y ago
I don't see how you could answer yes to that prompt without realizing it was the 'key has changed' prompt. Especially when half the ssh clients I've seen abort entirely when the key changes.

slug 15y ago

The issue of using ports above 1024 is that unless you redirect it to <1024 through the kernel firewall, if the ssh daemon crashes, a local user can run a daemon and compromise your keys/passwords. If you trust all your users, it should be fine though, but still...

tedunangst 15y ago
That's why the server has a private key, too, to identify itself to the user.
- dspillett 15y ago
  You can't rely on that if you have other users connecting though. Too many people ignore even the starkest of warning messages. While that problem will not go away, keeping SSH on a port below 1024 is slightly safer and has no disadvantage other than it isn't as catchy as 2222 (and if you are using 2222, be aware that automated attacks often check that as well as 22 because of how common an alternative it is, so you might as well just use 22 and be done with it).