7 ms·

KeyBox: A better way to SSH

82 points by escapologybb 12y ago

pritambaral 12y ago
So, fanterm[1] for the web. [1]: http://www.stearns.org/fanout/README.html http://www.stearns.org/fanout/README.html
- devnonymous 12y ago
  Thanks ! This is nice to know. I'm sure this will be useful.
- SpaceInvader 12y ago
  https://code.google.com/p/parallel-ssh/ https://code.google.com/p/parallel-ssh/
- Argorak 12y ago
  I've also seen clusterssh: http://freecode.com/projects/clusterssh http://freecode.com/projects/clusterssh
  - res0nat0r 12y ago
    There are tons of parallel shells out there...each seem to have their good and bad features: http://www.stearns.org/fanout/README.html http://www.stearns.org/fanout/README.html http://sourceforge.net/projects/mussh/ http://sourceforge.net/projects/mussh/ https://code.google.com/p/parallel-ssh/ https://code.google.com/p/parallel-ssh/ https://github.com/ndenev/mpssh https://github.com/ndenev/mpssh https://code.google.com/p/csshx/ https://code.google.com/p/csshx/ http://taktuk.gforge.inria.fr/kanif/ http://taktuk.gforge.inria.fr/kanif/
johnwards 12y ago
Big fan of keybox, used it massively at my old place. So handy to remove contractors from servers at a push of button.
jpgvm 12y ago
Single point of compromise. :( I wish people would just stop with these things. The appropriate way to be able to manage many users is called LDAP, it's been LDAP for decades and it's unlikely to change. These days it's super easy to use SSH keys with LDAP, still using the standard openssh-lpk schema but now not requiring any patches to OpenSSH itself, just need to use the AuthorizedKeysCommand and an appropriate helper (which normally ships with distro). By forgoing the above gateway style thing you now have central key management without a single point of compromise. Revoking a key is as simple as deleting it from LDAP or disabling that users account.
- pmoriarty 12y ago
  "These days it's super easy to use SSH keys with LDAP" Are there any articles that go in to detail on exactly how to do this?
  - devonkim 12y ago
    Digital Ocean has a ton of systems management guides aimed at developers first, but they're pretty reasonable for small scale setups and when you have no clue where to start. https://www.digitalocean.com/community/tutorials/how-to-authenticate-client-computers-using-ldap-on-an-ubuntu-12-04-vps https://www.digitalocean.com/community/tutorials/how-to-auth...
  - subway 12y ago
    FreeIPA has provided this for a while: https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/user-keys.html https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_... More recently the AuthorizedKeysCommand patch has made it's way into Ubuntu's sshd, similarly allowing sshd to call script that looks up a user's authorized keys from LDAP.
    - jpgvm 12y ago
      More correctly AuthorizedKeysCommand is in mainline OpenSSH, thus every recent release of all major distros have it.
phaemon 12y ago
This is the kind of thing I currently use Ansible for. Is there a big advantage to using KeyBox for this instead?
- johnwards 12y ago
  Ansible is a good idea for something like that. The groups is a handy feature. Also the multiple terminal session stuff is rather useful in an emergency patch across a ton of servers. (Drupal patch last month it was very handy)
- aftbit 12y ago
  I've used fabric for basically the same thing. Basically just runs shell commands across lots of servers. Our 5-person operation used DigitalOcean with a custom image that contained about 80% of our config, and then a fabric script that managed things like deploys and emergency patches.
perlgeek 12y ago
Adding the browser to the mix won't make it much more secure, I fear.
- _cbdev 12y ago
  I especially like the absurdity presented in this diagram: http://sshkeybox.com/img/keybox_dia.jpg http://sshkeybox.com/img/keybox_dia.jpg Not only does it create a single point of failure in the Administration, but the third case illustrates that this is some kind of feature, advertising blocking normal SSH traffic to the server network, instead replacing it with HTTPS traffic. Please don't do this. Just accept SSH and learn to deal with it. If you can't, maybe systems administration is not for you and you should pay someone to do it.
  - kavanutz 12y ago
    It's definitely not for everyone. Inbound/outbound SSH is usually blocked on corp networks. One of the reasons is you can tunnel/forward ports and expose the internal network. HTTPS takes that away. Plus you can't copy files off the server and the idea is you can audit what is being done. Depends on what the threat is in IMHO.
    - opejn 12y ago
      You can tunnel through HTTPS too, given a client/server pair that supports HTTP CONNECT. Conversely it's possible to disable the SSH port forwarding function. From the firewall's point of view, they ought to be equally risky.
    - jpgvm 12y ago
      Corp networks are almost never a shining example of network design or security. Most people that work doing that sort of thing are the checkbox type and will block SSH (and other protocols) because it gives them some sense of warm and fuzzies. The reality is this is stupid and just leads to people working around the problem. Take for example corkscrew, which allows you to tunnel SSH over HTTPS proxies, without losing any of it's port forwarding or other juicy features. If you feel like you really need to embarass them you can ofcourse run something like sshuttle over the top providing automatic VPN routing over this rogue SSH tunnel. Worse yet they might install KeyBox on their AWS deployment because they don't have SSH outbound, which then promptly gets pwned because it's a relatively unproven Java web application rather than a battle-hardened unix staple (i.e sshd). Corp networks and infosec departments are a joke. In terms of auditing all you need to do is make proper use of *nix permission model and then enable sudo input/output logging and control access to sudo via LDAP groups. Send all of your sudo logs to centralized logging system like Splunk/ELK/fluentd/Flume etc.
VieElm 12y ago
It's a neat system, but I also like that it's written in Java. Given all the new things coming out with Go, Scala, clojure node.js and what not it's inspiring to see people still also building things on top of the Java platform with just straight up Java. I haven't used struts but it doesn't look that crazy when looking at this code. It looks pretty sane.
- skavanagh 12y ago
  Awesome, appreciate that!!!
gfodor 12y ago
Does anyone know of a web-based ssh solution that has good enough termcaps to allow me to enjoyably use vim + tmux inside of a web browser? Also, it can't use browser extensions (but can use plugins like flash/java/etc.)
- gnosek 12y ago
  You might give shellinabox a try.
- ryan-c 12y ago
  https://github.com/macton/hterm https://github.com/macton/hterm I use the chrome extension version on my chromebook quite heavily, no real complaints.
mrmondo 12y ago
Sounds like an easy target to gain control of someone's entire network, between that and Java, I'm not convinced.
- kgilpin 12y ago
  If ops can't keep critical systems secured, then it doesn't matter what approach you take.
strzalek 12y ago
tmux-cssh
deleted 12y ago
[deleted]
xorcist 12y ago
If you have a large enough installation to make use of such a thing you should absolutely not go distributing keys in this homecooked way. Either you already have an authentication infrastructure in place, such as Kerberos, in which case you should absolutely use that for SSH as well and not roll your own. If haven't, and your problem concerns mainly SSH, you should absolutely use the PKI mode of OpenSSH unless you have some reason not to. It has existed since 5.3 and works like you would expect, with a central CA and CRL. Start with a good overwiew such as http://blog.habets.pp.se/2011/07/OpenSSH-certificates http://blog.habets.pp.se/2011/07/OpenSSH-certificates (or some other Google hit), then consult the official documentation for a few more details.
rdl 12y ago
Forcing all traffic through a bastion host (especially for things like logging) can be a good practice -- especially if it's uncommon for users to need to be able to log into machines (e.g. a production network), but where you want to retain access. For something where it's more "lots of users need to connect to lots of boxes regularly", I'd prefer kerberos or LDAP/AD (to manage keys). There's also a good argument against ssh keys anyway -- they don't have expiration dates, don't necessarily provide 2fa, don't have good secure storage on client devices, etc. (In the long run I'd probably go with a client-device managed credential, some kind of client-device-specific biometric or other auth through a secure path, and some scheme to ensure users don't authenticate via a tampered client device. It's a hard problem in a mobile/laptop environment.)
- cpach 12y ago
  There are solutions in place to combine SSH keys with 2FA. E.g. Duo Security has a solution for that: https://www.duosecurity.com/blog/ssh-keys-that-call-you-back https://www.duosecurity.com/blog/ssh-keys-that-call-you-back [Edit: Removed redundant comments.]
