Activity log for bug #1588457

Date Who What changed Old value New value Message
2016-06-02 17:10:40 Felipe Reyes bug added bug
2016-06-02 18:26:37 Felipe Reyes summary authorized_keys using from="hostnamee" no longer work when upgrading to Xenial authorized_keys using from="hostname" no longer work when upgrading to Xenial
2016-06-03 19:27:51 Felipe Reyes description [Impact] When a user has configured their authorized_keys file with the directive "from=" to restrict the usage of those keys, if that server is upgraded to Xenial (or Wily) the user may get locked out. [Test Case] * Create 3 containers (client, trusty, xenial) $ lxc launch ubuntu:14.04 client $ lxc launch ubuntu:14.04 ssh-trusty $ lxc launch ubuntu:16.04 ssh-trusty * To make sure their hostnames are properly registered in dnsmasq and dns resolution works, ssh into each container and run "sudo reboot" (restart the network should do the trick too) * In the 'client' container generate a ssh key $ lxc exec client /bin/bash (client)# ssh-keygen * Add the ssh key in the other two containers for the user ubuntu * Verify a connection can be established from client to ssh-xenial and ssh-trusty (client)# ssh ssh-xenial (client)# ssh ssh-trusty * Edit in add the prefix from="client.lxd" in both containers authorized_keys file (ssh-xenial and ssh-trusty) * Check if you can connect (client)# ssh ssh-trusty (client)# ssh ssh-xenial Expected: you can connect to both containers Actual results: You can connect to the trusty server, but you can't to the xenial one, because since Wily (openssh 1:6.9p1-1[0] ) the configuration key UseDNS default changed from "yes" to "no", so sshd is not doing a reverse dns request to know if the incoming connection matched "client.lxd" [Workaround] Edit /etc/ssh/sshd_config and set "UseDNS yes" $ echo "UseDNS yes" | sudo tee -a /etc/ssh/sshd_config [More Info] Relevant portion from the manpage[1]: UseDNS Specifies whether sshd(8) should look up the remote host name, and to check that the resolved host name for the remote IP address maps back to the very same IP address. If this option is set to “no” (the default) then only addresses and not host names may be used in ~/.ssh/known_hosts from and sshd_config Match Host directives. [0] http://changelogs.ubuntu.com/changelogs/pool/main/o/openssh/openssh_6.9p1-1/changelog [1] http://manpages.ubuntu.com/manpages/xenial/en/man5/sshd_config.5.html [Impact] When a user has configured their authorized_keys file with the directive "from=" to restrict the usage of those keys, if that server is upgraded to Xenial (or Wily) the user may get locked out. [Test Case] * Create 3 containers (client, trusty, xenial)   $ lxc launch ubuntu:14.04 client   $ lxc launch ubuntu:14.04 ssh-trusty   $ lxc launch ubuntu:16.04 ssh-trusty * To make sure their hostnames are properly registered in dnsmasq and dns resolution works, ssh into each container and run "sudo reboot" (restart the network should do the trick too) * In the 'client' container generate a ssh key   $ lxc exec client /bin/bash   (client)# ssh-keygen * Add the ssh key in the other two containers for the user ubuntu * Verify a connection can be established from client to ssh-xenial and ssh-trusty   (client)# ssh ssh-xenial   (client)# ssh ssh-trusty * Edit in add the prefix from="client.lxd" in both containers authorized_keys file (ssh-xenial and ssh-trusty) * Check if you can connect   (client)# ssh ssh-trusty   (client)# ssh ssh-xenial Expected: you can connect to both containers Actual results: You can connect to the trusty server, but you can't to the xenial one, because since Wily (openssh 1:6.9p1-1[0] ) the configuration key UseDNS default changed from "yes" to "no", so sshd is not doing a reverse dns request to know if the incoming connection matched "client.lxd" [Workaround] Edit /etc/ssh/sshd_config and set "UseDNS yes" $ echo "UseDNS yes" | sudo tee -a /etc/ssh/sshd_config [More Info] Relevant portion from the manpage[1]:      UseDNS Specifies whether sshd(8) should look up the remote host name,              and to check that the resolved host name for the remote IP              address maps back to the very same IP address.              If this option is set to “no” (the default) then only addresses              and not host names may be used in ~/.ssh/known_hosts from and              sshd_config Match Host directives. commit 3cd5103c1e1aaa59bd66f7f52f6ebbcd5deb12f9 [2] Author: deraadt@openbsd.org <deraadt@openbsd.org> Date: Mon Feb 2 01:57:44 2015 +0000 upstream commit increasing encounters with difficult DNS setups in darknets has convinced me UseDNS off by default is better ok djm [0] http://changelogs.ubuntu.com/changelogs/pool/main/o/openssh/openssh_6.9p1-1/changelog [1] http://manpages.ubuntu.com/manpages/xenial/en/man5/sshd_config.5.html [2] https://github.com/openssh/openssh-portable/commit/3cd5103c1e1aaa59bd66f7f52f6ebbcd5deb12f9
2016-06-06 04:57:57 Dominique Poulain bug added subscriber Dominique Poulain
2016-06-06 08:44:18 Ivy Alexander bug added subscriber Ivy Alexander
2016-06-06 10:26:28 Robie Basak summary authorized_keys using from="hostname" no longer work when upgrading to Xenial UseDNS default changed to no, locking out authorized_keys from="hostname" users when upgrading to Xenial
2016-06-07 17:31:24 Robie Basak openssh (Ubuntu): status New Won't Fix
2016-06-07 17:31:27 Robie Basak bug added subscriber Robie Basak
2016-06-22 16:28:52 Mathew Hodson bug task added ubuntu-release-notes
2016-06-22 16:29:20 Mathew Hodson ubuntu-release-notes: status New Fix Released