On 1/16/19 1:45 PM, Maupertuis Philippe wrote:
When using regular ssh access the the ssh publickey is in the cache if needed. A user who had not connected previously is able to connect even if the backend is unreachable When using the console, we have to rely on the password. When something goes wrong (sshd down or network issue), there is a high probability that the user would connect to the console for the first time. So if there is no guarantee the login could be successful offline we need to have a local (shared) account to connect to the console.
I've been through these discussions already in large environments.After all it turned out that this console use-case is not relevant (besides a very rare niche use-case with manually reloading a network driver kernel module due to a very specific hardware issue).
Ask yourself: Can the admin do any reasonable action on a machine in case the network is down? The answer is generally no. The admin will simply wait for the network guys to fix things on their side.
If you have network you can use emergency SSH keys to get root access if user management is broken. Some well-defined process for getting access to the private keys will also work even for strict auditors - YMMV. In my case the admins removed the emergency keys because the LDAP user management is available (dozens of replicas).
A shared account is a nightmare to manage and a sore point for audits, we would like to remove it.
Yes, one should try to avoid that. Ciao, Michael.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