- e12e 12y ago
  I'd say ssh keys generally don't have 2fa. A passphrase doesn't really turn a ssh-key into 2fa. It's still really only "something you have (access to)": the plaintext of the private half of the key. Granted, you can use ssh-keys with tokens -- my recommendation is to use encrypted ssh-keys paired with a recent[1] openssh server that allows stacking OTP on top, for 2fa with the RequiredAuthentication-directive (well, OTP is generally code for: can demonstrate access to OTP secret) -- but at least it is rather easy to store the two on separate devices (say a phone, and on the filesystem of your workstation/laptop). Not really maximum security, but quite a lot better than traditional passwords. Until you store both the key and the authenticator on your phone, in order to use ssh from your phone. At which point you end up with "rather convoluted 1fa" -- which might still be marginally better than traditional passwords (along with a warm fuzzy feeling of false security :-). Other than that I've been looking into using openssh certificates with openssh, but it still looks like it's rather complicated -- and for a single-/few-user setup it's questionable if the expiration etc really adds much actual security. Maybe the best would be to apply some of the kerberos design lessons to openssh with certificates, issuing short-lived certs much like kerberos ticket-granting tickets (so have an easy way to get a user certificate that's valid for 8 hours or so...). Not sure the added complexity would be worth it, though... [1] https://blog.flameeyes.eu/2013/03/openssh-6-2-adds-support-for-two-factor-authentication https://blog.flameeyes.eu/2013/03/openssh-6-2-adds-support-f...
