KeyBox: A better way to SSH

More correctly AuthorizedKeysCommand is in mainline OpenSSH, thus every recent release of all major distros have it.

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

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.

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

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

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.

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.