That said, Mosh does seem pretty interesting, -- and by golly, considering the terrible 3G speeds I get on my Android phone and how often the 'connectbot' app acts up, I will surely be giving this a try when I get time later this week.

(is it possible to strike text?) Thanks for the correction, I misunderstood how the protocol Mosh uses works. SSH is apparently used for initiation. Caution seems wise.

Am I missing something, because the mosh site seems to indicate it works on most things except Windows and the KiTTY site seems to say it works only on Windows so they don't even serve the same set of potential users.

autossh is a program to start a copy of ssh and monitor it, restarting it as necessary should it die or stop passing traffic. The idea is from rstunnel (Reliable SSH Tunnel), but implemented in C.

If you're that concerned about security, there are a handful of additional things you can do:

* Use a non-standard ssh port

* Disable root ssh login

* Configure 'Single Packet Authorization and Port Knocking' -- http://www.cipherdyne.org/fwknop/

* Have decent iptables rules. Use either fail2ban or denyhosts with stringent rules, if you must, that ban on 3+ failed logins.

* Have a whitelist of acceptable IP's for ssh access

* Use any system of 2-factor authentication. I'm partial to Google's Authenticator. Here're some directions to get that set up, if anyone is interested: http://guides.webbynode.com/articles/security/ubuntu-google-...

But seriously, if you have keys set up and someone manages to steal them... you've really got bigger things you should be focusing on.

  * Use a non-standard ssh port

  * Disable root ssh login

  * Configure 'Single Packet Authorization and Port Knocking' --
    http://www.cipherdyne.org/fwknop/

  * Have decent iptables rules. Use either fail2ban or denyhosts
    with stringent rules, if you must, that ban on 3+ failed
    logins.

  * Have a whitelist of acceptable IP's for ssh access

  * Use any system of 2-factor authentication. I'm partial to
    Google's Authenticator. Here're some directions to get that
    set up, if anyone is interested:   

* Use a non-standard ssh port <= not security. plus i bet you're on 2222.

* Fail2ban: useless for key auth, you don't remote brute keys like that

* 2 factor: that is ok

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.

2 factor or tiny cryptokeys are best.

With a reaction to that I expected overwhelming technical objections to everything the parent said. Based on the actual contents of your objections, I think you would have been better starting it Yes! Additionally...

Think of it as security through irregularity instead of security through obscurity. You are not making your box secure by changing the ssh port, but you are decreasing the number of automated attempts that will hit your ssh port, which could, in theory, reduce your security risk.

> * 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. :)

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.

If you have a Mac and secure your SSH keys with Keychain someone could take it, crack it open, freeze your memory, and dump it.

Two factor is definitely the best you could do on this front but who sets up two factor with SSH?

p.s. using a password with keys is two factor