* Configure http tunnelling if you want, it's trivially easy to set up with either Chrome or Firefox
The end result: an SSH connection that's always alive when I need it to be. When I open up my laptop's lid, it reconnects automatically, and because I've set up keys (without a passphrase) I do not have to do _anything_ and I'm all good to go. You can have a tmux attach command coded and you really do not have to do a thing.
Some other notes: KiTTY is a PuTTY fork, with many new extremely delicious features (hyper links, better clipboard support, etc.)
To tunnel your http traffic (for when you're in a public spot and would opt for basic security):
Connection > SSH > Tunnels. Add a dynamic port... and concordantly configure proxy settings on your browser's end. For Firefox you don't need any extensions... for Chrome this extension, in my experiences, is fairly decent: http://switchy.samabox.com/ -- these directions will work for both PuTTY and KiTTY.
>> SSH waits for the server's reply before showing you your own typing. That can make for a lousy user interface. Mosh is different: it gives an instant response to typing, deleting, and line editing. It does this adaptively and works even in full-screen programs like emacs and vim.
That's definitely pretty workable. One big problem with these TCP-level approaches is you have to KNOW the connection is dead for roaming to work. So if you just walk and roam from one 802.11 ESSID to another, it won't necessarily just work until the TCP connection actually dies. Mosh roams right away (and warns you when it hasn't heard in a while) -- even if the client doesn't know it's roamed (e.g. because it's tethered to a NAT and it's the NAT that has roamed).
I feel a bit guilty that my negative post is the top post, instead of a post discussing Mosh itself, most especially considering that Keith's responses throughout this thread have been quite elucidative and creditable. However I still think we should approach something as fundamental and important as remote access to our machines with great caution -- I'll be sticking with the tools tried and tested for years (and recommended by those I trust) for the foreseeable future.
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.
~~It all tunnels over SSH, what is the security risk compared to other protocols that also go over SSH?~~
(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.
It's not all over SSH. It uses SSH to authenticate and start a server daemon, which it then connects to over UDP. The UDP connection is not tunneled through the SSH connection.
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.
Except the nicest feature of Mosh is it makes the remote session feel more responsive. Is there anything out there (not just local echo) that does this?
If someone has your private ssh key, then they presumably have access to your client-side ssh configuration. This might prevent random Internet attacks, but this doesn't do much against a targeted attack (which is what someone will do once they jack your private key).
* Disable root ssh login
If your private key isn't authorized for root anyways, this doesn't really matter. This is just a point of general ssh security, not a protection against stolen private keys.
* Configure 'Single Packet Authorization and Port Knocking' --
http://www.cipherdyne.org/fwknop/
As with point 1, if someone is able to jack your private ssh key, they probably have enough access to view your ssh config.
* Have decent iptables rules. Use either fail2ban or denyhosts
with stringent rules, if you must, that ban on 3+ failed
logins.
If someone steals your private key, then they won't have any failed login attempts. I'm unsure how you feel this makes using a password-less private key anymore secure.
* Have a whitelist of acceptable IP's for ssh access
This presumably defeats the purpose of ssh mobility.
* 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:
Using a password (something you know) + private key (something you have) already is two-factor authentication.
* 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.
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...
All the great-grandparent's points are true, but irrelevant. There are plenty of ways to improve SSH security. None of them make having passwordless keys anything other than utterly brain-damagedly stupid.
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.
but the original objection was regarding using passwordless keys. again, the main concern here isn't about automated attacks, it's about targeted attacks. someone got your key, it doesn't matter that you're running on a non-standard port. they'll figure that out, if they're targeting your machine specifically.
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. :)
> 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.
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...
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).
Best not rely on any security once attackers have access to your physical system. Someone could even take your computer, install a keylogger, and get it back to you.
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?
Instead of fake security solutions, how about using something like keychain (http://www.gentoo.org/doc/en/keychain-guide.xml)? Simply kill ssh-agent as part of the sleep event and you can have security and convenience. Trivial to implement and actually accomplishes something--unlike changing server settings in a scenario where I probably have access to your computer, which already knows how to login to your server!
You realize you've effectively done the same thing as saving the password on the machine to auto-log-in with a password, right? The exception being it's harder to brute force the server (but you did mention server filtering, so forget that). They have ssh-agent for a reason.
If it's on OS X, keychains does a pretty good job of unlocking your (password secured) private key transparently. That's preferable to leaving your private key sitting around without a passphrase.
* Use tmux, a multi-plexer, so you never lose the state of a program
* Use KiTTY as an SSH client- http://kitty.9bis.com/ - enable 'Reconnect' options
* Configure http tunnelling if you want, it's trivially easy to set up with either Chrome or Firefox
The end result: an SSH connection that's always alive when I need it to be. When I open up my laptop's lid, it reconnects automatically, and because I've set up keys (without a passphrase) I do not have to do _anything_ and I'm all good to go. You can have a tmux attach command coded and you really do not have to do a thing.
Some other notes: KiTTY is a PuTTY fork, with many new extremely delicious features (hyper links, better clipboard support, etc.)
To tunnel your http traffic (for when you're in a public spot and would opt for basic security):
Connection > SSH > Tunnels. Add a dynamic port... and concordantly configure proxy settings on your browser's end. For Firefox you don't need any extensions... for Chrome this extension, in my experiences, is fairly decent: http://switchy.samabox.com/ -- these directions will work for both PuTTY and KiTTY.
>> SSH waits for the server's reply before showing you your own typing. That can make for a lousy user interface. Mosh is different: it gives an instant response to typing, deleting, and line editing. It does this adaptively and works even in full-screen programs like emacs and vim.
If real-time text rendering is a must for you, consider TRAMP: http://www.gnu.org/software/tramp/
Also consider using EmacsClient: http://www.emacswiki.org/emacs/EmacsClient
And for vim, apparently there's netrw: http://www.vim.org/scripts/script.php?script_id=1075