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.