Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

upgrade to bookworm broke ssh x11 forwarding

69 views
Skip to first unread message

fxkl...@protonmail.com

unread,
Nov 9, 2023, 10:10:06 AM11/9/23
to
i upgraded from bullseye to bookworm with no problems
when i try ssh with -X/-Y to the bookworm machine x11 forwarding fails

debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending env LC_ALL = en_US.UTF-8
X11 forwarding request failed on channel 0

the .Xauthority file is not updated
is there new security or configuration

fxkl...@protonmail.com

unread,
Nov 9, 2023, 11:50:06 AM11/9/23
to
On Thu, 9 Nov 2023, Greg Wooledge wrote:
> On the server, run:
>
> grep X11 /etc/ssh/sshd_config
>
> That should tell you whether X11Forwarding and its related options have
> been disabled.
>

$ grep X11 /etc/ssh/sshd_config
X11Forwarding yes

Greg Wooledge

unread,
Nov 9, 2023, 11:50:07 AM11/9/23
to
On Thu, Nov 09, 2023 at 03:01:29PM +0000, fxkl...@protonmail.com wrote:

fxkl...@protonmail.com

unread,
Nov 9, 2023, 12:10:07 PM11/9/23
to
now it makes a bit more sense
sshd isn't running
for some reason the upgrade switched to dropbear
is this a new thing for bookworm
is there a reason i shouldn't disable dropbear and use sshd

Greg Wooledge

unread,
Nov 9, 2023, 1:10:07 PM11/9/23
to
On Thu, Nov 09, 2023 at 04:59:32PM +0000, fxkl...@protonmail.com wrote:
> now it makes a bit more sense
> sshd isn't running
> for some reason the upgrade switched to dropbear
> is this a new thing for bookworm
> is there a reason i shouldn't disable dropbear and use sshd

No, this is not a normal phenomenon for bookworm upgrades. I've never
heard of it happening to anyone before.

You should be able to reinstall openssh-server and remove dropbear
and get back to normal, unless there's something else unusual in
your package set. As this situation is (AFAIK) unique to your system,
you'll have to be the one to try it and see what happens.

Jeffrey Walton

unread,
Nov 9, 2023, 1:30:07 PM11/9/23
to
Probably need a 'grep -IR' since overrides can be provided in sshd_config.d/ :

$ sudo ls /etc/ssh/sshd_config.d/
10-pubkey_auth.conf 20-no_root_login.conf

And:

$ sudo cat /etc/ssh/sshd_config.d/10-pubkey_auth.conf
PasswordAuthentication no
ChallengeResponseAuthentication no
KerberosAuthentication no
KerberosOrLocalPasswd no
GSSAPIAuthentication no
UsePAM no
PubkeyAuthentication yes

Jeff

fxkl...@protonmail.com

unread,
Nov 9, 2023, 1:40:06 PM11/9/23
to
my /etc/ssh/sshd_config.d/ is empty

fxkl...@protonmail.com

unread,
Nov 9, 2023, 1:40:06 PM11/9/23
to
On Thu, 9 Nov 2023, Greg Wooledge wrote:

openssh was installed just not running
i stopped and disabled dropbear and started sshd
all is right for now
thanks

Jeffrey Walton

unread,
Nov 9, 2023, 7:00:07 PM11/9/23
to
> my /etc/ssh/sshd_config.d/ is empty

/etc/ssh/sshd_config.d/ is where you are supposed to make changes.
Otherwise, new config files get written during upgrades, and overwrite
the old settings. Changes in sshd_config.d always survive, and always
take precedence over the distro's settings.

Jeff

Michael

unread,
Nov 10, 2023, 5:10:08 AM11/10/23
to
On Thursday, 9 November 2023 19:08:25 CET, Greg Wooledge wrote:
> No, this is not a normal phenomenon for bookworm upgrades. I've never
> heard of it happening to anyone before.


i disagree. i had the same problem b/c i also had dropbear installed. for
some reason the dropbear daemon is started first in bookworm, so port 22
was already in use when sshd was started. reading the log file (aka
systemd-journal) was very enlightening.

