Debian Bug report logs - #1007822
"ssh -XAf localhost xeyes" uses 100% CPU after losing tty

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Harald Dunkel <harri@afaics.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: "ssh -XAf localhost xeyes" uses 100% CPU after losing tty

Date: Thu, 17 Mar 2022 13:26:09 +0100

Package: openssh-client
Version: 1:8.9p1-3

If I use

	ssh -XAf localhost xterm

to run a second xterm, then ssh eats up 100% CPU after closing the
first xterm.

Same happens for xeyes or other XWindow apps. It doesn't have to be
localhost, either.

"nohup ssh -XAf ..." seems to work, but for Bullseye it works very well
without nohup.

SHELL is bash 5.1-6


Regards
Harri

Message #10 received at 1007822@bugs.debian.org (full text, mbox, reply):

From: Harald Dunkel <harri@afaics.de>

To: 1007822@bugs.debian.org

Subject: Re: Bug#1007822: Acknowledgement ("ssh -XAf localhost xeyes" uses 100% CPU after losing tty)

Date: Thu, 17 Mar 2022 13:40:13 +0100

PS: No such problem for openssh-client 1:8.8p1-1 from Testing.

Message #15 received at 1007822@bugs.debian.org (full text, mbox, reply):

From: Harald Dunkel <harri@afaics.de>

To: 1007822@bugs.debian.org

Subject: Re: "ssh -XAf localhost xeyes" uses 100% CPU after losing tty

Date: Wed, 23 Mar 2022 07:14:16 +0100

see https://bugzilla.mindrot.org/show_bug.cgi?id=3411

Message #20 received at 1007822@bugs.debian.org (full text, mbox, reply):

From: Ralf Jung <post@ralfj.de>

To: 1007822@bugs.debian.org

Subject: Re: "ssh -XAf localhost xeyes" uses 100% CPU after losing tty

Date: Wed, 23 Mar 2022 20:30:52 -0400

Hi all,

I am also seeing 100% CPU load from SSH when using it with autossh to set up 
port forwarding in the background (no X11 forwarding involved):

/usr/bin/autossh -M 0 -N -o "ServerAliveInterval 30" -R $IP:$PORT1:localhost:443 
-R $IP:$PORT2:localhost:80 $USER@$HOST -i $KEY

This only recently started with the latest 'apt upgrade'.

; Ralf

On Thu, 17 Mar 2022 13:26:09 +0100 Harald Dunkel <harri@afaics.de> wrote:
> Package: openssh-client
> Version: 1:8.9p1-3
> 
> If I use
> 
> 	ssh -XAf localhost xterm
> 
> to run a second xterm, then ssh eats up 100% CPU after closing the
> first xterm.
> 
> Same happens for xeyes or other XWindow apps. It doesn't have to be
> localhost, either.
> 
> "nohup ssh -XAf ..." seems to work, but for Bullseye it works very well
> without nohup.
> 
> SHELL is bash 5.1-6
> 
> 
> Regards
> Harri
> 
> 

Message #25 received at 1007822-close@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 1007822-close@bugs.debian.org

Subject: Bug#1007822: fixed in openssh 1:9.0p1-1

Date: Sat, 09 Apr 2022 13:34:58 +0000

Source: openssh
Source-Version: 1:9.0p1-1
Done: Colin Watson <cjwatson@debian.org>

