[Bug 1588457] Re: UseDNS default changed to no, locking out authorized_keys from="hostname" users when upgrading to Xenial

[Robie Basak]

Thank you for taking the time to report this bug and helping to make
Ubuntu better.

This is certainly worthy of a release note, and I have edited the Xenial
release notes to highlight this issue.

Further discussion: http://irclogs.ubuntu.com/2016/06/06/%23ubuntu-
devel.html#t10:26

Based on this discussion I'm marking the bug Won't Fix, but again thank
you for the report since it means that we can alert other users via the
release notes.

** Changed in: openssh (Ubuntu)
       Status: New => Won't Fix

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1588457

Title:
  UseDNS default changed to no, locking out authorized_keys
  from="hostname" users when upgrading to Xenial

Status in openssh package in Ubuntu:
  Won't Fix

Bug 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.

  commit 3cd5103c1e1aaa59bd66f7f52f6ebbcd5deb12f9 [2]
  Author: deraadt at openbsd.org <deraadt at 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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1588457/+subscriptions