ssh-keygen -H corrupts already hashed entries

Bug #1668093 reported by Sarah Newman on 2017-02-26
26
This bug affects 2 people
Affects Status Importance Assigned to Milestone
openssh (Debian)
Fix Released
Unknown
openssh (Ubuntu)
High
Colin Watson
Xenial
High
ChristianEhrhardt
Yakkety
High
ChristianEhrhardt

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/known_hosts.old ~/.ssh/known_hosts; done

 * 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/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old
WARNING: /root/.ssh/known_hosts.old contains unhashed entries
Delete this file to ensure privacy of hostnames
# ssh root@XXXXXX
Permission denied (publickey).
# ssh-keygen -H
/root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old
WARNING: /root/.ssh/known_hosts.old contains unhashed entries
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|BoAbRpUE3F5AzyprJcbjdepeDh8=|x/1AcaLxh45FlShmVQnlgx2qjxY= XXXXX
---
> |1|nTPsoLxCugQyZi3pqOa2pc/cX64=|bUH5qwZlZPp8msMGHdLtslf3Huk= XXXXX

ChristianEhrhardt (paelzer) wrote :

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.

Changed in openssh (Ubuntu):
status: New → Confirmed
ChristianEhrhardt (paelzer) wrote :

And the behavior is clearly against what the manpage says:
-H Hash a known_hosts file. This replaces all hostnames and addresses with hashed representations within the specified file; the original content is moved to a file with a .old suffix. These hashes may be used normally by ssh and sshd, but they do not reveal identifying information should the file's contents be disclosed. This option will not modify existing hashed hostnames and is therefore safe to use on files that mix hashed and non-hashed names.

ChristianEhrhardt (paelzer) wrote :

Confirmed to be also broken in Zesty (openssh-client 1:7.4p1-6)

ChristianEhrhardt (paelzer) wrote :

Confirmed to not affect Trusty (as reported)
(openssh-client 1:6.6p1-2ubuntu2)

ChristianEhrhardt (paelzer) wrote :

Building and testing latest released upstream
https://mirror.hs-esslingen.de/pub/OpenBSD/OpenSSH/portable/openssh-7.4p1.tar.gz

autoreconf && ./configure && make -j 4
And Testing local ./ssh-keygen just built.

To make sure lib dependencies are not the one that introduce this I built this on Trusty and Zesty after pulling in the "usual" build dependencies for openssh via "apt-get build-dep openssh".

openssh-7.4p1$ ./ssh-keyscan 10.245.71.133 > ~/.ssh/known_hosts
# 10.245.71.133:22 SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
# 10.245.71.133:22 SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
# 10.245.71.133:22 SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1

# Save the initial file with Hosts
openssh-7.4p1$ cp ~/.ssh/known_hosts ~/.ssh/known_hosts-upstream-step1

# Check if keys are known (working)
openssh-7.4p1$ ./ssh ubuntu@10.245.71.133
Permission denied (publickey).

# Hash entries
openssh-7.4p1$ ./ssh-keygen -H
/root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old
WARNING: /root/.ssh/known_hosts.old contains unhashed entries
Delete this file to ensure privacy of hostnames

# Save the first round of hashes
openssh-7.4p1$ cp ~/.ssh/known_hosts ~/.ssh/known_hosts-upstream-step2

# Check if keys are known (still working)
openssh-7.4p1$ ./ssh ubuntu@10.245.71.133
Permission denied (publickey).

# Re-hash breaking the content
openssh-7.4p1$ ./ssh-keygen -H
/root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old
WARNING: /root/.ssh/known_hosts.old contains unhashed entries
Delete this file to ensure privacy of hostnames

# Save the re-hashed file
openssh-7.4p1$ cp ~/.ssh/known_hosts ~/.ssh/known_hosts-upstream-step3

