Industry Best Practices For SSH - DevOps.com Webinar
0 likes465 views
The document discusses best practices for securing SSH access, emphasizing the transition from public keys to certificates for better security and management. Key recommendations include using a bastion host for centralized access, enforcing two-factor authentication, and utilizing an identity provider for user management. These strategies are aimed at improving visibility, reducing risks, and simplifying the onboarding and offboarding processes in organizations.
Industry Best Practices For SSH - DevOps.com Webinar
- 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!