Ubuntu
openssh package

Can't connect to iLO on HP servers without doing "unset LANG"

Bug #46299 reported by Piers Cornwell
30
This bug affects 3 people
Affects Status Importance Assigned to Milestone
openssh (Debian)
Fix Released
Unknown
openssh (Ubuntu)
Won't Fix
Medium
Unassigned

Bug Description

Binary package hint: openssh-client

When trying to connect via SSH to iLO (lights out management) on Hewlett Packard Proliant servers, the SSH in Ubuntu Dapper gives the following error after authentication:

dispatch_protocol_error: type 100 seq 7
buffer_get_ret: trying to get more bytes 4 than in buffer 0
buffer_get_int: buffer error

Doing "unset LANG" allows the login to work fine.

The full "ssh -v" output is:

$ ssh -v servername -l root
OpenSSH_4.2p1 Debian-7ubuntu3, OpenSSL 0.9.8a 11 Oct 2005
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to servername [168.192.63.44] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version mpSSH_0.0.1
debug1: no match: mpSSH_0.0.1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host 'servername' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:245
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: password,publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/identity
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Trying private key: /home/user/.ssh/id_dsa
debug1: Next authentication method: password
root@servername's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_GB.UTF-8
dispatch_protocol_error: type 100 seq 7
buffer_get_ret: trying to get more bytes 4 than in buffer 0
buffer_get_int: buffer error

See original description
Revision history for this message
In , Florian Weimer (fw) wrote : Re: Bug#343896: no longer works with HP iLO

* Wichert Akkerman:

> debug1: Remote protocol version 2.0, remote software version mpSSH_0.0.1
> debug1: no match: mpSSH_0.0.1

Find out what (Open)SSH version this actually is, we can then add a
regexp to set the proper compatibility flags.

Revision history for this message
In , Wichert Akkerman (wichert) wrote :

Previously Florian Weimer wrote:
> * Wichert Akkerman:
> > debug1: Remote protocol version 2.0, remote software version mpSSH_0.0.1
> > debug1: no match: mpSSH_0.0.1
>
> Find out what (Open)SSH version this actually is, we can then add a
> regexp to set the proper compatibility flags.

It's all in HP iLO firmware, I doubt we can figure that out.

Wichert.

--
Wichert Akkerman <email address hidden> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.

Revision history for this message
In , Florian Weimer (fw) wrote :

* Wichert Akkerman:

> Previously Florian Weimer wrote:
>> * Wichert Akkerman:
>> > debug1: Remote protocol version 2.0, remote software version mpSSH_0.0.1
>> > debug1: no match: mpSSH_0.0.1
>>
>> Find out what (Open)SSH version this actually is, we can then add a
>> regexp to set the proper compatibility flags.
>
> It's all in HP iLO firmware, I doubt we can figure that out.

But HP can, so we just need someone with proper contacts. If this
problem affects upstream as well, I'm sure they are quite eager to
help. 8-/

Revision history for this message
In , Colin Watson (cjwatson) wrote :

On Sun, Dec 18, 2005 at 08:48:35PM +0100, Florian Weimer wrote:
> * Wichert Akkerman:
> > debug1: Remote protocol version 2.0, remote software version mpSSH_0.0.1
> > debug1: no match: mpSSH_0.0.1
>
> Find out what (Open)SSH version this actually is, we can then add a
> regexp to set the proper compatibility flags.

I suspect that this will not be enough, although it would certainly be
useful on general principles.

The message on which we're getting dispatch_protocol_error is
SSH2_MSG_CHANNEL_FAILURE. We've discovered that disabling SendEnv is a
workaround. My initial reaction was that this meant that the OpenSSH
client is not prepared for the possibility of a server that does not
support the "env" channel request. However, on further investigation I
discovered that OpenSSH sets the "want reply" flag in that channel
request to false; mpSSH appears not to be honouring that flag the way
that http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-25.txt
(expired draft though it is) says it should. I don't see any
bug-compatibility handling for this case in OpenSSH at the moment.

For further head-scratching value, when I deliberately break an OpenSSH
server so that it doesn't understand the "env" channel request and fails
to honour the "want reply" flag, the client emits the
dispatch_protocol_error messages noted by Wichert but manages to connect
anyway; so something more is going on here.

Cheers,

--
Colin Watson [<email address hidden>]

Revision history for this message
In , Wichert Akkerman (wichert) wrote :
Download full text (3.5 KiB)

On request from Colin here is the -vvv output:

