systemd, PAM, NSS, and SSHD:
step-ssh-renewrotates the SSH host certificate every eight hours.
step-ssh-metadatasyncs user ACLs with your CA every 3 seconds.
This step only applies to multi-user environments.
Host Tags (key-value pairs) are the pillar our access control model. Rather than mapping people or groups directly to hosts, you'll map tag combinations to your hosts and to your user groups. First you'll put your hosts into logical groups using tags, eg.
staging. Then, you'll grant user groups access to all hosts with a specific tag combination. Finally, you'll choose which user group tag combinations will allow
sudo privileges on any matching hosts.
Let's look at an example:
developersgroup will have access to
datagroup will have access to
opsgroup will have
Of course, hosts and groups can have as many tag combinations as you like. Take a minute to think about how you'd like to use Host Tags in your environment.
Now let's set up your host. You'll run the entire Host Configuration setup as the
$ curl -L -o step https://files.smallstep.com/step-linux-0.15.3 $ install -m 0755 -t /usr/bin step
This step will install modules and services.
Install on Ubuntu & Debian (DEB package)
$ curl -LO https://files.smallstep.com/step-ssh_0.19.0-1_amd64.deb $ dpkg -i step-ssh_0.19.0-1_amd64.deb
Comment out the broken
common-session, which causes a delay at login (this is a known Ubuntu/Debian bug):
sed -e '/pam_systemd.so/s/^/#/g' -i /etc/pam.d/common-session
Install on CentOS or Amazon Linux 2 (RPM package)
$ curl -LO "https://files.smallstep.com/step-ssh-0.19.0-1.x86_64.rpm" $ yum -y install step-ssh-0.19.0-1.x86_64.rpm
step ca bootstrap --team="[your smallstep team ID]"
Remember the enrollment token you got when you signed up? You'll need it now. If you downloaded it, the file is called
_👇 This leading space will (usually) keep the token out of your shell's history.
$ export enrollment_token="[your enrollment token]" $ export hostname="[your hostname]"
hostname is your host's canonical hostname or IP. This will be the name clients use to SSH to this host.
Run the following to issue a certificate for your host:
step ssh certificate $hostname /etc/ssh/ssh_host_ecdsa_key.pub \ --host --sign --provisioner "Service Account" --token $enrollment_token
Note: When a host has multiple hostnames, your users will only be able to
sshto the canonical
$hostname, as shown by the
step ssh hostscommand.
If you need multiple hostnames in your host certificate (e.g., public and private hostnames, or a hostname and an IP address), you can pass each of them to
step ssh certificate via the
step ssh certificate $hostname /etc/ssh/ssh_host_ecdsa_key.pub \ --host --sign --provisioner "Service Account" --token $enrollment_token \ --principal $hostname --principal 10.0.0.42
When multiple hostnames are needed, the canonical
$hostname must be passed twice: Once to establish the certificate's Key ID, and again explicitly as its first Principal.
step ssh config --host --set Certificate=ssh_host_ecdsa_key-cert.pub \ --set Key=ssh_host_ecdsa_key
This command will add a few lines of configuration to the end of your
/etc/ssh/sshd_config to enable certificate authentication. These lines are annotated with a comment that says
# autogenerated by step @ <timestamp> so you can identify them later if you need to modify or revert these changes.
step-ssh activate "$hostname"
step-ssh activate command will leverage a short-lived identity certificate to authenticate itself to the host inventory.
This command will leverage the host identity certificate to authenticate itself to the host inventory.
step-ssh-ctl register --hostname "$hostname"
For access control in multi-user environments, host tags can be assigned via the
step-ssh-ctl register --tag <key=value> --tag <role=web> --hostname "$hostname"
It is possible to rerun
step-ssh-ctl register multiple times, to rename the host, replace its tags, or change the bastion settings. Note: This command replaces all existing tags and bastion settings for a host.
If the host you're registering is a bastion, add the
step-ssh-ctl register --hostname "$hostname" --is-bastion
Note: Your bastion host will need the
nc command installed. Our bastion host support uses
nc (along with the
ProxyCommand directive) because it's widely compatible with older SSHD servers.
If the host you're registering is behind a bastion, add the
step-ssh-ctl register --hostname "$hostname" --bastion "[bastion hostname]"
Before you sign out of your
sudo session, test your installation by logging in and running
sudo in a separate session.
This step is especially important if you have made any non-standard changes to your PAM or NSS stacks.
Now sign in at
You should see your host listed under the "Hosts" tab.
On the host, run:
This will remove the host from the host inventory on the CA, using the host identity certificate.
Now that you're using certificates, you may wish to explicitly disallow the use of
authorized_keys files on the host.
You can do this by setting
AuthorizedKeysFile none in
sshd_config. You may want to allow
authorized_keys for an emergency access account, however. A configuration for this might look like:
Match User *,!ubuntu AuthorizedKeysFile none
Having trouble? You should be able to revert any changes by running
Suspect host or user certificates are not working? In other words, your ssh client fails to log in or shows "trust on first use" warning? Try this:
step ssh listand find your user certificate marked
256 SHA256:Bb2TcimUYj8Nc5w4FhpZ/gmeNIIvLIzphTx35NzaRoA firstname.lastname@example.org (ECDSA-CERT), which you can inspect with
step ssh list --raw email@example.com | step ssh inspect. Be sure the current time is neither before or after the period specified in
step ssh inspect /etc/ssh/ssh_host_ecdsa_key-cert.pub. Make sure the current time is within the period of
sshd_configshould show included the following lines for
sshd(make sure the service has reloaded its config) to leverage certificate-based authentication:
$ tail -n 7 /etc/ssh/sshd_config # ForceCommand cvs server # autogenerated by step @ 2020-04-02T21:16:05Z TrustedUserCAKeys /etc/ssh/ca.pub HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub HostKey /etc/ssh/ssh_host_ecdsa_key # end
sshd -t(as root) to test you SSHD configuration. No output means the file is OK; you'll get an error if any of the referenced files (eg. host keys) are not accessible to
Suspect your ssh client might have a problem? Use verbose logging
ssh -v <hostname>. Look out for following key lines/events below in your log. If you don't see errors the absence of these events might indicate your config is invalid / not being applied.
Your team's config is applied for this specific host:
debug1: Executing command: 'step ssh check-host ec2-52-200-74-193.compute-1.amazonaws.com' debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 48: Applying options for * debug1: /etc/ssh/ssh_config line 52: Applying options for * debug1: Executing proxy command: exec step ssh proxycommand --provisioner "okta" alice ec2-52-200-74-193.compute-1.amazonaws.com 22
The host certificate passed authentication on the client:
debug1: Server host certificate: firstname.lastname@example.org SHA256:ON/csaCQ4yDKfxblQnOLTiZIOoOtsHPAjQn6DrW+k9I, serial 2468062085372141930 ID "ec2-52-200-74-193.compute-1.ama debug1: Server host certificate: email@example.com SHA256:46gC0CEzXWN4acTHGQldL6H+QlbhB4+KPZjkoRToI/w, serial 8551898981883739717 ID "ec2-52-200-74-193.compute-1.amazonaws.com" CA ecdsa-sha2-nistp256 SHA256:sqfZG6AOPUvcheFUIZDX+DEesnyfNZQ5JwqpcxUzY+0 valid from 2020-04-14T04:45:10 to 2020-05-14T04:46:10 debug1: Host 'ec2-52-200-74-193.compute-1.amazonaws.com' is known and matches the ECDSA-CERT host certificate. debug1: Found CA key in /Users/alice/.step/ssh/known_hosts:1
The username being used for authentication:
debug1: Authenticating to ec2-52-200-74-193.compute-1.amazonaws.com:22 as 'alice'
The ssh client offers the user's certificate to the destination host:
debug1: Offering public key: firstname.lastname@example.org ECDSA-CERT SHA256:VIa1uWhBTjjtpW3IBkUG/aFGfqlUhjkXNQVk6Hc1lXc agent debug1: Server accepts key: email@example.com ECDSA-CERT SHA256:VIa1uWhBTjjtpW3IBkUG/aFGfqlUhjkXNQVk6Hc1lXc agent debug1: sign_and_send_pubkey: no separate private key for certificate "firstname.lastname@example.org"