| 2022-08-15 10:45:38 |
Michael Rutter |
bug |
|
|
added bug |
| 2022-08-17 19:52:22 |
Sergio Durigan Junior |
nominated for series |
|
Ubuntu Jammy |
|
| 2022-08-17 19:52:22 |
Sergio Durigan Junior |
bug task added |
|
openssh (Ubuntu Jammy) |
|
| 2022-08-17 19:52:32 |
Sergio Durigan Junior |
openssh (Ubuntu): status |
New |
Fix Released |
|
| 2022-08-17 19:52:35 |
Sergio Durigan Junior |
openssh (Ubuntu Jammy): status |
New |
Triaged |
|
| 2022-08-17 19:52:37 |
Sergio Durigan Junior |
openssh (Ubuntu Jammy): importance |
Undecided |
Medium |
|
| 2022-08-17 19:52:43 |
Sergio Durigan Junior |
bug |
|
|
added subscriber Ubuntu Server |
| 2022-08-17 19:53:03 |
Sergio Durigan Junior |
bug watch added |
|
https://bugzilla.mindrot.org/show_bug.cgi?id=3405 |
|
| 2022-08-17 19:53:03 |
Sergio Durigan Junior |
bug task added |
|
openssh |
|
| 2022-10-17 21:38:28 |
Bryce Harrington |
tags |
|
server-todo |
|
| 2022-11-09 16:19:53 |
Christian Ehrhardt |
openssh (Ubuntu Jammy): assignee |
|
Bryce Harrington (bryce) |
|
| 2022-12-01 03:01:41 |
Bryce Harrington |
description |
The OpenSSH package 8.9p1 as shipped with U22.04 (8.9p1-3) suffers from the bug described at
https://bugzilla.mindrot.org/show_bug.cgi?id=3411 and https://bugzilla.mindrot.org/show_bug.cgi?id=3405
A command such as "xterm -e 'ssh -f remote.host sleep 60'" will pop up an xterm, ask for whatever authentication is needed, close the xterm, and leave the ssh client spinning consuming CPU time for 60 seconds before it exits. It should leave the ssh client idle for 60 seconds. Many uses of ssh to launch graphical applications will be caught by this bug.
This is fixed in OpenSSH 9.0p1 as the first bugfix listed in its release notes at https://www.openssh.com/txt/release-9.0 |
[Test Case]
$ lxc launch ubuntu-daily:jammy ssh-cpu
$ lxc shell ssh-cpu
# passwd -d root
# ssh-keygen -t rsa -N '' -f /root/.ssh/id_rsa
# cat << EOF >>/etc/ssh/ssh_config
StrictHostKeyChecking accept-new
EOF
# sed -ri 's/^PasswordAuthentication/#PasswordAuthentication/' /etc/ssh/sshd_config
# cat << EOF >>/etc/ssh/sshd_config
PermitRootLogin yes
PubkeyAuthentication yes
PermitEmptyPasswords yes
PasswordAuthentication yes
ChallengeResponseAuthentication no
UsePAM no
EOF
# systemctl restart sshd
# ssh localhost 2> >({exec 1>&2})
You can shell into the container from a second terminal and use "htop"
to verify that ssh is using 100% of one of the CPU cores:
$ lxc shell ssh-cpu
# htop
This should show one CPU pegged at 100% due to the 'ssh localhost' process
Next, return to the first terminal, exit out of the sub-ssh session and
install the fix:
# logout
# add-apt-repository -yus ppa:bryce/openssh-sru-lp1986521
# apt-get full-upgrade -y
Now repeat the test in the first terminal window, while viewing htop in
the second terminal:
# ssh localhost 2> >({exec 1>&2})
[Original Report]
The OpenSSH package 8.9p1 as shipped with U22.04 (8.9p1-3) suffers from the bug described at
https://bugzilla.mindrot.org/show_bug.cgi?id=3411 and https://bugzilla.mindrot.org/show_bug.cgi?id=3405
A command such as "xterm -e 'ssh -f remote.host sleep 60'" will pop up an xterm, ask for whatever authentication is needed, close the xterm, and leave the ssh client spinning consuming CPU time for 60 seconds before it exits. It should leave the ssh client idle for 60 seconds. Many uses of ssh to launch graphical applications will be caught by this bug.
This is fixed in OpenSSH 9.0p1 as the first bugfix listed in its release notes at https://www.openssh.com/txt/release-9.0 |
|
| 2022-12-01 03:58:53 |
Bryce Harrington |
description |
[Test Case]
$ lxc launch ubuntu-daily:jammy ssh-cpu
$ lxc shell ssh-cpu
# passwd -d root
# ssh-keygen -t rsa -N '' -f /root/.ssh/id_rsa
# cat << EOF >>/etc/ssh/ssh_config
StrictHostKeyChecking accept-new
EOF
# sed -ri 's/^PasswordAuthentication/#PasswordAuthentication/' /etc/ssh/sshd_config
# cat << EOF >>/etc/ssh/sshd_config
PermitRootLogin yes
PubkeyAuthentication yes
PermitEmptyPasswords yes
PasswordAuthentication yes
ChallengeResponseAuthentication no
UsePAM no
EOF
# systemctl restart sshd
# ssh localhost 2> >({exec 1>&2})
You can shell into the container from a second terminal and use "htop"
to verify that ssh is using 100% of one of the CPU cores:
$ lxc shell ssh-cpu
# htop
This should show one CPU pegged at 100% due to the 'ssh localhost' process
Next, return to the first terminal, exit out of the sub-ssh session and
install the fix:
# logout
# add-apt-repository -yus ppa:bryce/openssh-sru-lp1986521
# apt-get full-upgrade -y
Now repeat the test in the first terminal window, while viewing htop in
the second terminal:
# ssh localhost 2> >({exec 1>&2})
[Original Report]
The OpenSSH package 8.9p1 as shipped with U22.04 (8.9p1-3) suffers from the bug described at
https://bugzilla.mindrot.org/show_bug.cgi?id=3411 and https://bugzilla.mindrot.org/show_bug.cgi?id=3405
A command such as "xterm -e 'ssh -f remote.host sleep 60'" will pop up an xterm, ask for whatever authentication is needed, close the xterm, and leave the ssh client spinning consuming CPU time for 60 seconds before it exits. It should leave the ssh client idle for 60 seconds. Many uses of ssh to launch graphical applications will be caught by this bug.
This is fixed in OpenSSH 9.0p1 as the first bugfix listed in its release notes at https://www.openssh.com/txt/release-9.0 |
[Impact]
In certain edge cases where the terminal goes away while an ssh process is running, ssh can be left consuming 100% CPU. This increases processing costs for cloud users and wastes energy.
This is a regression in jammy presumably due to change from select() to poll() (see OpennSSH 8.9 Release Announcement [1] ), fixed by upstream commit d6556de1db0822c76ba2745cf5c097d9472adf7c "upstream: fix poll() spin when a channel's output fd closes..." [2].
1: https://lwn.net/Articles/885886/
2. https://github.com/openssh/openssh-portable/commit/d6556de1db0822c76ba2745cf5c097d9472adf7c
[Test Case]
$ lxc launch ubuntu-daily:jammy ssh-cpu
$ lxc shell ssh-cpu
# passwd -d root
# ssh-keygen -t rsa -N '' -f /root/.ssh/id_rsa
# cat << EOF >>/etc/ssh/ssh_config
StrictHostKeyChecking accept-new
EOF
# sed -ri 's/^PasswordAuthentication/#PasswordAuthentication/' /etc/ssh/sshd_config
# cat << EOF >>/etc/ssh/sshd_config
PermitRootLogin yes
PubkeyAuthentication yes
PermitEmptyPasswords yes
PasswordAuthentication yes
ChallengeResponseAuthentication no
UsePAM no
EOF
# systemctl restart sshd
# ssh localhost 2> >({exec 1>&2})
You can shell into the container from a second terminal and use "htop"
to verify that ssh is using 100% of one of the CPU cores:
$ lxc shell ssh-cpu
# htop
This should show one CPU pegged at 100% due to the 'ssh localhost' process
Next, return to the first terminal, exit out of the sub-ssh session and
install the fix:
# logout
# add-apt-repository -yus ppa:bryce/openssh-sru-lp1986521
# apt-get full-upgrade -y
Now repeat the test in the first terminal window, while viewing htop in
the second terminal:
# ssh localhost 2> >({exec 1>&2})
[Where Problems Could Occur]
While the patch in question is well tested upstream, it has a relatively high line count and as such is difficult to assure correctness by visual code checking. However, it's not clear that the line count could be significantly reduced without risking loss of correctness. Thus this relies more on testing to assure robustness, than on code review.
The code involves polling behavior, so issues to watch for would more likely involve process handling, i.e. problems with socket polling.
Beyond that, the usual generic issues to watch for - build issues, dependency issues during build or on upgrade, and service restarting.
[Original Report]
The OpenSSH package 8.9p1 as shipped with U22.04 (8.9p1-3) suffers from the bug described at
https://bugzilla.mindrot.org/show_bug.cgi?id=3411 and https://bugzilla.mindrot.org/show_bug.cgi?id=3405
A command such as "xterm -e 'ssh -f remote.host sleep 60'" will pop up an xterm, ask for whatever authentication is needed, close the xterm, and leave the ssh client spinning consuming CPU time for 60 seconds before it exits. It should leave the ssh client idle for 60 seconds. Many uses of ssh to launch graphical applications will be caught by this bug.
This is fixed in OpenSSH 9.0p1 as the first bugfix listed in its release notes at https://www.openssh.com/txt/release-9.0 |
|
| 2022-12-01 04:00:11 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~bryce/ubuntu/+source/openssh/+git/openssh/+merge/433911 |
|
| 2022-12-01 04:04:36 |
Bryce Harrington |
description |
[Impact]
In certain edge cases where the terminal goes away while an ssh process is running, ssh can be left consuming 100% CPU. This increases processing costs for cloud users and wastes energy.
This is a regression in jammy presumably due to change from select() to poll() (see OpennSSH 8.9 Release Announcement [1] ), fixed by upstream commit d6556de1db0822c76ba2745cf5c097d9472adf7c "upstream: fix poll() spin when a channel's output fd closes..." [2].
1: https://lwn.net/Articles/885886/
2. https://github.com/openssh/openssh-portable/commit/d6556de1db0822c76ba2745cf5c097d9472adf7c
[Test Case]
$ lxc launch ubuntu-daily:jammy ssh-cpu
$ lxc shell ssh-cpu
# passwd -d root
# ssh-keygen -t rsa -N '' -f /root/.ssh/id_rsa
# cat << EOF >>/etc/ssh/ssh_config
StrictHostKeyChecking accept-new
EOF
# sed -ri 's/^PasswordAuthentication/#PasswordAuthentication/' /etc/ssh/sshd_config
# cat << EOF >>/etc/ssh/sshd_config
PermitRootLogin yes
PubkeyAuthentication yes
PermitEmptyPasswords yes
PasswordAuthentication yes
ChallengeResponseAuthentication no
UsePAM no
EOF
# systemctl restart sshd
# ssh localhost 2> >({exec 1>&2})
You can shell into the container from a second terminal and use "htop"
to verify that ssh is using 100% of one of the CPU cores:
$ lxc shell ssh-cpu
# htop
This should show one CPU pegged at 100% due to the 'ssh localhost' process
Next, return to the first terminal, exit out of the sub-ssh session and
install the fix:
# logout
# add-apt-repository -yus ppa:bryce/openssh-sru-lp1986521
# apt-get full-upgrade -y
Now repeat the test in the first terminal window, while viewing htop in
the second terminal:
# ssh localhost 2> >({exec 1>&2})
[Where Problems Could Occur]
While the patch in question is well tested upstream, it has a relatively high line count and as such is difficult to assure correctness by visual code checking. However, it's not clear that the line count could be significantly reduced without risking loss of correctness. Thus this relies more on testing to assure robustness, than on code review.
The code involves polling behavior, so issues to watch for would more likely involve process handling, i.e. problems with socket polling.
Beyond that, the usual generic issues to watch for - build issues, dependency issues during build or on upgrade, and service restarting.
[Original Report]
The OpenSSH package 8.9p1 as shipped with U22.04 (8.9p1-3) suffers from the bug described at
https://bugzilla.mindrot.org/show_bug.cgi?id=3411 and https://bugzilla.mindrot.org/show_bug.cgi?id=3405
A command such as "xterm -e 'ssh -f remote.host sleep 60'" will pop up an xterm, ask for whatever authentication is needed, close the xterm, and leave the ssh client spinning consuming CPU time for 60 seconds before it exits. It should leave the ssh client idle for 60 seconds. Many uses of ssh to launch graphical applications will be caught by this bug.
This is fixed in OpenSSH 9.0p1 as the first bugfix listed in its release notes at https://www.openssh.com/txt/release-9.0 |
[Impact]
In certain edge cases where the terminal goes away while an ssh process is running, ssh can be left consuming 100% CPU. This increases processing costs for cloud users and wastes energy. While this is an uncommon error, googling indicates many people have run into it in several different ways. It seems important to get this fixed in stable releases.
This is a regression in jammy presumably due to change from select() to poll() (see OpennSSH 8.9 Release Announcement [1] ), fixed by upstream commit d6556de1db0822c76ba2745cf5c097d9472adf7c "upstream: fix poll() spin when a channel's output fd closes..." [2].
1: https://lwn.net/Articles/885886/
2. https://github.com/openssh/openssh-portable/commit/d6556de1db0822c76ba2745cf5c097d9472adf7c
[Test Case]
$ lxc launch ubuntu-daily:jammy ssh-cpu
$ lxc shell ssh-cpu
# passwd -d root
# ssh-keygen -t rsa -N '' -f /root/.ssh/id_rsa
# cat << EOF >>/etc/ssh/ssh_config
StrictHostKeyChecking accept-new
EOF
# sed -ri 's/^PasswordAuthentication/#PasswordAuthentication/' /etc/ssh/sshd_config
# cat << EOF >>/etc/ssh/sshd_config
PermitRootLogin yes
PubkeyAuthentication yes
PermitEmptyPasswords yes
PasswordAuthentication yes
ChallengeResponseAuthentication no
UsePAM no
EOF
# systemctl restart sshd
# ssh localhost 2> >({exec 1>&2})
You can shell into the container from a second terminal and use "htop"
to verify that ssh is using 100% of one of the CPU cores:
$ lxc shell ssh-cpu
# htop
This should show one CPU pegged at 100% due to the 'ssh localhost' process
Next, return to the first terminal, exit out of the sub-ssh session and
install the fix:
# logout
# add-apt-repository -yus ppa:bryce/openssh-sru-lp1986521
# apt-get full-upgrade -y
Now repeat the test in the first terminal window, while viewing htop in
the second terminal:
# ssh localhost 2> >({exec 1>&2})
[Where Problems Could Occur]
While the patch in question is well tested upstream, it has a relatively high line count and as such is difficult to assure correctness by visual code checking. However, it's not clear that the line count could be significantly reduced without risking loss of correctness. Thus this relies more on testing to assure robustness, than on code review.
The code involves polling behavior, so issues to watch for would more likely involve process handling, i.e. problems with socket polling.
Beyond that, the usual generic issues to watch for - build issues, dependency issues during build or on upgrade, and service restarting.
[Original Report]
The OpenSSH package 8.9p1 as shipped with U22.04 (8.9p1-3) suffers from the bug described at
https://bugzilla.mindrot.org/show_bug.cgi?id=3411 and https://bugzilla.mindrot.org/show_bug.cgi?id=3405
A command such as "xterm -e 'ssh -f remote.host sleep 60'" will pop up an xterm, ask for whatever authentication is needed, close the xterm, and leave the ssh client spinning consuming CPU time for 60 seconds before it exits. It should leave the ssh client idle for 60 seconds. Many uses of ssh to launch graphical applications will be caught by this bug.
This is fixed in OpenSSH 9.0p1 as the first bugfix listed in its release notes at https://www.openssh.com/txt/release-9.0 |
|
| 2022-12-02 23:11:17 |
Bryce Harrington |
openssh (Ubuntu Jammy): status |
Triaged |
In Progress |
|
| 2022-12-06 21:41:55 |
Brian Murray |
openssh (Ubuntu Jammy): status |
In Progress |
Fix Committed |
|
| 2022-12-06 21:41:57 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2022-12-06 21:41:58 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2022-12-06 21:42:01 |
Brian Murray |
tags |
server-todo |
server-todo verification-needed verification-needed-jammy |
|
| 2022-12-16 23:09:48 |
Bryce Harrington |
tags |
server-todo verification-needed verification-needed-jammy |
server-todo verification-done verification-done-jammy |
|
| 2023-01-10 19:37:21 |
Launchpad Janitor |
openssh (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2023-01-10 19:37:26 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
