Cannot SSH to HP ilO4 after upgrade from 2.10 to 2.10

[cwstevens]

I understand from the title that this is more an issue with something that has changed with HPs iLO4 but I feel like a fix or workaround is more likely to come from the SecureCRT side. Here it is:

I have always been able to SSH into HP iLO 2/3/4 etc over the years but a recent change (updated iLO4 2.10 to 2.20) now has all attempts result in this response from the iLO:

The server has disconnected with an error.  Server message reads:
Disconnected by application.  Client Disconnect

I have enabled trace in SCRT and I receive this:

[LOCAL] : SSH2Core version 7.3.0.839 
[LOCAL] : Connecting to 10.1.1.239:22 ... 
[LOCAL] : Changing state from STATE_NOT_CONNECTED to STATE_EXPECT_KEX_INIT 
[LOCAL] : Using protocol SSH2 
[LOCAL] : RECV : Remote Identifier = 'SSH-2.0-mpSSH_0.2.1' 
[LOCAL] : CAP  : Remote can re-key 
[LOCAL] : CAP  : Remote sends language in password change requests 
[LOCAL] : CAP  : Remote sends algorithm name in PK_OK packets 
[LOCAL] : CAP  : Remote sends algorithm name in public key packets 
[LOCAL] : CAP  : Remote sends algorithm name in signatures 
[LOCAL] : CAP  : Remote sends error text in open failure packets 
[LOCAL] : CAP  : Remote sends name in service accept packets 
[LOCAL] : CAP  : Remote includes port number in x11 open packets 
[LOCAL] : CAP  : Remote uses 160 bit keys for SHA1 MAC 
[LOCAL] : CAP  : Remote supports new diffie-hellman group exchange messages 
[LOCAL] : CAP  : Remote correctly handles unknown SFTP extensions 
[LOCAL] : CAP  : Remote correctly encodes OID for gssapi 
[LOCAL] : CAP  : Remote correctly uses connected addresses in forwarded-tcpip requests 
[LOCAL] : CAP  : Remote can do SFTP version 4 
[LOCAL] : CAP  : Remote uses SHA1 hash in RSA signatures for x.509v3 
[LOCAL] : CAP  : Remote x.509v3 uses ASN.1 encoding for DSA signatures 
[LOCAL] : CAP  : Remote correctly handles zlib@openssh.com 
[LOCAL] : SEND : KEXINIT 
SecureCRT - Version 7.3.4 (x64 build 839)
[LOCAL] : RECV : Read kexinit 
[LOCAL] : Available Remote Kex Methods = diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 
[LOCAL] : Selected Kex Method = diffie-hellman-group14-sha1 
[LOCAL] : Available Remote Host Key Algos = ssh-rsa,ssh-dss 
[LOCAL] : Selected Host Key Algo = ssh-dss 
[LOCAL] : Available Remote Send Ciphers = aes256-cbc,aes128-cbc,3des-cbc 
[LOCAL] : Selected Send Cipher = aes256-cbc 
[LOCAL] : Available Remote Recv Ciphers = aes256-cbc,aes128-cbc,3des-cbc 
[LOCAL] : Selected Recv Cipher = aes256-cbc 
[LOCAL] : Available Remote Send Macs = hmac-sha1,hmac-md5 
[LOCAL] : Selected Send Mac = hmac-sha1 
[LOCAL] : Available Remote Recv Macs = hmac-sha1,hmac-md5 
[LOCAL] : Selected Recv Mac = hmac-sha1 
[LOCAL] : Available Remote Compressors = none 
[LOCAL] : Selected Compressor = none 
[LOCAL] : Available Remote Decompressors = none 
[LOCAL] : Selected Decompressor = none 
[LOCAL] : Changing state from STATE_EXPECT_KEX_INIT to STATE_KEY_EXCHANGE 
[LOCAL] : SEND : KEXDH_INIT 
[LOCAL] : Changing state from STATE_KEY_EXCHANGE to STATE_CLOSING 
[LOCAL] : RECV: Disconnect packet (reason: 11: Disconnected by application.  Client Disconnect ) 
[LOCAL] : Changing state from STATE_CLOSING to STATE_CLOSED 
[LOCAL] : Connected for 1 seconds, 905 bytes sent, 317 bytes received
 
[LOCAL] : Stream has closed [CLOSE_TYPE_NONSPECIFIC] : The server has disconnected with an error.  Server message reads: Disconnected by application.  Client Disconnect  

The server has disconnected with an error.  Server message reads:
Disconnected by application.  Client Disconnect

