Lösung 1:
Sie können den AuthorizedKeysFile verwenden Direktive in /etc/ssh/sshd_config, um dies zu tun. Der Standardspeicherort ist .ssh/authorized_keys aber Sie könnten etwas verwenden, das einen absoluten Pfad enthält, z. B.
AuthorizedKeysFile /path/to/your/keyfile
die Manpages sagen das
AuthorizedKeysFile
Gibt die Datei an, die die öffentlichen Schlüssel enthält, die für die Benutzerauthentifizierung verwendet werden können. AuthorizedKeysFile kann Token der Form %T enthalten, die beim Verbindungsaufbau ersetzt werden. Die folgenden Token sind definiert:%% wird durch ein wörtliches ’%’ ersetzt, %h wird durch das Home-Verzeichnis des zu authentifizierenden Benutzers ersetzt und %u wird durch den Benutzernamen dieses Benutzers ersetzt. Nach der Erweiterung wird AuthorizedKeysFile als absoluter Pfad oder relativ zum Home-Verzeichnis des Benutzers angenommen. Der Standardwert ist „.ssh/authorized_keys“.
Lösung 2:
Bearbeiten :Sie sollten die Antwort von @ Iain oben positiv bewerten. Es ist vollständig und genau. Meine Antwort unten ist auf gemeinsam genutzte private ausgerichtet Schlüssel - eindeutig ein Missverständnis meinerseits. Ich werde diese Antwort hier lassen, da ich sie für eine wertvolle Information halte, nur nicht für diese spezielle Frage.
Ich kenne Ihren Anwendungsfall nicht, aber ich bin versucht zu sagen:"Sie machen es falsch."
Jeder Benutzer sollte sein eigenes kepair haben. Auf diese Weise widerrufen Sie einfach diesen einen Schlüssel, wenn ein Benutzer das Unternehmen verlässt, versetzt wird, in eine Verwaltungsrolle befördert wird oder irgendetwas anderes der Widerruf von Rechten erfordert. Dies macht auch ein effektives Auditing viel, viel schwieriger.
Wenn Benutzer in der Lage sein müssen, sich als andere Benutzer auszugeben, sollten sie mit sudo so konfiguriert werden . Es ist normalerweise keine gute Idee, SSH-Schlüssel gemeinsam zu nutzen.
Lösung 3:
Ihre Administratoren sollten eine (für Ihre Umgebung) geeignete Kombination aus sudo verwenden und su .
ssh ist dafür nicht das richtige Werkzeug.
Widersprüchliche Bearbeitung (Tut mir leid, es sieht so aus, als hätte ich an Titelblindheit gelitten. Danke, Zoredache):
Setzen Sie alle Dienstkonten in denselben group , verwenden Sie diese Gruppe als Teil eines Match Block in sshd_config Geben Sie den AuthorisedKeysFile an Sie möchten, dass sie alle verwendet werden. (Die Übereinstimmungsgruppe ist so, dass alle Konten sind davon nicht betroffen.) Sie verfügen jedoch nicht mehr über individuelle AuthorisedKeysFiles. openssh-lpk kann zulassen, dass die einzelnen Konten zusätzlich ihre eigenen Schlüssel haben, aber da bin ich mir nicht sicher.