SSH/SFTP connection failures between Debian bookworm and Tumbleweed systems
 

I cannot seem to get ssh connections from a new bookworm install to a TW server on our LAN. TBH, I've had problems connecting to the TW system for some time starting with an older Leap 15.3 desktop. I was able to ssh into the TW system from a laptop that's still running 15.3. However the TW system was patched today and, for now, I'm unable to confirm whether the laptop is still able to connect. If I exchange keys between the bookworm and the TW systems, I'm still getting prompted for passwords in either connection direction. (These are for regular user accounts, not root)

I noticed that when I generated new ssh keys on the TW system, it wanted to save them in "id_ed25519" and "id_ed25519.pub" instead of the normal files. I'm not sure what to make of that change and don't know if it's telling me something significant but the old ".pub" file is 397 bytes while the new one is only 97 (which seems low). Is this a new location for SSH keys?

Any help on this would be helpful as it's broken some cron jobs (that can't now authenticate to the SMTP service on the TW system) that need to send emails and Ansible. Everything I've run across online seems to want firewall settings to be opened up which would make sense if either system was running a firewall. Client connections to the TW system's IMAP service are not affected (using plaintext passwords for now) so I can receive email,just not send it through the same system.

TIA for any hints, pointers to HOWTOs, etc. someone can offer up

I assume by normal you mean rsa. ed25519 is considered better because it provides the same level of security with smaller keys. Normally the default key names are automatically tried but if you are using something else you might have to specify the key name using the -i option or setup a config file. Have you checked the debug messages by adding -vvv options when trying to login?

Set higher loglevel in sshd_config on the server if necessary and check logs.

The quick way to do that is to fire up a separate instance of sshd on another port and save the session information to its own log file:

That will allow a single session on port 2222 and save the whole log from start to finish in the file /tmp/sshd.log and no other sessions. That will weed out the noise, especially if it is a busy server.

The -d option can be added one to three times to allow for a variable amount of debugging material.

So the "ed25519" files re considered the new norm, then? (I missed that announcement.)

I tried wading through the messages the debug switches enabled. Still trying to make heads/tails out of what was displayed.

Thanks for the feedback.

That happened in OpenSSH 9.5 back in October:

And in 8.5 for the server host keys.

Thanks. Looks like I fell behind in my leisure reading. :D

I hate to quote myself...

I figured this out. I'll dig a little deeper to get a better understanding as to why this worked. I generated a new key using the "-t ed25519" switch on the Bookworm system and imported it into the TW system's authorized_keys file. Success!

Now I'll look for a means of making ed25519 a new default or build some muscle memory when working with SSH from hereon. Gonna marked this as solved.

Thanks all...