SSH Case Studies: Agents and Authentication - 11.1.3 Hostbased Authentication
(Page 2 of 2 )
If security concerns are relatively light, consider hostbased authentication for batch jobs. In this case, the “credentials” are the operating system’s notion of a process’s uid: the identity under which a process is running, which determines what rights it has over protected objects. An attacker need only manage to get control of a process running under your uid, to impersonate you to a remote SSH server. If he breaks root on the client, this is particularly simple, since root may create processes under any uid. The real crux, though, is the client host key: if the attacker gets that, he can sign bogus authentication requests presenting himself as any user at all, and sshd will believe them.
Hostbased authentication is in many ways the least secure SSH authentication method. [188.8.131.52] It leaves systems vulnerable to transitive compromise: if an attacker gains access to an account on host H, she immediately has access to the same account on all machines that trust H, with no further effort. Also, hostbased configuration is limited, fragile, and easy to get wrong. Public-key authentication affords both greater security and flexibility, particularly since you can restrict the commands that may be invoked and the client hosts that may connect, using its forced commands and other options in the authorization file.
Of course, if your security policy permits and you’re already using hostbased for general user authentication, then you’re all set for batch jobs too. However if you’re using something stronger for user authentication, and you’re considering the host-based method for batch jobs, then we recommend that you:
Restrict its use to the batch accounts only (via /etc/shosts.equiv rules); continue to use stronger methods for interactive authentication.
Use only the SSH-specific configuration files /etc/shosts.equiv and ~/.shosts, and not the legacy files /etc/hosts.equiv and ~/.rhosts. This avoids any accidental changes to the behavior of wildly insecure mechanisms like rcmd and rsh.
Set options such as OpenSSHIgnoreRhostsandIgnoreUserKnownHosts, and TectiaAllowSHosts/DenySHosts, if possible. Since per-account hostbased configuration can override the systemwide files, it’s best to disable them.
There’s no reason to deploy Kerberos [11.4] solely in order to support batch jobs; it has no special overall advantage in this regard. However, if you’re already using Kerberos, you might want to keep things simple by using it for batch as well as interactive jobs. Unattended Kerberos usage has similar security properties to using a plaintext SSH key as described earlier: the Kerberos principal’s key is stored on disk, can be similarly strong since it does not have to be derived from a user-memorable passphrase, and is not revealed in the authentication process.
To do this, use the kadmin command:
$ kadmin -q "ktadd -k keytab principal"
to store the principal’s key in the file keytab, and protect that file appropriately (e.g., so that only the Unix batch account can read it). The batch job can then call kinit:
$ kinit -k -t keytab
to obtain Kerberos credentials for that principal.
We suggest the following arrangement:
Arrange that the keytab file does not travel insecurely over the network, e.g., on an unsecured NFS filesystem. Perhaps also arrange that it is not dumped to backup tapes.
Create separate principals for batch jobs; do not use existing user principals.
Create a random key for the batch principal using the kadmin option,addprinc -randkey.
If feasible, periodically change these keys. An advantage of the Kerberos system is that this does not require changing corresponding authorization entries, as changing a simple SSH key would require updating the matching authorized_keys files. Any running jobs will have to be restarted, though, since their credentials will become invalid.
As always, restrict what the batch principal can do on the server side, here using the Kerberos ~/.k5login or ~/.k5users files.
Kerberos-5 contains support for long-running jobs with “renewable” tickets, but note that this is still intended for jobs started interactively; it just supports those that may run for a long time. It is not intended as a solution for truly unattended jobs.
Please check back next week for the next part of this series.
DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.