Do you work with a lot of linux servers?
Do you log in to each of them using your ssh key? On the one hand, you would like to change it more often, but on the other, the overwhelming amount of work associated with changing certificates on many servers discourages you?
In today's episode of "from 0 to pentesting hero", we will take a look at how Netflix1 solved this problem.
In a standard SSH server configuration - if we want our key to allow logging in to the server, we must add it to the ~/.ssh/authorized_keys file.
Then the server knows that the person using this key is authorized to access the server.
Everything works fine as long as we connect to only one server and we are its only administrator.
Things get complicated if there are several servers to supervise and there are more administrators.
Keys of all administrators, with access to a given computer, must be present in the authorized_keys file.
In addition, if any key leaks out - we must remove it from all servers to protect them.
So how can you deal with this problem?
On the SSH server we can configure the option called TrustedUserCAKeys2.
What does this solution give us, and how does it work?
With this, server does not check the specific key.
It checks, however, if the given key has been signed by another key - the one we provide in the TrustedUserCAKeys configuration.
This can be compared to how the trust of SSL certificates work.
There are some entities in the world, whose keys are trusted by browsers.
When we want our site to be accessible via the https, we generate our own private and public keys and we ask such trusted institution to sign our public key with its private key.
Therefore, the company verifies if we are the owners of a given domain - and if everything is correct, it signs our key with its key.
While browsing the internet, the browser verifies if our key is signed with a key of a trusted company. If yes, it displays a green padlock next to our address.
This way, the browser knows that it can trust the certificate.
The same pattern is used here.
Every time we want to connect to the server we don't use our SSH key - but we generate a completely new, unique key.
Then we connect to the certification server - which owns a private key, that all our servers recognize and trust.
This server verifies if we have rights to log in to the given server - and signs our key with its private key.
A key signed in this way could be used for unlimited time - that's why an additional parameter is used - it specifies the exact time period when a given key is valid.
Thanks to this you can log in only for a limited time.
Even if our key leaks out - it will no longer be valid for the server.
If we deprive a person of access rights to a given server - it is enough to modify the permissions in the signing server accordingly - so it will not sign the keys for the given user.
Bless is a tool that is used for such purpose. It was created in such way that it can be easily run on Amazon servers.
So we install an instance of this server together with our private key in the AWS Lambda infrastructure.
Now, if we want to connect to some server, we first use the Bless server - and we log in with our amazon's credentials.
Interestingly, it can be configured to require two-factor authentication.
If you need an implementation of a client in python, it's worth taking a look at the related project3.
Icon made by Freepik, Flat-icons-com, srip,
Flat Icons, monkik, Smashicons, Prosymbols
from www.flaticon.com
