The man page ssh-keygen.1 still lists for option "-t" only the possible values dsa | ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa However the first of these ("dsa" generating an "ssh-dss" key) is already disabled, the last of these (rsa) seems scheduled to be disabled, and many newer key types are missing. In comparison, the default list of acceptable keytypes for publickey authentication is given in sshd_config.5 under option PubkeyAcceptedKeyTypes as ssh-ed25519-cert-v01@openssh.com, ecdsa-sha2-nistp256-cert-v01@openssh.com, ecdsa-sha2-nistp384-cert-v01@openssh.com, ecdsa-sha2-nistp521-cert-v01@openssh.com, sk-ssh-ed25519-cert-v01@openssh.com, sk-ecdsa-sha2-nistp256-cert-v01@openssh.com, rsa-sha2-512-cert-v01@openssh.com, rsa-sha2-256-cert-v01@openssh.com, ssh-rsa-cert-v01@openssh.com, ssh-ed25519, ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, sk-ssh-ed25519@openssh.com, sk-ecdsa-sha2-nistp256@openssh.com, rsa-sha2-512,rsa-sha2-256,ssh-rsa Please update the list of available values after -t in ssh-keygen.1.
(In reply to Markus Kuhn from comment #0) > The man page ssh-keygen.1 still lists for option "-t" only the > possible values > > dsa | ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa > > However the first of these ("dsa" generating an "ssh-dss" key) is > already disabled, It's not disabled in ssh-keygen: $ ssh-keygen -t dsa -f key -N '' Generating public/private dsa key pair. Your identification has been saved in key Your public key has been saved in key.pub > the last of these (rsa) seems scheduled to be > disabled, RSA keys are not scheduled to be deprecated. One authentication algorithm that uses RSA keys with a weak hash (ie ssh-rsa, which uses sha1) is. Existing and new RSA keys can still be used with the stronger sha2 variants as long as both client and server support them. > and many newer key types are missing. > > In comparison, the default list of acceptable keytypes for publickey > authentication is given in sshd_config.5 under option > PubkeyAcceptedKeyTypes as Unfortunately that keyword is pretty misleading. It specifies *algorithms* not *key types*. (In its defense, the lists were equivalent when the keyword was added, they diverged later). We should consider changing its name. > Please update the list of available values after -t in ssh-keygen.1. I think the list in ssh-keygen is accurate as it stands now.
(In reply to Darren Tucker from comment #1) [...] > Unfortunately that keyword is pretty misleading. It specifies > *algorithms* not *key types*. (In its defense, the lists were > equivalent when the keyword was added, they diverged later). We > should consider changing its name. We've renamed PubkeyAcceptedKeyTypes to PubkeyAcceptedAlgorithms which will hopefully reduce potential confusion in future. https://github.com/openssh/openssh-portable/commit/ee9c0da8035b3168e8e57c1dedc2d1b0daf00eec
Renaming PubkeyAcceptedKeyTypes to PubkeyAcceptedAlgorithms looks helpful, but it does not yet solve the current problem that the ssh-keygen man page leaves the reader somewhat in the dark about the precise relationship between key types, bits and algorithms. I think it would be great to add to ssh-keygen a table that shows which key type (-t) with which bits (-b) is suitable for which algorithms, just to make sure that the user interface presented by ssh-keygen (which talks about key types) and the user interface presented by sshd (which talks about algorithms) meet each other at a prominent place in the documentation. Some other cryptographic applications (e.g. Kerberos https://web.mit.edu/kerberos/www/krb5-latest/doc/admin/enctypes.html ), have a one-to-one relationship between what key types the user can generate and what algorithms these key types are used with. There are far fewer choices to be made. In OpenSSH, that relationship is more complicated, and a table showing how the values that can be specified after ssh-key options -t and -b match up with the options that can be specified after PubkeyAcceptedAlgorithms would be an incredibly useful resource for users faced with choosing a key type. That table could also list which algorithms have been introduced or deprecated by which OpenSSH version. All that is crucial information for ssh-keygen users to make an informed decision about which values to pick for -t and -b. (One can use tbl tables in man pages with .TS and .TE macros, as krb5.conf(5) or systemd.unit(5) demonstrate. See "man tbl" for documentation.)
I came to this report after being misled by the manual page of ssh-keygen. It would have saved me a lot of time if it was written somewhere that DSA was disabled by OpenSSH. This manual page even lists dsa first, leading to believe it is a preferred choice. -t dsa | ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa Specifies the type of key to create. The possible values are “dsa”, “ecdsa”, “ecdsa-sk”, “ed25519”, “ed25519-sk”, or “rsa”. After using the first option, dsa, I was left trying to figure out why it was still asking the password. After all, ssh doesn't warn of the disabled algorithm either. It would be good the warn the user of this change at some point in the process of setting up a new public key authentication.