23 Apr
2012
23 Apr
'12
3:36 a.m.
On 04/22/2012 07:58 PM, Timothy Pearson wrote:
Tim,
I hope it can be this straight forward. I'll add all this information to
the
bug report. Here is my normal connection (I have pre-shared keys) I'll
also get
the information for a usual login as well (will be later tonigh):
21:06 archangel:/dat_e/pkg> ssh -v nirvana
OpenSSH_5.9p1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /home/david/.ssh/config
debug1: /home/david/.ssh/config line 26: Applying options for nirvana
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to nirvana [192.168.6.17] port 6660.
debug1: Connection established.
debug1: identity file /home/david/.ssh/id_rsa type -1
debug1: identity file /home/david/.ssh/id_rsa-cert type -1
debug1: identity file /home/david/.ssh/id_dsa type 2
debug1: identity file /home/david/.ssh/id_dsa-cert type -1
debug1: identity file /home/david/.ssh/id_ecdsa type -1
debug1: identity file /home/david/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9
debug1: match: OpenSSH_5.9 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA fd:59:75<snipped>0d:6b
debug1: Host '[nirvana]:6660' is known and matches the ECDSA host key.
debug1: Found key in /home/david/.ssh/known_hosts:25
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/david/.ssh/id_rsa
debug1: Offering DSA public key: /home/david/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 434
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).
Authenticated to nirvana ([192.168.6.17]:6660).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions(a)openssh.com
debug1: Entering interactive session.
Last login: Sun Apr 22 01:29:55 2012 from ochiltree-d2.3111skyline.com
====== slightly OT openssl patch =============
I have also found a 'openssl' 1.0.0 patch for openssl in kdelibs. I
don't know
if this has been applied to TDE yet, but I've included that as well in
case it
hasn't.
I just tested on my Debian Squeeze system with OpenSSH_5.5p1 and OpenSSL
0.9.8o, and sftp from GIT worked perfectly. I am going to try a newer
system to see if I can get it to fail.
Tim
On
04/22/2012 06:59 PM, David C. Rankin wrote:
This is very useful information that should be posted to the bug report.
My initial guess would be that the mechanism TDE uses to determine SSH
version is failing with the latest SSH binaries. Can you also post the
output of 'ssh -v' on your system, specifically the version line?
Thanks!
Tim So it looks like that is the recommended
direction. A complete
re-write is way
beyond me, so we will need the skill of the c/c++ gurus to help with
this bug.
Can someone who knows the openssh responses (as well as c++), help take
a
look
at the top of ksshprocess.cpp -- we might avoid a complete rewrite if
we
can
update the response tables for the newer versions of openssh.
ksshprocess
does
response lookups depending on the openssh version. If this has been the
problem
all along -- we may be able to put off the complete rewrite and fix
sftp:// for
3.5.14.