-----Message d'origine-----
De : Michael Ströder [mailto:michael@stroeder.com]
Envoyé : vendredi 25 janvier 2019 07:30
À : End-user discussions about the System Security Services Daemon;
Maupertuis Philippe
Objet : ** SPAM scored: High **Re: [SSSD-users] Re: Understanding sssd
cache
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.
We do have a very common use case where we need console access.
When either SSH or the network inside the server need to be restarted.
For sshd (and sssd) that can be mitigated by using the restart on failure feature of
systemd.
SSHD is sometimes in a stale state, not working but not dead either.
I failed to find something similar for the network layer.
If I missed something there I would be glad to know what should we do.
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.
!!!*************************************************************************************
"Ce message et les pièces jointes sont confidentiels et réservés à l'usage
exclusif de ses destinataires. Il peut également être protégé par le secret professionnel.
Si vous recevez ce message par erreur, merci d'en avertir immédiatement
l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur
Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce
message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission
exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa
responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus
transmis.
This e-mail and the documents attached are confidential and intended solely for the
addressee; it may also be privileged. If you receive this e-mail in error, please notify
the sender immediately and destroy it. As its integrity cannot be secured on the Internet,
the Worldline liability cannot be triggered for the message content. Although the sender
endeavours to maintain a computer virus-free network, the sender does not warrant that
this transmission is virus-free and will not be liable for any damages resulting from any
virus transmitted.!!!"