# Show the error of hashes now being unknown
openssh-7.4p1$ ./ssh ubuntu@10.245.71.133
The authenticity of host '10.245.71.133 (10.245.71.133)' can't be established.
ECDSA key fingerprint is SHA256:AoKckr17ygqfpIfx94bRSHAzrnVQN6DfKsHR0hySjTM.
Are you sure you want to continue connecting (yes/no)?

The Test can be driven further, the following loop shows nothing on good systems (no diff after the first hashing), while on broken systems it does rehash (and therefore show diff) over and over again.
for i in $(seq 1 20); do ssh-keygen -H; diff -Naur /root/.ssh/known_hosts.old /root/.ssh/known_hosts; done

ChristianEhrhardt (paelzer) wrote :

As I expected it also affects Debian (openssh-client 1:7.4p1-6)

ChristianEhrhardt (paelzer) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. I appreciate the quality of this bug report and I'm sure it'll be helpful to others experiencing the same issue.

As I proved in my checks this is an upstream bug. OTOH while annoying it is not "very" fatal other than for convenience or certain automation (which could code workarounds I think).

That said the best route to getting it fixed in Ubuntu in this case would be to file an upstream bug. It would be great if you're able to do that.

Otherwise, I'm not sure what we can do directly in Ubuntu to fix the problem.

If you do end up filing an upstream bug, please link to it from here so we get auto-notified once there is something we can merge or even backport depending on the complexity.
Thanks!

ChristianEhrhardt (paelzer) wrote :

On
git://anongit.mindrot.org/openssh.git

With bisect helper:
$cat ../test-ssh.sh
#!/bin/bash
set -ux

make clean
autoreconf && ./configure && make -j4
if [[ $? -ne 0 ]]; then
        # skip build issue
        exit 125
fi

rm ~/.ssh/known_hosts /root/.ssh/known_hosts.old /root/.ssh/known_hosts
./ssh-keyscan 10.245.71.133 > ~/.ssh/known_hosts
./ssh-keygen -H
./ssh-keygen -H
# here .old and current should have no diff
# no diff = still ok, diff = broken - diff RC matches that
diff -q /root/.ssh/known_hosts.old /root/.ssh/known_hosts

$ git bisect start V_7_2_P2 V_6_6_P1

Gives me:

$ git bisect log
# bad: [5c35450a0c901d9375fb23343a8dc82397da5f75] update versions for release
# good: [19158b2447e35838d69b2b735fb640d1e86061ea] - (djm) Release OpenSSH 6.6
git bisect start 'V_7_2_P2' 'V_6_6_P1'
# bad: [39e2f1229562e1195169905607bc12290d21f021] upstream commit
git bisect bad 39e2f1229562e1195169905607bc12290d21f021
# skip: [08c0eebf55d70a9ae1964399e609288ae3186a0c] upstream commit
git bisect skip 08c0eebf55d70a9ae1964399e609288ae3186a0c
# good: [f067cca2bc20c86b110174c3fef04086a7f57b13] upstream commit
git bisect good f067cca2bc20c86b110174c3fef04086a7f57b13
# bad: [fe8a3a51699afbc6407a8fae59b73349d01e49f8] upstream commit
git bisect bad fe8a3a51699afbc6407a8fae59b73349d01e49f8
# good: [9010902954a40b59d0bf3df3ccbc3140a653e2bc] upstream commit
git bisect good 9010902954a40b59d0bf3df3ccbc3140a653e2bc
# bad: [3fdc88a0def4f86aa88a5846ac079dc964c0546a] upstream commit
git bisect bad 3fdc88a0def4f86aa88a5846ac079dc964c0546a
# bad: [9e06a0fb23ec55d9223b26a45bb63c7649e2f2f2] upstream commit
git bisect bad 9e06a0fb23ec55d9223b26a45bb63c7649e2f2f2
# good: [f101d8291da01bbbfd6fb8c569cfd0cc61c0d346] upstream commit
git bisect good f101d8291da01bbbfd6fb8c569cfd0cc61c0d346
# bad: [cecb30bc2ba6d594366e657d664d5c494b6c8a7f] upstream commit
git bisect bad cecb30bc2ba6d594366e657d664d5c494b6c8a7f
# good: [c29811cc480a260e42fd88849fc86a80c1e91038] upstream commit
git bisect good c29811cc480a260e42fd88849fc86a80c1e91038
# good: [ec3d065df3a9557ea96b02d061fd821a18c1a0b9] upstream commit
git bisect good ec3d065df3a9557ea96b02d061fd821a18c1a0b9
# first bad commit: [cecb30bc2ba6d594366e657d664d5c494b6c8a7f] upstream commit

