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.
* 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.
[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,
address maps back to the very same IP address.
and to check that the resolved host name for the remote IP
If this option is set to “no” (the default) then only addresses
sshd_ config Match Host directives.
and not host names may be used in ~/.ssh/known_hosts from and
[0] http:// changelogs. ubuntu. com/changelogs/ pool/main/ o/openssh/ openssh_ 6.9p1-1/ changelog manpages. ubuntu. com/manpages/ xenial/ en/man5/ sshd_config. 5.html
[1] http://