We believe that the bug you reported is fixed in the latest version of
openssh, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1007822@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Colin Watson <cjwatson@debian.org> (supplier of updated openssh package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Sat, 09 Apr 2022 14:14:10 +0100
Source: openssh
Architecture: source
Version: 1:9.0p1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian OpenSSH Maintainers <debian-ssh@lists.debian.org>
Changed-By: Colin Watson <cjwatson@debian.org>
Closes: 144579 204546 327019 1007822
Changes:
 openssh (1:9.0p1-1) unstable; urgency=medium
 .
   * New upstream release (https://www.openssh.com/releasenotes.html#9.0p1):
     - scp(1): Use the SFTP protocol by default (closes: #144579, #204546,
       #327019). This changes scp's quoting semantics by no longer performing
       wildcard expansion using the remote shell, and (with some server
       versions) no longer expanding ~user paths. The -O option is available
       to use the old protocol. See NEWS.Debian for more details.
     - ssh(1), sshd(8): use the hybrid Streamlined NTRU Prime + x25519 key
       exchange method by default ("sntrup761x25519-sha512@openssh.com").
       The NTRU algorithm is believed to resist attacks enabled by future
       quantum computers and is paired with the X25519 ECDH key exchange (the
       previous default) as a backstop against any weaknesses in NTRU Prime
       that may be discovered in the future. The combination ensures that the
       hybrid exchange offers at least as good security as the status quo.
     - sftp-server(8): support the "copy-data" extension to allow server-
       side copying of files/data, following the design in
       draft-ietf-secsh-filexfer-extensions-00.
     - sftp(1): add a "cp" command to allow the sftp client to perform
       server-side file copies.
     - ssh(1), sshd(8): upstream: fix poll(2) spin when a channel's output fd
       closes without data in the channel buffer (closes: #1007822).
     - sshd(8): pack pollfd array in server listen/accept loop. Could cause
       the server to hang/spin when MaxStartups > RLIMIT_NOFILE.
     - ssh-keygen(1): avoid NULL deref via the find-principals and
       check-novalidate operations. bz3409 and GHPR307 respectively.
     - scp(1): fix a memory leak in argument processing.
     - sshd(8): don't try to resolve ListenAddress directives in the sshd
       re-exec path. They are unused after re-exec and parsing errors
       (possible for example if the host's network configuration changed)
       could prevent connections from being accepted.
     - sshd(8): when refusing a public key authentication request from a
       client for using an unapproved or unsupported signature algorithm
       include the algorithm name in the log message to make debugging
       easier.
     - ssh(1), sshd(8): Fix possible integer underflow in scan_scaled(3)
       parsing of K/M/G/etc quantities.
     - sshd(8): default to not using sandbox when cross compiling. On most
       systems poll(2) does not work when the number of FDs is reduced with
       setrlimit, so assume it doesn't when cross compiling and we can't run
       the test.
   * Remove obsolete FAQ, removed from openssh.com in 2016.
Checksums-Sha1:
 10bef2e8c5736db098294e86fb3de29cd37af262 3347 openssh_9.0p1-1.dsc
 06dd658874dcd22d66311cf5999bd56c614de509 1822183 openssh_9.0p1.orig.tar.gz
 af112ac3c8d4ebd515e71fb6ef4d7633056c11e1 833 openssh_9.0p1.orig.tar.gz.asc
 ce125a7f2ed78c5830b0f0273bce9772df56c64a 176128 openssh_9.0p1-1.debian.tar.xz
Checksums-Sha256:
 ff368f3247c89eea2be10cd2ad2fcb9d0811fc6652c9cab9d01d087203e28fdd 3347 openssh_9.0p1-1.dsc
 03974302161e9ecce32153cfa10012f1e65c8f3750f573a73ab1befd5972a28a 1822183 openssh_9.0p1.orig.tar.gz
 5db3a2eb3e8e9c8ae62527ea55f5a6fa41c395ebd0bbb65f4b3dfebeeee5fa00 833 openssh_9.0p1.orig.tar.gz.asc
 46f24ab534892c55c82ebafdac23564579f9be73a7cc0230730a2e6aa64e17ab 176128 openssh_9.0p1-1.debian.tar.xz
Files:
 7c4fc7db25ae43e139147c863c58dcce 3347 net standard openssh_9.0p1-1.dsc
 5ed8252a0ee379c0f7c9e0d25d32424d 1822183 net standard openssh_9.0p1.orig.tar.gz
 eb64a4f2d204c43658c2d9d3bc6b3a2a 833 net standard openssh_9.0p1.orig.tar.gz.asc
 69841d0ed1008a71168dd4277df50e69 176128 net standard openssh_9.0p1-1.debian.tar.xz

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAmJRhtcACgkQOTWH2X2G
UAvu3BAAjS5VRJ+iDTnJzL8wNTKEwfC8pbK3EovhYNXGVZPgYRUSFVHcuCS0NWwR
11TRkiugwBrM60y5ZzNU0N8T7ypn0gTdFf6S3HhN5DxM2IWb+xNmk/27/RPp1LrI
/Ywg3pXGXPnveJvVI9TS/AWBp4n/D7ABqTrD8+H3P33MC70Otgwuw5MvJmD+RM5z
N5C3/q3B8/8ciuW7h8pm/YDKkbxod1oKCJqRPLGGE4f5bqFGh0V3dKQaPS1tnxkj
+6adxCN1ix0Ci3jJurFjFw1QxTITl/PV1kyNiuaBhu2a7tGqV3vs9dt3mD5B7pt3
DEuw3MzEpZoU31sR+uGeksMnYqyxh+4P7o8qOQtP7LMuR/0iS2pwNG+mSDBMp5mq
J4svdzn0dYBut9ic2qr2Aj/Bf/pISTnA8EWr3l9zyN4Oo9QzmtD/PLZ7FNVvCCii
0v5poNVVuZANWKGDCNnhGDOPvIsxKG/IQ+3sU1EUv79dnFvrTDEhzLTLigA5hGH2
cJhD4BbxfMky1SnqMSOKW7MHBH4eKdf7AI83zlXjMPBe4F5xJ113F2BiMJHuvu99
S7fPdWMrhoTXXaB0MCFr1B02lBiJXDG0oho2P6pUXQaWoN5qajy/IJrWryxwfhxM
rYuPGD+QuXhEgTD5q/Gjccdq/FEXExnJDzYskclgJ2+onNOc7i4=
=gUly
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.