I can still SSH into the HP iLO if I first SSH into one of our Linux systems (Ubuntu 14.04.1 LTS).

 ssh -v administrator@10.1.1.237
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 10.1.1.237 [10.1.1.237] port 22.
debug1: Connection established.
debug1: identity file /home/username/.ssh/id_rsa type -1
debug1: identity file /home/username/.ssh/id_rsa-cert type -1
debug1: identity file /home/username/.ssh/id_dsa type -1
debug1: identity file /home/username/.ssh/id_dsa-cert type -1
debug1: identity file /home/username/.ssh/id_ecdsa type -1
debug1: identity file /home/username/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/username/.ssh/id_ed25519 type -1
debug1: identity file /home/username/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: Remote protocol version 2.0, remote software version mpSSH_0.2.1
debug1: no match: mpSSH_0.2.1
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: Server host key: RSA 70:2f:16:60:53:06:fa:95:29:0c:e0:a7:cc:a8:82:1b
debug1: Host '10.1.1.237' is known and matches the RSA host key.
debug1: Found key in /home/username/.ssh/known_hosts:94
debug1: ssh_rsa_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: password,publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/username/.ssh/id_rsa
debug1: Trying private key: /home/username/.ssh/id_dsa
debug1: Trying private key: /home/username/.ssh/id_ecdsa
debug1: Trying private key: /home/username/.ssh/id_ed25519
debug1: Next authentication method: password
administrator@10.1.1.237's password: 
debug1: Authentication succeeded (password).
Authenticated to 10.1.1.237 ([10.1.1.237]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
User:administrator logged-in to Server-Name -iLO.(10.1.1.237 / FE80::EEB1:D7FF:FE79:1426)

iLO 4 Advanced 2.20 at  May 20 2015
Server Name: 
Server Power: On

Based on customer feedback, we will be enhancing the SSH command line
interface in a future release of the iLO 4 firmware.  Our future CLI will
focus on increased usability and improved functionality.  This message is
to provide advance notice of the coming change.  Please see the iLO 4 
Release Notes on www.hp.com/go/iLO for additional information.


</>hpiLO->

Your help is appreciated. Thank you.

[cwstevens]

Woops, title is wrong. It was an upgrade from 2.10 to 2.20. Thank you.

[bgagnon]

Hi cwstevens,

In looking at the differences in the traces/logs, this seems that it may be the issue:

SecureCRT:
[LOCAL] : Available Remote Host Key Algos = ssh-rsa,ssh-dss
[LOCAL] : Selected Host Key Algo = ssh-dss

OpenSSH:
debug1: Server host key: RSA 70:2f:16:60:53:06:fa:95:29:0c:e0:a7:cc:a8:82:1b
debug1: Host '10.1.1.237' is known and matches the RSA host key.

When SecureCRT connects, the remote server seems to falsely advertise that it supports the DSA (ssh-dss) algorithm for host keys. In fact, the SSH protocol (RFC 4253) *requires* that ssh-dss be supported for host keys (see section 6.6). Therefore, we ask that you please report this issue also to the admin of the remote server.

You should be able to work around the issue by configuring SecureCRT to prefer RSA rather than DSA host keys. You will need to modify two session INI file options. If this is something you need for all future sessions, you can make the change to the Default.ini file.

Session INI files (and Default.ini) are stored in the Sessions subfolder of the configuration folder. The location of your installation's Configuration folder is found in the General / Configuration Paths category of SecureCRT's Global Options.

D:"Use Global Host Key Algorithms"=00000001

To:
D:"Use Global Host Key Algorithms"=00000000

And

S:"Host Key Algorithms"=ssh-dss,ssh-rsa,null,x509v3-sign-rsa,x509v3-sign-dss

To:
S:"Host Key Algorithms"=ssh-rsa,ssh-dss,null,x509v3-sign-rsa,x509v3-sign-dss

Note that the list of algorithms may differ from above. What is important is that it is changed so that ssh-rsa appears *first*.

To edit a session's INI file:

1. Close all instances of SecureCRT. If changes are made to the session's INI file while SecureCRT is running, the changes made will be undone when SecureCRT is restarted.
   
2. Edit the session's INI file (modify lines as shown above).
   
3. Save changes made to the session's INI file and start SecureCRT.

Note: If you use the /F command-line option in the target of the shortcut used to launch SecureCRT, then the path to the Config folder will be different than the path in step 2 above.

[cwstevens]

That worked! Thank you so much. This will allow me to continue working until HP releases a correction.

[mwhite]

Hi, I have the same problem my iLo4 is at v2.20 but I do not find the lines stated above ini files (global or session).
I do have an older SecureCRT if that makes a differance.
Version 6.7.5 (x64 build 411) - Official Release - April 19, 2012

D:"Use Global Host Key Algorithms
S:"Host Key Algorithms"=

In the session.ini or global ini files.
I tried adding them but still get the error.

The server has disconnected with an error. Server message reads:
Disconnected by application. Client Disconnect

Do they have to be in a certain place in the ini file.

Thanks.
Michael White

[rtb]

Hi Michael,

It does make a difference. The workaround that Brenda posted will not work in 6.7.

You might consider upgrading so that you can use the workaround that Brenda posted, and have access to all of the improvements that have been added to SecureCRT between 6.7 and 7.3. You can find upgrade pricing information at the following location:

https://www.vandyke.com/pricing/corp...des/index.html

Here is another workaround to the problem on the server that should work in 6.7:

https://forums.vandyke.com/showpost....37&postcount=7

[mwhite]

Thank you.
Yes the alternate workaround did work.