a simple

systemctl stop dropbear.service
systemctl disable dropbear.service
systemctl start ssh.service

was enough to solve the problem. of course, one needs access to the
console...

greetings...

Vincent Lefevre

unread,
Nov 10, 2023, 9:50:07 AM11/10/23
to
On 2023-11-10 10:57:21 +0100, Michael wrote:
> On Thursday, 9 November 2023 19:08:25 CET, Greg Wooledge wrote:
> > No, this is not a normal phenomenon for bookworm upgrades. I've never
> > heard of it happening to anyone before.
>
> i disagree. i had the same problem b/c i also had dropbear installed.

It would be interesting to know why dropbear got installed (if
openssh-server was already installed, this is rather surprising),
e.g. with "aptitude why dropbear".

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

fxkl...@protonmail.com

unread,
Nov 10, 2023, 10:40:06 AM11/10/23
to
On Fri, 10 Nov 2023, Vincent Lefevre wrote:

> On 2023-11-10 10:57:21 +0100, Michael wrote:
>> On Thursday, 9 November 2023 19:08:25 CET, Greg Wooledge wrote:
>>> No, this is not a normal phenomenon for bookworm upgrades. I've never
>>> heard of it happening to anyone before.
>>
>> i disagree. i had the same problem b/c i also had dropbear installed.
>
> It would be interesting to know why dropbear got installed

at sometime in the distance past i thought it would be handy
my initial ramdisk is set up so i can remotely unlock the filesystems

David Wright

unread,
Nov 10, 2023, 11:20:07 AM11/10/23
to
You may have been relying on a race condition as to whether
openssh or dropbear started first, and were just lucky in bullseye.

The OP's "for some reason the upgrade switched to dropbear" is
somewhat ambiguous, but it looks like the same problem. Perhaps
Greg interpreted that "switched to" as meaning "installed as
a dependency".

Cheers,
David.

to...@tuxteam.de

unread,
Nov 10, 2023, 12:50:06 PM11/10/23
to
Wait a minute: dropbear is supposed to run in the initramfs, while
sshd will be active afterwards, after pivot-root and all that, right?

Then I don't quite get why they should collide at all.

Cheers
--
t
signature.asc

to...@tuxteam.de

unread,
Nov 10, 2023, 1:30:06 PM11/10/23
to
On Fri, Nov 10, 2023 at 01:01:28PM -0500, Dan Ritter wrote:
> to...@tuxteam.de wrote:

[...]

> > Wait a minute: dropbear is supposed to run in the initramfs, while
> > sshd will be active afterwards, after pivot-root and all that, right?
> >
> > Then I don't quite get why they should collide at all.
>
> Because dropbear *can* be run as an ordinary sshd, and some
> people do.

Ugh. Re-reading I realise that I was ambiguous. I meant
"in this case", not in general. Of course, you're right.

Cheers
--
t
signature.asc

Dan Ritter

unread,
Nov 10, 2023, 1:30:06 PM11/10/23
to
Because dropbear *can* be run as an ordinary sshd, and some
people do.

-dsr-

to...@tuxteam.de

unread,
Nov 13, 2023, 5:20:07 AM11/13/23
to
On Mon, Nov 13, 2023 at 11:10:17AM +0100, Vincent Lefevre wrote:

[...]

> This is what I've done for my old laptop, but the dropbear package
> is *not* needed for that! You just need the dropbear-initramfs
> package [...]

Aha -- now I know the full story. Thanks, Vincent (and all the other
smart folks sharing their wisdom here)

Cheers
--
t
signature.asc

Vincent Lefevre

unread,
Nov 13, 2023, 5:20:07 AM11/13/23
to
This is what I've done for my old laptop, but the dropbear package
is *not* needed for that! You just need the dropbear-initramfs
package (dropbear-bin will be installed as a consequence as a
dependency, but not the dropbear package, which contains the
startup scripts). If you install the dropbear package, i.e. the
startup scripts, this means that you want dropbear as you're
main sshd daemon rather than the one from OpenSSH.
0 new messages