Public Key Authentication
SSH provides a mechanism to authenticate users with public/private key pairs.(1) The user has a private key, and they provide their public key to the server. When the user attempts to login, the server sends a session identifier to the client. The client can then prove that it has a secret key by generating a digital signature which contains this random session identifier and the public key.(2) If the user can prove they have the private key of a public key that the server knows to authorize, they are authenticated.
This mechanism for authentication is considerably more secure than using passwords, because the difficulty of guessing a password is fairly trivial compared to the difficulty of guessing a private key.(3, 4, 5)
Public key authentication is not ideal though, and has its own challenges. For one, the server must be made aware of the public keys to authorize in advance. For another, the server has no control over how the user secures their private key. The user is free to use a weak password, or even a completely unencrypted (no password) private key.
Certificate Based Authentication
Certificate based SSH authentication is essentially an extension to public key authentication.(6) However, with certificate based authentication, the server is not required to know the public key in advance. Instead, the server is configured with a trusted Certificate Authority (CA) certificate, and it uses that certificate to validate that a client’s public key has been signed by that trusted CA. This way, the user presents both their public key, and proof that they have the private key corresponding to that public key all in one step. (The public key is included in the message the client signs to prove it has the private key.) This method of authentication is a significant improvement over “regular” public key authentication because every server you have does not need to be made aware in advance of every public key it should authorize.
However, there are still some problems to be addressed. Specifically, servers blindly trust any signed key for the duration of that signature, and synchronizing revocation lists or otherwise revoking certificates is non-trivial. Further, there is still no control over the private keys being used, nor how well protected those keys are. For example, a user could have checked their private key into a public git repository, and for the lifetime of the certificate, anyone can use it to login.
ScaleFT uses certificate based authentication, and solves the problems of key management and certificate revocation by issuing ephemeral credentials with certificates that expire within minutes. No revocation lists are required because every certificate we issue expires within minutes, and so are “revoked” automatically. Because keys are also ephemeral, and only ever signed once, if a user went out of their way to grab one and commit it into a public git repository, that key is rendered useless within minutes.
Authenticating that a user is who they claim to be is obviously important, but it is equally important that the user verify the authenticity of the host they are connecting to.(7) If the user cannot authenticate the host they are connecting to, all the user-validation in the world is easily circumvented with something called a “Man-in-the-Middle” (MitM) attack.(8, 9)
While MitM attacks are somewhat confounded by the fact that session-ids are negotiated via key-exchange algorithms(10) and public key authentication requires that the session-id be included in the signed message(2), such attacks are still possible (e.g., in cases where you forward your ssh-agent to the malicious host, or in cases where a weak KEX is used(11)). Essentially, the user’s client connects to a machine they believe is the target-host, but is really just a server that pretends to be that target-host. This imposter (the MitM) uses whatever mechanisms it can to authenticate as the user; either by exploiting the user’s forwarded ssh-agent, or by somehow forcing the negotiation of the same session-id it already negotiated with the target-host. Once logged in, this MitM can do anything it likes up to, and including sending any commands it wants as though the user had input them; all without ever seeing the private key.
The SSH Protocol has a solution for this problem called host-key validation, and it is essentially the same thing as the Public Key Authentication explained above, but backwards. The server authenticates itself to the client by proving that it has the private key corresponding to a public key known to the client. The problem with this solution is that the public key must be known to the client in advance. (Just as with public key authentication before certificate based authentication.) As a solution to this, certificate-based host-key validation is also supported in openssh, but getting revocations to client machines is considerably less reliable than getting them to servers, which was already a hard problem.
By providing a secure, out-of-band mechanism to exchange the public key of all your hosts, ScaleFT ensures that your SSH client will always have the correct host-keys necessary to authenticate target hosts and establish a secure connection. This completely avoids the “Trust On First Use” (TOFU) problem most SSH users experience the first time they connect to a host, and they must blindly trust that the key they are presented with is valid for that host.
ScaleFT obtains the server’s public host key directly from the source, and then ensures your client is configured with that public key, all securely over TLS at every step.
Before ScaleFT, you may have just accepted:
as something you see when you re-image a machine, or spin up a new instance with the same name as a prior instance, with ScaleFT this warning becomes rare, meaningful, and you should definitely not proceed if you see it.