Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
SSH Bad Packet Length - Key Exchange ????
2,751 views
Skip to first unread message
nos...@notreal.com
Dec 9, 2014, 10:02:15 PM12/9/14
to
I am trying to connect to a device that appears to have SSH installed on
it. However, when I try to make a connection to it using Putty, it
hangs and then aborts with no output shown on the screen.
When I try to connect to it from a Linux box using SSH at the command
line, it fails as a result of a "bad packet length" Below are the last
twelve lines of the output using the "-v" switch indicating the failure.
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.5
debug1: match: OpenSSH_6.5 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client 3des-cbc hmac-m...@openssh.com none
debug1: kex: client->server 3des-cbc hmac-m...@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
Bad packet length 3159191491.
Disconnecting: Packet corrupt
It appears to have something to do with the key exchange, but that is
just a guess on my part. Could it be a case of the device looking for a
key to confirm authorization or something else? Does anyone have an
idea what I can do to make this work?
As you can clearly see, I am not well versed on SSH so I might be
completely off base. If you need to see any of the first lines of the
command line connection process as well, I can certainly provide them.
As background, the device is on a local LAN and the only thing between
the device and the Linux box is a switch. I say that because I found
one reference while looking for a solution that suggested bad packet
length might be the result of packet corruption somewhere on the LAN. I
use SSH across that switch all the time to shell into Linux servers
without a problem. Lastly, I do not have any access to the device
programming so there is not much I can do from the device end. If the
problem cannot be solved from Linux or Putty side, I think I am out of
luck. Even if that is the case, it would nice to know why.
Thanks for taking the time to read this.
it. However, when I try to make a connection to it using Putty, it
hangs and then aborts with no output shown on the screen.
When I try to connect to it from a Linux box using SSH at the command
line, it fails as a result of a "bad packet length" Below are the last
twelve lines of the output using the "-v" switch indicating the failure.
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.5
debug1: match: OpenSSH_6.5 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client 3des-cbc hmac-m...@openssh.com none
debug1: kex: client->server 3des-cbc hmac-m...@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
Bad packet length 3159191491.
Disconnecting: Packet corrupt
It appears to have something to do with the key exchange, but that is
just a guess on my part. Could it be a case of the device looking for a
key to confirm authorization or something else? Does anyone have an
idea what I can do to make this work?
As you can clearly see, I am not well versed on SSH so I might be
completely off base. If you need to see any of the first lines of the
command line connection process as well, I can certainly provide them.
As background, the device is on a local LAN and the only thing between
the device and the Linux box is a switch. I say that because I found
one reference while looking for a solution that suggested bad packet
length might be the result of packet corruption somewhere on the LAN. I
use SSH across that switch all the time to shell into Linux servers
without a problem. Lastly, I do not have any access to the device
programming so there is not much I can do from the device end. If the
problem cannot be solved from Linux or Putty side, I think I am out of
luck. Even if that is the case, it would nice to know why.
Thanks for taking the time to read this.
Bruce Esquibel
Dec 10, 2014, 6:02:50 AM12/10/14
to
nos...@notreal.com wrote:
> I am trying to connect to a device that appears to have SSH installed on
> it. However, when I try to make a connection to it using Putty, it
> hangs and then aborts with no output shown on the screen.
Well, if you don't want to explain what this device is, it's really going to
> I am trying to connect to a device that appears to have SSH installed on
> it. However, when I try to make a connection to it using Putty, it
> hangs and then aborts with no output shown on the screen.
be a shot in the dark if anyone can come up with an answer.
That error message dealing with "bad packet length" is generic to having
software doing a seg_fault, could be something, could be anything.
What I'd do is google for SSH2_MSG_KEX_ECDH_REPLY and read some of the 1st
page results, most from this year. The suggested fixes are to change the MTU
on your linux box (which may or may not be of help because of the switch)
and other suggestions adding in protocols in your ssh_config file that the
remote device is expecting but not present.
Keep in mind this year SSL/SSH took a beating with the heartbleed stuff and
many of the fixes were hacks, many of those just turning off things rather
than patching in a fix. This involves the HostKeyAlgorithms in your config
for ssh.
One other thing it could be, again depending what the device is, if it has
any kind of internal firewall built in, it might just be blocking you.
Software ones like tcpwrapper and even ipfilter (ipf) could be shutting down
the connection mid handshake. If you can't get into the device by other
means, this one will be a major problem.
But it would be handy to know what the device is and the history, if it's
new, used, did it work before like this, is an unknown peice of hardware or
something else.
-bruce
b...@ripco.com
Simon Tatham
Dec 10, 2014, 6:14:07 AM12/10/14
to
Bruce Esquibel <b...@ripco.com> wrote:
> Keep in mind this year SSL/SSH took a beating with the heartbleed stuff and
> many of the fixes were hacks, many of those just turning off things rather
> than patching in a fix. This involves the HostKeyAlgorithms in your config
> for ssh.
That's a misrepresentation - SSH and SSL are completely different
> Keep in mind this year SSL/SSH took a beating with the heartbleed stuff and
> many of the fixes were hacks, many of those just turning off things rather
> than patching in a fix. This involves the HostKeyAlgorithms in your config
> for ssh.
protocols, and Heartbleed has nothing to do with SSH.
(Don't be misled by the fact that OpenSSH depends on the OpenSSL
libraries. In fact it only uses the low-level crypto primitives from
those libraries, and not any of the higher-level SSL protocol
implementation, which is where recent SSL security issues have shown
up.)
--
import hashlib; print (lambda p,q,g,y,r,s,m: m if (lambda w:(pow(g,int(hashlib.
sha1(m).hexdigest(),16)*w%q,p)*pow(y,r*w%q,p)%p)%q)(pow(s,q-2,q))==r else "!"
)(0xb80b5dacabab6145, 0xf70027d345023, 0x7643bc4018957897, 0x11c2e5d9951130c9,
0xa54d9cbe4e8ab, 0x746c50eaa1910, "Simon Tatham <ana...@pobox.com>")
Simon Tatham
Dec 10, 2014, 6:25:20 AM12/10/14
to
<nos...@notreal.com> wrote:
> debug1: sending SSH2_MSG_KEX_ECDH_INIT
> debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
> Bad packet length 3159191491.
> Disconnecting: Packet corrupt
>
> It appears to have something to do with the key exchange, but that is
> just a guess on my part.
Yes, I think this is happening inside the key exchange, which is
> debug1: sending SSH2_MSG_KEX_ECDH_INIT
> debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
> Bad packet length 3159191491.
> Disconnecting: Packet corrupt
>
> It appears to have something to do with the key exchange, but that is
> just a guess on my part.
surprising and unusual.
The most common cause of 'bad packet length' errors is that something
has gone wrong with the cryptography (either due to data corruption in
the network as you suggested, or an implementation bug at one end or
the other), so that a packet encrypted at one end and decrypted at the
other end comes out as gibberish instead of coming out the same as the
sender's version. But here, it looks as if the client hasn't even got
as far as enabling encryption - if it had, you'd expect OpenSSH to
have printed 'SSH2_MSG_NEWKEYS sent' and SSH2_MSG_NEWKEYS received'
before displaying that error message.
So this looks like a more unusual case, where a fundamental packet
formatting error manages to occur during the initial key exchange -
which is conducted in cleartext, so misbehaving encryption can't be
the cause.
If you're seeing failures with PuTTY as well as OpenSSH, then could
you generate a full log of a failing PuTTY session by setting the
logging mode to 'SSH packets and raw data'? That might give enough
information for a more specific diagnosis.
--
for k in [pow(x,37,0x1a1298d262b49c895d47f) for x in [0x50deb914257022de7fff,
0x213558f2215127d5a2d1, 0x90c99e86d08b91218630, 0x109f3d0cfbf640c0beee7,
0xc83e01379a5fbec5fdd1, 0x19d3d70a8d567e388600e, 0x534e2f6e8a4a33155123]]:
print "".join([chr(32+3*((k>>x)&1))for x in range(79)]) # <ana...@pobox.com>
nos...@notreal.com
Dec 10, 2014, 10:11:05 AM12/10/14
to
In article <f1t*NT...@news.chiark.greenend.org.uk>, ana...@pobox.com
says...
First of all, I thank you both for taking the time to reply. It is
appreciated.
Below is the output of Putty when "SSH packets and raw data" is
selected.
=~=~=~=~=~=~=~ PuTTY log 2014.12.10 09:07:51 =~=~=~=~=~=~=~=~=
Event Log: Writing new session log (SSH raw data mode) to file:
putty.log
Event Log: Looking up host "192.168.1.175"
Event Log: Connecting to 192.168.1.175 port 8190
Event Log: Network error: Software caused connection abort
I am afraid it is not of much use.
As for the request for information on the device itself, I will try to
give you additional information without identifying the device. It is
device with both a Wi-Fi and Ehternet connection and it normally runs
through the Wi-Fi connection. The normal way to configure the device is
through a browser with a GUI but I also noted an open port that appeared
to have SSH implemented on it. Unfortunately the device does not
exchange data automatically with a computer the way it designed to for
certain functions and I thought a way around the problem was to
interrogate it through the SSH port. A similar situation might be if
you wrote a bash script to interrogate a DSL modem every minute to
obtain and log the current SNR values through its telnet port.
The reason I am being so cryptic is because I have been in contact with
the manufacturer and working with one of their engineers. They have
acknowledged that there is a problem and are working on solving it. He
appears to be sincere in his communications with me so I am giving him
the benefit of the doubt and do not want to disparage his device or
reveal its shortcomings, at least for now. The problem is that it is
taking a long time (months) that he attributes to difficulty with
working with one of his vendors. As a result I was looking for a work
around in the meantime to make the device work the way I want it to work
until there is a real solution.
says...
appreciated.
Below is the output of Putty when "SSH packets and raw data" is
selected.
=~=~=~=~=~=~=~ PuTTY log 2014.12.10 09:07:51 =~=~=~=~=~=~=~=~=
Event Log: Writing new session log (SSH raw data mode) to file:
putty.log
Event Log: Looking up host "192.168.1.175"
Event Log: Connecting to 192.168.1.175 port 8190
Event Log: Network error: Software caused connection abort
I am afraid it is not of much use.
As for the request for information on the device itself, I will try to
give you additional information without identifying the device. It is
device with both a Wi-Fi and Ehternet connection and it normally runs
through the Wi-Fi connection. The normal way to configure the device is
through a browser with a GUI but I also noted an open port that appeared
to have SSH implemented on it. Unfortunately the device does not
exchange data automatically with a computer the way it designed to for
certain functions and I thought a way around the problem was to
interrogate it through the SSH port. A similar situation might be if
you wrote a bash script to interrogate a DSL modem every minute to
obtain and log the current SNR values through its telnet port.
The reason I am being so cryptic is because I have been in contact with
the manufacturer and working with one of their engineers. They have
acknowledged that there is a problem and are working on solving it. He
appears to be sincere in his communications with me so I am giving him
the benefit of the doubt and do not want to disparage his device or
reveal its shortcomings, at least for now. The problem is that it is
taking a long time (months) that he attributes to difficulty with
working with one of his vendors. As a result I was looking for a work
around in the meantime to make the device work the way I want it to work
until there is a real solution.
Simon Tatham
Dec 10, 2014, 10:27:13 AM12/10/14
to
<nos...@notreal.com> wrote:
> Below is the output of Putty when "SSH packets and raw data" is
> selected.
>
> Below is the output of Putty when "SSH packets and raw data" is
> selected.
>
> Event Log: Connecting to 192.168.1.175 port 8190
> Event Log: Network error: Software caused connection abort
>
> I am afraid it is not of much use.
Ah, I see. That suggests that the device is refusing connections
> Event Log: Network error: Software caused connection abort
>
> I am afraid it is not of much use.
completely from the machine you're running PuTTY on. You're right,
that's less helpful than I'd hoped for.
Are you able to try the same test using the Linux version of PuTTY,
running on the same machine where you used OpenSSH to connect to the
device and get as far as the key exchange problem?
(The reason I really want you to try PuTTY in particular is because it
can produce this particular kind of log file, whereas I don't know of
any way to get comparably detailed data out of OpenSSH. If I did, I'd
suggest that instead.)
nos...@notreal.com
Dec 10, 2014, 11:30:41 AM12/10/14
to
The Linux version of putty produced the same output as the Windows
version.
I requested information from the device vendor the same time as I tried
Usenet and I have now heard from him. He indicates that SSH is not on
the device. Well, it might not be fully implemented but it does seem
to me that it is there. I followed up with a question asking what the
protocol might be to communicate with the device if it is not SSH, but
so far, no resposne.
Here is the full output of the Linux command line SSH connection with
the maximum amount of logging that I am aware of. I do see where it
"loaded 0 keys" which doesn't look good.
I could also try tcpdump to capture the actual data, but I must confess
that when I have done that in the past, most of the output unless I am
looking for something specific is gibberish to me.
OpenSSH_6.5, OpenSSL 1.0.1j 15 Oct 2014
debug1: Reading configuration data /usr/local/etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.175 [192.168.1.175] port 8190.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug3: put_host_port: [192.168.1.175]:8190
debug3: load_hostkeys: loading entries for host "[192.168.1.175]:8190"
from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-
exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-
group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01
@openssh.com,ecdsa-sha2-nis...@openssh.com,ecdsa-sha2-
nistp521...@openssh.com,ssh-ed2551...@openssh.com,ssh-rsa-
cert...@openssh.com,ssh-dss-...@openssh.com,ssh-rsa-cert-v00
@openssh.com,ssh-dss-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-
sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-
ctr,arcfour256,arcfour128,aes12...@openssh.com,aes256-
g...@openssh.com,chacha20...@openssh.com,aes128-cbc,3des-
cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-
c...@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-
ctr,arcfour256,arcfour128,aes12...@openssh.com,aes256-
g...@openssh.com,chacha20...@openssh.com,aes128-cbc,3des-
cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-
c...@lysator.liu.se
debug2: kex_parse_kexinit: hmac-m...@openssh.com,hmac-sha1-
e...@openssh.com,umac-...@openssh.com,umac-1...@openssh.com,hmac-
sha2-2...@openssh.com,hmac-sha...@openssh.com,hmac-ripemd160-
e...@openssh.com,hmac-sha...@openssh.com,hmac-md5-96-
e...@openssh.com,hmac-md5,hmac-sha1,uma...@openssh.com,umac-128
@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160
@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-m...@openssh.com,hmac-sha1-
e...@openssh.com,umac-...@openssh.com,umac-1...@openssh.com,hmac-
sha2-2...@openssh.com,hmac-sha...@openssh.com,hmac-ripemd160-
e...@openssh.com,hmac-sha...@openssh.com,hmac-md5-96-
e...@openssh.com,hmac-md5,hmac-sha1,uma...@openssh.com,umac-128
@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160
@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: curve255...@libssh.org,ecdh-sha2-
nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-
exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-
group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01
@openssh.com,ecdsa-sha2-nis...@openssh.com,ecdsa-sha2-
nistp521...@openssh.com,ssh-ed2551...@openssh.com,ssh-rsa-
cert...@openssh.com,ssh-dss-...@openssh.com,ssh-rsa-cert-v00
@openssh.com,ssh-dss-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-
sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-
ctr,arcfour256,arcfour128,aes12...@openssh.com,aes256-
g...@openssh.com,chacha20...@openssh.com,aes128-cbc,3des-
cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-
c...@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-
ctr,arcfour256,arcfour128,aes12...@openssh.com,aes256-
g...@openssh.com,chacha20...@openssh.com,aes128-cbc,3des-
cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-
c...@lysator.liu.se
debug2: kex_parse_kexinit: hmac-m...@openssh.com,hmac-sha1-
e...@openssh.com,umac-...@openssh.com,umac-1...@openssh.com,hmac-
sha2-2...@openssh.com,hmac-sha...@openssh.com,hmac-ripemd160-
e...@openssh.com,hmac-sha...@openssh.com,hmac-md5-96-
e...@openssh.com,hmac-md5,hmac-sha1,uma...@openssh.com,umac-128
@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160
@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-m...@openssh.com,hmac-sha1-
e...@openssh.com,umac-...@openssh.com,umac-1...@openssh.com,hmac-
sha2-2...@openssh.com,hmac-sha...@openssh.com,hmac-ripemd160-
e...@openssh.com,hmac-sha...@openssh.com,hmac-md5-96-
e...@openssh.com,hmac-md5,hmac-sha1,uma...@openssh.com,umac-128
@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160
@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-m...@openssh.com
debug1: kex: server->client aes128-ctr hmac-m...@openssh.com none
debug2: mac_setup: found hmac-m...@openssh.com
debug1: kex: client->server aes128-ctr hmac-m...@openssh.com none
Disconnecting: Packet corrupt
version.
I requested information from the device vendor the same time as I tried
Usenet and I have now heard from him. He indicates that SSH is not on
the device. Well, it might not be fully implemented but it does seem
to me that it is there. I followed up with a question asking what the
protocol might be to communicate with the device if it is not SSH, but
so far, no resposne.
Here is the full output of the Linux command line SSH connection with
the maximum amount of logging that I am aware of. I do see where it
"loaded 0 keys" which doesn't look good.
I could also try tcpdump to capture the actual data, but I must confess
that when I have done that in the past, most of the output unless I am
looking for something specific is gibberish to me.
OpenSSH_6.5, OpenSSL 1.0.1j 15 Oct 2014
debug1: Reading configuration data /usr/local/etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.175 [192.168.1.175] port 8190.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.5
debug1: match: OpenSSH_6.5 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Local version string SSH-2.0-OpenSSH_6.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.5
debug1: match: OpenSSH_6.5 pat OpenSSH* compat 0x04000000
debug3: put_host_port: [192.168.1.175]:8190
debug3: load_hostkeys: loading entries for host "[192.168.1.175]:8190"
from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve255...@libssh.org,ecdh-sha2-
debug1: SSH2_MSG_KEXINIT received
nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-
exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-
group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01
@openssh.com,ecdsa-sha2-nis...@openssh.com,ecdsa-sha2-
nistp521...@openssh.com,ssh-ed2551...@openssh.com,ssh-rsa-
cert...@openssh.com,ssh-dss-...@openssh.com,ssh-rsa-cert-v00
@openssh.com,ssh-dss-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-
sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-
ctr,arcfour256,arcfour128,aes12...@openssh.com,aes256-
g...@openssh.com,chacha20...@openssh.com,aes128-cbc,3des-
cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-
c...@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-
ctr,arcfour256,arcfour128,aes12...@openssh.com,aes256-
g...@openssh.com,chacha20...@openssh.com,aes128-cbc,3des-
cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-
c...@lysator.liu.se
debug2: kex_parse_kexinit: hmac-m...@openssh.com,hmac-sha1-
e...@openssh.com,umac-...@openssh.com,umac-1...@openssh.com,hmac-
sha2-2...@openssh.com,hmac-sha...@openssh.com,hmac-ripemd160-
e...@openssh.com,hmac-sha...@openssh.com,hmac-md5-96-
e...@openssh.com,hmac-md5,hmac-sha1,uma...@openssh.com,umac-128
@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160
@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-m...@openssh.com,hmac-sha1-
e...@openssh.com,umac-...@openssh.com,umac-1...@openssh.com,hmac-
sha2-2...@openssh.com,hmac-sha...@openssh.com,hmac-ripemd160-
e...@openssh.com,hmac-sha...@openssh.com,hmac-md5-96-
e...@openssh.com,hmac-md5,hmac-sha1,uma...@openssh.com,umac-128
@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160
@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: curve255...@libssh.org,ecdh-sha2-
nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-
exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-
group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01
@openssh.com,ecdsa-sha2-nis...@openssh.com,ecdsa-sha2-
nistp521...@openssh.com,ssh-ed2551...@openssh.com,ssh-rsa-
cert...@openssh.com,ssh-dss-...@openssh.com,ssh-rsa-cert-v00
@openssh.com,ssh-dss-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-
sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-
ctr,arcfour256,arcfour128,aes12...@openssh.com,aes256-
g...@openssh.com,chacha20...@openssh.com,aes128-cbc,3des-
cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-
c...@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-
ctr,arcfour256,arcfour128,aes12...@openssh.com,aes256-
g...@openssh.com,chacha20...@openssh.com,aes128-cbc,3des-
cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-
c...@lysator.liu.se
debug2: kex_parse_kexinit: hmac-m...@openssh.com,hmac-sha1-
e...@openssh.com,umac-...@openssh.com,umac-1...@openssh.com,hmac-
sha2-2...@openssh.com,hmac-sha...@openssh.com,hmac-ripemd160-
e...@openssh.com,hmac-sha...@openssh.com,hmac-md5-96-
e...@openssh.com,hmac-md5,hmac-sha1,uma...@openssh.com,umac-128
@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160
@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-m...@openssh.com,hmac-sha1-
e...@openssh.com,umac-...@openssh.com,umac-1...@openssh.com,hmac-
sha2-2...@openssh.com,hmac-sha...@openssh.com,hmac-ripemd160-
e...@openssh.com,hmac-sha...@openssh.com,hmac-md5-96-
e...@openssh.com,hmac-md5,hmac-sha1,uma...@openssh.com,umac-128
@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160
@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-m...@openssh.com
debug1: kex: server->client aes128-ctr hmac-m...@openssh.com none
debug2: mac_setup: found hmac-m...@openssh.com
debug1: kex: client->server aes128-ctr hmac-m...@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
Bad packet length 3824798710.
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
Disconnecting: Packet corrupt
Simon Tatham
Dec 10, 2014, 11:38:34 AM12/10/14
to
<nos...@notreal.com> wrote:
> The Linux version of putty produced the same output as the Windows
> version.
Really? 'Software caused connection abort', and no packets or even the
> The Linux version of putty produced the same output as the Windows
> version.
SSH-2.0-xxxxx greeting written to the log file?
That seems very unlikely, since that error message doesn't even mean
the same thing on Linux and Windows. Also, I can't see how connecting
to the same hostname and port number from the same machine with two
different pieces of application software could cause a failure at
_connection setup time_ on only one of them - it would make sense if
the failure occurred later, after data had been transferred, because
then the far end would have a way to tell the difference.
I'm sorry to doubt your word, but could you double-check, and make
sure that OpenSSH and Linux PuTTY really are connecting to exactly the
same IP address and port number, in the same way, from the same Linux
machine, and quote the exact log from Linux PuTTY as you did for
Windows?
> I could also try tcpdump to capture the actual data, but I must confess
> that when I have done that in the past, most of the output unless I am
> looking for something specific is gibberish to me.
the SSH key exchange, it might be useful for once - that would give
all the same information as the PuTTY packet log I've been hoping for.
nos...@notreal.com
Dec 10, 2014, 11:45:53 AM12/10/14
to
In article <xyC*b3...@news.chiark.greenend.org.uk>, ana...@pobox.com
says...
Here is the actual log.
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2014.12.10 09:55:55
=~=~=~=~=~=~=~=~=~=~=~=
Event Log: Connection reset by peer
says...
> <nos...@notreal.com> wrote:
> > The Linux version of putty produced the same output as the Windows
> > version.
>
> Really? 'Software caused connection abort', and no packets or even the
> SSH-2.0-xxxxx greeting written to the log file?
>
> That seems very unlikely, since that error message doesn't even mean
> the same thing on Linux and Windows. Also, I can't see how connecting
> to the same hostname and port number from the same machine with two
> different pieces of application software could cause a failure at
> _connection setup time_ on only one of them - it would make sense if
> the failure occurred later, after data had been transferred, because
> then the far end would have a way to tell the difference.
>
> I'm sorry to doubt your word, but could you double-check, and make
> sure that OpenSSH and Linux PuTTY really are connecting to exactly the
> same IP address and port number, in the same way, from the same Linux
> machine, and quote the exact log from Linux PuTTY as you did for
> Windows?
>
> > I could also try tcpdump to capture the actual data, but I must confess
> > that when I have done that in the past, most of the output unless I am
> > looking for something specific is gibberish to me.
>
> In this case, with the error apparently being in the cleartext part of
> the SSH key exchange, it might be useful for once - that would give
> all the same information as the PuTTY packet log I've been hoping for.
>
Not a problem. Ask for anything you want.
> > The Linux version of putty produced the same output as the Windows
> > version.
>
> Really? 'Software caused connection abort', and no packets or even the
> SSH-2.0-xxxxx greeting written to the log file?
>
> That seems very unlikely, since that error message doesn't even mean
> the same thing on Linux and Windows. Also, I can't see how connecting
> to the same hostname and port number from the same machine with two
> different pieces of application software could cause a failure at
> _connection setup time_ on only one of them - it would make sense if
> the failure occurred later, after data had been transferred, because
> then the far end would have a way to tell the difference.
>
> I'm sorry to doubt your word, but could you double-check, and make
> sure that OpenSSH and Linux PuTTY really are connecting to exactly the
> same IP address and port number, in the same way, from the same Linux
> machine, and quote the exact log from Linux PuTTY as you did for
> Windows?
>
> > I could also try tcpdump to capture the actual data, but I must confess
> > that when I have done that in the past, most of the output unless I am
> > looking for something specific is gibberish to me.
>
> In this case, with the error apparently being in the cleartext part of
> the SSH key exchange, it might be useful for once - that would give
> all the same information as the PuTTY packet log I've been hoping for.
>
Here is the actual log.
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2014.12.10 09:55:55
=~=~=~=~=~=~=~=~=~=~=~=
Event Log: Writing new session log (SSH raw data mode) to file:
putty.log
Event Log: Looking up host "192.168.1.175"
putty.log
Event Log: Looking up host "192.168.1.175"
Event Log: Connecting to 192.168.1.175 port 8190
Event Log: Failed to connect to 192.168.1.175: Connection reset by peer
Event Log: Connection reset by peer
Bruce Esquibel
Dec 12, 2014, 8:43:01 AM12/12/14
to
nos...@notreal.com wrote:
> As for the request for information on the device itself, I will try to
> give you additional information without identifying the device. It is
> device with both a Wi-Fi and Ehternet connection and it normally runs
> through the Wi-Fi connection. The normal way to configure the device is
> through a browser with a GUI but I also noted an open port that appeared
> to have SSH implemented on it. Unfortunately the device does not
> exchange data automatically with a computer the way it designed to for
> certain functions and I thought a way around the problem was to
> interrogate it through the SSH port. A similar situation might be if
> you wrote a bash script to interrogate a DSL modem every minute to
> obtain and log the current SNR values through its telnet port.
Hmmm.
> As for the request for information on the device itself, I will try to
> give you additional information without identifying the device. It is
> device with both a Wi-Fi and Ehternet connection and it normally runs
> through the Wi-Fi connection. The normal way to configure the device is
> through a browser with a GUI but I also noted an open port that appeared
> to have SSH implemented on it. Unfortunately the device does not
> exchange data automatically with a computer the way it designed to for
> certain functions and I thought a way around the problem was to
> interrogate it through the SSH port. A similar situation might be if
> you wrote a bash script to interrogate a DSL modem every minute to
> obtain and log the current SNR values through its telnet port.
Playing 20 questions here, uses both wifi and ethernet and seems like it's
running something like SSH on port 8190?
If it's a security camera or some DVR dealing with cameras, I think you are
barking up the wrong tree.
Maybe it tastes and smells like SSH but if the device is along those lines,
I beleive that port is used to send commands to (encrypted of course) from
like a smart phone or some other controller, maybe even a bridge mode if you
have several of them.
If I'm on the right track, and remember this correctly, most of those
devices use some kind of Linux kernel but a mini version. You need the
username and password for the GUI login and using the controller software,
stick those two tidbits in along with the IP address, then there is some
kind of key exchange so it only recognizes the commands from that controller.
It's more like SCP I guess, the controller doesn't exactly log into the
device, it just sends the client key (private/public whatever) along with
the codes to do what you want to do.
If it's not a security camera or DVR setup, sorry for the theory but I just
get the feeling at this point you aren't going to do what you think you can
do.
-bruce
b...@ripco.com
nos...@notreal.com
Dec 12, 2014, 11:17:51 AM12/12/14
to
In article <m6erd4$a9u$1...@remote5bge0.ripco.com>, b...@ripco.com says...
of DVR device, but you have given me some more food for thought. I will
have to do some research on SCP since the SSH approach seems to be a
dead end. Thank you.
>
> Hmmm.
>
> Playing 20 questions here, uses both wifi and ethernet and seems like it's
> running something like SSH on port 8190?
>
> If it's a security camera or some DVR dealing with cameras, I think you are
> barking up the wrong tree.
>
> Maybe it tastes and smells like SSH but if the device is along those lines,
> I beleive that port is used to send commands to (encrypted of course) from
> like a smart phone or some other controller, maybe even a bridge mode if you
> have several of them.
>
> If I'm on the right track, and remember this correctly, most of those
> devices use some kind of Linux kernel but a mini version. You need the
> username and password for the GUI login and using the controller software,
> stick those two tidbits in along with the IP address, then there is some
> kind of key exchange so it only recognizes the commands from that controller.
>
> It's more like SCP I guess, the controller doesn't exactly log into the
> device, it just sends the client key (private/public whatever) along with
> the codes to do what you want to do.
>
> If it's not a security camera or DVR setup, sorry for the theory but I just
> get the feeling at this point you aren't going to do what you think you can
> do.
>
> -bruce
> b...@ripco.com
>
Thanks for replying. It is not a security camera or any other type of
> Hmmm.
>
> Playing 20 questions here, uses both wifi and ethernet and seems like it's
> running something like SSH on port 8190?
>
> If it's a security camera or some DVR dealing with cameras, I think you are
> barking up the wrong tree.
>
> Maybe it tastes and smells like SSH but if the device is along those lines,
> I beleive that port is used to send commands to (encrypted of course) from
> like a smart phone or some other controller, maybe even a bridge mode if you
> have several of them.
>
> If I'm on the right track, and remember this correctly, most of those
> devices use some kind of Linux kernel but a mini version. You need the
> username and password for the GUI login and using the controller software,
> stick those two tidbits in along with the IP address, then there is some
> kind of key exchange so it only recognizes the commands from that controller.
>
> It's more like SCP I guess, the controller doesn't exactly log into the
> device, it just sends the client key (private/public whatever) along with
> the codes to do what you want to do.
>
> If it's not a security camera or DVR setup, sorry for the theory but I just
> get the feeling at this point you aren't going to do what you think you can
> do.
>
> -bruce
> b...@ripco.com
>
of DVR device, but you have given me some more food for thought. I will
have to do some research on SCP since the SSH approach seems to be a
dead end. Thank you.
Dag-Erling Smørgrav
Jan 11, 2015, 6:26:30 PM1/11/15
to
<nos...@notreal.com> writes:
> Thanks for replying. It is not a security camera or any other type of
> of DVR device, but you have given me some more food for thought. I will
> have to do some research on SCP since the SSH approach seems to be a
> dead end. Thank you.
SCP runs on top of SSH. If you can't even complete an SSH handshake, SCP
> Thanks for replying. It is not a security camera or any other type of
> of DVR device, but you have given me some more food for thought. I will
> have to do some research on SCP since the SSH approach seems to be a
> dead end. Thank you.
is not going to help you.
There is a very simple, 100% foolproof way to verify whether your
appliance runs SSH. Run 'nc -v 192.168.1.175 8190'. If you get an SSH
banner, the appliance runs an SSH server on port 8190. Otherwise, it
doesn't. And frankly, I don't think it does - I think it's just
reflecting what you're sending, which will fool an SSH client up to a
certain point because the initial banner exchange and algorithm
negotiation are symmetrical. The fact that its seems to be running the
exact same (fairly recent) OpenSSH version that you are should be a dead
giveaway - embedded systems usually run Dropbear or some other
low-footprint implementation.
DES
--
Dag-Erling Smørgrav - d...@des.no
0 new messages