Google Cloud SSH Keys

Just random stuff - Nothing to see here - Move along...

Google Cloud SSH Keys

You can manage persistent SSH keys in one of two ways:
METHOD 1:  gcloud
1A.  You can use the gcloud command line tool to create a key pair for you.  Provided you’ve authenticated to gcloud as an IAM user with the compute instance admin role, it will create keys for you the first time you SSH into an instance in your project.  Here’s an example walkthrough:
gcloud auth list # Make sure you’re logged in as the correct IAM user.
# If not logged in as the right IAM user:
gcloud auth revoke –all
gcloud auth login [your-iam-user]
gcloud compute ssh [NAME-OF-RUNNING-INSTANCE]
1B.  If you’ve never connected via SSH using gcloud, it will create a private key and prompt you for an optional passphrase.  It creates a public key as well and uploads that to project metadata (ssh-keys).  If the instance to which you’re connecting has the “block project wide SSH keys” set, the public key is uploaded to the instance’s metadata (also ssh-keys, but visible in the Cloud Console for the particular instance).  The private key is kept locally on your computer, in your home directory.  These are the filesystem locations for your private and public keys:
~/.ssh/google_compute_engine # private key
~/.ssh/ # public key
1C.  As you can see, the private key is stored in your home directory, on your computer.  If you share it, someone who knows your IAM user name can use it to SSH into the instance.  If you lose it, you can have gcloud recreate it by deleting the corresponding public key.  In general, deleting these keys will force them to be re-created and project/instance metadata for ssh-keys will be updated to hold the new public key.

METHOD 2:  Roll your own…

With the previous example, gcloud controls access to your instances by IAM user role.  Any compute instance admin can generate key pairs, with the public keys written to project/instance metadata, and picked up by the Linux Guest Environment (which includes the Google Accounts Daemon).

But you can also leverage project/instance metadata and the Accounts Daemon to distribute your own public keys.  This is useful if you have established systems for users to create their own key material, or if you have users who just need to SSH into some instances.  Here’s a walkthrough:

2A.  You or your users would generate SSH key pairs in the usual way, using ssh-keygen [1][2].  Your user keeps track of his/her private key.

2B.  Format the public key [3] so it matches one of these patterns:

ssh-rsa [KEY_VALUE] [USERNAME] # for keys that do not expire

ssh-rsa [KEY_VALUE] google-ssh {“userName”:”[USERNAME]”,”expireOn”:”[EXPIRE_TIME]”} # for keys that you want to expire
2C.  Add the formatted public key to project or instance ssh-keys metadata [4].  This must be done by an IAM user with the compute instance admin role, but you can control the deployment of the key to just some instances, etc.  Again, this is a great way to leverage existing conventions in places where you may have users who just need to SSH into their instances.
* SSH access requires that instances have public IP addresses unless you’ve connected to your VPC network via a VPN connection [5] or if you use another instance as a SSH bastion [6].
* SSH access can be blocked by firewall rules you define on your VPC network.
* In both cases, even where you add SSH keys yourself, you must have a working Linux Guest Environment.  This includes the Accounts Daemon, which is responsible for picking up the metadata.  Without that, defining SSH keys in instance metadata will have no effect on instances.  All instance images provided by Google have either the Google Linux Guest Environment or an equivalent (as is the case for CoreOS), so this is usually only a concern if you import images and need to install the Guest Environment manually.