Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

KeyBox: A better way to SSH

sshkeybox.com

Post reply on HN
Print view View original

41–50 of 57 posts

Re: KeyBox: A better way to SSH

#41

Post by STRML »

e12e wrote: post #36
rdl wrote: post #29

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 ag…

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,…

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.

Re: KeyBox: A better way to SSH

#44

Post by e12e »

STRML wrote: post #41
e12e wrote: post #36

Earlier quoted context omitted.

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,…

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

Re: KeyBox: A better way to SSH

#45

Post by STRML »

e12e wrote: post #44
STRML wrote: post #41

Earlier quoted context omitted.

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 u…

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.

Re: KeyBox: A better way to SSH

#47

Post by theandrewbailey »

fsniper wrote: post #42

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

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/

Re: KeyBox: A better way to SSH

#48

Post by jjmason »

dustinrcollins wrote: post #37

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

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

Re: KeyBox: A better way to SSH

#50

Post by kgilpin »

jpgvm wrote: post #34
kavanutz wrote: post #21

Earlier quoted context omitted.

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…

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.

Post reply on HN