
KeyBox: A better way to SSH - escapologybb
http://sshkeybox.com/
======
jpgvm
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
_" 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?

~~~
subway
FreeIPA has provided this for a while:

[https://docs.fedoraproject.org/en-
US/Fedora/18/html/FreeIPA_...](https://docs.fedoraproject.org/en-
US/Fedora/18/html/FreeIPA_Guide/user-keys.html)

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.

~~~
STRML
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](https://github.com/AndriiGrytsenko/openssh-ldap-publickey)

------
xorcist
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.

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

~~~
aftbit
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.

------
rdl
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.)

~~~
e12e
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...](https://blog.flameeyes.eu/2013/03/openssh-6-2-adds-support-for-
two-factor-authentication)

~~~
STRML
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.

~~~
e12e
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](http://www.google.com/patents/WO2014141263A1?cl=en)

~~~
STRML
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.

------
fsniper
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...](http://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski.27s_law_of_software_envelopment)

~~~
theandrewbailey
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/)

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

~~~
_cbdev
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
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.

~~~
jpgvm
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.

~~~
kgilpin
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.

~~~
skavanagh
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.

~~~
jpgvm
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.

~~~
skavanagh
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...](http://www.sans.org/reading-
room/whitepapers/vpns/security-implications-ssh-1180)

Your right in saying this is an unproven application!

------
pritambaral
So, fanterm[1] for the web.

[1]:
[http://www.stearns.org/fanout/README.html](http://www.stearns.org/fanout/README.html)

~~~
Argorak
I've also seen clusterssh:
[http://freecode.com/projects/clusterssh](http://freecode.com/projects/clusterssh)

~~~
res0nat0r
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/)

------
VieElm
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
Awesome, appreciate that!!!

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

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

------
dustinrcollins
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
It's worth noting that Conjur's SSH solution is built around familiar unix
tools like pam-ldap and AuthorizedKeysCommand. Why reinvent the wheel?

------
gfodor
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.)

~~~
ryan-c
[https://github.com/macton/hterm](https://github.com/macton/hterm)

I use the chrome extension version on my chromebook quite heavily, no real
complaints.

------
feld
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#)

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

------
strzalek
tmux-cssh

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

