SFTP login 'size error' (works with openssh; logs included) #1171
Comments
|
The server administrator has also replied with some further information, saying that the problem is that when phpseclib attempts to connect, then it only supports weak ciphers, which their server does not support. Is this something configurable within phpseclib, or does the problem lie elsewhere? |
|
It's possible.
I think you have to use OpenSSH debug2 (-vv) or debug3 to see which ciphers
etc. are negotiated.
|
|
Actually, nevermind, that info should be in the phpseclib log as well.
|
|
Looked over the logs. Phpseclib should have matching ciphers/algos. Unless
I am missing something.
|
|
Is there any more info I can get that may help? Here's what I think is the relevant section of the OpenSSH (sftp) -v -v output: |
|
phpseclib should be able to do e.g. diffie-hellman-group14-sha1, ssh-rsa, aes128-ctr, aes128-ctr, hmac-md5, hmac-md5, none, none. |
|
Looks like this has something to do with the advertised max packet size. |
@bantu So, it sounds like the SFTP server admin's statement that the problem was a lack of mutually compatible ciphers is wrong, and is a distraction.
Would it help if I sent him a modified version of phpseclib that will distinguish the three conditions on that line, so that we can find out which one is the problem? |
The server administrator is an idiot, serving up FUD. phpseclib supports ECDH if you have libsodium installed. It doesn't currently support chacha20-poly1305@openssh.com but then again your server doesn't either. The best symmetric cipher that phpseclib supports is AES and it supports it in every mode save for GCM (just as with PuTTY) and, guess what, the server supports the AES algorithms too. phpseclib does support "weak" ciphers like arcfour256 but, then again, so does the server. In fact, there-in probably lies the problem. Anyway, try this: ie. the server says it supports arcfour256 and arcfour128 but it really doesn't. What it supports is a buggy implementation of those algorithms. |
|
@terrafrost Thank you very much. Yes, disabling those lines fixes it. So, I suppose I'll tell the end-user (of my code which uses phpseclib) to tell the server admin (of the SFTP server he's trying to access) that his implementation of those algorithms is buggy? Would it be an advantage to phpseclib to retry with something else if it encounters this problem? Even if I exposed the encryption algorithm settings to the end-user, that would still be a terrible user experience, to have to diagnose the problem and then tweak something that technically challenging. |
|
For what it's worth - openssh works (`sftp -v -v -oCiphers='arcfour128') (arcfour256 also). Perhaps the server is only tested against openssh. |
That's not how it works. The algorithm is determined through the key exchange process. If subsequent packets do not decrypt correctly the connection just stops working. You can't do a new key exchange either because subsequent key exchanges are supposed to be encrypted.
Probably. But it's also worth mentioning that OpenSSH doesn't always behave consistently. phpseclib often is able to connect to OpenSSH servers using arcfour128 / arcfour256 without issue but often times it's also not worth it.
Unless he did his own home grown implementation then it seems unlikely that it's his implementation. FWIW the reason phpseclib has historically favored arcfour128 / arcfour256 is for speed purposes. But when OpenSSL or mcrypt are being used speed is less of a consideration, I will concede.. |
|
Would you be able to provide me with the IP address of the server that has this problem? I don't need a username or password - logging in with a fake username would be sufficient to allow me to reproduce the problem. What I'm thinking I can do is make it so that if the packet doesn't decrypt correctly and that the selected cipher is arcfour128 or arcfour256 that it recreates the the cipher object. To test it out, however, I need to be able to connect to a server that demonstrates the problem and none of the servers I have access to (existing servers or new servers on fresh Linux installs) demonstrate it. Thanks! |
|
136.243.27.43 |
|
So the issue is actually a bug in SSH servers built against sufficiently old versions of OpenSSL: https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/ssh2-aesctr-openssh.html The workaround I chose to implement disconnects when the "invalid size" error would be output (and when the login has yet to be completed and the algorithm is one of the affected algorithms, etc) and re-connects using a shorter key. Here's the commit: I'll need to merge it into 2.0 and master at some point. |
|
The fix has been merged. As such, I'm gonna go ahead and close this. |
|
Thank you! |
|
Thanks for the fix, just tested it and it works as expected, no longer any "size error" messages! |
|
Are there any plans to tag a new release that includes this fix soon in the 2.0 version (i.e. a 2.0.7 version)? I ran into this issue suddenly over the weekend with an external party, and the fix works. |
I'll try to do it in early October. I'm traveling in Europe right now and don't want to enjoy my trip as opposed to getting too wrapped up in phpseclib stuff lol |
Hi,
Thank you for your work on phpseclib over the years. I'm using the latest 1.0 branch version (1.0.7).
We've had a couple of users recently reporting failure to login. The error message they get is:
One of them has given me login credentials, allowing me to confirm the error, test with openssh, and get phpseclib logs.
His SFTP server software is ProFTPD Version 1.3.6 with mod_sftp (mod_sftp is mentioned in the log below; he informed me of the other information).
Here is the (anonymised) openssh debug log for a successful login (I can also do other normal operations after login):
And here is what is logged by NET_SSH2_LOG_COMPLEX:
The text was updated successfully, but these errors were encountered: