Stellen Sie sich folgendes Szenario vor:
Ich bin auf ServerA als Benutzer 'common' angemeldet. Das Wichtigste angemeinsam Der Nachteil des Benutzers besteht darin, dass eine Menge Leute darauf zugreifen können. Der Zugriff ist von Natur aus uneingeschränkt und unsicher.
Nehmen wir an, ich muss mich regelmäßig von diesem Benutzer/Server aus anmelden, umServerBals Benutzersicher- d. h. ich muss Dateien per SCP übertragen, die Eigentum vonsicher@serverB.
Während ich vollen Zugriff und Kontrolle habe übersicherBenutzer, ich möchte sicherlich nicht hinzufügengemeinsam's öffentlicher Schlüssel zu vertrauenswürdigen Schlüsseln fürsicherBenutzer - Ich möchte nicht, dass sich jemand alsgemeinsamum sich anmelden zu können alssichersowie.
Ich möchte auch nicht eingebensicher's Passwort 5 Mal pro Stunde. Idealerweise würde ich es gerne einmal eingeben, es von einem Agenten oder so auf magische Weise merken lassen – aber nur für diese Anmeldesitzung – und es dann jedes Mal verwenden, wenn ich mich von dieser Sitzung aus verbinde, bis das Timeout abläuft. kinitEigentlich nicht unähnlich .
Gibt es etwas, mit dem dieses Ziel erreicht werden könnte?
Antwort1
Es ist nicht so einfach, wenn Sie einen gemeinsamen Benutzer auf einem Zwischenserver haben und dieser Benutzer Shell-Zugriff hat, da dort standardmäßig fast alles von jeder anderen Sitzung aus zugänglich ist.
In modernen Kerneln gibt es dafür natürlich Möglichkeiten.
Entweder könnte es ein Tool geben, das Sitzungsschlüsselringe (Prozess/Thread) verwendet, um die privaten Daten im Kernel zu speichern, oder das System kann wahrscheinlich so sicher gemacht werden, dass den verschiedenen Prozessen desselben Benutzers der gegenseitige Zugriff verwehrt wird, sodass ein Programm die Authentifizierungsinformationen auch im normalen Benutzerspeicher geschützt vor anderen Sitzungen speichern könnte. Auf jeden Fall mussten beide Anfragen zur Durchführung der Authentifizierung anhand einiger PID/SID-Informationen identifizieren, die für die grundlegende Verwendung funktionieren. Am Ende brauchen Sie einen Daemon, der die Sitzung für Sie einrichtet oder die gespeicherten Passwörter an Ihren Prozess übermittelt, sodass Sie ihn mit dem Tool „sshpass“ oder ähnlichem verwenden können.
Ein anderer Ansatz besteht darin, Namespaces zu verwenden und ein privates tmpfs oder tmpdir bereitzustellen (wobei tmpfs besser geschützt oder für Root-Benutzer zumindest weniger leicht zugänglich ist als tmpdir).
Sie können entweder sshd auf einem separaten Port mit einem Wrapper verwenden, der die Namespace-Umgebung für diesen Benutzer einrichtet, oder, was auf einem modernen System am einfachsten ist, pam und pam_namespace.so verwenden, um ein privates Benutzer-tmpdir oder tmpfs einzurichten. Dort können Sie entweder Ihr Passwort im Klartext speichern, damit es von sshpass oder ähnlichem verwendet werden kann, oder noch besser den Socket für den ssh-Agenten in dieses Verzeichnis legen und Ihren persönlichen privaten Schlüssel in diesen Agenten laden und dabei sicherstellen, dass der Zugriff auf den Agenten vor dem Zugriff durch andere Sitzungen desselben Benutzers geschützt ist. Wenn Sie einen privaten Schlüssel mit einem starken Passwort haben, können Sie ihn auch auf der Maschine speichern. Andernfalls müssten Sie ihn übertragen. Sie können auch das ganze /tmp-Verzeichnis zu einem solchen privaten Verzeichnis machen (eventuell mit einigen gemeinsam genutzten Unterverzeichnissen) und die SSH-Agent-Weiterleitung auf ziemlich sichere Weise nutzen (Sie können es nicht wirklich vor Missbrauch durch Root-Benutzer schützen, aber zumindest wenn Sie tmpfs verwenden, ist es für Root schwierig und für normale Benutzer nicht möglich, den Auth-Socket zu verwenden).
Allerdings muss der Server ausreichend konfiguriert sein bzw. zumindest so konfiguriert sein, dass sich die Prozesse der Benutzer nicht gegenseitig anhängen können.
Antwort2
Sie suchen wahrscheinlich nachssh-agent, das mit OpenSSH geliefert wird. Verwenden Sie die -tOption, um ein Timeout festzulegen.