[Bug 3939] New: Interactive SSH sessions freeze after a short period

[bugzilla-daemon at mindrot.org]

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

            Bug ID: 3939
           Summary: Interactive SSH sessions freeze after a short period
           Product: Portable OpenSSH
           Version: 10.2p1
          Hardware: amd64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: charles.thompson217 at gmail.com

Summary:

Interactive SSH sessions freeze after a short period (approximately
1–60 seconds) during normal usage, often while typing. The system
remains fully responsive via local console (KVM), and new SSH sessions
can be established immediately, but they also eventually freeze.

Non-interactive SSH sessions (no PTY) remain stable.

The issue reproduces even with minimal shells and when typing into
`cat`, suggesting the problem is in the interactive PTY/TTY input path,
not shell logic.

---

Environment:

OS: Arch Linux
Kernel: 6.19.10-arch1-1
OpenSSH: OpenSSH_10.2p1
OpenSSL: 3.6.1
Client: macOS (Terminal and iTerm2 tested)
Connection: local LAN (no VPN, no Cloudflare)

---

Expected behavior:

Interactive SSH sessions remain responsive indefinitely.

---

Actual behavior:

* SSH login succeeds normally
* Shell works initially
* After ~1–60 seconds, session freezes (often mid-typing)
* No input/output is processed after freeze
* Server remains responsive via KVM
* Reconnecting works immediately, but the issue repeats

---

Reproduction:

Minimal reproduction:

ssh user at server
cat

Typing into `cat` eventually causes the session to freeze.

---

Key observations:

Non-PTY sessions are stable:

ssh -T user at server 'while true; do echo alive; sleep 1; done'

Runs indefinitely without freezing.

Output-only workloads can remain stable:

while true; do echo alive; sleep 1; done

Running this inside an SSH session does not reliably trigger the issue.

`script` avoids the issue:

ssh user at server 'script -q /dev/null'

This session remains stable.

Occurs independent of shell:

* Reproduces with `bash --noprofile --norc`
* Reproduces when typing into `cat`
* Not dependent on prompt or shell config

---

Diagnostics:

After freeze:

`cat` process:

read(0, ...)

* Blocked reading from stdin (/dev/pts/0)
* stdin/stdout/stderr all point to /dev/pts/0

`sshd` session process:

ppoll([...], ...)

* Waiting on socket and PTY-related file descriptors

FDs include:

* sockets (network side)
* /dev/ptmx (PTY master side)

Interpretation of diagnostics:

* Processes are not crashing or exiting
* `cat` is correctly waiting for input on the PTY
* `sshd` is waiting for activity on sockets/PTY fds
* Interactive input appears to stop propagating through the SSH → PTY
path

---

Tests performed:

Network:

* ping stable during freeze
* large-packet ping (MTU test) passes
* local LAN only (no VPN, no tunnels)

System / kernel:

* dmesg -w shows no errors
* no processes stuck in D state
* system remains fully responsive via KVM

Filesystem:

* issue persists even after cd /
* root filesystem on SSD

SSH / terminal:

* ssh -F /dev/null → still freezes
* ssh -tt user at server 'bash --noprofile --norc' → still freezes
* different TERM values → no change
* stty -ixon -ixoff → no change
* multiple terminal clients → same behavior

PAM:

* UsePAM no does not eliminate the issue

Logging:

* journalctl -u sshd shows no errors during freeze

---

Interpretation:

The issue appears isolated to the interactive input path of PTY-backed
SSH sessions:

* SSH transport is functional (non-PTY stable)
* system is stable (KVM unaffected)
* not dependent on shell behavior
* not explained by PAM
* input stops propagating to the PTY

The fact that:

* `cat` reproduces the issue
* `script` avoids it
* non-PTY sessions are stable

suggests a problem in one of:

* OpenSSH PTY input forwarding
* Linux TTY/PTTY subsystem
* terminal line discipline
* interaction between client terminal and server PTY

---

Workarounds:

* Use non-interactive SSH (ssh -T)
* Use:

ssh user at server 'script -q /dev/null'

---

Versions:

Linux quasar 6.19.10-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 26 Mar 2026
19:20:28 +0000 x86_64 GNU/Linux
OpenSSH_10.2p1, OpenSSL 3.6.1 27 Jan 2026

---

Notes:

* Issue is consistently reproducible
* Not observed via local console
* No indication of system compromise
* Behavior strongly tied to interactive terminal input

-- 
You are receiving this mail because:
You are watching the assignee of the bug.