[SOLVED] SSH/SFTP connection failures between Debian bookworm and Tumbleweed systems
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: openSUSE, Raspbian, Slackware. Previous: MacOS, Red Hat, Coherent, Consensys SVR4.2, Tru64, Solaris
Posts: 2,803
Rep:
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:
Code:
sudo /usr/sbin/sshd -p 2222 -d -E /tmp/sshd.log
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.
Distribution: openSUSE, Raspbian, Slackware. Previous: MacOS, Red Hat, Coherent, Consensys SVR4.2, Tru64, Solaris
Posts: 2,803
Original Poster
Rep:
Quote:
Originally Posted by michaelk
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?
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.
* ssh-keygen(1): generate Ed25519 keys by default. Ed25519 public keys
are very convenient due to their small size. Ed25519 keys are
specified in RFC 8709 and OpenSSH has supported them since version 6.5
(January 2014).
Distribution: openSUSE, Raspbian, Slackware. Previous: MacOS, Red Hat, Coherent, Consensys SVR4.2, Tru64, Solaris
Posts: 2,803
Original Poster
Rep:
Quote:
Originally Posted by rnturn
I cannot seem to get ssh connections from a new bookworm install to a TW server on our LAN.
[snip]
TIA for any hints, pointers to HOWTOs, etc. someone can offer up
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.