Why SSH Keys?

Note: To make sure your connection to the Genesis Cloud instance is secure, two modes of authentication for SSH are available: 1) SSH Public/Private Key pair 2) Password.

SSH is a security protocol used to protect your data with a private and a public key. Your private key is yours alone and in contrast to using a password doesn't have to be stored on the server to authenticate into. It is safer and when set up properly a as quick and convenient as using password to access your instances. In this article you will learn about both options.

SSH Key-pair (Recommended)

Under "Authentication" select "SSH Key"

               Under "Authentication" select "SSH Key"

This is the preferred method because it is significantly more secure and once set up even less of a hassle to use. The connection is established using a public and a private key. 

To generate SSH Keys and access instance on Linux or macOS: 

On your local machine open a terminal and execute 'ssh-keygen' command. To protect your keys you can enter a passphrase that will be used to encrypt the communication. You can also leave the prompt for a passphrase empty. Store the key in the default location. 

Retrieve the public key using:

cat ~/.ssh/id_rsa.pub

Upload your public key using the 'Add New Key' button under 'Keys and Tokens' in 'Account' section. Paste the complete key and add a fitting name. In the field "Public Key" insert your public key as raw text inputIn the field "Public Key" insert your public key as raw text input

Once this authentication is set up, you can easily access every new instance that you create by executing 'ssh ubuntu@public_ipv4_address_of_the_instance' in the terminal of your OS.

To generate SSH Keys and access instance on Windows: 

Password (Intended for testing)

Under "Authentication" select "Password"

Under "Authentication" select "Password" 

Alternatively, you can also set up your instance access using a password for the ubuntu user. This requires you to enter this password every time you want to access the instance. 

Passwords are considered less secure than an SSH Key pair given that a weak password can be brute-forced (that means just testing all combinations or the most common password patterns). As SSH connections are open to the Internet they are routinely attacked by automatic botnets or bad actors. Cracking even 7 letter passwords can take as little as a few seconds when using a well-populated wordlist of typical password patterns e.g. password1234. 

To ensure your instance's security if you still chose to set up a password we autogenerate a password for you in our web application and enforce rules for password requirements when using the API. 

Important: For your own security, the auto-generated password will only be shown once, so make sure to store it in a secure location like a password manager. We don't provide a password reset mechanism at this point.

Common Problems

ECDSA Key being rejected

When connecting to an instance for the first time a warning appears. 

Sample output:

$ ssh ubuntu@
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
Please contact your system administrator.
Add correct host key in /home/gc/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/gc/.ssh/known_hosts:4
remove with:
ssh-keygen -f "/home/gc/.ssh/known_hosts" -R ""
ECDSA host key for has changed and you have requested strict checking.
Host key verification failed.

To make sure that nobody is listening in on the connection between you and your instance your computer keeps track of what is known as the ECDSA key by a remote host. Think of it as a fingerprint that identifies the remote host. If you would be attacked by a man in the middle attack, the attacker would not be able to imitate this fingerprint. 

This warning is telling you that the fingerprint associated with that IP has changed and so it suspects something nasty is going on.

If this happens when you connect to an instance for the first time, what is more probable is that you created a new instance that has the same IP than an instance that you used before, but you don't have running anymore. 

This might happen because Genesis Cloud regularly reassigns IPs to new instances if the old one has been deleted. Your machine correctly recognizes that the underlying fingerprint has changed, but that is to be expected and not a sign of somebody actually attacking your connection. Without compromising on your security, there is really no way around this warning other than following what it tells you to do, which is to remove the fingerprint from the known hosts and try again.

Password prompt appears

A password prompt appears even though you did not choose to authenticate via password. 

Sample output:

$ ssh ubuntu@
The authenticity of host ' (' can't be established.
ECDSA key fingerprint is SHA256:s4IcxkBCy13S6O8N1nppCAX4a9ZTC0v17GXr5OFSKeE.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (ECDSA) to the list of known hosts.
ubuntu@'s password:

There are two possible reasons for this. One is that you selected to perform password authentication accidentally. Beware that at this time you can select either password authentication or key-pair authentication, but not both. 

If you selected instance access via SSH Key but still are prompted for a password there are a few things that can go wrong with the key authentication. 

  • Is the private SSH Key on the device from which you try to access your Genesis Cloud instance?

  • What are the permissions of your ssh folder and the private key file?

  • If you did not store private SSH Key in the default location you might need to specify it using  

ssh -i <PATH-TO-KEY> ubuntu@

Instance is unresponsive even though it has just turned active

Starting the SSH server on the instance takes a little time to become available even though the instance state has already turned to active. 

If you took enough time to find this answer it should already be fine. Maybe just check again? Can you ping the instance? 

If the problem persists, please reach out to our support. 

Key file has the wrong permissions

SSH refuses to connect because your key file has the wrong permission settings.

$ ssh -i test/id_rsa ubuntu@
Permissions 0664 for 'test/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "test/id_rsa": bad permissions
ubuntu@'s password:

Here SSH is concerned that other users also working on your local machine are able to view your key file. If you want to be sure that this problem is fixed, generate a new key and update all the places where you uploaded your old one. 

If you are sure that no one else is able to see your key files (for example if you are the only user on your machine) you can fix this issue by modifying the permission settings of your private key file.

$ chmod 600 test/id_rsa 

Connection timed out

If your SSH connection lays idle for a long time it might time out. This will look something like this:

packet_write_wait: Connection to port 22: Broken pipe

This can be easily fixed by just reconnecting.