openssh bugs - Jan 2021 - [Bug 3253] New: ssh-keygen man page still lists deprecated key types for -t

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

            Bug ID: 3253
           Summary: ssh-keygen man page still lists deprecated key types
                    for -t
           Product: Portable OpenSSH
           Version: 8.4p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: minor
          Priority: P5
         Component: ssh-keygen
          Assignee: unassigned-bugs at mindrot.org
          Reporter: Markus.Kuhn at cl.cam.ac.uk

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 at openssh.com,
ecdsa-sha2-nistp256-cert-v01 at openssh.com,
ecdsa-sha2-nistp384-cert-v01 at openssh.com,
ecdsa-sha2-nistp521-cert-v01 at openssh.com,
sk-ssh-ed25519-cert-v01 at openssh.com,
sk-ecdsa-sha2-nistp256-cert-v01 at openssh.com,
rsa-sha2-512-cert-v01 at openssh.com,
rsa-sha2-256-cert-v01 at openssh.com,
ssh-rsa-cert-v01 at openssh.com,
ssh-ed25519,
ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
sk-ssh-ed25519 at openssh.com,
sk-ecdsa-sha2-nistp256 at openssh.com,
rsa-sha2-512,rsa-sha2-256,ssh-rsa

Please update the list of available values after -t in ssh-keygen.1.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #1 from Darren Tucker <dtucker at dtucker.net> ---
(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.

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

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

Darren Tucker <dtucker at dtucker.net> changed:

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

--- Comment #2 from Darren Tucker <dtucker at dtucker.net> ---
(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

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

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

Markus Kuhn <Markus.Kuhn at cl.cam.ac.uk> changed:

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

--- Comment #3 from Markus Kuhn <Markus.Kuhn at cl.cam.ac.uk> ---
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.)

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

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

Seff <ajdkgmfr at duck.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ajdkgmfr at duck.com

--- Comment #4 from Seff <ajdkgmfr at duck.com> ---
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.

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