Bug 1282423

The root of this behaviour change is, that in Fedora 23 we finally dropped SSH1 support at compile time, so none of the tools should be able to communicate with SSH1 protocol and tools should not recognize these old keys.

From this point, it is correct behaviour, if agent can't recognize any key, he expects it is encrypted one and asks for a passphrase.

It should not add these keys on its own, but if you are trying to force the agent to accept this key, is is wrong usage (unfortunately the documentation was not updated accordingly. I will report upstream, if there is a thing to do).

As noted in heads up on Devel [1] (unfortunately missed release notes if I am right), if you really need to use SSH1, there is clients package "openssh-clients-ssh1".


[1] https://lists.fedoraproject.org/pipermail/devel/2015-August/213362.html

yubico-piv-tool-1.1.2-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-42d86cf1e7

wrong bug id. Sorry.

Similarly, ssh-keygen won't create rsa1 keys.

> rpm -qf /usr/bin/ssh-keygen
openssh-7.1p1-5.fc23.x86_64

> ssh-keygen --help 2>&1 |grep rsa1
usage: ssh-keygen [-q] [-b bits] [-t dsa | ecdsa | ed25519 | rsa | rsa1]

> man ssh-keygen|grep rsa1
     ssh-keygen [-q] [-b bits] [-t dsa | ecdsa | ed25519 | rsa | rsa1] [-N new_passphrase] [-C comment] [-f output_keyfile]
     -A      For each of the key types (rsa1, rsa, dsa, ecdsa and ed25519) for which host keys do not exist, generate the host keys with
     -t dsa | ecdsa | ed25519 | rsa | rsa1
             Specifies the type of key to create.  The possible values are “rsa1” for protocol version 1 and “dsa”, “ecdsa”, “ed25519”, or

> ssh-keygen -q -C xxx -N '' -t rsa1 -f zzz
Saving key "zzz" failed: unknown or unsupported key type

I can understand if it intentionally no longer supports rsa1, but in that case it probably shouldn't say that it supports rsa1.

(In reply to Jakub Jelen from comment #1)
> From this point, it is correct behaviour, if agent can't recognize any key,
> he expects it is encrypted one and asks for a passphrase.

I see that that is indeed the behaviour in that if I try to add nonsense.txt
then it asks me for the passphrase even though it couldn't possibly decrypt it.
But "correct behaviour"?  Even the "file" command can recognise whether it's a
private key or not (and tells me what type), so couldn't ssh-add check this
before it tries to decrypt?

(In reply to Jason Tibbitts from comment #4)
> > ssh-keygen --help 2>&1 |grep rsa1
> usage: ssh-keygen [-q] [-b bits] [-t dsa | ecdsa | ed25519 | rsa | rsa1]

About the usage and manual pages, it should totally not mention the rsa1 keys anymore, but it is not so easy as #ifdef parts as in the code. I will have a look around what can be done and fill upstream bug.


(In reply to Ian Collier from comment #5)
> I see that that is indeed the behaviour in that if I try to add nonsense.txt
> then it asks me for the passphrase even though it couldn't possibly decrypt
> it.
> But "correct behaviour"?  Even the "file" command can recognise whether it's
> a
> private key or not (and tells me what type), so couldn't ssh-add check this
> before it tries to decrypt?

These are the openssh keys with proper headers, so they can be recognized unambiguous by definition also by openssh.

But openssh can also handle also some legacy(?) keys without headers *somehow* (I was trying to search for some documentation but still without success) and if it doesn't see the expected pattern in the beginning, it assumes it is encrypted key (random bytes). The software somehow expects that users know what are they doing. But anyhow I will investigate the issue further.

Thanks for reporting upstream.  I would have done so myself, but they usually won't even talk about vendor-modified versions.

For the manpage, if it were up to me I would just move anything related to SSH1 support to a separate section and just say "If openssh is compiled with protocol 1 support, then these additional options are available".

Jason,
Thank you for forcing me to dig into this a bit more.
I took some time to investigate and you were right. I summed all the information on SE [1] and filled the bug upstream [2]. Lets wait for upstream resolution.


[1] http://unix.stackexchange.com/a/253411/121504
[2] https://bugzilla.mindrot.org/show_bug.cgi?id=2522

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.