[Bug 3253] ssh-keygen man page still lists deprecated key types for -t

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3253

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #5 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Markus Kuhn from comment #3)
> 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.

from ssh-keygen(1):

       -b bits
               Specifies  the  number  of  bits in the key to create. 
For RSA
               keys, the minimum size is 1024 bits and  the  default 
is  3072
               bits.   Generally,  3072  bits  is  considered
sufficient.  For
               ECDSA keys, the -b flag determines the key length by 
selecting
               from  one  of three elliptic curve sizes: 256, 384 or
521 bits.
               Attempting to use bit lengths other than these three
values for
               ECDSA keys will fail.  ECDSA-SK, Ed25519  and 
Ed25519-SK  keys
               have a fixed length and the -b flag will be ignored.

It doesn't mention the max size for RSA, because that's dependent on
what the underlying libcrypto supports, but it's typically 8k or
greater.  All other sizes are documented.

[...]
> 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.

You can always query the set of supported algorithms with the ssh -Q
option: ssh -Q [Keyword] outputs the list of accepted algorithms for
that keyword:

$ ./ssh -Q PubkeyAcceptedAlgorithms
ssh-ed25519
ssh-ed25519-cert-v01 at openssh.com
sk-ssh-ed25519 at openssh.com
[etc]

> 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.

       -t ecdsa | ecdsa-sk | ed25519 | ed25519-sk | mldsa44-ed25519 |
rsa
               Specifies  the  type of key to create.  The possible
values are
               "ecdsa", "ecdsa-sk",  "ed25519  (the  default)," 
"ed25519-sk",
               "mldsa44-ed25519" or "rsa".


(In reply to Seff from comment #4)
> 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”. 

That was written while DSA was in the process of being deprecated. 
It's was fully deprecated in OpenSSH 10.0
(https://www.openssh.org/txt/release-10.0) and is no longer listed (see
above).

> 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.

In general, OpenSSH's defaults are sensible.  In this case, omitting
the key type and accepting the default would have resulting in a
working configuration.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.