the last _send_channel_packet was unnecessarily complex. this lead
to a number of problems. for example,
the window size was checked for adjustments in two places. in the
second place it receives a window adjustment packet and just assumes
that the window adjustment packet was big enough for the rest of the
data.
(thanks, pixall!)
Sometimes SSH servers will null pad their RSA keys. this null padding
broke Net/SSH2.php's RSA implementation (Crypt/RSA.php's implementation
works just fine). Also, the -3 was counting the initial "\0" of $h
twice so adjust it to -2.
it doesn't need to be defined since the strlen($this->last_interactive_response)
check in _login_helper serves the same purpose that NET_SSH_MASK_LOGIN_INTERACTIVE
was intended to serve
SSH2: make it so negotiated algorithms can be seen before login
* terrafrost/ssh2-show-methods-before-login:
SSH2: white space adjustment
SSH: update getServerPublicHostKey() to use new _connect() method
SSH2: fix if statement for conditional _connect() call
simplify calls to $this->_connect()
SSH2: make it so negotiated algorithms can be seen before login
This small patch adds hmac-sha2-256 support separately as requested in #423.
Some security standards now recommend to disable MD5 and SHA1, and use SHA2 instead. This change was tested using SHA2 against RHEL6's OpenSSH v5.3p1 and Solaris 11. And was also tested with RHEL5's OpenSSH 4.3p2 which doesn't include SHA2.
Random: include the Crypt_* classes if they're available
* bantu/a-random-change:
phpseclib_is_includable() -> phpseclib_resolve_include_path()
Drop Net_SSH2::_is_includable() method.
Random: a few changes to the stream_resolve_include_path_function
Replace stream_resolve_include_path with phpseclib_is_includable.
Random: add explanatory comment
SSH2: replace _is_includable() with stream_resolve_include_path
Random: include the Crypt_* classes if they're available
none of the other statically defined variables have the potential
to change as multiple Net_SSH2 objects are created but this one does.
ie. if you connect to one SSH-2.0-SSHD server then no subsequent server
will use hmac-sha1-96 even if it could
Also, in Net_SSH2::_connect() $host is used in multiple places. Rather than changing all references to {$this->host}:{$this->port} preserve existing $host reference and update it accordingly
this change will make it so some parameters can be set after the
Net_SSH2 object has been created. eg. instead of doing
define('NET_SSH2_LOGGING', NET_SSH2_LOG_COMPLEX) one can now do
$ssh->setLogging(...) or something.
In logs that were provided to me phpseclib sent a packet that was 2536 bytes long (excluding the bytes denoting the channel and data length) but the length packet said it was 32764 bytes long (ie. $max_size).
So when $max_size is less than the data being sent and has to be adjusted by a new window adjust message from the server and the adjustment makes $max_Size bigger than the data being sent over problems arise.
SSH's window size has caused issues before. Overall I don't think the SSH specs really explain the window size very well. I opened up an errata on SSH's RFC a while back about the issue.
- PHP4 doesn't allow method chaining
- $_SESSION isn't always defined
- on PHP5.1 and earlier using 0x100000000 instead of 4294967296 gives E_NOTICE
- array('Net_SSH2', 'func_name') doesn't work so we fix this by passing $this to it.
to make that work on PHP4 pass by call-time reference. normally this would result
in a fatal error on PHP5.4+ but doesn't seem to in this case. the following URL
elaborates:
http://stackoverflow.com/q/20732563/569976
sending the close channel packet right after the eof seems to make some scp transfers terminate prematurely.
unfortunately, sometimes this behavior is undesirable as it is in this case:
http://www.frostjedi.com/phpbb3/viewtopic.php?f=46&t=29457
hence the $want_reply parameter
also, this commit makes the scp packet length account for the length portion
Removed unused piece of code @2352.
Added $this->_get_interactive_channel() to reset(). Unless we don't want to close the subsystem channel?? Leaving that decision up to you.
- keep track of server -> client window size and look out for NET_SSH2_MSG_CHANNEL_WINDOW_ADJUST packets as appropriate
- send client -> server window size packets based on channel of received packet - not of desired channel
- buffer incoming packets based on received packets channel - not on desired channel