The offending commit you want to report in your upstream bug is:
cecb30bc2ba6d594366e657d664d5c494b6c8a7f is the first bad commit
commit cecb30bc2ba6d594366e657d664d5c494b6c8a7f
Author: <email address hidden> <email address hidden>
Date: Sun Jan 18 21:49:42 2015 +0000

    upstream commit

    make ssh-keygen use hostkeys_foreach(). Removes some
     horrendous code; ok markus@

Upstream accidentally dropped the "non-overwrite" feature of ssh-keygen -H, but it is part of a much bigger rework, therefore this is nothing we just can/want to revert.

tags: added: needs-upstream-report
Changed in openssh (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Medium
Sarah Newman (srn-f) wrote :

Yes, I will report the bug upstream within the next few days if nobody else reports it first.

Colin Watson (cjwatson) wrote :

Thanks - I'll cherry-pick that into Debian, so zesty will get the fix. I'd appreciate somebody else handling SRUs, though.

Changed in openssh (Debian):
importance: Undecided → Unknown
status: New → Unknown
Changed in openssh (Ubuntu):
importance: Medium → High
Colin Watson (cjwatson) on 2017-03-09
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
ChristianEhrhardt (paelzer) wrote :

Discussed with cjwatson, the Debian upload to unstable will happen today and a sync to Zesty will follow.

So it is about preparing the SRUs and pushing them to unapproved once the sync came in.

description: updated
Changed in openssh (Debian):
status: Fix Committed → Fix Released
ChristianEhrhardt (paelzer) wrote :

I did prepare in Bileto:
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2585
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2586

Associated autopkgtests ran fine: https://bileto.ubuntu.com/excuses/2585/xenial.html

Also the openssh tests of the QA Test suite (https://git.launchpad.net/qa-regression-testing) ran fine in Xenial/Yakkety VMs.

And finally the test for the explicit issue we are fixing here was confirmed to be fixed on the Bileto PPAs.

Adding SRU Template now, but unfortunately (no core dev) I can't sponsor them myself, but the debdiff to do so can be picked from the tested Bileto ppas at:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-2585/2017-03-15_13:33:40/xenial_openssh_content.diff
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-2586/2017-03-15_13:33:46/yakkety_openssh_content.diff

Eventually for Sponsorsing the easiest might be via bileto itself, IIRC one with permissions could also just hit "publish" on the two tickets - that might be the easiest way:
https://bileto.ubuntu.com/#/ticket/2585
https://bileto.ubuntu.com/#/ticket/2586

The autopkgtest showed some issues I want to look into first, therefore (except if you know all these) do not sponsor yet. That also gives us time to have the fixed sync to appear in zesty.

ChristianEhrhardt (paelzer) wrote :

My first guess is that all non openssh fails are random transient issues, but the openssh test itself seems to be related - test is "failed ssh-keygen known_hosts".
Maybe some expected content did not match, I'll look into that tomorrow.

@cjwatson - did you have anything like that on your upload?
I might as well check debci once it appears in Debian, but maybe you have seen it already.

ChristianEhrhardt (paelzer) wrote :

First I checked if the change that got into Debian matches mine that I prepared for SRU - they do.

I triggered a local autopkgtest of pre/post SRU upload locally and while that was running evaluated the history of these tests in Ubuntu and Debian.
It seems to fail in Debian just as much, while the former version was ok [1].
On Ubuntu the recent sync failed as well [2].

The output format of the regress test changed slightly, but the SRUs fail essentially at the same test that the last version does "didn't find find simple in hashed" (and similar).

In the meantime my local Tests completed - and of course - they worked (once I want to find a case that is easy to debug). I need to go deeper to see what is going on now.

But for now wanted to make clear that the Zesty sync is broken as well as outlined above.
As expected it is haning in z-p [3] at the moment with that error.

[1]: https://ci.debian.net/packages/o/openssh/unstable/amd64/
[2]: http://autopkgtest.ubuntu.com/packages/openssh/zesty/amd64
[3]: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html

ChristianEhrhardt (paelzer) wrote :

Can now reproduce locally (was my fault), debugging further by isolating the testcase from the regress suite

Colin Watson (cjwatson) wrote :

Thanks, I'll look into this at the Debian end as soon as I can.

I'd suggest bundling fixes for bug 1670745 with any SRUs where it's relevant; I intended those to go together.

ChristianEhrhardt (paelzer) wrote :

Yes I've seen this in the Debian upload as well, I'll bundle it - thanks for the heads up.

ChristianEhrhardt (paelzer) wrote :

Testing and shell into SRU for Xenial (others have the same, so just one is ok)
Former Version:
$ autopkgtest --apt-upgrade --shell --no-built-binaries openssh_7.2p2-4ubuntu2.1.dsc -- lxd ubuntu-daily:xenial/amd64
New Version:
$ autopkgtest --apt-upgrade --shell --setup-commands="add-apt-repository ppa:ci-train-ppa-service/2585; apt update; apt -y dist-upgrade" --no-built-binaries openssh_7.2p2-4ubuntu2.2.dsc -- lxd ubuntu-daily:xenial/amd64

Rerun full regression check
 $

Isolated execution of the Regression Test with:
 $ cd ${AUTOPKGTEST_TMP}/tree/regress
 $ env TEST_SHELL="sh" $(pwd)/test-exec.sh $(pwd) $(pwd)/keygen-knownhosts.sh

There are actually two tests that report "find simple in hashed".
The second one is the one failing:

rm -f $OBJ/kh.expect
expect_key host-h host-h host-f
check_hashed_find host-h "find simple in hashed" $OBJ/kh.hosts

That creates an expected hosts file and compares vs the created one.
In the bad case the result has 3x the same line, expected is just one (the content is good, just x3).

Expected is "constructed" by the script and always the same.
The input here is kh.hosts which shall be filtered for host-h.
The "special" thing on host-h is that it has multiple entries host-f, host-g, host-h

good case:
cat kh.hosts
# host-f
|1|qOQ8g9WMxPbnPpDWt+uKrbIDg+I=|CRVR2cmi1FQ2yOQOJI92OsewK0Y= ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHu6oWC3VvOmfMSUXHCnCalWeV+BwsdbFohYI4pbt/bk host-f
|1|iR+WMF7scwVxrq6gMEvU7FDT3rw=|nKJaAF8aL7QBcrdhr5ktbvNpphc= ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHu6oWC3VvOmfMSUXHCnCalWeV+BwsdbFohYI4pbt/bk host-f
|1|I7Fz/FqixsITHRgQMQ1qh3Z0MOs=|35k5Pgsdi26LnX8qEa/x5AA1Ra0= ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHu6oWC3VvOmfMSUXHCnCalWeV+BwsdbFohYI4pbt/bk host-f
$ ssh-keygen -f kh.hosts -H -F host-h
|1|I7Fz/FqixsITHRgQMQ1qh3Z0MOs=|35k5Pgsdi26LnX8qEa/x5AA1Ra0= ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHu6oWC3VvOmfMSUXHCnCalWeV+BwsdbFohYI4pbt/bk host-f

bad case:
cat kh.hosts
# host-f
host-f,host-g,host-h ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJUaapZHmhvIshkUwydfXMBUucV8bDnJQzRr5w3KLvhC host-f
ssh-keygen -f kh.hosts -H -F host-h
|1|2F+CF0DKXdtLe0Hnb/4/uk82u7g=|oY3P3goocNH/nGO8I+851qQUBMQ= ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJUaapZHmhvIshkUwydfXMBUucV8bDnJQzRr5w3KLvhC host-f
|1|ggIXIbTzzzTUU1boKmqEyIkzZEo=|7RZjQXl9O0GdwqwKJI7IVqnZq58= ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJUaapZHmhvIshkUwydfXMBUucV8bDnJQzRr5w3KLvhC host-f
|1|mzIFYbXFU5rWYEAQVK1u+T4OaAM=|kXqon1yIIgUGSPQ5iJx4Qy97rHM= ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJUaapZHmhvIshkUwydfXMBUucV8bDnJQzRr5w3KLvhC host-f

So in the old case it was already hashed when it got here in the test (that might be the failure actually).
Now since it is not hashed (yet) when it gets here the code generates 3x (one for each hostname) hashed entries.

Both agree on "kh.hosts.orig" content other than the actual generated pubs.

Next step: need to debug if the error is either:
1. that kh.hosts is different when it gets to the test
or
2. the handling by ssh-keygen on it then.

ChristianEhrhardt (paelzer) wrote :

Upstream has made no change to the tests since then.
I'd have expected upstream to fail as well, but it seems to not fail.

On latest upstream:
autoreconf -f -i
./configure
make -j
mkdir /var/empty
cd regress
$ PATH=`pwd`/..:$PATH:. TEST_SHELL=/bin/sh sh test-exec.sh `pwd` keygen-knownhosts.sh

Works !

I was able to track down further to a segfault in the bad case.
And in fact it seems to be related to a comment being in the hosts file:
Testable as easy as this:

 $ printf '#foo' > kh.test; ../ssh-keygen -qf ./kh.test -H

All else seem to be follow on issues.

I'll track down the segfault after lunch

Colin Watson (cjwatson) wrote :

I'm still setting up my own test environment since I've been doing other things this morning, but I'd guess at https://anongit.mindrot.org/openssh.git/commit/?id=18501151cf272a15b5f2c5e777f2e0933633c513 in that case.

ChristianEhrhardt (paelzer) wrote :

Was my guess as well, in a bit I'll be able to test and confirm.

Colin Watson (cjwatson) wrote :

Yep, that seems to do the job here; thanks for narrowing it down. Cherry-picking and then I'll do a full adt-run before uploading again.

Colin Watson (cjwatson) wrote :

I've uploaded 1:7.4p1-9 to unstable to fix this, and will sync it once I can.

ChristianEhrhardt (paelzer) wrote :

Thanks Colin,
I have new bileto tickets with all the fixes prepared:

Xenial: https://bileto.ubuntu.com/#/ticket/2597
Yakkety: https://bileto.ubuntu.com/#/ticket/2598

Although things looked good on testing at first (local amd64), you can see there that arm and s390x seem to fail now.

ARM:
run test connect.sh ...
ssh-keygen -lf /tmp/autopkgtest.U8eLXQ/autopkgtest_tmp/tree/regress/t12.out.pub | grep test-comment-1234 >/dev/null
ssh connect with protocol 2 failed
make: *** [t-exec] Error 1
failed simple connect

s390x:
run test forwarding.sh ...
failed copy of /bin/ls
cmp: EOF on /data/adttmp/autopkgtest-virt-lxc.shared.j0fd9gxe/downtmp/autopkgtest_tmp/tree/regress/copy
corrupted copy of /bin/ls
failed local and remote forwarding

These reproduce in 4/4 cases :-/
Then I checked history and it seems those are accepted and ignored cases all through Xenial/Yakkety.
See:
http://autopkgtest.ubuntu.com/packages/openssh/xenial/armhf
http://autopkgtest.ubuntu.com/packages/openssh/yakkety/armhf
http://autopkgtest.ubuntu.com/packages/openssh/xenial/s390x
http://autopkgtest.ubuntu.com/packages/openssh/yakkety/s390x

Same failure since:
- Xenial openssh 1:7.2p2-4ubuntu2.1
- Yakkety systemd/231-3

That said, Colin - would you mind to sponsor by hitting "publish" on those two tickets after you synced the latest Debian to Zesty?

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openssh - 1:7.4p1-9

---------------
openssh (1:7.4p1-9) unstable; urgency=medium

  * Fix null pointer dereference in ssh-keygen; this fixes an autopkgtest
    regression introduced in 1:7.4p1-8.

 -- Colin Watson <email address hidden> Thu, 16 Mar 2017 13:43:15 +0000

Changed in openssh (Ubuntu):
status: Fix Committed → Fix Released
ChristianEhrhardt (paelzer) wrote :

Great, I see zesty has the fix that works through tests now - thanks cjwatson!

Colin could you hit publish on the bileto tickets then to kick of the related SRUs into unapproved?
(I'm also subscribing sponsors in case you have no time)

Bileto references:
Xenial: https://bileto.ubuntu.com/#/ticket/2597
Yakkety: https://bileto.ubuntu.com/#/ticket/2598

Changed in openssh (Ubuntu Xenial):
assignee: nobody → ChristianEhrhardt (paelzer)
Changed in openssh (Ubuntu Yakkety):
assignee: nobody → ChristianEhrhardt (paelzer)
Colin Watson (cjwatson) wrote :

I've hit the publish buttons now.

Colin Watson (cjwatson) on 2017-04-04
Changed in openssh (Ubuntu):
assignee: nobody → Colin Watson (cjwatson)

Hello Sarah, or anyone else affected,

Accepted openssh into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/openssh/1:7.3p1-1ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in openssh (Ubuntu Yakkety):
status: Triaged → Fix Committed
tags: added: verification-needed
Changed in openssh (Ubuntu Xenial):
status: Triaged → Fix Committed
Łukasz Zemczak (sil2100) wrote :

Hello Sarah, or anyone else affected,

Accepted openssh into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/openssh/1:7.2p2-4ubuntu2.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

ChristianEhrhardt (paelzer) wrote :

Prior to the update I had a diff when rehashing like:
$ ssh-keyscan 10.245.71.133 > ~/.ssh/known_hosts; for i in $(seq 1 20); do ssh-keygen -H; diff -Naur ~/.ssh/known_hosts.old ~/.ssh/known_hosts; done

Removing the known_hosts file and upgrading to proposed version.

After the update I see one diff when initially adding the entries, but then now bad rehashing anymore.

Verified Xenial and Yakkety.

tags: added: verification-done
removed: verification-needed

The verification of the Stable Release Update for openssh has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openssh - 1:7.3p1-1ubuntu0.1

---------------
openssh (1:7.3p1-1ubuntu0.1) yakkety; urgency=medium

  * Fix ssh-keygen -H accidentally corrupting known_hosts that contained
    already-hashed entries (LP: #1668093).
  * Fix ssh-keyscan to correctly hash hosts with a port number (LP: #1670745).

 -- Christian Ehrhardt <email address hidden> Wed, 15 Mar 2017 14:25:22 +0100

Changed in openssh (Ubuntu Yakkety):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openssh - 1:7.2p2-4ubuntu2.2

---------------
openssh (1:7.2p2-4ubuntu2.2) xenial; urgency=medium

  * Fix ssh-keygen -H accidentally corrupting known_hosts that contained
    already-hashed entries (LP: #1668093).
  * Fix ssh-keyscan to correctly hash hosts with a port number (LP: #1670745).

 -- Christian Ehrhardt <email address hidden> Wed, 15 Mar 2017 13:16:56 +0100

Changed in openssh (Ubuntu Xenial):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.