Timeline for Is using a public-key for logging in to SSH any better than saving a password?
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Dec 8, 2020 at 10:14 | history | suggested | Martin Prikryl | CC BY-SA 4.0 |
typos + typography
|
| Dec 8, 2020 at 9:27 | review | Suggested edits | |||
| S Dec 8, 2020 at 10:14 | |||||
| S Apr 15, 2016 at 4:57 | history | suggested | xuiqzy | CC BY-SA 3.0 |
explain that compromised server also doesn't affect other servers with pub/priv keys, not only compromised connection and client; made the paragraph with "other advantages of pub key pair" more clear to what the *other* advantages are
|
| Apr 15, 2016 at 2:42 | review | Suggested edits | |||
| S Apr 15, 2016 at 4:57 | |||||
| Aug 28, 2015 at 21:13 | comment | added | kasperd | @RichardE.Silverman Maybe you should suggest an edit. The poster is unlikely to edit himself considering that he hasn't been on this site for three years. | |
| Aug 26, 2015 at 1:52 | comment | added | Richard E. Silverman | The use of the session identifier in publickey authentication has an interesting effect not often remarked on: it affords extra protection against a man-in-the-middle attack. If the attacker executes the key exchange separately on each side, the session identifiers (IDs) will be different. The server demands a signature over the ID for its connection with the attacker -- but the client will only produce a signature over the ID on its side. The attacker has no way to force them to be the same, and no way to induce the client to do anything else. A challenge-response protocol would not do this. | |
| Aug 26, 2015 at 1:41 | comment | added | Richard E. Silverman | Parts of this answer are a bit too detailed, and go astray as a result. The distinguishing feature of publickey authentication in this context is that the client signs something with his private key, and does not need to reveal a secret in the process. SSH-2 publickey authentication does not actually use a challenge-response protocol as described in this answer. The client signs a value which is derived independently by each side as part of the symmetric key-agreement process; see RFC-4252, section 7 (in particular the "session identifier"). Both sides contribute, and neither can determine it. | |
| Aug 5, 2013 at 16:07 | comment | added | David Cary | If "not using a passphrase isn't smart", then why does the OpenSSL documentation specifically say that "it may be a good thing to avoid protecting it with a password" ? (Should I ask this as an independent question?) | |
| May 22, 2012 at 21:14 | vote | accept | Nick T | ||
| S May 18, 2011 at 8:02 | history | suggested | CommunityBot | CC BY-SA 3.0 |
removed unnecessary word
|
| May 18, 2011 at 7:52 | review | Suggested edits | |||
| S May 18, 2011 at 8:02 | |||||
| May 18, 2011 at 0:08 | comment | added | crazy2be | My private keys can be decrypted automatically on Ubuntu, the passwords for them are encrypted with my login password, and Ubuntu unlocks them for me automatically when I log in. This is really the best of both worlds, because I have the convenience of a passwordless key with the security of a passphrased one (almost). If you are logging in to a high-security computer system, this might not be secure enough, since your login password can be compromised fairly easily, and thus the passphases for your keys can be compromised as well. However, it is much better than a key without a passphase. | |
| May 17, 2011 at 17:10 | history | edited | john | CC BY-SA 3.0 |
added 139 characters in body
|
| May 17, 2011 at 16:55 | history | edited | john | CC BY-SA 3.0 |
added 12 characters in body; deleted 11 characters in body
|
| May 17, 2011 at 16:46 | history | edited | john | CC BY-SA 3.0 |
deleted 118 characters in body
|
| May 17, 2011 at 16:38 | history | edited | john | CC BY-SA 3.0 |
added 280 characters in body; added 24 characters in body; added 22 characters in body
|
| May 17, 2011 at 16:26 | history | answered | john | CC BY-SA 3.0 |