13

I've been happily using SSH to connect to my Raspberry Pi for years. I hadn't connected to it using SSH in a few months, but today I reinstalled the OS on the Raspberry Pi and found I was unable to connect. There wasn't any error output, but then a timeout after a long wait period.

In my attempts to debug, I installed PuTTY and tried connecting using that and it worked perfectly. However, I'd prefer to keep using standard OpenSSH if I can.

My output when running with -vvv:

debug1: OpenSSH_10.0p2, OpenSSL 3.5.1 1 Jul 2025
debug3: Running on Linux 6.15.8-arch1-2 #1 SMP PREEMPT_DYNAMIC Tue, 29 Jul 2025 15:05:00 +0000 x86_64
debug3: Started with: ssh [email protected] -vvv
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 2: Including file /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf
debug2: resolve_canonicalize: hostname 192.168.1.90 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/johndoe/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/johndoe/.ssh/known_hosts2'
debug3: channel_clear_timeouts: clearing
debug3: ssh_connect_direct: entering
debug1: Connecting to 192.168.1.90 [192.168.1.90] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
*A few minutes of waiting*
debug1: connect to address 192.168.1.90 port 22: Connection timed out
ssh: connect to host 192.168.1.90 port 22: Connection timed out

And my output from running with -G:

host 192.168.1.90
user johndoe
hostname 192.168.1.90
port 22
addressfamily any
batchmode no
canonicalizefallbacklocal yes
canonicalizehostname false
checkhostip no
compression no
controlmaster false
enablesshkeysign no
clearallforwardings no
exitonforwardfailure no
fingerprinthash SHA256
forwardx11 no
forwardx11trusted no
gatewayports no
gssapiauthentication no
gssapidelegatecredentials no
hashknownhosts no
hostbasedauthentication no
identitiesonly no
kbdinteractiveauthentication yes
nohostauthenticationforlocalhost no
passwordauthentication yes
permitlocalcommand no
proxyusefdpass no
pubkeyauthentication true
requesttty auto
sessiontype default
stdinnull no
forkafterauthentication no
streamlocalbindunlink no
stricthostkeychecking ask
tcpkeepalive yes
tunnel false
verifyhostkeydns false
visualhostkey no
updatehostkeys true
enableescapecommandline no
canonicalizemaxdots 1
connectionattempts 1
forwardx11timeout 1200
numberofpasswordprompts 3
serveralivecountmax 3
serveraliveinterval 0
requiredrsasize 1024
obscurekeystroketiming yes
ciphers [email protected],[email protected],[email protected],aes128-ctr,aes192-ctr,aes256-ctr
hostkeyalgorithms [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],rsa-sha2-512,rsa-sha2-256
hostbasedacceptedalgorithms [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],rsa-sha2-512,rsa-sha2-256
kexalgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,[email protected],curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
casignaturealgorithms ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],rsa-sha2-512,rsa-sha2-256
loglevel INFO
macs [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
securitykeyprovider internal
pubkeyacceptedalgorithms [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],rsa-sha2-512,rsa-sha2-256
xauthlocation /usr/bin/xauth
identityfile ~/.ssh/id_rsa
identityfile ~/.ssh/id_ecdsa
identityfile ~/.ssh/id_ecdsa_sk
identityfile ~/.ssh/id_ed25519
identityfile ~/.ssh/id_ed25519_sk
identityfile ~/.ssh/id_xmss
canonicaldomains none
globalknownhostsfile /etc/ssh/ssh_known_hosts /etc/ssh/ssh_known_hosts2
userknownhostsfile /home/johndoe/.ssh/known_hosts /home/johndoe/.ssh/known_hosts2
logverbose none
channeltimeout none
permitremoteopen any
addkeystoagent false
forwardagent no
connecttimeout none
tunneldevice any:any
canonicalizePermittedcnames none
controlpersist no
escapechar ~
ipqos af21 cs1
rekeylimit 0 0
streamlocalbindmask 0177
syslogfacility USER

The Raspberry Pi is running OpenSSH version 9.2. I've seen some posts saying that a lack of modern algorithms on the server could cause this type of issue, so I tried using this:

ssh -oHostKeyAlgorithms=+ssh-rsa -oKexAlgorithms=+diffie-hellman-group1-sha1 -oCiphers=+aes128-cbc [email protected]

But the issue persisted.

Output of plink [email protected] -v:

Looking up host "192.168.1.90" for SSH connection
Connecting to 192.168.1.90 port 22
We claim version: SSH-2.0-PuTTY_Release_0.83
Connected to 192.168.1.90 (from 192.168.1.83:36597)
Remote version: SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u7
Using SSH protocol version 2
Enabling strict key exchange semantics
Doing NTRU Prime / Curve25519 hybrid key exchange, using hash SHA-512 (unaccelerated)
Server also has ecdsa-sha2-nistp256/rsa-sha2-512/rsa-sha2-256 host keys, but we don't know any of them
Host key fingerprint is:
ssh-ed25519 255 SHA256:gP8YCbyFXK/YWNvJBbfBje39GmZvvtpcQkCQO96WKII
Initialised AES-256 SDCTR (AES-NI accelerated) outbound encryption
Initialised HMAC-SHA-256 (SHA-NI accelerated) outbound MAC algorithm
Initialised AES-256 SDCTR (AES-NI accelerated) inbound encryption
Initialised HMAC-SHA-256 (SHA-NI accelerated) inbound MAC algorithm
Using username "johndoe".
[email protected]'s password:
Sent password
Access granted
Access granted. Press Return to begin session.
Opening main session channel
Opened main channel
Allocated pty
Started a shell/command

I'm using the same machine with PuTTY and OpenSSH.

Improve this question
New contributor
drake14w is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
2
  • 2
    Could you retry with -o IPQoS=0?
    – grawity
    Commented 2 days ago
  • @grawity Thank you so much, using -o IPQoS=0 has solved the issue.
    – drake14w
    Commented 2 days ago

1 Answer 1

Reset to default
24

using -o IPQoS=0 has solved the issue.

It worked around the issue. The real issue seems to be that something in your network – maybe a router, maybe a switch, maybe iptables on the RaspPi – is dropping packets when they have the IP DSCP (aka "IP Type of Service") parameter set to anything, or at least set to the specific values OpenSSH uses.

OpenSSH has used ToS/DSCP for a long time to advise the network how to prioritize packets (e.g. to indicate that SFTP is 'background' traffic but interactive SSH should be low-latency)

Normally that has zero effect when the network isn't overloaded, but this wouldn't be the first time when some network equipment mishandles less-often-seen DSCP values. (For example, a few years ago OpenSSH switched from obsolete ToS values to DSCP ones, and immediately issues were discovered even in allegedly modern equipment.)

So as a temporary workaround you can add this to your ~/.ssh/config, but your network remains broken.

I've seen some posts saying that a lack of modern algorithms on the server could cause this type of issue

It cannot. Your error messages say nothing about difference in algorithms, or about algorithm negotiation happening at all. The Connection timed out is a completely different type of issue, one which means the client wasn't able to even offer any algorithms or indeed never even managed to talk to the server in any way.

Network connections happen in layers; it is rarely if ever "all or nothing". (In this case, a TCP connection must be fully established before the SSH connection can even begin negotiation) So you cannot assume that every "failed to connect" error is equivalent. Different error messages mean different amounts of progress were made before the error occurred.

Improve this answer
4
  • 1
    FWIW, SoftBank Japan actually uses the ToS field, and "low-latency" packets are indeed lower latency but rate limited. Super annoying when using rsync over ssh, but great when logging into a server on the other side of the world.
    – Simon Richter
    Commented 2 days ago
  • @SimonRichter Hmm, but OpenSSH dynamically sets DSCP to one of the two default values depending on whether it's interactive or not, so I'd expect rsync-over-ssh packets to be tagged as 'cs1', not the low-latency 'af21'? (And from what I understand, even 'af21' isn't really supposed to get rate-limited, only 'ef' is...)
    – grawity
    Commented 2 days ago
  • 1
    ...of course, just as I've said that, OpenSSH switches its default IPQoS to the 'ef' DSCP the next day.
    – grawity
    Commented 12 hours ago
  • Sounds much like a bug in Raspberry Pi's packet handling. Maybe some bad firewall filtering.
    – U. Windl
    Commented 1 hour ago

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.