wichert@217.196.43.133's password:
debug3: packet_send2: adding 64 (len 60 padlen 4 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 0
debug3: tty_make_modes: ospeed 38400
debug3: tty_make_modes: ispeed 38400
debug3: tty_make_modes: 1 3
debug3: tty_make_modes: 2 28
debug3: tty_make_modes: 3 127
debug3: tty_make_modes: 4 21
debug3: tty_make_modes: 5 4
debug3: tty_make_modes: 6 0
debug3: tty_make_modes: 7 0
debug3: tty_make_modes: 8 17
debug3: tty_make_modes: 9 19
debug3: tty_make_modes: 10 26
debug3: tty_make_modes: 12 18
debug3: tty_make_modes: 13 23
debug3: tty_make_modes: 14 22
debug3: tty_make_modes: 18 15
debug3: tty_make_modes: 30 0
debug3: tty_make_modes: 31 0
debug3: tty_make_modes: 32 0
debug3: tty_make_modes: 33 0
debug3: tty_make_modes: 34 0
debug3: tty_make_modes: 35 0
debug3: tty_make_modes: 36 1
debug3: tty_make_modes: 37 0
debug3: tty_make_modes: 38 1
debug3: tty_make_modes: 39 0
debug3: tty_make_modes: 40 0
debug3: tty_make_modes: 41 0
debug3: tty_make_modes: 50 1
debug3: tty_make_modes: 51 1
debug3: tty_make_modes: 52 0
debug3: tty_make_modes: 53 1
debug3: tty_make_modes: 54 1
debug3: tty_make_modes: 55 1
debug3: tty_make_modes: 56 0
debug3: tty_make_modes: 57 0
debug3: tty_make_modes: 58 0
debug3: tty_make_modes: 59 1
debug3: tty_make_modes: 60 1
debug3: tty_make_modes: 61 1
debug3: tty_make_modes: 62 0
debug3: tty_make_modes: 70 1
debug3: tty_make_modes: 71 0
debug3: tty_make_modes: 72 1
debug3: tty_make_modes: 73 0
debug3: tty_make_modes: 74 0
debug3: tty_make_modes: 75 0
debug3: tty_make_modes: 90 1
debug3: tty_make_modes: 91 1
debug3: tty_make_modes: 92 0
debug3: tty_make_modes: 93 0
debug1: Sending environment.
debug3: Ignored env SSH_AGENT_PID
debug3: Ignored env GPG_AGENT_INFO
debug3: Ignored env SHELL
debug3: Ignored env USER
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env PATH
debug3: Ignored env DESKTOP_SESSION
debug3: Ignored env _
debug3: Ignored env GDM_XSERVER_LOCATION
debug1: Sending env LC_COLLATE = C
debug2: channel 0: request env confirm 0
debug3: Ignored env PWD
debug3: Ignored env GDMSESSION
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LOGNAME
debug3: Ignored env DBUS_SESSION_BUS_ADDRESS
debug1: Sending env LC_CTYPE = en_GB.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env DISPLAY
debug3: Ignored env XAUTHORITY
debug3: Ignored env TERM
debug3: Ignored env WINDOWID
debug3: Ignored env XTERM_VERSION
debug3: Ignored env XTERM_SHELL
debug3: Ignored env OLDPWD
debug3: Ignored env MANOPT
debug3: Ignored env EDITOR
debug3: Ignored env VISUAL
debug3: Ignored env CVS_RSH
debug3: Ignored env RSYNC_RSH
debug3: Ignored env JAVA_HOME
debug3: Ignored env IRCNICK
debug3: Ignored env IRCNAME
debug3: Ignored env IRCUMODE
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debu...

Read more...

Revision history for this message
In , Matt Taggart (taggart) wrote : workaround

Here's a workaround for #343896:

------- Forwarded Message

From: DELETED
Dave
Sent: Thu 1/26/2006 7:51 AM
To: BALETED
Subject: RE: ssh error dispatch_protocol_error: type 100 seq 8 when
accessing iLO

We had a similar issue and oddly enough changing our ssh config file to
turn ForwardAgent off fixed it:

1) grep ForwardAgent ~/.ssh/iLO-config
ForwardAgent no

- -----Original Message-----
Subject: ssh error dispatch_protocol_error: type 100 seq 8 when
accessing iLO

Hello,

I've been having this error message for a while when trying to access
some iLO I/F using ssh from Debian (or Ubuntu) :

$ ssh Administrator@{iLO Address}
Administrator@{iLO Address}'s password:
dispatch_protocol_error: type 100 seq 8
buffer_get_ret: trying to get more bytes 4 than in buffer 0
buffer_get_int: buffer error

I tried to google the msg and found that the guys @Debian are having the
same problem

