• Andree Toonk

Using your gmail account to ssh to your servers

Updated: Mar 10

In this blog, we’ll look at how your users can ssh to servers and authenticate using OpenID connect. No need for passwords or even per user ssh keys. Instead, we’ll use Gmail as an example to authenticate users. Gmail is just an example; this could be your email as well.

Demo of starting an ssh session using Gmail credentials

Password management and key rollovers are a pain.

You’ve probably had the conversations about password and key rollovers, because of security compliance, or best practices, you need to roll your password and change your ssh keys every 90 days. Depending on the size of your environment and the level of automation, this can be a major pain and inconvenience.

A better way

In an ideal world, your users would use their primary credentials to log in to most services. Most folks use some form of Single sign-on for this, typically built with SAML or OpenID connect. This account is well protected, has proper password rollover schedules, multi-factor authentication, and extensive logging.

However, for ssh, it’s still often the case that folks use either separate usernames and passwords or static ssh keypairs.

Combining single sign-on and ssh public keys

In this blog, we’ll show how we can combine the convenience of ssh key pairs with a single sign-on solution. This is the workflow:

  1. After the user initiates an ssh session, a browser window opens, and the user is asked to log in with single sign-on (we'll use Google for this example).

  2. Assuming the authentication succeeds, we’ll check the authorization rules as configured in mysocket. For example, by checking if the user’s email address matches the list of allowed addresses.

  3. Assuming the authorization is successful, the mysocket system returns a short-lived signed ssh key, that the user can then use to authenticate and login to the ssh server.

The advantage of this workflow is that we use the centralized login service (single sign-on), so in case of user termination, there is no risk of lingering accounts. We also have one place to manage the authorization rules. For the user the advantage is that they don't need to be aware of keys, from their perspective all they need to do is log in with Google through the browser and the rest feels like magic.

Test it yourself!

I’ve set up a VM that anyone with a Gmail account can log in to. Testing it is simple, just complete the one-time prerequisites below and then ssh to like below.


One time setup

Users that would like to ssh to your servers will need the mysocketctl client, this will make sure the browser window starts, and the authentication flow kicks off. It will also facilitate the process of fetching the temporary ssh keys. Note that the steps below are a one-time setup only.

Note: this is the URL for Apple users, see for Linux and Windows links:

curl -o mysocketctl 
chmod +x ./mysocketctl
sudo mv ./mysocketctl /usr/local/bin/

We’ll also add the following to our ssh client config file. This is a one-time setup and will ensure the ssh traffic to * and are sent through the mysocketctl client tool, you can just copy this in your terminal and it will be added to your ssh config (~/.ssh/config).

cat <<EOF >> ~/.ssh/config

Match host * exec "mysocketctl client ssh-keysign --host %h"
  IdentitiesOnly yes
  IdentityFile ~/.ssh/%h
  ProxyCommand mysocketctl client tls --host %h

Match host exec "mysocketctl client ssh-keysign --host   
  IdentitiesOnly yes
  IdentityFile ~/.ssh/%h
  ProxyCommand mysocketctl client tls --host %h


You should now be able to ssh to my test server like this: ssh

When asked to log in, make sure you choose google and log in with your Gmail account. This is because I’ve configured the authorization rules for this service to only allow any account to be granted access.

Demo of starting an ssh session using Gmail credentials

Cool, I want this on my own server!

Alright! That’s easy, let's make this work for your ssh server. Assuming you already have a mysocket account, the steps below are all that’s needed to enable this kind of authentication on your server:

Download the mysocketctl client on your ssh server

curl -o mysocketctl 

chmod +x ./mysocketctl
sudo mv ./mysocketctl /usr/local/bin/

Login and fetch a token

mysocketctl login

Create a socket for your ssh service using the cli. Note this can also be done using the web portal at

mysocketctl socket create \ 
  --allowed_email_domains \ 
  --cloudauth \
  --name "ssh gmail demo" \ 
  --type tls

Make sure to take note of the SSH Public CA for this Socket, as we’ll use that in a second.

next up, we’ll set up a secure tunnel between the ssh server and the mysocket edge servers.

mysocketctl tunnel create -s <socket_id>

We now have a socket and tunnel. With this we can connect the secure tunnel like this:

mysocketctl tunnel connect --port 22 -s  <socket_id> -t  <tunnel_id>

Finally, we’ll configure the ssh server to accept ssh connections that authenticate using signed ssh keys from the mysocket certificate authority. We specifically enable this for clients that log in as user ubuntu. Note that the <ssh public ca key> was printed earlier when we create the socket. No worries if you lost it, as it can be seen in the portal as well.

echo "TrustedUserCAKeys /etc/ssh/" >>/etc/ssh/sshd_config
echo "AuthorizedPrincipalsFile %h/.ssh/authorized_principals" >>/etc/ssh/sshd_config
echo "mysocket_ssh_signed" > ~ubuntu/.ssh/authorized_principals
echo <ssh public ca key> /etc/ssh/
service ssh reload

And that’s it! You’ve now enabled your ssh server to accept signed ssh keys from the mysocket certificate authority. These keys are only issued to authenticated users that pass the authorization check. In this case, any user with a Gmail account will pass the authorization phase, but obviously, this can be changed to your domain.

Wrapping up

In this article, we saw how using mysocket we can solve the compliance requirements of rolling username & password and ssh keys. We saw how we issue short-lived signed ssh keys to only those users you’d like to have access to your server. In this example, we used, but we can use a combination of domains as well as specific email addresses. For example, anyone at and to allow temporary access for a third-party contractor.

The tunnel between the ssh server and the mysocket infrastructure requires only outbound network connectivity, so no need to poke holes in your firewalls. This allows the ssh server to be behind strict outbound only firewalls or even NAT.

We also used the custom DNS feature of mysocket by adding as an alternative name to the service. You can use any of your custom domain names for your service.

For more details about ssh and zero trust using mysocket also see this blog: Introducing SSH zero trust, Identity aware TCP sockets

516 views0 comments

Recent Posts

See All