3 ms·

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

by STRML 12y ago

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 12y ago
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 12y ago
  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.

by STRML 12y ago

e12e 12y ago

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 12y ago
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.