You are not logged in.
I have one server with archlinux(server1), the other one with ubuntu(server2).
And there's 3 linux system on my laptop.(Arch Linux, Ubuntu, Kali Linux(A debian based system))
When I use ssh to connect to server1, no matter what system I'm using, it is particularly lagging when entering a command after login.
However, when I tries to connect server2 with debain based system, the input is very smooth. But when I connect server2 with Arch Linux, the lag appears again...
According to the above conditions, is there a problem with SSH in archLinux?
~
❯ ssh -V
OpenSSH_9.8p1, OpenSSL 3.3.1 4 Jun 2024
Last edited by HotspringDev (2024-08-16 05:54:41)
Offline
I run Arch on both my home system as well on my server - can't confirm any issues
Offline
What does the SSH server's and the SSH client's logs say when the latter is run with increased debug level?
Be sure to filter out any possibly confidential data before posting those!
Inofficial first vice preseident of the Rust Evangelism Strike Force
Offline
the input is very smooth
I guess you're talking about latency here and since ssh defdault to sync action, I'd check the general network performance eg. w/ iperf
The default way to screw this is to run parallel network managing services,
find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
Offline
If you have anything in /etc/profile.d that stalls on logon (for instance a script that sends notification on user login in absence of internet access), that could slow down getting to the terminal after a successful authentication.
Not sure if this is applicable to your case.
Last edited by itarill (2024-08-06 18:55:08)
Offline
What does the SSH server's and the SSH client's logs say when the latter is run with increased debug level?
Be sure to filter out any possibly confidential data before posting those!
I compared the log in arch and the log in debian-based distro.
the differents are these:
Arch:
debug1: Next authentication method: publickey
debug1: Will attempt key: t1.pem explicit
debug2: pubkey_prepare: done
debug1: Trying private key: t1.pem
debug3: sign_and_send_pubkey: using publickey-hostbound-v00@openssh.com with RSA SHA256:{SHA256}
debug3: sign_and_send_pubkey: signing using rsa-sha2-512 SHA256:{SHA256}
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 52
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debian-based:
debug1: Next authentication method: publickey
debug3: ssh_get_authentication_socket_path: path '/tmp/ssh-YlDeSWi0fsmV/agent.2010'
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: ssh_fetch_identitylist: agent contains no identities
debug1: Will attempt key: t1.pem explicit
debug2: pubkey_prepare: done
debug1: Trying private key: t1.pem
debug3: sign_and_send_pubkey: using publickey-hostbound-v00@openssh.com with RSA SHA256:{SHA256}
debug3: sign_and_send_pubkey: signing using rsa-sha2-512 SHA256:{SHA256}
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 52
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
I'm not sure if they are the influencing factors of the lag
Offline
the input is very smooth
I guess you're talking about latency here and since ssh defdault to sync action, I'd check the general network performance eg. w/ iperf
The default way to screw this is to run parallel network managing services,find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
server1(with archlinux) is in LAN environment, so the network latency is not high and the network performance is not bad.
Here's the result of the command:
clash-verge-service.service | multi-user.target.wants
cups.path | multi-user.target.wants
cups.service | multi-user.target.wants
cups.service | printer.target.wants
cups.socket | sockets.target.wants
dbus-org.freedesktop.nm-dispatcher.service | system
dbus-org.freedesktop.timesync1.service | system
display-manager.service | system
getty@tty1.service | getty.target.wants
NetworkManager.service | multi-user.target.wants
NetworkManager-wait-online.service | network-online.target.wants
nvidia-hibernate.service | systemd-hibernate.service.wants
nvidia-resume.service | systemd-hibernate.service.wants
nvidia-resume.service | systemd-suspend.service.wants
nvidia-suspend.service | systemd-suspend.service.wants
p11-kit-server.socket | sockets.target.wants
pipewire-pulse.socket | sockets.target.wants
pipewire-session-manager.service | user
pipewire.socket | sockets.target.wants
remote-fs.target | multi-user.target.wants
systemd-timesyncd.service | sysinit.target.wants
systemd-userdbd.socket | sockets.target.wants
wireplumber.service | pipewire.service.wants
xdg-user-dirs-update.service | default.target.wants
Offline
If you have anything in /etc/profile.d that stalls on logon (for instance a script that sends notification on user login in absence of internet access), that could slow down getting to the terminal after a successful authentication.
Not sure if this is applicable to your case.
However, I did not edit any file under /etc/profile.d
debuginfod.csh freetype2.sh gawk.sh jre.csh locale.sh perlbin.sh
debuginfod.sh gawk.csh gpm.sh jre.sh perlbin.csh
Offline
server1(with archlinux) is in LAN environment, so the network latency is not high and the network performance is not bad.
By royal decree?
Run the iperf test, ssh lags for network latency (unless of course you're running this on a 486@66MHz and your cpu is at 100% to do the encryption), you don't have concurrent services but there could be device issues (firmware crashes, power saving etc) or MTU issues.
Just saying "oh it's lan therefore I pretend to know that this isn't the problem and won't check" is not how reality works.
If you type and then it takes a moment before the output appears and the used terminal does not show this behavior otherwise, you've some latency issues.
You can also try https://aur.archlinux.org/packages/sshping but it's only gonna report the ssh latency (where the prediction is "bad"), not whether it's caused by lower layer latency.
Offline
The problem solved after a system upgrade using pacman -Syyu.
Offline