Why SSH Keys?
To ensure your connection to the Genesis Cloud instance is secure, two modes of authentication are available for SSH: 1) SSH Public/Private Key pair 2) Password.
SSH is a secure protocol used to protect your data through the use of a private and public key pair. Unlike a password, your private key is not stored on the server, making it more secure. When properly set up, key-based authentication is both safer and as quick and convenient as using a password to access your instances. In this article, you will learn about both authentication options.
SSH Key-pair (Recommended)
Under "Authentication" select "SSH Key"
This method is preferred because it is significantly more secure and, once set up, even easier to use. The connection is established using a public and private key pair.
Generate SSH Key Pair
Run the following command in a terminal of your local machine to create an SSH key pair:
ssh-keygen |
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
The default location for SSH keys will be within the user's home directory, under the .ssh folder. Run the following command:
cat ~/.ssh/id_rsa.pub |
Upload Public Key to Console
To add a new SSH key, please follow these steps:
Open the console dashboard and click on 'Keys & Tokens' in the left sidebar.
In the 'SSH Keys' section, click on the 'Add new key' button located in the top-right corner of that section.
A new popup window will appear; here, you can enter your SSH Public Key, assign it a name, and then click on the 'Save' button to complete the process.
For more information on 'How to Upload SSH Public Keys' click here
Create an Instance Using the Public Key
Please visit the given link for more information on how to create an instance:
How to Create an Instance
Access the Instance
To access the created instance using your private key, open a terminal on your local system and use the following command:
ssh ubuntu@<public_ip_address> |
Replace <public_ip_address> with the public IP address of your instance.
If everything is set up correctly, you should now have access to your instance.
To Generate SSH Keys and Access Instance on Windows, Click here.
Password (Intended for testing)
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@194.61.20.69
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
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
SHA256:cRoUH04xQ2y5x2z1GyQmmE3BLqPMvelMaIj4h/L4Ci0.
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 "194.61.20.69"
ECDSA host key for 194.61.20.69 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@194.61.21.203
The authenticity of host '194.61.21.203 (194.61.21.203)' can't be established.
ECDSA key fingerprint is SHA256:s4IcxkBCy13S6O8N1nppCAX4a9ZTC0v17GXr5OFSKeE.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '194.61.21.203' (ECDSA) to the list of known hosts.
ubuntu@194.61.21.203'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@194.61.21.203
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@194.61.21.97
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
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@194.61.21.97'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 194.61.21.142 port 22: Broken pipe
This can be easily fixed by just reconnecting.