Connection closed by server #1572
Comments
|
Can you post the full logs instead of just snippets from them? Thanks! |
|
No problem : |
|
I'm actually thinking this is a bug in the server tbh. You're using https://twistedmatrix.com/documents/current/conch/examples/ ? If so can you share the code you're using for the SSH server? If it looks like it should work but isn't I can submit a bug report to them! |
|
The thing is that I have to send a file from my server (Server A) to an external server (server B) I don't manage. |
Since I guess you're running phpseclib on server A then, from phpseclib's perspective, the only server is server B. So it'd be server B - the server you don't control - that'd be the issue. My guess is that you couldn't even connect to the server using PuTTY / RSA authentication or OpenSSH / RSA authentication. If true then that would be even stronger evidence that it's a bug on their end. If you can connect using PuTTY (in particular), using RSA authentication, then the next step would be to get me logs of what PuTTY is doing so I can compare what PuTTY is doing to what phpseclib is doing. I can walk you through how to do that if PuTTY does indeed work (don't want to overwhelm you with too much info in one post lol). Thanks! |
|
Indeed, lots of information ;) I've tried to deal with the dev team which manage SSH connection. They told me that the SSH connection is doing well. They tried with Python with the following code : # sudo pip install pysftp
import pysftp
with pysftp.Connection(host = 'sftp.xxxx.yyy', username='xxx', private_key = 'yyy.key') as sftp_c
on:
print('Connection successfull')
with sftp_con.cd('/mnt'):
data=sftp_con.listdir()
print(data)and the response was : So the connexion is successful and the directories are listed.. But with Python, I suppose that it is out of scope... unless if it gives you unexpected clue ? Thanks |
|
That is not a very helpful response. I'd rather know if PuTTY can connect. If so then logs could be generated by going to Session -> Logging and setting "Session logging" to "SSH packets". Besides, PuTTY and OpenSSH are much more industry standards than pysftp. If neither of those can connect then it's immaterial if pysftp can connect. Having to install https://twistedmatrix.com/documents/current/conch/examples/ myself, in lieu of being able to get the PuTTY SSH logs from you, is going to slow things down. None-the-less, I did try. I did |
|
Looking at their sample SSH server code it doesn't even look like that provides SFTP functionality. So yah I'm going to need the PuTTY SSH logs to effectively diagnose the issue. Thanks! |
|
Here is the content of putty.log parametered as mentionned |
|
I see the issue and it is a bug in your server. Actually, it's more of a security vulnerability. So https://tools.ietf.org/html/rfc4252#page-9 talks about how public key authentication in SSH works. So in public key crypto you have the public and private key. The way public key auth works in SSH is... you send the public key (but not the private key) and the server says whether or not it'll accept it. It's supposed to be respond with either SSH_MSG_USERAUTH_FAILURE or SSH_MSG_USERAUTH_PK_OK. Your SSH server is responding with SSH_MSG_USERAUTH_SUCCESS. Not only is that in violation of the specs - it's a security vulnerability. So let's say the server did respond with SSH_MSG_USERAUTH_PK_OK. At this point the client is then supposed to use the private key to sign a string that contains, among other things, the session hash. This way the server sees the public key but never sees the private key. Your SSH server isn't doing that. It's just accepting the server key prima facie. At best, that makes it analogous to password authentication instead of public key authentication. At worst, it completely compromises the integrety of your server (ultimately, this depends on whether or not anyone has access to your public key; normally, it isn't an issue because public keys are kinda supposed to be public, but in your case, the public key is being treated like a password, so it is more of an issue). I'll try to work on a change to make phpseclib behave in a manner that's more consistent with PuTTY, but I do think an argument could be made for why I'd be better off not doing that and I also think the server needs to fix its stuff.. |
|
Should work better with 7f1b53f |
terrafrost
referenced
this issue
Jan 13, 2021
|
So, if I try to reformulate your answer : |
Correct.
Yes.
I wouldn't say that. There are changes phpseclib could make (and indeed, they were made with 7f1b53f) to make phpseclib behave in a manner more consistent with PuTTY, but that doesn't change the fact that their software has a vulnerability. It's kinda like... you can physically drive a car with an expired registration or inspection.... but it doesn't mean you should - what you should do is get an up-to-date registration and inspection.
Yes. phpseclib can accommodate the way the server is behaving but it doesn't change the fact that it's still a vulnerability and is off spec. And to be clear, even with the workaround that I've implemented, this isn't a client side vulnerability - it's a server side one. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am a windows 10 user. I try to send file on a server via SFTP with username and private key (no password and no passphrase).
I try to connect the server via WinSCP and it seems all right : i have even created a directory.
But impossible to do with PHP. Here is my code :
error_reporting(E_ALL);
include 'vendor/autoload.php';
define('NET_SSH2_LOGGING', 3);
use phpseclib3\Crypt\PublicKeyLoader;
use phpseclib3\Net\SFTP;
$sftp = new SFTP('sftp.xxx.xxx');
$privateKey = file_get_contents('xxx.pem');
$key = PublicKeyLoader::load($privateKey);
if (!$sftp->login('xxx.xxx', $key)) {
throw new \Exception('Login failed');
}
var_dump($sftp->nlist());
I can see in the logs that after "-> NET_SSH2_MSG_USERAUTH_REQUEST", there is a "<- NET_SSH2_MSG_USERAUTH_SUCCESS", but it continues and make another request.. The result is "<- NET_SSH2_MSG_UNIMPLEMENTED" and finally "-> NET_SSH2_MSG_DISCONNECT".
Do you have an idea about the scope of the problem ?
Thanks for your help.
The text was updated successfully, but these errors were encountered: