Entsprechen die SSH-Protokollierungsfunktionen der su-Protokollierung für die Authentifizierung mit privatem / öffentlichem Schlüssel?

Hier bei der Arbeit haben wir ein nicht root-freigegebenes Anmeldekonto unter UNIX, mit dem eine bestimmte Anwendung verwaltet wird. Die Richtlinie besteht darin, keine direkten Anmeldungen für das freigegebene Konto zuzulassen. Sie müssen sich als Sie selbst anmelden und mit dem Befehl "su" zum freigegebenen Konto wechseln. Dies dient der Protokollierung / Sicherheit.

Ich habe begonnen, die Authentifizierung mit öffentlichem / privatem SSH-Schlüssel mit einem Agenten zu verwenden, damit ich mein Kennwort einmal täglich eingeben und die Weiterleitung des Kennworts die Kennwortaufforderungen für den Rest des Tages eliminieren kann. Es ist wirklich nett.

Einige Systeme sind jedoch gesperrt, sodass ich den Befehl "su" verwenden muss, um zum freigegebenen Konto zu gelangen. Arg! Immer wieder Passwörter eingeben!

Gibt es genügend Informationen, die mit der Authentifizierung für öffentliche / private SSH-Schlüssel protokolliert wurden, sodass ich eine vernünftige Chance haben könnte, eine Richtlinienänderung anzufordern, um Remote-Anmeldungen bei einem freigegebenen Konto zuzulassen, wenn öffentliche / private Schlüssel verwendet werden?

Ich hatte einen Administrator-Look in / var / log / Secure und es heißt nur, dass ein öffentlicher Schlüssel für ein Benutzerkonto von einer bestimmten IP-Adresse akzeptiert wurde. Es wurde nicht angegeben, wer der öffentliche Schlüssel ist oder wer der private Schlüssel für die Authentifizierung ist.

Über die sshd_configDatei stehen viele Protokollierungsstufen zur Verfügung . Siehe die Manpage und suchen Sie nach LogLevel. Die Standardebene ist, INFOaber es ist trivial einfach, sie auf eine VERBOSEoder sogar eine der DEBUG#Ebenen zu bringen.

Darüber hinaus sollten Sie sudoals Alternative zu erkunden su. Eine vollständige Erörterung der Vorteile von sudowäre eine eigene Frage. Aber ich kann sagen, dass sudoSie mit anpassen können, wie oft Sie Ihr Passwort eingeben müssen, welche Befehle ausgeführt werden können usw., die alle über die sudoers- Konfigurationsdatei gesteuert werden können .

Eine andere Möglichkeit wäre, sich authorized_keysaußerhalb des Bereichs des Benutzers zu bewegen (z. B. nach /etc/ssh/authorized_keys), sodass nur Systemadministratoren steuern, welche öffentlichen Schlüssel zum Protokollieren bei bestimmten Konten verwendet werden können.

Früher haben wir die AuthorizedKeysFileRichtlinie in sshd_configFolgendes geändert .

AuthorizedKeysFile /etc/ssh/authorized_keys/%u

Erstellen Sie dann ein /etc/ssh/authorized_keysVerzeichnis und füllen Sie es mit Dateien für jeden Benutzer, der sich anmelden soll. Stellen Sie dabei sicher, dass die rootDatei nur für Root- und andere Dateien lesbar / beschreibbar ist, die von einem geeigneten Benutzer gelesen werden können, wie folgt:

-rw-------  1 root root    1,7K 2008-05-14 14:38 root
-rw-r-----  1 root john     224 2008-11-18 13:15 john

Jede Datei enthält eine Reihe von öffentlichen Schlüsseln, mit denen Sie sich bei einem bestimmten Konto anmelden können. Es ist durchaus üblich, dass für jedes Benutzerkonto auch eine entsprechende Gruppe vorhanden ist.

Die Verwendung öffentlicher / privater Schlüssel ist eine viel bessere Methode zur Steuerung des Remotebenutzerzugriffs. Sie müssen das Kennwort nicht jeden Monat ändern (Sie müssen es auch nicht festlegen) und müssen es nicht ändern, nur weil ein Mitarbeiter Ihr Unternehmen verlassen hat. Entfernen Sie einfach seinen öffentlichen Schlüssel. und natürlich können Sie mit SSH-Optionen ( http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8#SSHRC) genau festlegen, auf was und von wo aus ein bestimmter Benutzer möglicherweise Zugriff hat.

Die Authentifizierung mit öffentlichem / privatem SSH-Schlüssel ist von der Hostauthentifizierung getrennt. Sie haben hier kein Glück. Sie können jedoch beantragen, dass Mitglieder einer bestimmten Gruppe bestimmte Verwaltungsbefehle sudoohne Kennwort ausführen dürfen. Im folgenden Beispiel können Benutzer in der secretariesGruppe Konten verwalten:

# file: /etc/sudoers
...
%secretaries    ALL= NOPASSWD: /usr/bin/adduser, /usr/bin/rmuser   
...