Package: openssh-server Version: 1:10.0p1-7+deb13u4 Severity: normal X-Debbugs-Cc: [email protected]
Dear Maintainer, Please review this bug. ## SUMMARY ## In some configurations, interactive SSH login has a noticeable delay. ## BACKGROUND ## I encountered the bug when running Debian in a VM that’s managed by a VM manager called Lima. When connecting to the VM, for example using the command `limactl shell <vm-name>`, there is a delay of about four seconds before the shell becomes available. The bug is fixed upstream[0]. I ran a test on Debian unstable[1], and the bug isn’t present there (openssh-server 10.4p1-4). See below for further details. ## HOW TO REPRODUCE THE BUG ## - Create a new VM like this: limactl create --name=myvm template:debian-13 - Start the VM: limactl start myvm - Run this command and notice how long it takes to complete: ssh -F $HOME/.lima/myvm/ssh.config lima-myvm /usr/bin/true - Then run almost the same command again, except this time we force pseudo-terminal allocation. Notice how long it takes to complete. ssh -t -F $HOME/.lima/myvm/ssh.config lima-myvm /usr/bin/true ### What I expected to happen ### That both commands would finish instantly. ### What actually happens ### The first command (no pseudo-terminal) finishes instantly. The second command, where the pseudo-terminal is allocated, has a quite significant delay before completing. On my system it takes about four seconds to complete. ## WHY THE DELAY OCCURS ## Please see the issue that I filed in Lima’s GitHub project, I have shared my analysis there[2]. If desirable, I can re-post it here on the list. Summary: Attempting to resolve the single-lable DNS name `UNKNOWN` is unsuccessful and causes a four-second delay. ## WORKAROUNDS ## I have found two feasible workarounds. One way is to add an entry to /etc/hosts, like this: ``` 127.0.0.1 UNKNOWN ::1 UNKNOWN ``` The other option is to modify the file /etc/systemd/resolved.conf.d/00-lima-enable-mdns.conf, like this: ``` [Resolve] MulticastDNS=yes LLMNR=no ``` ## REFERENCES ## [0] Upstream commit that fixes the bug: https://github.com/openssh/openssh-portable/commit/e5055ef26abc [1] Image used when testing with Debian unstable: https://cloud.debian.org/images/cloud/sid/daily/20260805-2561/debian-sid-genericcloud-arm64-daily-20260805-2561.qcow2 [2] Analysis of the bug: https://github.com/lima-vm/lima/issues/5389#issuecomment-5219820915 -- System Information: Debian Release: 13.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 6.12.96+deb13-cloud-arm64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openssh-server depends on: ii debconf [debconf-2.0] 1.5.91 ii init-system-helpers 1.69~deb13u1 ii libaudit1 1:4.0.2-2+b2 ii libc6 2.41-12+deb13u3 ii libcom-err2 1.47.2-3+b11 ii libcrypt1 1:4.4.38-1 ii libgssapi-krb5-2 1.21.3-5+deb13u1 ii libkrb5-3 1.21.3-5+deb13u1 ii libpam-modules 1.7.0-5 ii libpam-runtime 1.7.0-5 ii libpam0g 1.7.0-5 ii libselinux1 3.8.1-1 ii libssl3t64 3.5.7-1~deb13u2 ii libwrap0 7.6.q-36 ii libwtmpdb0 0.73.0-3+deb13u1 ii openssh-client 1:10.0p1-7+deb13u4 ii openssh-sftp-server 1:10.0p1-7+deb13u4 ii procps 2:4.0.4-9 ii runit-helper 2.16.4 ii systemd [systemd-sysusers] 257.13-1~deb13u1 ii sysvinit-utils [lsb-base] 3.14-4 ii ucf 3.0052 ii zlib1g 1:1.3.dfsg+really1.3.1-1+b1 Versions of packages openssh-server recommends: ii libpam-systemd [logind] 257.13-1~deb13u1 pn ncurses-term <none> pn xauth <none> Versions of packages openssh-server suggests: pn molly-guard <none> pn monkeysphere <none> pn ssh-askpass <none> pn ufw <none> -- debconf information: openssh-server/password-authentication: true openssh-server/permit-root-login: true
