Quick look if major Git hosting providers are up-to-date about security.
The possibility to use ed25519-sk is a critical point when evaluating Git hosting.
When you generate this type of key, you need your physical security key,
ssh-keygen -t ed25519-sk
You obtain this type of output:
Generating public/private ed25519-sk key pair. You may need to touch your authenticator to authorize key generation. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/sycured/.ssh/demo_ed25519-sk Your public key has been saved in /home/sycured/.ssh/demo_ed25519-sk.pub The key fingerprint is: SHA256:c3J9KE2GsDr4gXE0OYfkNqC/ApDE5r7gP5sK2SiHUZY sycured@x9 The key's randomart image is: +[ED25519-SK 256]-+ |.. ..+o. | |.+ o ++..o . | |= E . =o. . o | |.+ . * o = . | |+ + + S + + . | |.O o o = . . | |O = . . | |o+ o. | | .o+o | +----[SHA256]-----+
The most important part is You may need to touch your authenticator to authorize key generation.
Each time that you'll want to use this key, you'll need your physical security key (Yubikey & co) otherwise it'll be impossible.
For critical accounts/repositories, it must be enforced with 1 to 3 spares stored in different safe places. Yes, you'll need to generate an ed25519-sk with each but it's nothing compared to losing your access.
It's not a surprise, Bitbucket doesn't implement it.
Gitea is up-to-date about ed25519-sk.
Tested on my personal Git server (self-hosted)
Gitee, the Chinese platform (OSChina is the owner) doesn't implement it.
Of course, GitHub is up-to-date about security.
Tested on gitlab.com, and it's working fine.
If your self-hosted Gitea/GitLab doesn't support ed25519-sk, just update it and have an OpenSSH server >= 8.2.