VMware Cloud Community
EborComputing
Contributor
Contributor

Cannot SSH into ESXi 4.1

Hi All,

Recently,  we can no longer ssh into our ESXi 4.1 box. vSphere into it is OK and all the VMs are running fine.

Using putty to ssh into the ESXi 4.1 exits straight away with "Server unexpectedly closed network connection"

I have created a temporary symbolic link to dropbearmulti to use as an ssh client on the box itself via TSM and I am getting the same result.

The only error we get in /var/log/messages is:

dropbear[######]: premature exit: bad buf_getptr

This happened after adding ssh keys. These keys have since been removed to no effect.

We have tried to disable remote SSH and TSM and restarted management network and then enabled TSM and remote SSH and restarted the management network to no effect.

I've done some search but all the articles are talking about ESX 4.1 and to check the sshd_config file etc which does not exist in ESXi 4.1.

All help much appreciated,

Vlad

Tags (3)
Reply
0 Kudos
15 Replies
beckham007fifa

EborComputing wrote:

Hi All,

Recently,  we can no longer ssh into our ESXi 4.1 box. vSphere into it is OK and all the VMs are running fine.

Using putty to ssh into the ESXi 4.1 exits straight away with "Server unexpectedly closed network connection"

I have created a temporary symbolic link to dropbearmulti to use as an ssh client on the box itself via TSM and I am getting the same result.

The only error we get in /var/log/messages is:

dropbear[######]: premature exit: bad buf_getptr

This happened after adding ssh keys. These keys have since been removed to no effect.

We have tried to disable remote SSH and TSM and restarted management network and then enabled TSM and remote SSH and restarted the management network to no effect.

I've done some search but all the articles are talking about ESX 4.1 and to check the sshd_config file etc which does not exist in ESXi 4.1.

All help much appreciated,

Vlad

no sshd_config file in esxi. It uses dropbear ssh. I would say check for the ports, Since there is no firewall on esxi you have to check from network end is there any fw coming.

Also are you using root user or non root user?

Regards, ABFS
Reply
0 Kudos
EborComputing
Contributor
Contributor

AB wrote:

no sshd_config file in esxi. It uses dropbear ssh. I would say check for the ports, Since there is no firewall on esxi you have to check from network end is there any fw coming.

Also are you using root user or non root user?

Hi AB,

Thanks for the quick reply. By fw coming, you mean incoming firewall? We use root. There are no other non-default users.

Regards,

Vlad

Reply
0 Kudos
beckham007fifa

EborComputing wrote:

Thanks for the quick reply. By fw coming, you mean incoming firewall? We use root. There are no other non-default users.

Regards,

Vlad

YES

Regards, ABFS
Reply
0 Kudos
EborComputing
Contributor
Contributor

We have updated our ESXi 4.1 to update 2 and restarted the host and we still cannot SSH into it.

I have tried to ssh to it from another linux box with -vvvv and the following is the output:

[root@linux_host:~]# ssh -vvvv testesxi1
OpenSSH_5.6p1, OpenSSL 1.0.0j-fips 10 May 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to testesxi1 [xxx.yyy.zzz.aaa] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug3: Not a RSA1 key file /root/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
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
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
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
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 /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
ssh_exchange_identification: Connection closed by remote host
[root@linux_host:~]#

I have looked at inetd.conf and the file seems OK, no -w or -g for the SSH line. Nothing in the /etc/pam.d directory was modified and /etc/security/login.map appears to be ok as well.

We are genuinely stumped. It is not allowing password authentication at all.

Reply
0 Kudos
A25Simon
Contributor
Contributor

Check if the SSH daemon is started via the Configuration->Security Profile-> Start SSH ……….

Reply
0 Kudos
iw123
Commander
Commander

Have you tried creating another user with root privileges and logging in via SSH as that user?

This will help determine whether the issue is with the root users ssh keys.

*Please, don't forget the awarding points for "helpful" and/or "correct" answers
Reply
0 Kudos
beckham007fifa

did you take away # from inetd.conf file? also did you change the 4th field value to 100 from 0 in /etc/shadow for the user account which you have created.

Also make sure you have /home/xyz created for the user.

Regards, ABFS
Reply
0 Kudos
EborComputing
Contributor
Contributor

Hi All,

Thanks for the replies,

I have created another user with root permissions, created home dir and chmoded and chowned it accordingly. Modified the passwd file to specified /bin/ash and am unable to ssh as that user.

However, I have not touched the shadow file, esp the 4th parameter.

Will try that next.

Regards,

Vlad

Edit:

Have modified the fourth field to 100 with no effect.

I have created a dropbear server softlink to dropbearmulti named dropbear and tried to run it with -E -i -F commands and it just returns immediately with:

dropbear[######]: premature exit: bad buf_getptr

For obvious reasons, scp also does not work.

Reply
0 Kudos
beckham007fifa

i have tried it many time and it worked, I would tell you to have a new user and do the settings as i am writing here,

[ -d /home ] || mkdir /home
NEW_USER=jdoe
USER_COMMENT=’John Doe’
useradd -d /home/$NEW_USER -c “$USER_COMMENT” -s /bin/ash -n -P $NEW_USER


Alternatively, you can avoid the “-P” command and copy the password hash
from the “/etc/shadow” file from another ESXi or Linux server.
If the user already exists
Change the user shell to “/bin/ash”


Just modify the “/etc/passwd” file to reflect the change:
~ # grep jdoe /etc/passwd
jdoe:x:500:0:John Doe:/home/jdoe:/bin/ash
~ #
Create homedir


~ # mkdir -p /home/$NEW_USER
~ # chmod 700 /home/$NEW_USER
~ # chown -R $NEW_USER:users /home/$NEW_USER
Prevent ssh login as root
Add the “-w” option to dropbermulti


dropbermulti is the SSH binary in ESXi. The ssh lines of the file
“/etc/inetd.conf” should look like this:


ssh      stream   tcp   nowait   root   /sbin/dropbearmulti   dropbear +
+min=0,swap,group=shell -w -i -K60
ssh      stream   tcp6  nowait   root   /sbin/dropbearmulti   dropbear +
+min=0,swap,group=shell -w -i -K60
Reload inetd configuration
~ # kill -HUP `cat /var/run/inetd.pid

~ # su -

Regards, ABFS
Reply
0 Kudos
EborComputing
Contributor
Contributor

We gave up in the end and installed v5.

It looked like dropbear was not able to start for some reason.

Reply
0 Kudos
beth22
Enthusiast
Enthusiast

This message 'ssh_exchange_identification: Connection closed by remote host' comes when:

1 - Host denies your peer like implementing DenyHosts (not this case)

2 - There is a problem with ssh keys

So please try backup your key which locate at /root/.ssh/id_rsa and remove it.

After that, try to connect to your ESXi host again.

Reply
0 Kudos
beckham007fifa

v5 is not having dropbear, it uses openssl and openssh

Regards, ABFS
Reply
0 Kudos
EborComputing
Contributor
Contributor

Hi All,

Beth22, we have removed all our keys. It was just not allowing password authentication at all.

AB, I know V5 uses openssh. In my reply to Beth22, I was stating that we gave up trying to solve the issue and installed V5. Was just summarising the fact that the issue could be a corrupt dropbear.

Reply
0 Kudos
beth22
Enthusiast
Enthusiast

:smileygrin: but its so sad that there is no log output after removing your SSH key.

Reply
0 Kudos
treovot
Contributor
Contributor

May be you not enable ssh,user console and enable ssh,and stop firewall,

Message was edited by: a.p. - Removed promotional link

Reply
0 Kudos