I use an unattended backup script to backup machines on my LAN. The main machine multiboots 3 linux distros. Recently, I did a clean install of Mint 21 over the previous distro (mint-20). Everything seems to work as expected except my backup script when Mint 21 is booted. The server should connect using ssh via public/private keys and run the backup. But it cannot connect. Previously, this worked with the other distros and Mint 20. Also, manually mounting the server thru the terminal on Mint 21 works, but the connection is very fragile...I get frequent: client_loop: send disconnect: Broken pipe messages. After comparing config files and everything else I could think of, still no joy. I'm wondering if OpenWrt may be seeing something differently with the new distro? To avoid redoing my script, I keep the same distro name: for example, "mint" "lmde" "ubuntu" and keep them on the same drive partition when upgrading. Could my OpenWrt router be affecting this in any way. This should be fairly simple, but I'm not seeing it! Any insight would be greatly appreciated.
provided manual operations succeed (and are representative for the script)… bad cable?
The server and main machine are wired, but those are fine. When I boot one of the other machine's distos, it works fine using commands like # ssh ws-ubun hostname and returns # ubuntu using the public/private keys w/o needing a pw. However mint 21 does ask for a pw and of course fails. Honestly, I don't think OpenWrt is involved as the machine names aren't changed and no machine ID is used (since these are multi-boot. But nothing seems to be working
If the public/private key pairs were generated a long time ago, they may be of a type or key length that is now deprecated.
If you get verbose output using
ssh -v hostname
to the host that is behaving badly, it may give helpful information.
The newer installation may be refusing to use some older key types.
No - that would not be the case.
First web search result: https://www.nixcraft.com/t/client-loop-send-disconnect-broken-pipe/2708/3
Yes, the keys were generated a long time ago and $ ssh -v hostname indicates that this may be the issue. There are several types of encryption keys suggested in sshd_config: dsa, ecdsa, ed25519. These are pre-generated ones. I could use one of those but not sure which is preferred, or generate a new set?
Also, I'm reading from the link: https://www.nixcraft.com/t/client-loop-send-disconnect-broken-pipe/2708/3 I've already tried some of those methods, but I'm reading this carefully...thx
The symptom for the key issue would be that authorized_keys never works (so it asks for a password)
The (newly upgraded) sending host may simply not present that key type for authorized_keys authentication.
You can create another key pair, and compare ssh -v -i oldkey thatsystem to ssh -v -i newkey thatsystem
to see if it tries to present them.
The disconnection errors, particularly if they're sporadic, would not be caused by this.
OK, my old keys were RSA which I read is so old it's not recommended. Generated new ecdsa ones and will test today. Will tackle the disconnect issues second. thx
if it's not too much of a hassle just delete the entire ~/.ssh directory, it always fixed my problems