When can I use ssh public key type like ed25519-sk and ecdsa-sk #22356
-
ed25519-sk and ecdsa-sk are newly supported public key types in OpenSSH 8.2 for MFA devices. see How to secure your SSH server with public key Ed25519 Elliptic Curve Cryptography. but I can not use them in github.com yet. May I ask when I can use these types of SSH pubic key? |
Beta Was this translation helpful? Give feedback.
Replies: 19 comments
-
Hi @shawnzhu, Thanks for this feedback! We’re always working to improve GitHub, and we consider every suggestion we receive. I’ve logged your feature request in our internal feature request list. Though I can’t guarantee anything or share a timeline for this, I can tell you that it’s been shared with the appropriate teams for consideration. |
Beta Was this translation helpful? Give feedback.
-
Seconded. I would prefer to use this key type as well in order to take advantage of the 2fa options it includes. |
Beta Was this translation helpful? Give feedback.
-
Hello, |
Beta Was this translation helpful? Give feedback.
-
Agreed. This would be a great feature to have as I’ve moved my SSH keys to this type. |
Beta Was this translation helpful? Give feedback.
-
Just adding my +1 to this. Would be a great security improvement to support this. Would be even nicer if we could enforce the use of this for organisations meaning any access to github either via web or ssh uses 2FA :slight_smile: Thanks - John. |
Beta Was this translation helpful? Give feedback.
-
+1 for this. Using ed25519-sk for SSH keys provides both convenience and security out of the box. |
Beta Was this translation helpful? Give feedback.
-
+1 ecdsa-sk too. GitHub has early support for WebAuthn in MFA, and I think they should support it as an example of a web service as well. |
Beta Was this translation helpful? Give feedback.
-
+1 ed25519-dk and ecdsa-sk here. They’re much more convenient and foolproof compared to existing hardware SSH authentication methods like GPG or PKCS11. |
Beta Was this translation helpful? Give feedback.
-
A huge +1 from me! Currently, managing SSH keys using smart cards can be somewhat complicated, requiring the use of gpg-agent to deploy effectively. Support and configuration for this setup varies from client to client, OS to OS. If GitHub adopts this setup, it would represent a big step forward not only in terms of security but in ease of use for security-conscious developers. |
Beta Was this translation helpful? Give feedback.
-
+1 ecdsa-sk seems like the easiest way to secure ssh keys with a second factor. |
Beta Was this translation helpful? Give feedback.
-
I also would love to see ecdsa-sk supported! |
Beta Was this translation helpful? Give feedback.
-
+1 for ecdsa-sk It would be great to have native support for hardware MFA devices like Trezor One and Trezor Model T. |
Beta Was this translation helpful? Give feedback.
-
If there’s some kind of metric being considered for the importance of implementing this feature, please count my vote for supporting security keys for ssh pushes. As things stand, I have to choose between security and convenience. I pick convenience, but would much rather prefer security if I could get it as easily as touching my security key. |
Beta Was this translation helpful? Give feedback.
-
Would love to see it implemented and working properly. Security is always first here. |
Beta Was this translation helpful? Give feedback.
-
+1 |
Beta Was this translation helpful? Give feedback.
-
+1 |
Beta Was this translation helpful? Give feedback.
-
+1 This issue has been open for almost more than half a year by now. Any progress yet? |
Beta Was this translation helpful? Give feedback.
-
+1 |
Beta Was this translation helpful? Give feedback.
-
+1 I would also really like this! |
Beta Was this translation helpful? Give feedback.
Hi @shawnzhu,
Thanks for this feedback! We’re always working to improve GitHub, and we consider every suggestion we receive. I’ve logged your feature request in our internal feature request list. Though I can’t guarantee anything or share a timeline for this, I can tell you that it’s been shared with the appropriate teams for consideration.