ssh-keygen -H corrupts already hashed entries
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
openssh (Debian) |
Fix Released
|
Unknown
|
|||
openssh (Ubuntu) |
Fix Released
|
High
|
Colin Watson | ||
Xenial |
Fix Released
|
High
|
Christian Ehrhardt | ||
Yakkety |
Fix Released
|
High
|
Christian Ehrhardt |
Bug Description
[Impact]
* re-execution of ssh-keygen -H can clobber known-hosts
* Due to that users might get spurious re-warnings of known systems. For Automation it might be worse as it might stop to work when re-executed.
* This is a regression from Trusty (working) to Xenial (fail) upgrade due to an upstream bug in the versions we merged.
* This is a backport of the upstream fix
[Test Case]
* Pick a Host IP to scan keys from that you can reach and replies with SSH, then run the following trivial loop:
$ ssh-keyscan ${IP} > ~/.ssh/known_hosts; for i in $(seq 1 20); do ssh-keygen -H; diff -Naur ~/.ssh/
* Expected: no diff reported, since already hashed entries should be left as-is
* Without fix: - diff in the hashes
[Regression Potential]
* The fix is upstream and soon in Debian as well, so we are not custom diverting here.
* The risk should be minimal as this only changes ssh-keygen so despite openssh being really critical this doesn't affect ssh itself at all.
[Other Info]
* n/a
---
xenial @ 1:7.2p2-4ubuntu2.1 on amd64 has this bug. trusty @ 1:6.6p1-2ubuntu2.8 on amd64 does not have this bug. I have not tested any other ssh versions.
The following should reproduce the issue:
#ssh-keyscan XXXX > ~/.ssh/known_hosts
# ssh root@XXXXX
Permission denied (publickey).
# ssh-keygen -H
/root/.
Original contents retained as /root/.
WARNING: /root/.
Delete this file to ensure privacy of hostnames
# ssh root@XXXXXX
Permission denied (publickey).
# ssh-keygen -H
/root/.
Original contents retained as /root/.
WARNING: /root/.
Delete this file to ensure privacy of hostnames
# ssh root@XXXXX
The authenticity of host 'XXXXXX' can't be established.
RSA key fingerprint is XXXXXX.
Are you sure you want to continue connecting (yes/no)?
# diff known_hosts.old known_hosts
1c1
< |1|BoAbRpUE3F5A
---
> |1|nTPsoLxCugQy
Changed in openssh (Ubuntu): | |
status: | Confirmed → Triaged |
importance: | Undecided → Medium |
Changed in openssh (Ubuntu Xenial): | |
status: | New → Triaged |
importance: | Undecided → High |
Changed in openssh (Ubuntu Yakkety): | |
status: | New → Triaged |
importance: | Undecided → High |
Changed in openssh (Ubuntu): | |
status: | Triaged → Fix Committed |
Changed in openssh (Debian): | |
status: | Unknown → Fix Committed |
tags: | added: patch server-next |
Changed in openssh (Debian): | |
status: | Fix Committed → Fix Released |
Changed in openssh (Ubuntu Xenial): | |
assignee: | nobody → ChristianEhrhardt (paelzer) |
Changed in openssh (Ubuntu Yakkety): | |
assignee: | nobody → ChristianEhrhardt (paelzer) |
Changed in openssh (Ubuntu): | |
assignee: | nobody → Colin Watson (cjwatson) |
Hi,
thank you a lot for the good debugging steps!
I can totally confirm the issue.
Need to check with upstream and Debian versions later.