为什么当我从计算机通过 SSH 连接到我的树莓派时,bash 有时无法正常启动(但从我的手机通过 SSH 连接时可以正常启动)?

为什么当我从计算机通过 SSH 连接到我的树莓派时,bash 有时无法正常启动(但从我的手机通过 SSH 连接时可以正常启动)?

通常情况下,我可以顺利通过 ssh 进入我的树莓派(运行 Raspbian 11)。但有时,每隔几天,ssh 就会超时。这种情况会持续大约一天(与重启电脑无关),直到我能够再次顺利通过 ssh。同时,我仍然可以使用手机通过 ssh 进入树莓派。在我看来,这排除了基本网络问题;至少肯定可以成功连接到树莓派。

从输出中ssh -vvv pi@mypi我了解到连接已成功建立,并且对于 ssh 来说没有问题,但是随后启动 bash 命令时,连接变得无响应并且超时:

$ ssh -vvv pi@mypi
OpenSSH_8.9p1 Ubuntu-3ubuntu0.1, OpenSSL 3.0.2 15 Mar 2022
[...]
debug1: Connection established.
[...]
Authenticated to mpyi ([10.0.0.1]:22) using "publickey".
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions[...]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: filesystem
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00[...] want_reply 0
[...]
debug1: Remote: /home/pi/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: receive packet: type 4
debug1: Remote: /home/pi/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug1: Sending environment.
debug3: Ignored env SOME_ENV  
[...] # this is repeated a few times
debug1: channel 0: setting env LANG = "de_DE.UTF-8"
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env SOME_ENV
[...] # this is repeated a lot. ignored envs include TERM and GNOME_TERMINAL_SCREEN
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: send packet: type 80
debug3: send packet: type 80
debug3: send packet: type 80
Timeout, server mypi not responding.

使用任何不需要在终端中运行的命令都可以。例如,当使用 并行启动第二个 ssh 会话时ssh pi@mypi sudo pstree,这将输出:

[...]
|-sshd-+-sshd---sshd---bash
|      `-sshd---sshd---sudo---pstree
[...]

为了了解 bash 没有响应的原因,我尝试使用以下选项启动 bash -x:。ssh -vvv pi@mypi bash -x命令提示符没有显示,但这允许交互式输入而不会超时(SSH ServerAlive 数据包现在也得到响应)。top但执行不起作用(“TERM 环境变量未设置。”)。

[...]
debug3: Ignored env SOME_ENV
debug1: Sending command: bash -x
debug2: channel 0: request exec confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug3: send packet: type 80
debug3: receive packet: type 82
echo test
debug2: channel 0: rcvd ext data 12
test
+ echo test
debug2: channel 0: written 12 to efd 6
debug3: send packet: type 80
debug3: receive packet: type 82
ps
debug2: channel 0: rcvd ext data 5
+ ps
debug2: channel 0: written 5 to efd 6
  PID TTY          TIME CMD
  310 ?        00:00:00 ps
  734 ?        00:00:01 systemd
  735 ?        00:00:00 (sd-pam)
 1438 ?        00:21:08 screen
29175 ?        00:06:40 screen
32743 ?        00:00:00 sshd
32744 ?        00:00:00 bash
top
debug2: channel 0: rcvd ext data 6
+ top
debug2: channel 0: written 6 to efd 6
debug2: channel 0: rcvd ext data 35
TERM environment variable not set.
debug2: channel 0: written 35 to efd 6
# at this time, i hit Ctrl+C (on purpose)
# with bash -x on the server side, this is accepted as it should be
# (note: in previous setting, without -x, no input was accepted)
^Cdebug3: send packet: type 1
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i0/0 o0/0 e[write]/0 fd 4/5/6 sock -1 cc -1 io 0x01/0x08)

Killed by signal 2.

显然,终端初始化过程没有成功完成。但只有在使用我的电脑上的 ssh 时,每隔几天才会发生一次,而且只持续一天左右的有限时间。我不知道是什么原因造成的,也不知道如何进一步调查。此外,我无法解释为什么这种情况只是偶尔发生,然后在一天左右后恢复正常(并且无需重新启动 Raspberry Pi)。

有人可以帮忙调查或解释这个问题吗?

相关内容