DL380 G7: Not able to access ILO on DL380 via ssh from a client

Question

I have problem where I can't access my ILO(ssh to ILO IP) thru client which is in different network.I am able to ping ILO IP thru this clinet but ssh access is not possible.

Is it possible to have ssh to ILO IP from a client which is in different network? FYI, from the same client I can do ssh to server application IP but ssh to this server ILO IP is not possible.

Kindly help?

Some more info added: ILO IP address is 10.247.172.70 and its VLAN is different than Client VLAN.

Client IP address is 10.247.167.80.

ping to ILO IP from this client is possible but not ssh.

I can do ssh to ILO IP if I try to do it from the server(hostname:node1) having ILO port or from the other node of this cluster itself,So ssh login is enabled.

[root@client ~]$ssh -v 10.247.173.70 OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to 10.247.173.70 [10.247.173.70] port 22.

[root@client ~]$ping 10.247.173.70 PING 10.247.173.70 (10.247.173.70) 56(84) bytes of data. 64 bytes from 10.247.173.70: icmp_seq=1 ttl=254 time=0.283 ms 64 bytes from 10.247.173.70: icmp_seq=2 ttl=254 time=0.344 ms 64 bytes from 10.247.173.70: icmp_seq=3 ttl=254 time=0.324 ms 64 bytes from 10.247.173.70: icmp_seq=4 ttl=254 time=0.367 ms

More Update

There is no firewall in between this client and server.But both client and server are in

different VLAN.But at the same time I can do ssh to server IP from this client and ssh to

server ILO is not possible.So I doubt different vlan has any role in this.Also client is

solaris and nmap is not installed.so do u know any equivalent of nmap on solaris.I tried running netstat cmd from client

root@client> # netstat -a -f inet | grep LISTEN

 *.11000              *.*                0      0 49152      0 LISTEN

  *.sunrpc             *.*                0      0 49152      0 LISTEN

  *.32771              *.*                0      0 49152      0 LISTEN
  *.32772              *.*                0      0 49152      0 LISTEN
  *.lockd              *.*                0      0 49152      0 LISTEN
  *.32773              *.*                0      0 49152      0 LISTEN
  *.fs                 *.*                0      0 49152      0 LISTEN
  *.32774              *.*                0      0 49152      0 LISTEN
  *.servicetag         *.*                0      0 49152      0 LISTEN
  *.finger             *.*                0      0 49152      0 LISTEN
  *.login              *.*                0      0 49152      0 LISTEN
  *.shell              *.*                0      0 49152      0 LISTEN
  *.ssh                *.*                0      0 49152      0 LISTEN

localhost.6788 . 0 0 49152 0 LISTEN localhost.6789 . 0 0 49152 0 LISTEN localhost.32786 . 0 0 49152 0 LISTEN *.telnet . 0 0 49152 0 LISTEN *.ftp . 0 0 49152 0 LISTEN *.44026 . 0 0 49152 0 LISTEN *.nfsd . 0 0 49152 0 LISTEN

see below ssh cmd to server IP is successful but ssh to server ILO IP is not succcessful

root@inst2is01 # ssh -v node1

Sun_SSH_1.1.3, SSH protocols 1.5/2.0, OpenSSL 0x0090704f

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Rhosts Authentication disabled, originating port will not be trusted.

debug1: ssh_connect: needpriv 0

debug1: Connecting to cmd3n1 [10.247.172.11] port 22.

debug1: Connection established.

debug1: identity file /root/.ssh/identity type -1

debug1: identity file /root/.ssh/id_rsa type -1

debug1: identity file /root/.ssh/id_dsa type 2

debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3

debug1: match: OpenSSH_4.3 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-Sun_SSH_1.1.3

debug1: use_engine is 'yes'

debug1: pkcs11 engine initialized, now setting it as default for RSA, DSA, and symmetric ciphers

debug1: pkcs11 engine initialization complete

debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible

Unknown code 0

)

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: Peer sent proposed langtags, ctos:

debug1: Peer sent proposed langtags, stoc:

debug1: We proposed langtags, ctos: i-default

debug1: We proposed langtags, stoc: i-default

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug1: dh_gen_key: priv key bits set: 128/256

debug1: bits set: 1051/2048

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Host 'cmd3n1' is known and matches the RSA host key.

