** Description changed:
[Impact]
On a default Xenial install, when sshd is configured to obtain the list
of allowed keys using AuthorizedKeysCommand (or the list of allowed
certificate principals using AuthorizedPrincipalsCommand), and if the
command pointed by Authorized{Keys,Principals}Command generates a lot of
output, sshd will hang while reading this same output. In a nutshell,
the problem happens when the subprocess generates enough data to fill
the pipe's buffer; in this scenario, sshd will wait(2) on the
subprocess, which will be blocked trying to write the rest of the
output.
[Test Case]
In order to reproduce the bug, one can:
$ lxc launch ubuntu-daily:xenial openssh-server-bug1877454
$ lxc shell openssh-server-bug1877454
# ssh-keygen
(no need to choose a passphrase for the key, just hit ENTER on all prompts)
# cat > authkeyscommand.sh << __EOF__
#!/bin/bash
cat /root/.ssh/id_rsa.pub
echo
head -c 1M < /dev/urandom
__EOF__
+ # chmod +x authkeyscommand.sh
# cat >> /etc/ssh/sshd_config << __EOF__
AuthorizedKeysCommand /root/authkeyscommand.sh
AuthorizedKeysCommandUser root
__EOF__
# systemctl reload sshd.service
# ssh root@127.0.0.1
You will notice that ssh will stay there waiting for sshd's reply, which
won't come. The expected result would be for ssh to succeed.
[Regression Potential]
Since the affected code deals with executing a subprocess, reading its
output through a pipe, and then relying on wait(2) to determine whether
the subprocess exited correctly; and considering that this code is
written in C without the help of features like RAII and with the use of
goto statements, we are not able to disconsider the chances of making a
mistake and forgetting to free a resource or to properly read/write
from/to pipes, for example. This is, after all, the reason the bug
happened in the first place.
Having said that, openssh contains extensive tests and the code is well
organized and relatively easy to follow. Upon close inspection, there
doesn't seem to be an evident problem with the backported fixes.
As usual when dealing with a somewhat older distribution, there is
always the possibility of encountering problems because we will be
recompiling openssh using the most recent versions of its build
dependencies.
[Original Description]
Please consider applying this change to openssh-server distributed in Xenial
(16.04).
Without it, sshd can sporadically hang when making use of the
`AuthorizedKeysCommand` option.
https://github.com/openssh/openssh-
portable/commit/ddd3d34e5c7979ca6f4a3a98a7d219a4ed3d98c2
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1877454
Title:
openssh-server hangs with AuthorizedKeysCommand
Status in openssh package in Ubuntu:
Fix Released
Status in openssh source package in Xenial:
Confirmed
Bug description:
[Impact]
On a default Xenial install, when sshd is configured to obtain the
list of allowed keys using AuthorizedKeysCommand (or the list of
allowed certificate principals using AuthorizedPrincipalsCommand), and
if the command pointed by Authorized{Keys,Principals}Command generates
a lot of output, sshd will hang while reading this same output. In a
nutshell, the problem happens when the subprocess generates enough
data to fill the pipe's buffer; in this scenario, sshd will wait(2) on
the subprocess, which will be blocked trying to write the rest of the
output.
[Test Case]
In order to reproduce the bug, one can:
$ lxc launch ubuntu-daily:xenial openssh-server-bug1877454
$ lxc shell openssh-server-bug1877454
# ssh-keygen
(no need to choose a passphrase for the key, just hit ENTER on all prompts)
# cat > authkeyscommand.sh << __EOF__
#!/bin/bash
cat /root/.ssh/id_rsa.pub
echo
head -c 1M < /dev/urandom
__EOF__
# chmod +x authkeyscommand.sh
# cat >> /etc/ssh/sshd_config << __EOF__
AuthorizedKeysCommand /root/authkeyscommand.sh
AuthorizedKeysCommandUser root
__EOF__
# systemctl reload sshd.service
# ssh root@127.0.0.1
You will notice that ssh will stay there waiting for sshd's reply,
which won't come. The expected result would be for ssh to succeed.
[Regression Potential]
Since the affected code deals with executing a subprocess, reading its
output through a pipe, and then relying on wait(2) to determine
whether the subprocess exited correctly; and considering that this
code is written in C without the help of features like RAII and with
the use of goto statements, we are not able to disconsider the chances
of making a mistake and forgetting to free a resource or to properly
read/write from/to pipes, for example. This is, after all, the reason
the bug happened in the first place.
Having said that, openssh contains extensive tests and the code is
well organized and relatively easy to follow. Upon close inspection,
there doesn't seem to be an evident problem with the backported fixes.
As usual when dealing with a somewhat older distribution, there is
always the possibility of encountering problems because we will be
recompiling openssh using the most recent versions of its build
dependencies.
[Original Description]
Please consider applying this change to openssh-server distributed in Xenial
(16.04).
Without it, sshd can sporadically hang when making use of the
`AuthorizedKeysCommand` option.
https://github.com/openssh/openssh-
portable/commit/ddd3d34e5c7979ca6f4a3a98a7d219a4ed3d98c2
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1877454/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
