Sorry that I didn’t post this sooner, since it seems to go back at least as far as Leap 15.1. When I sftp into the Leap system from another Linux install, including older versions of Leap, I’m prompted for the password, then I get this message:
Received message too long 1633841013
and the connection is terminated. Yet, if I sftp out of a Leap 15.x installation, into another Linux based system, including older versions of Leap, it works just fine. What appears to be a problem with some of the most recent versions of Leap, is visible from various Linux based systems, including Android. I used to be able to sftp into Leap installations from Android devices. Instead, now I have to install a server in the Android device, and sftp to the Android device.
Has some issue been introduced into the server on newer Leap versions?
Any helpful thoughts would be greatly appreciated.
The “SFTP received message too long (decimal number)” error is caused by the default shell startup (or initialization) file, such as .bashrc, .bash_profile, /etc/profile, or .cshrc, on the remote system (the SFTP server), which is running a command attempting to write text into the terminal. As a result, the SSH session has information being transmitted by a program at either the system or the per-user shell startup files, interfering with the normal SFTP or SCP protocol.
These startup files output text messages on login intended for humans, such as “Hello, today is …” conflict with SFTP. In other words, the SSH shell session might be trying to say “hi,” (because you initiated it with SFTP), but SFTP doesn’t understand “hi.”
I normally send any output from a per-user “profile”/start-up file, to a log file. But I had added some output to such a file that wasn’t sent to a log file, when I was trying to help someone debug something that they were trying to start when they logged in.
By coincidence, I didn’t need to sftp into that system for quite a long time. So when I finally did sftp into it, I didn’t make a correlation with the start-up file changes.