Frequently Asked Question

There may be several issues involved with not being able to connect to cloud VMs. A few of the most frequent ones are listed below:

Wrong key pair

Make sure you are using the right public key that was used when creating the cloud VM. You can check the key pair from your kaizen dashboard:

Compute –> Access and Security –> Key Pairs

You can compare the keys from the instance you are logging from your .ssh directory.

Incorrect Username

The root login is disabled on the cloud VMs. When you are trying to connect via ssh, make sure to use the correct usernames for your OS as listed below:

• CentOS: centos
• Ubuntu: ubuntu
• RHEL: cloud-user

e.g: ssh centos@123.45.67.89

If you fail to specify the user in the ssh command, it will try to log you in using whatever username you are logged in as on your local machine. Specify the user:

$ ssh -A ubuntu@your_vm's_IP

or

$ ssh -A -l ubuntu your_vm's_IP

Incorrectly Assigned Floating IP

For ssh access from the public Internet, you need a Floating IP associated with the machine.

Incorrectly configured Security Groups

Make sure to add the default security group while creating the VM.

For a VM with a floating IP, you will also need to open port 22 for SSH access. Optionally, you may also enable ICMP response so that the IP will respond to pings.

The rules below enable ssh, HTTP, https, ICMP(ping) connectivity from the public internet. We recommend you only

ALLOW IPv4 22/tcp from 0.0.0.0/0
ALLOW IPv6 to::/0
ALLOW IPv4 to 0.0.0.0/0
ALLOW IPv4 8080/tcp from 0.0.0.0/0
ALLOW IPv4 443/tcp from 0.0.0.0/0
ALLOW IPv4 80/tcp from 0.0.0.0/0
ALLOW IPv4 ICMP from 0.0.0.0/0

Key not on remote host

Did you just launch a VM, without selecting your key in the ‘Access and Security’ tab? Unless you used a teammate’s key and they can help you out, you will have to terminate that VM and start again, making sure to add your key this time.

If a VM was spawned using your teammate’s key, you can have them add your public key to .ssh/authorized_keys on the VM before you will be able to log in. Give them a file containing your public key (this is ‘cloud_key.pub’ in the example) and have them perform the following steps:

$ scp cloud_key.pub user@your_vm's_IP

$ ssh user@your_vm's_IP

$ cat cloud_key.pub >> ~/.ssh/authorized_keys

(Make sure to use >> and not > or else you will overwrite the other key instead of just appending yours).

SSH File Permissions

OpenStack sets the permissions automatically when it launches a new VM, so if you are trying to log into a newly spawned VM, this isn’t the problem. However, if people have been editing .ssh/authorized keys, they might have accidentally changed something.

You need to make sure that the permissions on .ssh are 700, which looks like drwx------:

[user@myvm ~]$ ls -al | grep .ssh

drwx------ 16 user user 544 Feb 12 11:38 .ssh

and .ssh/authorized keys should be 600, which looks like -rw-------:

[user@myvm ~]$ ls -al .ssh/

-rw------- 1 user user 2.2K Feb 9 15:13 authorized_keys

Also make sure the owner of the file is the user you are trying to log in as, not root or some other user.

If you have root access to the VM, for example via the web console login, you can fix the file permissions using the chmod and chown commands:

# chmod 700 /home//.ssh

# chmod 600 /home//.ssh/authorized_keys

# chown : /home//.ssh/

# chown : /home//.ssh/authorized_keys