Bug#343896: no longer works with HP iLO :
http://lists.debian.org/debian-ssh/2005/12/msg00025.html

I don't get that problem when trying it from RHEL3 or AS2.1 (don't have
a RHEL4 handy to test). Anyone have an idea on a fix ? Should I wave at
the Debian guys on the list and offer to work on this ?

------- End of Forwarded Message

I don't know if/when it is/will be fixed in the iLO firmware. If you are
reading this and running the latest firmare for the iLO in your system,
please report the following,

1) your hardware model
2) your iLO firmware version
3) the version of ssh you are using
4) if you are seeing the problem or not

Hopefully we can determine when it is fixed and can tell people what they
need to do to fix it on their systems.

Thanks,

--
Matt Taggart
<email address hidden>

Revision history for this message
Piers Cornwell (piers-gnome) wrote :

Binary package hint: openssh-client

When trying to connect via SSH to iLO (lights out management) on Hewlett Packard Proliant servers, the SSH in Ubuntu Dapper gives the following error after authentication:

dispatch_protocol_error: type 100 seq 7
buffer_get_ret: trying to get more bytes 4 than in buffer 0
buffer_get_int: buffer error

Doing "unset LANG" allows the login to work fine.

The full "ssh -v" output is:

$ ssh -v servername -l root
OpenSSH_4.2p1 Debian-7ubuntu3, OpenSSL 0.9.8a 11 Oct 2005
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to servername [168.192.63.44] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version mpSSH_0.0.1
debug1: no match: mpSSH_0.0.1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host 'servername' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:245
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: password,publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/identity
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Trying private key: /home/user/.ssh/id_dsa
debug1: Next authentication method: password
root@servername's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_GB.UTF-8
dispatch_protocol_error: type 100 seq 7
buffer_get_ret: trying to get more bytes 4 than in buffer 0
buffer_get_int: buffer error

Revision history for this message
In , Guillaume Tamboise (guillaume-patoche) wrote : Bug #343896: no longer works with HP iLO

It seems that the HP iLO does not like two things:
- attempts to set remote environment variables
- forward agent

So: if SendEnv is commented out in /etc/ssh/ssh_config, and ForwardAgent
set to "no", then ssh to an iLO port works just fine.

Unfortunately, I have not found any way to "unset" SendEnv on a per host
basis. Perhaps the Debian default of setting SendEnv in
/etc/ssh/ssh_config should be revisited?

From the man page:

SendEnv
[...]
Note that environment passing is only supported for protocol 2, the
server must also support it, and the server must be configured to accept
these environment variables.

Regards,

Guillaume Tamboise

Revision history for this message
In , Siim Põder (windo-p6drad-teel) wrote : same problem

Yo!

ILO Firmware:
    version=A05
    date=03/01/2006

The problem occured like before, when I started agent forwarding to the
host connects failed from.

Another workaround seems to be adding -o "PreferredAuthentication
password" to the command line/host config.

Revision history for this message
In , Matt Taggart (taggart) wrote : ilo ssh bug fixed

The bug in HP's integrated Lights Out 2 (iLO2) that was causing problems when
connecting with openssh has been fixed in the iLO2 firmware.

It was fixed in iLO2 firmware version 1.24 released on 27 Oct 2006.

