Fehler beim ssh zum fernen Server bei Verwendung des sudo-Benutzers

621
user2232357

Versuch, ssh mit Remote-Computer über sudo-Benutzer auszuführen und Fehler zu erhalten, aber ssh durch meinen normalen Benutzer, der einen Verbindungsfehler ausführt. Hier ist der Detailprozess.

case_1 - ssh von normalem Benutzer - funktioniert gut

  • Melden Sie sich mit Hilfe von NormalUser / Password am Host-Computer an
  • generierter ssh-Schlüssel mit ssh-keygen. Habe den privaten ssh-Schlüssel id_rsa & id_rsa.pub bei HostMachine / NormalUser / .ssh.
  • Kopieren Sie die öffentlichen Schlüsseldaten HostMachine / NormalUser / .ssh / id_rsa.pub nach RemoteMachine / NormalUser / .ssh / Authorized_keys
  • Führen Sie auf HostMachine ssh NormalUser @ RemoteMachine aus. Melden Sie sich an der RemoteMachine an, ohne das Passwort zu fragen. Funktioniert gut.

case_2 - ssh von Sudo User - Verbindungsfehler

  • Melden Sie sich mit Hilfe von NormalUser / Password am Host-Computer an

  • Sudo für Power User mit Sudo Su - PowerUser

  • generierter ssh-Schlüssel mit ssh-keygen. Habe den privaten ssh-Schlüssel id_rsa & id_rsa.pub bei HostMachine / PowerUser / .ssh.

  • Kopieren Sie die öffentlichen Schlüsseldaten HostMachine / PowerUser / .ssh / id_rsa.pub nach RemoteMachine / PowerUser / .ssh / Authorized_keys

  • Führen Sie auf HostMachine ssh PowerUser @ RemoteMaehchine aus. Kann sich NICHT an der RemoteMachine anmelden. Unterer Fehler wird angezeigt

Ist der in Case_2 erwähnte Prozess im Unix / ssh-Protokoll nicht zulässig ? Wenn ja, dann können Sie ssh für PowerUser verwenden.

Wenn nicht durch Unix / ssh eingeschränkt, was fehlt mir hier.

Error--: 

debug2: we did not send a packet, disable method debug1: Next authentication method: publickey debug1: Trying private key: /lch/fxclear/PowerUser/.ssh/identity debug1: Offering public key: /lch/fxclear/PowerUser/.ssh/id_rsa debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 277 debug2: input_userauth_pk_ok: SHA1 fp 74:56:cd:eb:f5:00:32:22:9f:e6:42:38:b1:bc:45:b6:6e:00:2f:6e debug1: read PEM private key done: type RSA Connection closed by 10.81.37.35

Update_1--: Der gleiche Prozess wurde vom neuen Host-Server auf demselben Zielserver ausprobiert, ähnliches Verhalten für beide Benutzer, jedoch ein Bitdiff-Fehler wie unten.

Error--:

debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available (default cache: KEYRING:persistent:11175)  debug2: we did not send a packet, disable method debug1: Next authentication method: publickey debug1: Offering RSA public key: /lch/fxclear/PowerUser/.ssh/id_rsa debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg rsa-sha2-512 blen 279 debug2: input_userauth_pk_ok: fp SHA256:tSSIY3zE4zXhDddegqs4UvvfEGwjmHN54pNZWSekWMo Authentication failed.
0
Wenn Sie die id_rsa.pub von Ihrer HostMachine nach RemoteMachine kopiert haben, haben Sie daran gedacht, den .ssh-Ordner vor dem Kopieren zu erstellen? Überprüfen Sie auch die Ordnerberechtigungen Bungicasse vor 6 Jahren 0
Sie können auch einfach die Datei authorized_keys aus dem Ordner "NormalUser .ssh" in den Ordner "PowerUser .ssh" kopieren. Es gibt keinen Grund dafür, dass zwei verschiedene Benutzer dieselbe RemoteMachine verwenden Bungicasse vor 6 Jahren 0
Ja, auch diese Option versucht. Wie dem auch sei, das jetzt gelöst wurde, stellt sich als Einschränkung auf Gruppenebene heraus. Ich habe die detaillierte Antwort unten gegeben. user2232357 vor 6 Jahren 0

2 Antworten auf die Frage

0
jawu

Ich denke, hier gibt es ein Erlaubnisproblem. Anscheinend gehören id_rsa & id_rsa.pub zum root und können nicht gelesen werden.

Es gibt zwei mögliche Lösungen für Sie:

  1. Fügen Sie Ihren Benutzer der Root-Gruppe hinzu ( nicht empfohlen).

  2. Ändern Sie den Schlüsselbesitzer mit chown

Keiner der Benutzer NormalUser / PowerUser gehört zur Root-Gruppe. Aber die beiden Benutzer gehören eigentlich zu verschiedenen Gruppen, wird das einen Unterschied machen? user2232357 vor 6 Jahren 0
0
user2232357

Endlich in der Lage, dieses Problem zu lösen.

Es stellt sich heraus, dass es sich bei meiner Organisation um eine Unix-Gruppenebeneneinschränkung handelt, die ssh für die Remote-Anmeldung bei einer anderen Box verwenden kann.

Der "NormalUser" gehörte zu einer Gruppe (auf dem Remote-Host), in der die ssh-Remote-Anmeldung zulässig war, nicht jedoch für die Gruppe "PowerUser".

Auf dem RemoteHost fügte das Unix-Team der Gruppe "ssh allowed" den "PowerUser" hinzu, der jetzt einwandfrei funktioniert.

Verwandte Probleme