KeyBox: A better way to SSH(sshkeybox.com)
sshkeybox.com
KeyBox: A better way to SSH
http://sshkeybox.com/
56 comments
"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?
Are there any articles that go in to detail on exactly how to do this?
FreeIPA has provided this for a while:
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.
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.
This is a great perl script that makes for an easy AuthorizedKeysCommand [1]. SSH with LDAP is definitely an easier way to distribute keys and manage permissions than logging into each box. It's also a single point of failure in a way, but you can at least keep it completely inside a private network, and LDAP is well-known and easy to secure.
1. https://github.com/AndriiGrytsenko/openssh-ldap-publickey
1. https://github.com/AndriiGrytsenko/openssh-ldap-publickey
More correctly AuthorizedKeysCommand is in mainline OpenSSH, thus every recent release of all major distros have it.
The IPA in FreeIPA stands for "Identity, Policy, and Audit". Yet on the Roadmap page (http://www.freeipa.org/page/Roadmap), enjoy this statement:
"The audit component of the project will remain deferred until further notice. You can see the reasoning in the About page."
Therefore, for enterprise purposes, I can't see why anyone would take FreeIPA seriously.
"The audit component of the project will remain deferred until further notice. You can see the reasoning in the About page."
Therefore, for enterprise purposes, I can't see why anyone would take FreeIPA seriously.
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-auth...
Some people use Kerberos instead of LDAP but there's far less people that have actually rolled out a Kerberos implementation that's not related to Active Directory than LDAP. Either way, LDAP and/or Kerberos are just re-inventing wheels that have not a whole lot of value in re-inventing / "innovating" partly because disparate identity and authorization management systems are an immense pain to deal with scaling beyond a small to medium size company and everyone would rather use what's well known first before they think they're smart enough to roll their own. This is pretty typical with developers versus systems management folks though culturally though I'd gather. It just pisses me off when I have to fix something some smartass thought "simpler = better" meant that he should roll his own thing instead of learning how people do it first and THEN rolling his own.
The thing about kerberized ssh that I've wondered, do you really want your kerberos session to open up ssh access to all the boxes in the enterprise you have an account on?
I'm not quite sure what you mean with this concern but Kerberos is really flexible and a Kerberos realm could act a lot more like roles than by domains (which is the typical correlation). Most enterprise networks I've worked with are extremely fragmented from decades of competing business units rolling their own thing and so the default in most enterprise networks is already quite restricted in many respects, and that is ironically a bit of a help for security by reducing the impact crater of an intrusion. Also, we have plenty of different accounts used by one physical user all the time, so nothing keeps administrators from requiring different accounts for different roles on top of realms. I don't necessarily mean that you need to create user1.support and user1.dev in the same domain but Kerberos solves a lot of problems that ssh alone just doesn't answer, which is a big reason why I reach for that after I have an ok ssh setup.
Nothing says you can't put resources in multiple Kerberos realms either. Then you can establish a digraph of trust chains across Kerberos realms to transfer tickets across realms based upon some business rules.
There's many reasons that Active Directory (LDAP + Kerberos + some magical bits of quirks and features) is the gold standard for large corporations and the reason is not "nobody got fired for buying Microsoft."
Nothing says you can't put resources in multiple Kerberos realms either. Then you can establish a digraph of trust chains across Kerberos realms to transfer tickets across realms based upon some business rules.
There's many reasons that Active Directory (LDAP + Kerberos + some magical bits of quirks and features) is the gold standard for large corporations and the reason is not "nobody got fired for buying Microsoft."
Kerberos is also acceptable, it is however much more complicated than LDAP for the average sysadmin to understand.
You also need to teach your users how to get kerberos tickets and setup keytab etc. Chances are if you are using kerberos you also have LDAP however.
You also need to teach your users how to get kerberos tickets and setup keytab etc. Chances are if you are using kerberos you also have LDAP however.
The thing about keybox is that it's nice and fast to get better. For someone that doesn't have an ops team, or even an ops person, it is a neat solution.
Yes you need to be careful with it, I ran it on an internal VM, with only 2 users who had access to the admin console.
I'd love to see something as simple to use as keybox based around LDAP, I've had a google and can't see anything.
Yes you need to be careful with it, I ran it on an internal VM, with only 2 users who had access to the admin console.
I'd love to see something as simple to use as keybox based around LDAP, I've had a google and can't see anything.
If you're a very small operation, using a configuration management tool to provision users with SSH keys is pretty simple.
IIRC the ”original” SSH server (from SSH Communications Security Oyj) can handle key management. Is there anyone who has tried it and want to share their experiences?
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 (or some other Google hit), then consult the official documentation for a few more details.
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 (or some other Google hit), then consult the official documentation for a few more details.
This is the kind of thing I currently use Ansible for. Is there a big advantage to using KeyBox for this instead?
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.
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)
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)
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.)
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.)
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-f...
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-f...
You can use SSH AuthenticationMethods to require a password as well, for 2FA in a sense - something you have (SSH key), something you know (password). You could even get more complex and pair with FreeIPA/PrivacyIDEA for 3(?)FA with Google Authenticator, RSA tokens, email, text, Yubikey, etc., via RADIUS.
Certainly. But password+key really isn't 2fa, and a lot of people seem to mix those up (not saying you do). Given realistic constraints, and possibly no real auth-token - I find encrypted-key+otp strikes a good balance between what can be achieved, and convenience.
Assuming the ssh key is used with a pass-phrase, it's hard to imagine any real scenario where the key is compromised, but not the password.
I suppose an unencrypted key might be lifted from compromised backups (but not passwords, assuming secure passwords, and secure hashing -- defeating even off-line brute-force). However, an encrypted key should be at least as secure (again assuming a "secure" pass-phrase).
OTP (especially on a separate device, such as a phone) has the benefit of not being compromised (permanently) by a keyboard-logger/root access on the terminal. On the other hand it is probably vulnerable to an attack on the device.
I also find it comparatively easy to manage one OTP secret per account, vs passwords, where they tend to end up becoming opaque tokens (ie: managed by a password manager -- and by extension, no longer "something you know", but rather "something you have"...).
One of the worst part of passwords, is that even if it is stored securely (salted, hashed, stretched) -- it is essentially a shared secret: the server has the opportunity to log it on every login/use. While a secret key can remain secret while you use it (as long as your terminal is secure).
I wonder if there's been any work towards asymmetric-key (T)OTP? I suppose it shouldn't be to hard, but I'm not aware of any established systems for it. Should be enough to use ECDH to derive a symmetric key, and then use that (or a derivative) with traditional TOTP.
Just found this[1] -- not sure if it's really relevant, though. Strange to find something like this with such a recent filing date on it, though.
http://www.google.com/patents/WO2014141263A1?cl=en
Assuming the ssh key is used with a pass-phrase, it's hard to imagine any real scenario where the key is compromised, but not the password.
I suppose an unencrypted key might be lifted from compromised backups (but not passwords, assuming secure passwords, and secure hashing -- defeating even off-line brute-force). However, an encrypted key should be at least as secure (again assuming a "secure" pass-phrase).
OTP (especially on a separate device, such as a phone) has the benefit of not being compromised (permanently) by a keyboard-logger/root access on the terminal. On the other hand it is probably vulnerable to an attack on the device.
I also find it comparatively easy to manage one OTP secret per account, vs passwords, where they tend to end up becoming opaque tokens (ie: managed by a password manager -- and by extension, no longer "something you know", but rather "something you have"...).
One of the worst part of passwords, is that even if it is stored securely (salted, hashed, stretched) -- it is essentially a shared secret: the server has the opportunity to log it on every login/use. While a secret key can remain secret while you use it (as long as your terminal is secure).
I wonder if there's been any work towards asymmetric-key (T)OTP? I suppose it shouldn't be to hard, but I'm not aware of any established systems for it. Should be enough to use ECDH to derive a symmetric key, and then use that (or a derivative) with traditional TOTP.
Just found this[1] -- not sure if it's really relevant, though. Strange to find something like this with such a recent filing date on it, though.
http://www.google.com/patents/WO2014141263A1?cl=en
I like keys with passphrases, although their security is somewhat questionable as you say. At least it prevents the scenario where the key is accidentally exposes somewhere via a lost storage device / bad scp command / whatever. And sometimes, for one-off non-prod servers, I don't bother with setting up AuthenticationMethods to require a separate password.
I think key + pass + OTP is the best of all worlds, except convenience. But in my opinion, it should be a pain to get into your servers, especially if they hold sensitive data. I am especially a big fan of hardware tokens like yubikeys; the best part is, you know when you lose them and can rotate keys. Even with Google Authenticator, you are not quite sure if the keys can be lifted from your phone.
I think key + pass + OTP is the best of all worlds, except convenience. But in my opinion, it should be a pain to get into your servers, especially if they hold sensitive data. I am especially a big fan of hardware tokens like yubikeys; the best part is, you know when you lose them and can rotate keys. Even with Google Authenticator, you are not quite sure if the keys can be lifted from your phone.
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
[Edit: Removed redundant comments.]
[Edit: Removed redundant comments.]
I've loaded SSH keys onto SafeNet tokens before. That's hardware 2FA (you need a password to use the token)
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...
We upgraded Zawinski's Law of Software Development into the next level.
http://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski.27s_law...
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/
Any application that can be written in JavaScript, will eventually be written in JavaScript.
http://blog.codinghorror.com/the-principle-of-least-power/
Adding the browser to the mix won't make it much more secure, I fear.
I especially like the absurdity presented in this diagram:
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.
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.
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.
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.
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.
I'm all for your contempt of corporate network security policies honestly, but I think they're typically trying to stop most users that are not particularly sophisticated and basically assume that anyone with half a brain will get around eventually. That's why audit policies are much more rigorously enforced than network tunneling restrictions, for example.
I regularly defeat most policies if I really have to get work done but the real deterrent, sadly, is for employees to be fearful of getting caught and having to deal with the immense mountain of bullshit paperwork and training that is likely to follow. Completely meaningless paperwork filling is a form of disciplinary action in my opinion.
I regularly defeat most policies if I really have to get work done but the real deterrent, sadly, is for employees to be fearful of getting caught and having to deal with the immense mountain of bullshit paperwork and training that is likely to follow. Completely meaningless paperwork filling is a form of disciplinary action in my opinion.
For example, at the US Air Force, the following policies are in place:
* Use of SSH is discouraged, because the traffic is encrypted, and the Air Force wants to be able to read all the traffic in and out of boxes.
* If you do get a waiver for SSH, the system admins require you to hand over all your SSH private keys, so that they can decrypt the traffic, read it, and re-encrypt it.
* Use of SSH is discouraged, because the traffic is encrypted, and the Air Force wants to be able to read all the traffic in and out of boxes.
* If you do get a waiver for SSH, the system admins require you to hand over all your SSH private keys, so that they can decrypt the traffic, read it, and re-encrypt it.
Yup! Make administration less confidential, but try and keep it as secure as possible. Inside attacks are a big problem in the financial industry too. I like the idea of controlling it through a hardened web-app, but may need a little help getting there.
Why? You can protect against insider threat by auditing the target system itself and streaming said audit logs to write only media.
Building a single point of compromise has no advantages over this and many disadvantages beyond just security.
Building a single point of compromise has no advantages over this and many disadvantages beyond just security.
Auditing can be a deterrent to an attack, but won't necessarily protect you against it. It's a good way of letting you know what has happened after the fact.
Think if you had a DB with financials (credit cards and such) in a isolated DMZ with SSH inbound/outbound blocked
How can you dump the DB and copy it off if all the traffic was "proxied" through this?? It's not like you can scp a tarball anywhere.
You can't forward ports and expose the DB outside of the DMZ either.
And it doesn't take admins to setup auditing or disable forwarding, you have physically disabled it.
I got to say I don't understand the single point of compromise thing. A single point of failure is a bad, but the less points of compromise the better. You identify your critical systems, you protect your critical systems. Spreading things out doesn't make you more secure.
Here is an old white paper on some things to think about SSH in your infrastructure.
http://www.sans.org/reading-room/whitepapers/vpns/security-i...
Your right in saying this is an unproven application!
Think if you had a DB with financials (credit cards and such) in a isolated DMZ with SSH inbound/outbound blocked
How can you dump the DB and copy it off if all the traffic was "proxied" through this?? It's not like you can scp a tarball anywhere.
You can't forward ports and expose the DB outside of the DMZ either.
And it doesn't take admins to setup auditing or disable forwarding, you have physically disabled it.
I got to say I don't understand the single point of compromise thing. A single point of failure is a bad, but the less points of compromise the better. You identify your critical systems, you protect your critical systems. Spreading things out doesn't make you more secure.
Here is an old white paper on some things to think about SSH in your infrastructure.
http://www.sans.org/reading-room/whitepapers/vpns/security-i...
Your right in saying this is an unproven application!
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.
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.
Awesome, appreciate that!!!
[deleted]
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
It's worth noting that Conjur's SSH solution is built around familiar unix tools like pam-ldap and AuthorizedKeysCommand. Why reinvent the wheel?
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.)
https://github.com/macton/hterm
I use the chrome extension version on my chromebook quite heavily, no real complaints.
I use the chrome extension version on my chromebook quite heavily, no real complaints.
You might give shellinabox a try.
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#
Big fan of keybox, used it massively at my old place. So handy to remove contractors from servers at a push of button.
tmux-cssh
Today on HN: Another Hipster webdev reinventing the wheel poorly due to insufficient Unix clue.
So, fanterm[1] for the web.
[1]: http://www.stearns.org/fanout/README.html
[1]: http://www.stearns.org/fanout/README.html
I've also seen clusterssh: http://freecode.com/projects/clusterssh
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://sourceforge.net/projects/mussh/
https://code.google.com/p/parallel-ssh/
https://github.com/ndenev/mpssh
https://code.google.com/p/csshx/
http://taktuk.gforge.inria.fr/kanif/
http://www.stearns.org/fanout/README.html
http://sourceforge.net/projects/mussh/
https://code.google.com/p/parallel-ssh/
https://github.com/ndenev/mpssh
https://code.google.com/p/csshx/
http://taktuk.gforge.inria.fr/kanif/
Thanks ! This is nice to know. I'm sure this will be useful.
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.