dustinrcollins 12y ago
conjur is a more robust solution for SSH management and avoids the single point of failure. Treating services and code as first-class citizens is not something LDAP excels at. http://www.conjur.net http://www.conjur.net
- jjmason 12y ago
  It's worth noting that Conjur's SSH solution is built around familiar unix tools like pam-ldap and AuthorizedKeysCommand. Why reinvent the wheel?
fsniper 12y ago
Why is the need to move everything into a browser? Browsers are not the OS. We upgraded Zawinski's Law of Software Development into the next level. http://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski.27s_law_of_software_envelopment http://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski.27s_law...
- theandrewbailey 12y ago
  I think what you're looking for is Atwood's Law: Any application that can be written in JavaScript, will eventually be written in JavaScript. http://blog.codinghorror.com/the-principle-of-least-power/ http://blog.codinghorror.com/the-principle-of-least-power/
psteynza 12y ago
Today on HN: Another Hipster webdev reinventing the wheel poorly due to insufficient Unix clue.
feld 12y ago
If you want better control of your enterprise SSH connections you should use FUDO http://wheel.pl/en/produkty/fudo/index.html# http://wheel.pl/en/produkty/fudo/index.html#

82 points by escapologybb 12y ago

pritambaral 12y ago

So, fanterm[1] for the web. [1]: http://www.stearns.org/fanout/README.html http://www.stearns.org/fanout/README.html

devnonymous 12y ago
Thanks ! This is nice to know. I'm sure this will be useful.
SpaceInvader 12y ago
https://code.google.com/p/parallel-ssh/ https://code.google.com/p/parallel-ssh/
Argorak 12y ago
I've also seen clusterssh: http://freecode.com/projects/clusterssh http://freecode.com/projects/clusterssh
- res0nat0r 12y ago
  There are tons of parallel shells out there...each seem to have their good and bad features: http://www.stearns.org/fanout/README.html http://www.stearns.org/fanout/README.html http://sourceforge.net/projects/mussh/ http://sourceforge.net/projects/mussh/ https://code.google.com/p/parallel-ssh/ https://code.google.com/p/parallel-ssh/ https://github.com/ndenev/mpssh https://github.com/ndenev/mpssh https://code.google.com/p/csshx/ https://code.google.com/p/csshx/ http://taktuk.gforge.inria.fr/kanif/ http://taktuk.gforge.inria.fr/kanif/

johnwards 12y ago

Big fan of keybox, used it massively at my old place. So handy to remove contractors from servers at a push of button.

jpgvm 12y ago

