Connecting (SSH) to Linux instance in Cloud

After a Linux compute instance is created in Cloud (for example in GCP or OCI), you can connect it either using a web browser (SSH-in-browser) provided by the cloud console or using the cloud shell.

No matter which way you use, the GCP or OCI will generate key pairs and transfer the public key to the compute instance and put it in the file authorized_keys under the user’s home directory ~/.ssh/.

And when connecting within the cloud shell, make sure you specify the correct priviate key or you will get the error like “Permission denied (publickey)“.

joe_techlife_li@cloudshell:~/.ssh (alert-nimbus-348800)$ ssh -i /home/joe_techlife_li/.ssh/google_compute_engine 34.28.236.49
Linux instance-1 5.10.0-15-cloud-amd64 #1 SMP Debian 5.10.120-1 (2022-06-09) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Jun 15 01:23:49 2022 from 35.238.224.32
joe_techlife_li@instance-1:~$

So why using SSH Public Key authentication?

  1. Provides cryptographic strength that even extremely long passwords can not offer.
  2. Allows SSO single sign-on. Once a user log into a central admin station, he/she can manage other SSH servers without providing password further.
  3. Allows automation process possible because it enables passwordless login.

SSH public key authentication relies on asymmetric cryptographic algorithms that generate a pair of separate keys (a key pair), one “private” and the other “public“:

A public key that is copied to the SSH server(s). Anyone with a copy of the public key can encrypt data which can then only be read by the person who holds the corresponding private key. Once an SSH server receives a public key from a user and considers the key trustworthy, the server marks the key as authorized in its authorized_keys file (adding the public key in the file). Such keys are called authorized keys.

A private key that remains (only) with the user (the client side). The possession of this key is proof of the user’s identity. Only a user in possession of a private key that corresponds to the public key at the server will be able to authenticate successfully. The private keys need to be stored and handled carefully, and no copies of the private key should be distributed. The private keys used for user authentication are called identity keys.

Other than two ways mentioned above, you may want to use your favorite SSH client such as putty to connect to the compute instance. You can use ssh-keygen to generate the key pair. (Note, Windows 10 also has this tool installed by default). No matter where do you run ssh-keygen (on Windows or on the server itself), you need to copy the public key and add it into the authorized_keys which is located under the .ssh directory of the user’s home directory.

For example, I run the command on the server:

joe_techlife_li@instance-1:~$ ssh-keygen -t rsa -f ~/.ssh/my-ssh-key -C joe_techlife_li -b 2048
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/joe_techlife_li/.ssh/my-ssh-key
Your public key has been saved in /home/joe_techlife_li/.ssh/my-ssh-key.pub
The key fingerprint is:
SHA256:brLlAZhWAnjGZsxJq9umlQKTLuIBAaWsFYWj9tjymRw joe_techlife_li
The key's randomart image is:
+---[RSA 2048]----+
|.B=+.            |
|+.%+             |
|oBo.. .          |
|o*   =           |
|O + + . S        |
|+* E   o         |
|=oO + . =        |
|+=.=   * .       |
|..    . .        |
+----[SHA256]-----+

It generates two files under /home/joe_techlife_li/.ssh/

joe_techlife_li@instance-1:~/.ssh$ ls -lart my-ssh*
-rw-r--r-- 1 joe_techlife_li joe_techlife_li  397 Jun 14 21:10 my-ssh-key.pub
-rw------- 1 joe_techlife_li joe_techlife_li 1876 Jun 14 21:10 my-ssh-key

I then copy the public key contained in the file my-ssh-key.pub and put it into the file authorized_keys.

On my Windows box, I need to use PuTTYgen to convert the the private key in OpenSSH format to PuTTY Private Key (PPK) format:

  1. Create a file with the OpenSSH private key copied from the server.
  2. Click Conversions from the PuTTY Key Generator menu and select Import key.
  3. Navigate to the OpenSSH private key file and click Open.
  4. Under Actions / Save the generated key, select Save private key.
  5. Choose an optional passphrase to protect the private key.
  6. Save the private key with the suffix ppk.

When configure a session in Putty for the remote compute instance, enter normal connection information such as public IP of the server, then go to Connection -> SSH -> Auth -> Private key for authentication, choose the ppk file created in the step 6 above. You may still need to provide the user name and passphase for the private key when connecting.

login as: joe_techlife_li
Authenticating with public key "joe_techlife_li"
Passphrase for key "joe_techlife_li":

If you want Putty to enter the username automatically, put the username in Connection -> Data -> Auto-login username or use the format username@IP instead of IP only when specify destionation in the session. If you don’t give a passphase for the private key, SSH won’t ask for it and you are automatically connected.

You can also use PuTTYgen to create the key pair. Then you need to hightlight the whole key string in the window when generated and copy it to the sever and save in the authorized_keys file. Don’t use the “Save public key” button because the format is not in OpenSSH format.

For GCP, you can use “gcloud compute ssh” as well. You can see the whole command when click SSH drop down in the platform console. For example: 

gcloud compute ssh --zone "us-central1-a" "instance-1" --project "alert-nimbus-348800"
PS D: ~awnmc> gcloud compute instances list
NAME        ZONE           MACHINE_TYPE  PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP   STATUS
instance-1  us-central1-a  e2-micro                   10.128.0.2   34.68.216.39  RUNNING

PS D: ~Temp> gcloud compute ssh instance-1 --zone us-central1-a
Updating project ssh metadata.../Updated [https://www.googleapis.com/compute/v1/projects/alert-nimbus-348800].
Updating project ssh metadata...done.
Waiting for SSH key to propagate.

When connecting with this way, things happening as below:

  1. Compute Engine sets a username and creates a persistent SSH key pair with the following configurations:
    • Your username is set as the username in your local machine.
      Note: You can override the default username by providing a different username when you connect to the VM. Use the format USERNAME@VM_NAME.
    • Your public SSH key is stored in project metadata. If Compute Engine can’t store the SSH key in project metadata, for example, because block-project-ssh-keys is set to TRUE, Compute Engine stores the SSH key in instance metadata.
    • Your private SSH key is stored on your local machine.
    • Your SSH key doesn’t have an expiry. It is used for all future SSH connections you make, unless you configure a new key.
  2. Compute Engine uploads the public SSH key and username to metadata.
  3. Compute Engine retrieves the SSH key and username from metadata, creates a user account with the username and public key, and stores the public key in your user’s ~/.ssh/authorized_keys file on the VM.
  4. Compute Engine grants your connection. A putty session will open.

References:

  1. https://cloud.google.com/compute/docs/instances/connecting-advanced
  2. https://cloud.google.com/compute/docs/connect/ssh-using-third-party-tools
  3. https://cloud.google.com/compute/docs/instances/connecting-to-instance
  4. https://cloud.google.com/compute/docs/connect/add-ssh-keys
  5. https://cloud.google.com/compute/docs/connect/create-ssh-keys

Leave a comment