As of 16 Apr 2007 (when I'm writing this) the latest version of iLO2
  firmware is 1.29, released on 20 Mar 2007. Here is the URL

http://h18023.www1.hp.com/support/files/server/us/download/26771.html

and the changelog

http://h18023.www1.hp.com/support/files/server/us/revision/9270.html

The latest "Firmware Update CD" (version 7.70, 1 Feb 2007) contains version
1.26 of the iLO2 firmware, which is new enough to fix the openssh problem, but
not the latest version. Here's the URL

http://h18023.www1.hp.com/support/files/server/us/download/26620.html

and the changelog

http://h18023.www1.hp.com/support/files/server/us/revision/9014.html

The Firmware Update CD is a pretty convienent way to upgrade all the firmwares
on the system at once (but requires console access). I expect future versions
of the Firmware Update CD will probably include the latest iLO2 update, but
depending on your equipment and usage, maybe this version that fixes the
openssh bug is enough and convienent.

--
Matt Taggart
<email address hidden>

Revision history for this message
Peter Lewis (pllewis72) wrote :

There is a known bug in ILO with forwarding keys. The easiest way is to us the -a option.

ssh -al Administrator mach-ilo or
ssh -a Administrator@mac-ilo

Pete

Revision history for this message
In , Colin Watson (cjwatson) wrote : Re: Bug#343896: ilo ssh bug fixed

On Mon, Apr 16, 2007 at 06:23:22PM -0700, Matt Taggart wrote:
> The bug in HP's integrated Lights Out 2 (iLO2) that was causing problems when
> connecting with openssh has been fixed in the iLO2 firmware.

This is good to hear. Thanks.

I just got James Troup to test this, and found that it advertises:

  debug1: Remote protocol version 2.0, remote software version mpSSH_0.0.1

In other words, *exactly the same version string* as the broken version.
What possessed HP to fix this bug but not change the version, so that it
is now impossible for OpenSSH to work around the broken versions in the
usual way?

Any chance you could raise an internal bug to get the version changed in
the next firmware revision?

Cheers,

--
Colin Watson [<email address hidden>]

Revision history for this message
Colin Watson (cjwatson) wrote :

See the linked Debian bug, in which it's noted that a newer revision of the iLO2 firmware fixes this bug. It would still be nice for OpenSSH to work around this when talking to the broken version, so I'm leaving this bug open.

Changed in openssh:
status: New → Triaged
Revision history for this message
In , Matt Taggart (taggart) wrote :

Colin Watson writes...

> Any chance you could raise an internal bug to get the version changed in
> the next firmware revision?

Thanks for the suggestion.

I sent it to the iLO2 Product Manager who forwarded it to the developer who
owns the iLO2 ssh, to be fixed in a future version. I will let you know
when the fix goes in a release.

--
Matt Taggart
<email address hidden>

Revision history for this message
In , Colin Watson (cjwatson) wrote :

On Tue, Jul 17, 2007 at 03:28:36PM -0700, Matt Taggart wrote:
> I sent it to the iLO2 Product Manager who forwarded it to the developer who
> owns the iLO2 ssh, to be fixed in a future version. I will let you know
> when the fix goes in a release.

Much appreciated.

--
Colin Watson [<email address hidden>]

Bug Watch Updater (bug-watch-updater)
Changed in openssh:
status: Unknown → New
Revision history for this message
Riskable (riskable) wrote :

While the latest iLO2 firmware fixes this problem the latest iLO (version 1) firmware does not (1.91). You still must "unset LANG" in order to connect to version 1 iLOs.

Revision history for this message
Mark Favas (mark-favas) wrote :

The problem is also present in Ubuntu 7.10, ssh version OpenSSH_4.6p1 Debian-5build1. The above suggestion of using "ssh -a" does not work for me (and "ForwardAgent" is set to "no" anyway in ssh_conf). Either doing "unset LANG" or editing /etc/ssh/ssh_config and commenting out the "SendEnv" line does work.

Revision history for this message
caba (dani-caba) wrote :

I have exactly the same problem... but it seems the problem is on the ssh server side (HP protocol implementation doesnt support sending this data).

Revision history for this message
In , Colin Watson (cjwatson) wrote : reassign important bugs away from transitional ssh package

reassign 183659 openssh-client
reassign 187558 openssh-server
reassign 195716 openssh-server
reassign 240506 openssh-server
reassign 242236 openssh-server
reassign 250311 openssh-client
reassign 314289 openssh-server
reassign 314596 openssh-client
reassign 341042 openssh-client
reassign 341767 openssh-server
reassign 341781 openssh-server
reassign 343896 openssh-client
reassign 414324 openssh-client

reassign 125171 openssh-server
reassign 151102 openssh-server
reassign 241496 openssh-server
reassign 286844 openssh-server

--
Colin Watson [<email address hidden>]

Revision history for this message
In , Matt Taggart (taggart) wrote : ssh iLO bug

Following up on #343896...

The advertised ssh version string is still the same in the most recent
version of firmware (v1.50 for ilo2). I sent another ping to the people who
own it.

--
Matt Taggart
<email address hidden>

Revision history for this message
Robert Siimon (robert-siimon) wrote :

Hello,

in ILO firmware version 1.92 it seems to be fixed. At least I upgraded some ILOs I have at hand and tried to ssh into them and it worked fine :)
Can anyone else confirm this?

Revision history for this message
In , Matt Taggart (taggart) wrote :

More follow up on #343896...

1.) I reported previously that the ilo/openssh bug was fixed for iLO2 in
iLO2 firmware version 1.24. I just discovered that for iLO1 it was fixed
in iLO1 firmware version 1.92, released 9 May 2008.

2.) As of 21 July 2008, the latest version of iLO2 is 1.50 and the latest
version of iLO1 is 1.92. Neither have adjusted their ssh banner strings to
a newer version that would allow ssh to work around the bug in older
versions. I will keep checking as new versions are released.