Single point of compromise. :( I wish people would just stop with these things. The appropriate way to be able to manage many users is called LDAP, it's been LDAP for decades and it's unlikely to change. These days it's super easy to use SSH keys with LDAP, still using the standard openssh-lpk schema but now not requiring any patches to OpenSSH itself, just need to use the AuthorizedKeysCommand and an appropriate helper (which normally ships with distro). By forgoing the above gateway style thing you now have central key management without a single point of compromise. Revoking a key is as simple as deleting it from LDAP or disabling that users account.

pmoriarty 12y ago
"These days it's super easy to use SSH keys with LDAP" Are there any articles that go in to detail on exactly how to do this?
- devonkim 12y ago
  Digital Ocean has a ton of systems management guides aimed at developers first, but they're pretty reasonable for small scale setups and when you have no clue where to start. https://www.digitalocean.com/community/tutorials/how-to-authenticate-client-computers-using-ldap-on-an-ubuntu-12-04-vps https://www.digitalocean.com/community/tutorials/how-to-auth...
- subway 12y ago
  FreeIPA has provided this for a while: https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/user-keys.html https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_... More recently the AuthorizedKeysCommand patch has made it's way into Ubuntu's sshd, similarly allowing sshd to call script that looks up a user's authorized keys from LDAP.
  - jpgvm 12y ago
    More correctly AuthorizedKeysCommand is in mainline OpenSSH, thus every recent release of all major distros have it.

phaemon 12y ago

This is the kind of thing I currently use Ansible for. Is there a big advantage to using KeyBox for this instead?

johnwards 12y ago
Ansible is a good idea for something like that. The groups is a handy feature. Also the multiple terminal session stuff is rather useful in an emergency patch across a ton of servers. (Drupal patch last month it was very handy)
aftbit 12y ago
I've used fabric for basically the same thing. Basically just runs shell commands across lots of servers. Our 5-person operation used DigitalOcean with a custom image that contained about 80% of our config, and then a fabric script that managed things like deploys and emergency patches.

perlgeek 12y ago

Adding the browser to the mix won't make it much more secure, I fear.

_cbdev 12y ago
I especially like the absurdity presented in this diagram: http://sshkeybox.com/img/keybox_dia.jpg http://sshkeybox.com/img/keybox_dia.jpg Not only does it create a single point of failure in the Administration, but the third case illustrates that this is some kind of feature, advertising blocking normal SSH traffic to the server network, instead replacing it with HTTPS traffic. Please don't do this. Just accept SSH and learn to deal with it. If you can't, maybe systems administration is not for you and you should pay someone to do it.
- kavanutz 12y ago
  It's definitely not for everyone. Inbound/outbound SSH is usually blocked on corp networks. One of the reasons is you can tunnel/forward ports and expose the internal network. HTTPS takes that away. Plus you can't copy files off the server and the idea is you can audit what is being done. Depends on what the threat is in IMHO.
  - opejn 12y ago
    You can tunnel through HTTPS too, given a client/server pair that supports HTTP CONNECT. Conversely it's possible to disable the SSH port forwarding function. From the firewall's point of view, they ought to be equally risky.
  - jpgvm 12y ago
    Corp networks are almost never a shining example of network design or security. Most people that work doing that sort of thing are the checkbox type and will block SSH (and other protocols) because it gives them some sense of warm and fuzzies. The reality is this is stupid and just leads to people working around the problem. Take for example corkscrew, which allows you to tunnel SSH over HTTPS proxies, without losing any of it's port forwarding or other juicy features. If you feel like you really need to embarass them you can ofcourse run something like sshuttle over the top providing automatic VPN routing over this rogue SSH tunnel. Worse yet they might install KeyBox on their AWS deployment because they don't have SSH outbound, which then promptly gets pwned because it's a relatively unproven Java web application rather than a battle-hardened unix staple (i.e sshd). Corp networks and infosec departments are a joke. In terms of auditing all you need to do is make proper use of *nix permission model and then enable sudo input/output logging and control access to sudo via LDAP groups. Send all of your sudo logs to centralized logging system like Splunk/ELK/fluentd/Flume etc.

VieElm 12y ago

It's a neat system, but I also like that it's written in Java. Given all the new things coming out with Go, Scala, clojure node.js and what not it's inspiring to see people still also building things on top of the Java platform with just straight up Java. I haven't used struts but it doesn't look that crazy when looking at this code. It looks pretty sane.

skavanagh 12y ago
Awesome, appreciate that!!!

gfodor 12y ago

Does anyone know of a web-based ssh solution that has good enough termcaps to allow me to enjoyably use vim + tmux inside of a web browser? Also, it can't use browser extensions (but can use plugins like flash/java/etc.)

gnosek 12y ago
You might give shellinabox a try.
ryan-c 12y ago
https://github.com/macton/hterm https://github.com/macton/hterm I use the chrome extension version on my chromebook quite heavily, no real complaints.

mrmondo 12y ago

Sounds like an easy target to gain control of someone's entire network, between that and Java, I'm not convinced.

kgilpin 12y ago
If ops can't keep critical systems secured, then it doesn't matter what approach you take.

strzalek 12y ago

tmux-cssh

deleted 12y ago

[deleted]

xorcist 12y ago

If you have a large enough installation to make use of such a thing you should absolutely not go distributing keys in this homecooked way. Either you already have an authentication infrastructure in place, such as Kerberos, in which case you should absolutely use that for SSH as well and not roll your own. If haven't, and your problem concerns mainly SSH, you should absolutely use the PKI mode of OpenSSH unless you have some reason not to. It has existed since 5.3 and works like you would expect, with a central CA and CRL. Start with a good overwiew such as http://blog.habets.pp.se/2011/07/OpenSSH-certificates http://blog.habets.pp.se/2011/07/OpenSSH-certificates (or some other Google hit), then consult the official documentation for a few more details.

rdl 12y ago

Forcing all traffic through a bastion host (especially for things like logging) can be a good practice -- especially if it's uncommon for users to need to be able to log into machines (e.g. a production network), but where you want to retain access. For something where it's more "lots of users need to connect to lots of boxes regularly", I'd prefer kerberos or LDAP/AD (to manage keys). There's also a good argument against ssh keys anyway -- they don't have expiration dates, don't necessarily provide 2fa, don't have good secure storage on client devices, etc. (In the long run I'd probably go with a client-device managed credential, some kind of client-device-specific biometric or other auth through a secure path, and some scheme to ensure users don't authenticate via a tampered client device. It's a hard problem in a mobile/laptop environment.)