debug1: Found key in /root/.ssh/known_hosts:61

debug1: bits set: 987/2048

debug1: ssh_rsa_verify: signature correct

debug1: newkeys: mode 1

debug1: set_newkeys: setting new keys for 'out' mode

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: newkeys: mode 0

debug1: set_newkeys: setting new keys for 'in' mode

debug1: SSH2_MSG_NEWKEYS received

debug1: done: ssh_kex2.

debug1: send SSH2_MSG_SERVICE_REQUEST

debug1: got SSH2_MSG_SERVICE_ACCEPT

debug1: Authentications that can continue: publickey,gssapi-with-mic,password

debug1: Next authentication method: gssapi-with-mic

debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible

Unknown code 0

)

debug1: Next authentication method: publickey

debug1: Trying private key: /root/.ssh/identity

debug1: Trying private key: /root/.ssh/id_rsa

debug1: Trying public key: /root/.ssh/id_dsa

debug1: Authentications that can continue: publickey,gssapi-with-mic,password

debug1: Next authentication method: password

root@cmd3n1's password:

Now ssh to server ILO IP (10.247.173.70) from client

[root@client ~]$ssh -v 10.247.173.70

OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Applying options for *

debug1: Connecting to 10.247.173.70 [10.247.173.70] port 22.

Edit - nmap output:

[root@client ~]#nmap -p22,80,443 10.247.172.70 
Starting Nmap 4.11 ( insecure.org/nmap ) at 2012-04-16 14:12 IST mass_dns: 
Interesting ports on 10.247.172.70: 
PORT STATE SERVICE 
22/tcp filtered ssh 
80/tcp filtered http 
443/tcp filtered https

Solution

From your client, run a quick scan to see which ILO ports are open. Something like nmap -p22,80,443 10.247.172.70 should show the status of the common ILO ports. You'd minimally need port 22 to respond as "open". Ports 80 and 443 are for web management.

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2012-04-12 10:09 CDT
Interesting ports on testilo.abc.net (172.16.16.23):
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https
MAC Address: 1C:C1:DE:78:04:F8 (Unknown)

Nmap finished: 1 IP address (1 host up) scanned in 0.187 seconds

If the nmap output shows the ports as filtered, talk to whomever manages the firewall/routing between subnets and indicate that you need inbound SSH (tcp port 22) open to the ILO.

Comments

[Tom O'Connor]

Gonna need more to go on than that.

[Tom O'Connor]

What are the IP addresses of the ILO and the client, and their respective subnet masks. What about any firewalls in place? Different VLANs?

[Chopper3]

The iLO bit is a red-herring here, you have a simple routing/firewall problem - as long as you've enabled SSH login on the iLO then it's irrelevant what you're trying to talk to.

[user117140]

ILO IP address is 10.247.172.70 and its VLAN is different than Client VLAN.Client IP address is 10.247.167.80.I can do ssh to ILO if I try to do it from the server or from the other node of this cluster itself,So ssh login is enabled.

[Chopper3]

Right you've got a routing or firewall problem - simple as that. Look at what's inbetween the client and server and speak to the people who those those things.

[user117140]

There is no firewall in between this client and server.But both client asd server are in different VLAN.But at the same time I can do ssh to server IP from this client and ssh to server ILO is not possible.So I doubt different vlan has any role in this

[user117140]

pls see more update in my original post

[user117140]

anyone can help?

[ewwhite]

I'm sorry nmap is not installed on your client. You can try telnet 10.247.172.70 22 and telnet 10.247.172.70 80 to see if you get any response from the ILO.

[user117140]

namp is now installed and i can see port 22 opened [root@client ~]#nmap -p22,80,443 10.247.172.70 Starting Nmap 4.11 ( insecure.org/nmap ) at 2012-04-16 14:12 IST mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns_servers Interesting ports on 10.247.172.70: PORT STATE SERVICE 22/tcp filtered ssh 80/tcp filtered http 443/tcp filtered https

[ewwhite]

I added the nmap output to your original post. The "filtered" means that the ports are not open or available. You're being blocked by an access policy either via a firewall or router/switch. Talk to your networking staff.

[user117140]

it seems switch is blocking this ssh access.How do i check this and what changes required on switch to unblock ssh access?

[ewwhite]

Talk to whoever manages the network.