> 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.
Re:Mosh: SSH for 2012
by Dylan16807 on Monday April 09, 2012 @10:01PM
(#3820312)
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.
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...
Re:Mosh: SSH for 2012
by tedunangst on Tuesday April 10, 2012 @12:38AM
(#3820706)
That's why the server has a private key, too, to identify itself to the user.
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).
> * 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. :)