Bug 1636706

Summary:	libssh 0.8.3 no longer reads PKCS8 keys
Product:	[Fedora] Fedora	Reporter:	Rick <fedora>
Component:	libssh	Assignee:	Andreas Schneider <asn>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	28	CC:	ansasaki, asn, jfch, jjelen, negativo17, rdieter
Target Milestone:	---	Keywords:	Regression
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-02-07 14:40:57 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Rick 2018-10-07 05:44:22 UTC

Description of problem:

Can't load my private key any more.  `ssh-add` errors out with:

Error loading key "/home/user/.ssh/id_rsa": invalid format

Version-Release number of selected component (if applicable):

libssh: 0.8.3-2.fc28

How reproducible:

Always

Steps to Reproduce:
1. Install fedora 28 stock
2. create a random ssh keypair
3. convert private key into PKCS8 format
4. Try to load key using ssh-add

Actual results:

Error loading key (path to key): invalid format

Expected results:

Identity added: id_rsa

Additional info:

This private key is a couple years old, and worked in fedora 24 through 28 until what I presume is the newest libssh upgrade that was made a week ago.

I tested it by using `openssl pkcs8 -in id_rsa -out id_rsa.clear -traditional` and then `ssh-add` was able to load the key immediately.

I get that not many people use this key format, but it's been advised as a security precaution for years, as the default RFC format for SSH private keys can be brute-forced rather quickly despite being "encrypted."

It's also a regression, and should probably be fixed. :)

Closest bug I found was this, reported a couple months ago: https://bugzilla.redhat.com/show_bug.cgi?id=1610222

Comment 1 Rick 2018-10-07 05:53:33 UTC

Crisis averted, I used the new openssh key format (Which appears to be the default now, nice) and converted by private key: `ssh-keygen -p -f id_rsa.clear -a 500` which probably obviates the need for PKCS8 style keys based on my reading of things: https://www.tedunangst.com/flak/post/new-openssh-key-format-and-bcrypt-pbkdf

Still, this was a *very* unpleasant surprise, and AFAICT, not documented anywhere.

Also, the default number of rounds is probably too low at 16, and using something on the order of `-a 500` (or higher!) with `ssh-keygen -p` is advised.

Comment 2 Rick 2018-10-07 05:58:39 UTC

also, in "steps to reproduce", the following should be appended:

5. key works
6, `dnf update libssh`
7. try to load key using ssh-add.
8. Key fails to load.

Comment 3 Jakub Jelen 2018-10-08 10:35:29 UTC

ssh-add is not using libssh at all. This sounds like a duplicate of a bug #1632902 in OpenSSH or OpenSSL, which changed a behavior in one of the latest updates ragards the zero-length passphrases.

Comment 4 Anderson Sasaki 2019-02-07 14:40:57 UTC

Thanks for reporting this bug. As pointed in comment 3, ssh-add does not use libssh at all, so libssh can't be the culprit of the issue.
Most likely the issue is a duplicate of bug #1632902, so I'll close as duplicate.

Please reopen the bug if the problem persists even after updating openssh to the newest version.

*** This bug has been marked as a duplicate of bug 1632902 ***