Temporary Crypto Glitches ... ??

[Konrad Bucheli]

Hi Jochen

We run a few thousands of hosts with varying quality of internet lines.
It is a fallback procedure to try to only use ed25519 crypto if the 
connection fails half-way through. The reason is that it needs only 
smaller packets which can help if there there is (more) trouble with 
bigger network packets.

Cheers

Konrad

On 09.11.21 17:35, Jochen Bern wrote:
> This has got to be one of the weirdest problem descriptions I've ever 
> dared publish ...
> 
> Yesterday evening, I had problems SSHing from a jump host through an 
> IPsec VPN to a couple customer servers (everything running CentOS 7). I 
> was able to work around the problem by fiddling with the crypto 
> settings; some more details below.
> 
> This morning, those connections were back to normal, but the supporter 
> on duty reported that he could not SSH into an entirely different server 
> (also CentOS 7, and straight from his workplace machine); that problem 
> fixed itself a couple hours later, too.
> 
> Is this just the spookiest coincidence since last Halloween, or did we 
> chance onto a rare, time-triggered malfunction somewhere in the 
> OpenSSH(/OpenSSL?) crypto ... ?
> 
> -------
> 
> Alas, the supporter isn't up to SSH connection debugging, so he never 
> did a -vv and couldn't tell any symptom beyond "it times out". I failed 
> to save my -vv's output, but I remember that roughly where you'd 
> normally get to the KEXINIT, my client claimed to be waiting for some 
> ECDH - and then just sat until the timeout.
> 
> I usually have two keypairs - one ed25519, one RSA - loaded into my 
> agent, and now that things are back to normal, the Kex chosen is 
> curve25519-sha256 at libssh.org. In order to circumvent the problem, I had 
> to remove my RSA keypair from the agent and use
> 
>> $ ssh -o "KexAlgorithms diffie-hellman-group-exchange-sha256" $SERVER
> 
> to get logged in.
> 
> I started haveged on "my" target machines, but 
> /proc/sys/kernel/random/entropy_avail reported > 3kbit anyway and my 
> colleague's remote system had haveged running already, so I doubt that 
> that actually did anything.
> 
> Our monitoring and automated data fetchers apparently never saw any 
> problem to SSH into those servers - using RSA keypairs. The server, set 
> to LogLevel VERBOSE and typically logging
> 
>> Connection from $CLIENT_IP ...
>> Postponed publickey for $LOCAL_USER ...
> 
> at the beginning of a connection, never wrote the second line for the 
> failed attempts. (With all our accesses getting SNATed, I'm not sure yet 
> whether there are any dangling instances of the *first* line.)
> 
> Nothing in hosts.allow/hosts.deny, and DNS lookups of the client IP 
> garner an NXDOMAIN normally.
> 
> Thanks for any pointers,
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev?mc_phishing_protection_id=45427-c65ab1euab2puk9vp28g
>