5 ms·

keys without passphrase? i hope they do not connect to a publicly available server with other people's data on it.

ghshephard 15y ago
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.
jimmyjim 15y ago
I knew someone would raise an issue there. 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/ 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-authenticator.html 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.
- zobzu 15y ago
  No. Just No. * 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.
  - jimmyjim 15y ago
    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...
- peterwwillis 15y ago
  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. p.s. using a password with keys is two factor
- pyre 15y ago
  * Use a non-standard ssh port 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.
- tdavis 15y ago
  Instead of fake security solutions, how about using something like keychain (http://www.gentoo.org/doc/en/keychain-guide.xml 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!

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.

jimmyjim 15y ago

I knew someone would raise an issue there. 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/ 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-authenticator.html 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.

zobzu 15y ago
No. Just No. * 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.
- jimmyjim 15y ago
  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...
peterwwillis 15y ago
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. p.s. using a password with keys is two factor
pyre 15y ago
* Use a non-standard ssh port 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.
tdavis 15y ago
Instead of fake security solutions, how about using something like keychain (http://www.gentoo.org/doc/en/keychain-guide.xml 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!