I can confirm that the updated package works in that the real use case
which triggered the original bug (involving a script setting up an ssh
tunnel) no longer does. Sorry for the delay in responding -- things have
been busy, so I have also not tested the updated package much.
I have not updated
And I can confirm that the patch at
https://bugzilla.mindrot.org/attachment.cgi?id=3581 applies cleanly and
fixes this issue.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
Public bug reported:
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
I think Dan's summary above is very good. For clarification I would add
a couple of points.
The issue is not just remote logins. xdm behaves in the same way, and
the absence of a systemd-logind session may mean that sound is then
unavailable to the user logged in at the console. (Mentioned to
I can confirm that installing nscd also solves the problem without
needing to fiddle with the systemd-logind restrictions. However, I am no
fan of nscd. Caching passwords for ten minutes (its default) causes all
sorts of confusion when a user changes his password, or requests a
password reset, for
Thanks for that. I can confirm that
systemctl daemon-reload; systemctl restart systemd-logind
(in that order) avoids the need for a reboot, and for a couple of my
machines I am very grateful for this information.
--
You received this bug notification because you are a member of Ubuntu
Touch
A little more information, after some investigation.
The issue affects xdm logins at the console, as well as remote ssh
logins. This also means that audio at the console fails to work, as ACLs
for the console's user are not added to the audio devices.
It seem that it can be solved by putting in
Public bug reported:
On the first login of the week, xdm (1.1.11-3ubuntu2) fails to start on
Ubuntu 20.04.
More correctly, it does start, but exits almost immediately on signal
12. It leaves /var/run/xdm.pid behind, and also a running X server with
no clients. This makes it hard to restart, for
A good idea, but it made no difference for me. I even went a little
further and tried
[Service]
RestrictAddressFamilies=AF_INET
IPAddressAllow=any
SystemCallFilter=
ProtectSystem=off
CapabilityBoundingSet=
but still no change, even after a reboot. Logins produce the pair of
lines
Apr 5
I think I am suffering from the same issue.
I have always run without "UsePAM yes" in sshd_config, but I recently
tried turning it on in order to get XDG_ variables set correctly and
proper systemd sessions for ssh logins.
In 18.04 it worked as expected, but in 20.04 I get
sshd[387766]:
10 matches
Mail list logo
