Noch ein "ssh Agent Forwarding funktioniert nicht"

2023
Richard Hansen

Ich kann ssh von hostAbis hostBund von hostAbis hostCmit Schlüsseln, die in ssh-agent geladen sind, ohne Probleme ausführen. Wenn ich jedoch ssh -A hostBaus mache hostA, dann probiere es ssh hostCaus hostB. Die Authentifizierung mit einem öffentlichen Schlüssel funktioniert nicht und fragt nach meinem Passwort.

Ein paar Details:

  • Ich verwende das ssh-agent, was mit OpenSSH geliefert wird, nicht mit GNOME Keyring oder ähnlichem.

  • Sowohl ssh -v hostBvon hostAals auch ssh -v hostCvon hostAShow:

    debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/rhansen/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 279 debug1: Authentication succeeded (publickey).

  • Ich sehe meine Schlüssel, wenn ich laufe ssh-add -Lauf hostB.

  • Mein Schlüssel hostAist mit einem Passwort geschützt.
  • Ein hostB, /etc/ssh/sshd_configenthält NICHT AllowAgentForwarding no.
  • Auf allen drei Systemen läuft Ubuntu 15.10 (Wily) mit OpenSSH 6.6.1p1.

  • Wenn ich laufe ssh -vvv hostCaus hostB, wird die folgende protokolliert:

    ... debug2: key: /home/rhansen/.ssh/id_rsa ((nil)), debug2: key: /home/rhansen/.ssh/id_dsa ((nil)), debug2: key: /home/rhansen/.ssh/id_ecdsa ((nil)), debug2: key: /home/rhansen/.ssh/id_ed25519 ((nil)), debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/rhansen/.ssh/id_rsa debug3: no such identity: /home/rhansen/.ssh/id_rsa: No such file or directory debug1: Trying private key: /home/rhansen/.ssh/id_dsa debug3: no such identity: /home/rhansen/.ssh/id_dsa: No such file or directory debug1: Trying private key: /home/rhansen/.ssh/id_ecdsa debug3: no such identity: /home/rhansen/.ssh/id_ecdsa: No such file or directory debug1: Trying private key: /home/rhansen/.ssh/id_ed25519 debug3: no such identity: /home/rhansen/.ssh/id_ed25519: No such file or directory debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password

  • Wenn ich ssh -vvv hostBaus hostA, dann tun ssh hostC, wird die folgende von protokolliert hostAkurz vor der hostCPasswortabfrage:

    debug1: client_input_channel_open: ctype auth-agent@openssh.com rchan 2 win 65536 max 16384 debug2: fd 10 setting O_NONBLOCK debug3: fd 10 is O_NONBLOCK debug1: channel 2: new [authentication agent connection] debug1: confirm auth-agent@openssh.com

  • Mein ~/.ssh/configauf allen Systemen enthält die folgenden ungewöhnlichen Einstellungen (sowie einige allgemeine Einstellungen, die ich für nicht relevant halte):

    ControlMaster auto ProxyCommand sh ~/.ssh/proxy.sh '%h' '%p' '%r' IdentitiesOnly yes

Irgendwelche Ideen?

0
Welchen Agenten verwenden Sie auf hostA - dem Standard-SSH-Agenten von OpenSSH? GNOME-Schlüsselring? gpg-agent Festzug? grawity vor 8 Jahren 0
Auch etwas Besonderes in hostBs ~ / .ssh / config oder / etc / ssh / ssh_config (der Client, nicht sshd_config)? grawity vor 8 Jahren 0
Können Sie auch "ssh -vv hostC" ** von hostA ** angeben, um zu bestätigen, dass es wirklich der Agent ist, der die Schlüssel für die funktionierende direkte Verbindung bereitstellt? grawity vor 8 Jahren 0
@ grawity: Ich habe meine Frage aktualisiert Richard Hansen vor 8 Jahren 0

2 Antworten auf die Frage

2
Richard Hansen

Es stellte sich heraus, dass der Täter die folgende Zeile in mir war ~/.ssh/config:

IdentitiesOnly yes

Ich hatte das vor einiger Zeit hinzugefügt, als ich mit vielen Schlüsseln experimentierte, die "zu viele Versuche" zur Ablehnung führten. Ich habe es vergessen, als ich mit dem Experiment fertig war, also habe ich es nie entfernt. (Es hatte nie Probleme verursacht, bis ich mit der Agent-Weiterleitung begann.)

0
Gordster

Ich bin froh zu sehen, dass Sie das Problem selbst beheben konnten.

Ihr Problem war anders als das, das ich hatte, aber ich werde das hinzufügen, das ich hatte, nur für den Fall, dass jemand auf diesen Beitrag mit demjenigen stößt, den ich hatte.

In meinem Fall bestand das Problem darin, dass mein Heimatverzeichnis Berechtigungen von 775 hatte, was ssh nicht zulässt. Das .ssh / -Verzeichnis muss nicht nur 700 sein, und die Authorized_keys müssen 600 sein, sondern das Home-Verzeichnis selbst muss 755 oder darunter sein (z. B. 700).

Verwandte Probleme