terrafrost
commented
11 months ago Well I can tell you that the "preauth" request is absolutely not malformed. Here's the "preauth" request:
-> NET_SSH2_MSG_USERAUTH_REQUEST (since last: 0.0001, network: 0.0001s)
00000000 00:00:00:10:6c:6c:65:77:65:6c:6c:79:6e:00:00:00 ....ubuntu....
00000010 00:00:00:00:00:00:00:0e:73:73:68:2d:63:6f:6e:6e ........ssh-conn
00000020 65:63:74:69:6f:6e:00:00:00:04:6e:6f:6e:65 ection....noneHere's what RFC4252 § Authentication Requests says:
All authentication requests MUST use the following message format.
Only the first few fields are defined; the remaining fields depend on
the authentication method.
byte SSH_MSG_USERAUTH_REQUEST
string user name in ISO-10646 UTF-8 encoding [[RFC3629](https://datatracker.ietf.org/doc/html/rfc3629)]
string service name in US-ASCII
string method name in US-ASCII
.... method specific fieldsSo the first four bytes in the packet that phpseclib is sending out (00:00:00:10) are the string length. The next 16 bytes
(6c:6c:65:77:65:6c:6c:79:6e:00:00:00:00:00:00:00) are the username. Now, it is a little strange that your username has null bytes tacked onto the end of it. It's like... your username isn't "ubuntu" - it's "ubuntu\0\0\0\0\0\0\0". So I'd do echo strlen($username) in your code before you do $sftp->login($username, PublicKeyLoader::load($private_key)). Is it 8 characters or 16? If what phpseclib is getting passed has a bunch of null bytes being tacked onto the end then it stands to reason that it would have a bunch when phpseclib sends the username to the server.
Anyway, after that the next four bytes are the service name string length (00:00:00:0e) and then the service name itself of ssh-connection. 0e is 14 in decimal and ssh-connection is indeed 14 bytes.
The next four bytes after that are the method name length (00:00:00:04) and then the method name itself ("none"). And then that's the end of the request. So per the SSH specs the packet is perfectly valid. The only thing I can see is that your username has null bytes tacked onto the end of it but that's not a phpseclib problem. Sure, I suppose phpseclib could do trim($username, "\0") or maybe you could just do that and make sure that the username you're passing to phpseclib doesn't have null bytes tacked onto the end.
Llewellynvdm
I have read over many issue that seem to have had similar issues.
When I use the keys I have (private-key) to normally login to the server it works, but with the Sftp class I get:
The SFTP connection passes an invalid format to the server, so on the server the logs read:
I followed the instructions on http://phpseclib.com/docs/diagnosis to try and see if there is more info in the
$sftp->getLog();values but it does not give any more details really. [see below]What is really strange is that this use to work, and suddenly it stopped a few updates back... I ignored it at the time, since I had to much things to attend to, but the last three days I have been trying to resolve this, and without any success.
I have spend hours on this and I can't see to make an connection to a server (fresh AWS ubuntu servers) with:
At first I thought it was an error on my part, but after three days, its seems very unlikely.
Here is the
$sftp->getLog()data:Here is the server log for this call:
If I am over looking something simple please let me know, I really need this to work.