--
Matt Taggart
<email address hidden>

Revision history for this message
In , Matt Taggart (taggart) wrote : HP ilo ssh support

Hi,

This is a status update on #343896, regarding openssh-client support when
connecting to HP integrated Lights Out management processors.

As of October 1, 2008:

* The latest firmware version for ilo1 is 1.92 (9 May 2008) and it works
properly with recent versions of openssh-client. However it still uses the
"mpSSH_0.0.1" version string, so it's not possible for openssh to
differentiate. I don't know if they plan to fix this one, given it's age
they may no longer care (although there are still tons of them deployed).

* The latest firmware version for ilo2 is 1.61 (B) (26 Sep 2008) and it
works properly with recent versions of openssh-client. It also now uses a
new version string of "mpSSH_0.1.0" which may help in differentiating the
problem versions.

Thanks,

--
Matt Taggart
<email address hidden>

Revision history for this message
In , Micah Anderson (micah-debian) wrote : Doesn't work with lenny/sid version of ssh
Download full text (8.2 KiB)

As it turns out, using the 1.92 firmware for the ilo with the lenny/sid
version of openssh (1:5.1p1-3), doesn't work, please find my ssh -vvv
output below. I tried the various workarounds suggested here with no
luck:

OpenSSH_5.1p1 Debian-3, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /home/micah/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 203.234.253.169 [203.234.253.169] port 22.
debug1: Connection established.
debug1: identity file /home/micah/.ssh/identity type -1
debug3: Not a RSA1 key file /home/micah/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/micah/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/micah/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version mpSSH_0.0.1
debug1: no match: mpSSH_0.0.1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,<email address hidden>,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,<email address hidden>,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,<email address hidden>,hmac-ripemd160,<email address hidden>,hmac-sha1-96,hmac-md5-96
debug2: kex_...

Read more...

Revision history for this message
In , Matt Taggart (taggart) wrote : openssh-client not working with ilo1

I can repeat the bug micah reported, also using ilo1 firmware version 1.92
and openssh-client version 1:5.1p1-3.

--
Matt Taggart
<email address hidden>

Revision history for this message
In , Paul Wise (Debian) (pabs) wrote : found 343896 in 1:4.2p1-5

found 343896 1:4.2p1-5

Revision history for this message
In , Paul Wise (Debian) (pabs) wrote : found 343896 in 1:5.1p1-3

found 343896 1:5.1p1-3

Revision history for this message
In , mimo (mimo-restoel) wrote : Workaround

This works for me on etch
unset LANG ; ssh -o ForwardAgent=no user@box

ii openssh-server 4.3p2-9etch3 Secure
shell server, an rshd replacement

mimo

Revision history for this message
pikapika (pikapika-8-0) wrote :
Download full text (4.5 KiB)

hello
I still have connecting problems with ssh to any ilo firmware, since natty, it used to work before :

# ssh -vvv root@box
OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to box [x.x.x.x] port 22.
debug1: Connection established.
debug1: identity file /home/raphael/.ssh/id_rsa type -1
debug1: identity file /home/raphael/.ssh/id_rsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/raphael/.ssh/id_dsa" as a RSA1 public key
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/raphael/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: identity file /home/raphael/.ssh/id_dsa-cert type -1
debug1: identity file /home/raphael/.ssh/id_ecdsa type -1
debug1: identity file /home/raphael/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version mpSSH_0.0.1
debug1: no match: mpSSH_0.0.1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-1ubuntu3
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "box" from file "/home/raphael/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: 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: <email address hidden>,<email address hidden>,<email address hidden>,<email address hidden>,<email address hidden>,<email address hidden>,<email address hidden>,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,<email address hidden>
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfo...

Read more...

Revision history for this message
rick beldin (rick-beldin) wrote :

Workarounds from:

http://lists.mindrot.org/pipermail/openssh-unix-dev/2011-May.txt

work for me to a variety of HP ILO devices from Natty:

In .ssh/config:

Host ilo1 ilo2 omfgilo ...
 KexAlgorithms diffie-hellman-group1-sha1
 HostkeyAlgorithms ssh-rsa

OR

ssh -oHostKeyAlgorithms=ssh-rsa ilo

Where ilo is the hostname of the ilo device.

Revision history for this message
pikapika (pikapika-8-0) wrote :

Thanks Rick, it works perfectly

Bug Watch Updater (bug-watch-updater)
Changed in openssh (Debian):
status: New → Fix Released
Revision history for this message
Benjamin Drung (bdrung) wrote :

Following https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343896#131 and mark this bug as Won't Fix.

Changed in openssh (Ubuntu):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.