-
Notifications
You must be signed in to change notification settings - Fork 6
ClientAuthentication
Etch supports client authentication, where the server verifies a client's identity. If you are managing host-specific privileged files (SSL or SSH keys, Kerberos keytabs, etc.) this is important to ensure that a rogue client does not pretend to be another host and receive copies of those privileged files. Client authentication is not enabled by default.
Etch uses the client's OpenSSH RSA SSHv2 host key for authentication credentials. More info about this choice can be found below. This key is typically in a file called /etc/ssh_host_rsa_key or /etc/ssh/ssh_host_rsa_key. The etch client will always sign requests with the SSH key if one exists on the box. Clients always report their SSH public keys via Facter, and the etch server stores all facts received from clients in its database, so the server already has what it needs to validate the client's signature. So if you want to enable authentication you just have to configure the server to verify that the signatures are valid. This is done by creating /etc/etchserver/etchserver.conf with:
auth_enabled = true
With authentication enabled etch will automatically accept clients it hasn't seen before, storing the public key they provide and then verifying future requests against that key. This is safe enough for most environments. However, for greater security you can disable the automatic acceptance of new clients, thus requiring that the host key for new clients be manually entered into the etch database. Add this additional line to etchserver.conf:
auth_deny_new_clients = true
Requests from clients include a timestamp. To reduce the risk of replay attacks the server requires that the timestamp in the request be within 5 minutes of the server's time. This means that your client's clock must be within 5 minutes of the server's clock. You'll probably have etch configure NTP, so in general operation this isn't a concern. But it can present a problem for new hosts, which may come from the factory with clocks that are weeks or months off. As such you might include a run of ntpdate in your Kickstart post script or otherwise make an effort to get the client's clock reasonably accurate before running etch the first time. Even without authentication enabled this is sometimes a problem as the client's clock may be so far off that it thinks the server's SSL certificate is not valid, as SSL certificates include the time they were issued and when they expire, often a 1 or 2 year window, and the client checks that the current time is within that window. If you see an SSL verification error or authentication failure with a new client check their clock.
Why use the SSH host key you might ask? If we were to provision an etch-specific authentication credential there are a variety of choices:
- Issue each client a different secret shared with the server and use symmetric encryption. That's fairly simple, but does leave the server with the problem of safely storing all of those secret keys. If the server were compromised you'd have to re-issue new keys to all clients.
- Issue each client the private half of a public-key cryptography key pair. This is the same cryptography as we're using with the SSH keys. In this case the server is storing the public key for each client, which is easier to do correctly than storing private keys.
- Use a public key infrastructure system like X.509, i.e. issue each client its own SSL cert signed by a certificate authority. At least initially this is the easiest on the server-side, as the server just needs the CA's certificate to verify the clients. It gets more complicated over time if you want to revoke certificates for clients that no longer exist, were rebuilt, or were compromised. Puppet uses this approach.
None of these approaches are intrinsically more secure. Each requires some special handling of new clients to issue them a new credential. Each also requires handling of clients where the authentication credential is lost (due to drive failure, re-imaging, etc.), either by restoring the private credential to the client if the server is storing a copy, or issuing a new credential to the client and invalidating the old one.
Using standard public-key cryptography seems like a good balance of security and simplicity. We didn't see any reason to generate our own key pair when the SSH host keys were always there. Facter already includes the public keys in the facts it reports, so we didn't have to add any code to find them, read them, or send them to the server. And lastly most shops have or want to have a mechanism for restoring SSH host keys to rebuilt boxes so that users don't get security warnings about keys that have changed, and if that's in place it eliminates one of the headaches of living with a config management authentication system.