cpach 12y ago
There are solutions in place to combine SSH keys with 2FA. E.g. Duo Security has a solution for that: https://www.duosecurity.com/blog/ssh-keys-that-call-you-back https://www.duosecurity.com/blog/ssh-keys-that-call-you-back [Edit: Removed redundant comments.]
e12e 12y ago
I'd say ssh keys generally don't have 2fa. A passphrase doesn't really turn a ssh-key into 2fa. It's still really only "something you have (access to)": the plaintext of the private half of the key. Granted, you can use ssh-keys with tokens -- my recommendation is to use encrypted ssh-keys paired with a recent[1] openssh server that allows stacking OTP on top, for 2fa with the RequiredAuthentication-directive (well, OTP is generally code for: can demonstrate access to OTP secret) -- but at least it is rather easy to store the two on separate devices (say a phone, and on the filesystem of your workstation/laptop). Not really maximum security, but quite a lot better than traditional passwords. Until you store both the key and the authenticator on your phone, in order to use ssh from your phone. At which point you end up with "rather convoluted 1fa" -- which might still be marginally better than traditional passwords (along with a warm fuzzy feeling of false security :-). Other than that I've been looking into using openssh certificates with openssh, but it still looks like it's rather complicated -- and for a single-/few-user setup it's questionable if the expiration etc really adds much actual security. Maybe the best would be to apply some of the kerberos design lessons to openssh with certificates, issuing short-lived certs much like kerberos ticket-granting tickets (so have an easy way to get a user certificate that's valid for 8 hours or so...). Not sure the added complexity would be worth it, though... [1] https://blog.flameeyes.eu/2013/03/openssh-6-2-adds-support-for-two-factor-authentication https://blog.flameeyes.eu/2013/03/openssh-6-2-adds-support-f...

dustinrcollins 12y ago

conjur is a more robust solution for SSH management and avoids the single point of failure. Treating services and code as first-class citizens is not something LDAP excels at. http://www.conjur.net http://www.conjur.net

jjmason 12y ago
It's worth noting that Conjur's SSH solution is built around familiar unix tools like pam-ldap and AuthorizedKeysCommand. Why reinvent the wheel?

fsniper 12y ago

Why is the need to move everything into a browser? Browsers are not the OS. We upgraded Zawinski's Law of Software Development into the next level. http://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski.27s_law_of_software_envelopment http://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski.27s_law...

theandrewbailey 12y ago
I think what you're looking for is Atwood's Law: Any application that can be written in JavaScript, will eventually be written in JavaScript. http://blog.codinghorror.com/the-principle-of-least-power/ http://blog.codinghorror.com/the-principle-of-least-power/

psteynza 12y ago

Today on HN: Another Hipster webdev reinventing the wheel poorly due to insufficient Unix clue.

feld 12y ago

If you want better control of your enterprise SSH connections you should use FUDO http://wheel.pl/en/produkty/fudo/index.html# http://wheel.pl/en/produkty/fudo/index.html#