Bug 1282423 - ssh-add says "bad passphrase" for RSA1 keys
ssh-add says "bad passphrase" for RSA1 keys
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
23
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Jakub Jelen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-16 06:16 EST by Ian Collier
Modified: 2016-12-20 10:58 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 10:58:23 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
OpenSSH Project 2513 None None None Never
OpenSSH Project 2522 None None None 2016-01-08 11:18 EST

  None (edit)
Description Ian Collier 2015-11-16 06:16:53 EST
I still have some RSA1 keys lying around, which I should probably get rid
of, but nevertheless:

$ ssh-add ~/.ssh/identity
Enter passphrase for /users/imc/.ssh/identity: 
Bad passphrase, try again for /users/imc/.ssh/identity: 

I understand that RSA1 may not be supported in this release, but in that
case it should say "this is not supported" instead of "bad passphrase" -
and asking me to try again is somewhat pointless.

Version of the package in question is: openssh-clients-7.1p1-5.fc23.x86_64

With the Fedora 23 ssh-agent running, if I use a Fedora 22 client to add the key
it instead says:

Could not add identity "/users/imc/.ssh/starbright/identity": agent refused operation

Whereas a Fedora 20 client says:

SSH_AGENT_FAILURE
Could not add identity: /users/imc/.ssh/starbright/identity
Comment 1 Jakub Jelen 2015-11-16 06:38:44 EST
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
Comment 2 Fedora Update System 2015-11-16 08:59:44 EST
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
Comment 3 Jakub Jelen 2015-11-16 09:01:28 EST
wrong bug id. Sorry.
Comment 4 Jason Tibbitts 2015-12-03 02:05:11 EST
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.
Comment 5 Ian Collier 2015-12-03 08:04:38 EST
(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?
Comment 6 Jakub Jelen 2015-12-04 09:07:15 EST
(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.
Comment 7 Jason Tibbitts 2015-12-08 12:00:25 EST
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".
Comment 8 Jakub Jelen 2016-01-08 11:18:23 EST
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
Comment 9 Fedora End Of Life 2016-11-24 08:29:00 EST
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.
Comment 10 Fedora End Of Life 2016-12-20 10:58:23 EST
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.

Note You need to log in before you can comment on or make changes to this bug.