Ask Your Question

Can ping vm instance but can't ssh (ssh command halts, with no output)

asked 2014-05-25 16:52:33 -0500

siouffy gravatar image

updated 2014-05-25 18:49:06 -0500

Dear Community, I have installed a 3 node openstack cluster with Controller, Network and Compute nodes on Ubuntu 14.04 servers. Everything seems working properly and as expected, networking, internet ... everything.

I have this weird situation that I can't ssh a vm instance. I've added the allow TCP rule on port 22 (Ingress). I can't ssh neither from a node on external network (from which i can ping) or from any of the controller, compute and network nodes to the vm instance.

The problem also is that i get no responce, the terminal just halts (sounds like its waiting for something or so, but it waits forever) .. if anyone had this situation before please help. Or if anyone knows how I can debug that problem. I have no clue where is the ssh log.

thank you

Update: I was able to get the debug output from ssh on the external host.

OpenSSH_6.6, 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 [] port 22.
debug1: Connection established.
debug1: identity file /home/siouffy/.ssh/id_rsa type -1
debug1: identity file /home/siouffy/.ssh/id_rsa-cert type -1
debug1: identity file /home/siouffy/.ssh/id_dsa type -1
debug1: identity file /home/siouffy/.ssh/id_dsa-cert type -1
debug1: identity file /home/siouffy/.ssh/id_ecdsa type -1
debug1: identity file /home/siouffy/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/siouffy/.ssh/id_ed25519 type -1
debug1: identity file /home/siouffy/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6p1 Ubuntu-2ubuntu1
debug1: Remote protocol version 2.0, remote software version dropbear_2012.55
debug1: no match: dropbear_2012.55
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: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY

edit retag flag offensive close merge delete


Just commenting to say I'm seeing the exact same problem on my test setup. I'm running two lapttops, one with 2 virtualbox VM's for the controller & network node and the other running the compute services. Let me know if you figure it out. I'll do likewise when I get a chance to debug it.

pjriot gravatar imagepjriot ( 2014-06-04 07:43:29 -0500 )edit

6 answers

Sort by » oldest newest most voted

answered 2014-09-02 10:31:51 -0500

Snowball gravatar image

updated 2014-09-02 20:10:38 -0500

Try lowering the MTU. On CirrOS that would be

sudo ip link set eth0 mtu 1400

After you run that, try SSHing into the machine again. If it works, you can make it permanent by making the following changes (source):

In /etc/neutron/dhcp_agent.ini:

dnsmasq_config_file = /etc/neutron/dnsmasq-neutron.conf

In /etc/neutron/dnsmasq-neutron.conf:



killall dnsmasq
service neutron-dhcp-agent restart

Next time you boot up an instance other than CirrOS ≤0.3.21, the MTU should be set correctly and you should be able to SSH in. (To view the MTU, you can run ip link.)

1 CirrOS ≤0.3.2 doesn't respect the DHCP MTU option, so SSH will still be broken on CirrOS. More information here.

edit flag offensive delete link more

answered 2015-02-19 06:43:11 -0500

I think we should add two rules to ping and ssh an VM .

why should we add these rules because we can access the data in a secure way so that's why we have to add All ICMP and SSH rules through the horizon. so check the horizon did you add those rules or not.

edit flag offensive delete link more

answered 2014-05-26 02:18:37 -0500

updated 2014-05-26 03:06:06 -0500

Ensure you're using the correct use of ssh command, example:

ssh -i MyKey.pem ubuntu@

edit flag offensive delete link more


thanks. yea im sure im using the correct cmd bec. it worked on a prev. installation. did u look at the debug output?

siouffy gravatar imagesiouffy ( 2014-05-26 04:01:45 -0500 )edit

i believe the issue is with you instance did not generated the keys below correctly.

HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_ed25519_key

can you check your instance if have this key or not.? happened to me before.

senyapsudah gravatar imagesenyapsudah ( 2014-05-26 05:33:46 -0500 )edit

Thanks senyapsudah ... I have booted cirros instance (the only one I can log in into without ssh) ... in /etc/ i don't have a folder ssh .. but I have in /etc/dropbear drop_bear_dss_host_key & dropbear_rsa_host_key, Can you confirm there should be more keys in that folder (for cirros!) ... Thanks. Or should be there a separate ssh folder regardless the os type ?

siouffy gravatar imagesiouffy ( 2014-05-27 00:22:26 -0500 )edit

answered 2015-07-14 13:05:59 -0500

busyboy gravatar image

change the MTU size for your GRE tunnel'd setup. This should be there in the openstack docs.

edit flag offensive delete link more

answered 2015-07-14 11:47:48 -0500

Andris Lismanis gravatar image

As per snowball's comment - check MTU settings, either lower them on instances or up it on hypervisor if network equipment allows.


edit flag offensive delete link more

answered 2015-07-06 00:30:20 -0500

From your description, it looks like you are able to get packets back and forth on port 22. Which might lead to suspect the SSH client. Have a look at this (bug and workaround.)

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools



Asked: 2014-05-25 16:52:33 -0500

Seen: 9,043 times

Last updated: Jul 14 '15