SFTP hangs after "Connected", but not KiTTY

[juef]

Greetings!

I have installed the brand new Linux Lite 4.0 on my computer and came across a weird problem with the FileZilla client. I want to connect through SSH (with key file). Other than the port (which I changed here to 22), the username and the key file, every connection setting is on default. Here's the log:

Code: Select all

Status:	Connecting to 192.168.1.1:22...
Status:	Connected to 192.168.1.1
Error:	Connection timed out after 20 seconds of inactivity
Error:	Could not connect to server
Status:	Waiting to retry...
Status:	Connecting to 192.168.1.1:22...
Response:	fzSftp started, protocol_version=7
Command:	keyfile "C:\Program Files\FileZilla FTP Client\.ssh\XXX.XXX"
Command:	open "XXX@192.168.1.1" 22
Command:	Pass: ********
Status:	Connected to 192.168.1.1

And so on. I would guess it's a problem with my server, if it wasn't for the fact that I can SSH successfully with KiTTY. Server has nothing special to say except that everything seems to go smoothly on its end:

Code: Select all

Jun  4 11:04:21 XXX sshd[31162]: Accepted publickey for XXX from 192.168.1.2 port 49187 ssh2: RSA SHA256:XXXXXXXXXXXXXXXXXx

Any help would be tremendously appreciated. Thank you!

[botg]

Please set the debug level to 3 in the settings dialog of FileZilla and post another log of a connection attempt that contains all the extra debug messages.

[juef]

Thank you for your reply! Here is the new log:

Code: Select all

Status:	Connecting to localhost:22...
Trace:	CControlSocket::SendNextCommand()
Trace:	CSftpConnectOpData::Send() in state 0
Trace:	Going to execute /usr/bin/fzsftp
Response:	fzSftp started, protocol_version=8
Trace:	CSftpConnectOpData::ParseResponse() in state 0
Trace:	CControlSocket::SendNextCommand()
Trace:	CSftpConnectOpData::Send() in state 2
Command:	keyfile "/home/MYUSERNAME/.ssh/MYKEYFILE"
Trace:	CSftpConnectOpData::ParseResponse() in state 2
Trace:	CControlSocket::SendNextCommand()
Trace:	CSftpConnectOpData::Send() in state 3
Command:	open "MYUSERNAME@localhost" 22
Trace:	Connecting to 127.0.0.1 port 22
Trace:	We claim version: SSH-2.0-FileZilla_3.28.0
Trace:	Server version: SSH-2.0-OpenSSH_7.6p1 Ubuntu-4
Trace:	Using SSH protocol version 2
Trace:	Doing ECDH key exchange with curve Curve25519 and hash SHA-256
Trace:	Server also has ecdsa-sha2-nistp256/ssh-rsa host keys, but we don't know any of them
Trace:	Host key fingerprint is:
Trace:	(REDACTED)
Trace:	Initialised AES-256 GCM client->server encryption
Trace:	Initialised AES256 GCM client->server MAC algorithm (in ETM mode) (required by cipher)
Trace:	Initialised AES-256 GCM server->client encryption
Trace:	Initialised AES256 GCM server->client MAC algorithm (in ETM mode) (required by cipher)
Trace:	Pageant is running. Requesting keys.
Trace:	Pageant has 0 SSH-2 keys
Trace:	Private key in '/home/MYUSERNAME/.ssh/MYKEYFILE' is encrypted, defer loading until use.
Trace:	Successfully loaded 1 key pair from file
Trace:	Offered public key from "/home/MYUSERNAME/.ssh/MYKEYFILE"
Trace:	Offer of public key accepted, trying to authenticate using it.
Command:	Pass: ********
Trace:	Access granted
Trace:	Opening session as main channel
Trace:	Opened main channel
Trace:	Started a shell/command
Status:	Connected to localhost

[boco]

Does the server's SFTP subsystem function normally? FileZilla only supports SFTP, not the whole SSH2 shebang.

[juef]

That's... a question I'm gonna have to do some reading to be able to answer, I think! I guess I was either doing something wrong before, or I'm doing something wrong now. This definitely sounds like I'm trying to SSH2 the whole thing, so I'll look into that.

Thanks a bunch to you both!

[botg]

You have some faulty shell script installed on the server that displays welcome messages on non-login shells.

[juef]

This certainly sounds like something that could have changed in my distro's latest release. I'll look into that and mark this as solved if that is indeed the problem. Thank you very much for the help, and most of all, for the great piece of software I've been using for over 13 years now! Merci!

[EDIT] That was it! Here's a little more details from here:

In order for this to work, the SSH session must be "clean" — that is, it must have on it only information transmitted by the programs at either end. What often happens, though, is that there are statements in either the system or per-user shell startup files on the server (.bashrc, .profile, /etc/csh.cshrc, .login, etc.) which output text messages on login, intended to be read by humans (like fortune, echo "Hi there!", etc.). Such code should only produce output on interactive logins, when there is a tty attached to standard input. If it does not make this test, it will insert these text messages where they don't belong: in this case, polluting the protocol stream between scp2/sftp and sftp-server. The first four bytes of the text gets interpreted as a 32-bit packet length, which will usually be a wildly large number, provoking the error message above.

[juef]

Thank you johey, I posted just that in a few posts above.

[botg]

Thank you johey, I posted just that in a few posts above.

Sadly that was just an Eliza-style spambot.