The Cambridge computer lab uses one of these for multi user machines. Home directories are mounted over Kerberised NFS and so you can’t store authorised keys in there because it’s not readable until after login (and often not until after running kinit after login). The authorised keys are on a separate NFS mount that is readable by the pre-auth user and there’s a little script for adding and removing authorised keys. This also lets the central tooling enforce policies on the keys. The key format provides a comment space at the end (ssh-keygen, by default, fills this with the user and machine where the key was generated). By default, keys are restricted to specific origin IP addresses, but if you put ‘laptop’ in the name then this restriction is removed.
Thus there is also a special AuthorizedKeysCommand that applies these policies (like the IP restriction) on each server? Or one uses the from="..." option in compliant authorized keys files (thus no need for the command)?
I love how many interesting tidbits ‘ssh’ and ‘ssh_config’ have! Just recently I learned about the ControlMaster’, ‘ControlPersist’, and ‘ControlPath’ options for ‘ssh_config’ and they proved to be incredibly useful.
I really like the ‘AuthorizedKeysFile’ option shown here to enable a fallback authorized keys file as I’ve definitely shoot myself in the foot before with just a user-specific file.
OpenSSH doesn’t support X.509. The openssh certificates are custom certificates very different from X.509 certificates.
The Cambridge computer lab uses one of these for multi user machines. Home directories are mounted over Kerberised NFS and so you can’t store authorised keys in there because it’s not readable until after login (and often not until after running kinit after login). The authorised keys are on a separate NFS mount that is readable by the pre-auth user and there’s a little script for adding and removing authorised keys. This also lets the central tooling enforce policies on the keys. The key format provides a comment space at the end (ssh-keygen, by default, fills this with the user and machine where the key was generated). By default, keys are restricted to specific origin IP addresses, but if you put ‘laptop’ in the name then this restriction is removed.
Thus there is also a special
AuthorizedKeysCommandthat applies these policies (like the IP restriction) on each server? Or one uses thefrom="..."option in compliant authorized keys files (thus no need for the command)?I love how many interesting tidbits ‘ssh’ and ‘ssh_config’ have! Just recently I learned about the ControlMaster’, ‘ControlPersist’, and ‘ControlPath’ options for ‘ssh_config’ and they proved to be incredibly useful.
I really like the ‘AuthorizedKeysFile’ option shown here to enable a fallback authorized keys file as I’ve definitely shoot myself in the foot before with just a user-specific file.