We've all used SSH dozens of times, but do we really understand how to SSH properly? Using such a powerful tool can come with a lot of risks, especially when we're on highly distributed teams with well-trodden workflows that can be tough to change. In an era of sophisticated phishing attacks and threats always knocking at our doors, we could all use a little help with making sure our infrastructure is as secure as it can be. Join Gus Luxton from Gravitational as he talks about how you too can level up your SSH game - switch from keys to certificates, funnel your access through a bastion server, set up 2-factor authentication and cross-reference your users with an external identity provider. For reference, check out Gus’ blog on the topic, How to SSH Properly.

1. Webinar
Gus Luxton
Solutions Engineer
Industry Best Practices
for SSH Access

2. Why securing SSH is important
● Managing access to servers has traditionally
involved sharing passwords via a password
manager or copying SSH keys around to servers
using automation.
● This doesn’t scale well with growing
organisations and can make
onboarding/offboarding users hard.
● Credential leaks and compromises are very real
and present a huge security risk.
● Once access is provided, there’s very
little visibility into what anyone is doing.

3. Summary
● Step 1: Switch from using public keys to certificates
● Step 2: Use a highly available bastion host as an access gateway
● Step 3: Enforce the use of a second factor
● Step 4: Get user identities from a identity provider

4. Step 1: Switch from public keys to certificates
Some pros of public keys
● Far more secure than shared passwords due to greater entropy
● Can’t be keylogged - nobody ever types a private key
● Cryptographically secure - reliable way to authenticate that the
person accessing your server actually has that private key in their
possession

5. Some cons of public keys
● Can be hard to keep track of which key goes where
● No expiration by default
● Requires a process for distribution to be useful
We’re all too busy for this...
● Lack of built-in accountability regarding what key belongs to who
● Makes credential rotation hard without building a separate process
Step 1: Switch from public keys to certificates

6. Some benefits of certificates
● All the benefits of public keys as described
beforehand, with none of the explicit downsides
● Support for additional metadata - add an email
address, internal username or ticket reference to
every certificate issued, and define a list of users that
the certificate is permitted to authenticate as
● Simple to issue and reissue without external
changes meaning credential expiry and rotation can
be built in automatically
● Can be revoked by synchronizing a CRL to servers

7. Certificate metadata: example
● Customizable ID that you can set per-certificate
● Short validity period to limit access by default
● Contains a list of authorized principals (logins) that the certificate will permit
● Extensions to limit permissions further if desired

8. But wait - there’s more!
It’s called “Trust on first use” or “TOFU” and represents a
fundamentally insecure model.
Messages like these can be a thing of the past if you switch to
using certificates to authenticate your hosts.
Anyone seen a prompt like this before?

9. Step 2: Use a bastion server for access
● In an era of more remote work we’re all connecting from different
locations regularly
● Whitelisting on a server-by-server basis is tricky - borderline impossible
● Bastions can be highly available and provide you with a reduced attack
surface by limiting locations you can connect from - no need for a VPN
● It doesn’t have to be hard - SSH supports the use of jump hosts out of
the box with the -J flag
● Blocking or revoking access becomes much simpler when you know that
all your connections are coming from a limited number of locations
● Provides a central location for logging and auditing access to your fleet

10. Step 3: Enforce the use of a second factor
● Two-factor authentication (2FA/2-Fac) refers to the idea of requiring
multiple factors before allowing access
○ “Something you know” like a password
○ “Something you have” like an authenticator app, or an SMS*
○ “Something you are” like a fingerprint/retina scan or voice print
● Lots of flexibility in ways to provide this
○ TOTP application - scan QR code, get a new code every 30 seconds
○ Push services like Duo, Okta, Auth0
○ Linux PAM (pluggable authentication modules) available for these
* SMS is not very secure. I don’t recommend you ever use it for a second factor.

11. ● Can you make a list of every user you have?
○ Could you do this for 100 users? 1,000 users? 10,000
users?
● If an SSH user leaves, you want to revoke their access
○ How do you know you’ve got all their keys?
● Use an identity provider as the source of truth for users
○ Active Directory, Okta, OneLogin, Auth0, Github
○ One place to add users, one place to remove users
Step 4: Get identity from a third party

12. Summary
● Step 1: Switch from using public keys to certificates
● Step 2: Use a highly available bastion host as an access gateway
● Step 3: Enforce the use of a second factor
● Step 4: Get user identities from a identity provider

13. How can you do this easily?
● Open source, written in Go
● Written by engineers for engineers
● Doesn’t get in the way
● Fully compatible with SSH and your existing tooling
https://github.com/gravitational/teleport

14. Recommended Next Steps
Read “How to SSH Properly”
https://gravitational.com/blog/how-to-ssh-properly/
Check us out on Github
https://github.com/gravitational/teleport
Download Teleport
https://gravitational.com/teleport/download

15. Thanks!