A while back I wrote about some basic usage of SSH certificates as an authentication system. I only described the core, but the comments went into some further detail.
I thought it time to write a follow up post describing some of the more advanced features.
Quick recap To handle cert based authentication you need a CA certificate. This is created with the ssh-keygen command.
e.g.
$ mkdir ssh-ca $ cd ssh-ca $ ssh-keygen -f server_ca Server certificates are similarly signed with the same command.
One of the major threats that companies are concerned about is “insider threat”. According to some Data Breach Incident Response (DBIR) analyses, insider threat may be the 2nd or 3rd major reason for data loss. It’s interesting to note that the insider threat is way down in the actual number of incidents, but they count for a larger number of successful data loss incidents because the insider knows where the data is, may have legitimate access to the data, and may know the controls that need to be bypassed to exfiltrate it.
This blog post is of a more practical nature, and may be of use for people at home who ssh into servers and then come back later to find their session disconnected. It might also help some people in offices with nasty firewalls!
Basically the scenario goes something like:
ssh into a server lock your screen, go away for a few hours come back, unlock your screen ssh session has been disconnected So how does this happen, and what can we do to stop it?
In previous articles I’ve explained how to use traditional SSH keys and why connecting to a wrong server could expose your password. I was reminded of a newer form of authentication supported by OpenSSH; CA keys.
The CA key model is closer to how SSL certs work; you have an authority that is trusted by the servers and clients, and a set of signed keys.
Creating the CA key Creating a certificate authority key is pretty much the same as creating any other key
In an earlier blog I wrote that SSH keys need to be managed. It’s important!
In the comments I was asked about keytabs. I felt this such a good question that it deserved it’s own blog entry.
The basics of Kerberos auth In essence, kerberos is a “ticket based” authentication scheme. You start by requesting a TGT (“Ticket granting ticket”). This, typically, is where you enter your password. This TGT is then used to request service tickets to access resources.
Over on the Unix/Linux Stackexchange someone asked if ssh’ing to the wrong machine could cause their password to be exposed.
I answered “yes”… and was surprised to see the answer get over 140 upvotes.
Demonstration So it seems as if there’s some interest in this. I decided to demonstrate this risk in a short practical session.
Let’s start with a generic CentOS 7 install. It’s got nothing special on it.
SSH is probably the most common method of logging into Unix machines over a network connection. It has pretty much replaced the older telnet and rlogin protocols because it encrypts data over the network and has other “goodness”.
However one of the “good” parts of ssh is probably the least well managed; ssh keys.
What is an ssh key? When attempting to login to a server, ssh will attempt multiple different authenticators.
So I decided to play a little bit with google authenticator on my systems that are visible to the internet. ie my linode, Panix v-colo and ‘bastion’ host at home.
The way sshd works, if you authenticate with public keys then PAM “auth” doesn’t seem to get called. So this is pretty much for “ChallengeResponse” (instead of “password”) authentication. Which makes it great for my need; if I’m coming from one of my own machines with my SSH key then I’m not impacted.
