emacs tramp arbeitet mit gnome-keyring-daemon

826
jarvisschultz

Im Moment habe ich mich gnome-keyring-daemonbeim Login angemeldet. Wenn ich emacs -qeine Datei auf einem Server starte und dann öffne, M-x find-fileund dann eine Datei auf einem Remote-Server eingeben, z. B. /ssh:user@server:/home/user/.bashrc, erscheint eine GUI und fragt nach meinem SSH-Kennwort für den privaten Schlüssel. Ich gebe das richtige Passwort ein und die Datei wird perfekt geöffnet.

Wenn das gnome-keyring-daemonKennwort jedoch vom Schlüsselbund abläuft, emacskann die Verbindung zur Datei auch ohne Eingabe des Kennworts hergestellt werden. Angenommen, ich öffne eine Remote-Datei und bringe die Datei dann mit ab C-x k. Dann gehe ich zu einem Terminal und tippe ssh-add -D. Ich kann überprüfen, dass dadurch der Schlüsselbund das Kennwort beim Ausführen vergisst ssh localhost(die GUI wird eingeblendet und fragt nach dem Kennwort.) Wenn ich jedoch versuche, die entfernte Datei in emacs erneut zu öffnen C-x C-f M-p RET, wird die Datei geöffnet, ohne dass das Kennwort erforderlich ist.

Durch Ausführen des tramp-cleanup-all-connectionsProblems wird dieses Problem behoben, dh der Agent fragt korrekt nach einem Kennwort, wenn sich der Schlüssel nicht im Schlüsselbund befindet. Die Einstellung tramp-persistency-file-nameauf nilscheint das Verhalten nicht zu ändern.

Wie kann dieses Problem effizient gelöst werden? Läuft ich tramp-cleanup-all-connectionsan einem Haken? Vielleicht auf einen Timer? Hat die Ausführung dieser Funktion einen negativen Einfluss auf zukünftige Fremdverbindungen?

  • emacs-version: GNU Emacs 24.3.1
  • tramp-version: 2.2.6-24.3
  • gnome-keyring-daemon --version: 3.2.2

BEARBEITEN

Ich befinde mich jetzt auf einem anderen Computer mit neuen Versionen der relevanten Pakete, sehe aber immer noch dasselbe Verhalten.

  • emacs-version: GNU Emacs 24.4.2
  • tramp-version: 2.2.9-24.4
  • gnome-keyring-daemon --version: 3.10.1

Ich habe gerade folgende Schritte ausgeführt:

  1. Emacs mit öffnen emacs -Q
  2. Eval (require 'tramp)und(setq tramp-verbose 10)
  3. Öffnen Sie die Datei auf dem Remote-Server tramp. gnome-keyring-daemon GUI fragt nach SSH-Schlüsselkennwort.
  4. Tötete die entfernte Datei mit C-x k
  5. In einem Terminal habe ich ausgeführt ssh-add -Dund überprüft, dass das Passwort nicht mehr zwischengespeichert wird.
  6. Remote-Datei erneut mit geöffnet C-x C-f M-p RET
  7. Tramp öffnete die Datei, ohne nach einem Passwort zu fragen.

Eine Kopie des Debug-Puffers von Tramp befindet sich in diesem Pastebin .

0

1 Antwort auf die Frage

0
Michael Albinus

Tramp-Caches verwendeten Passwörter. Sie können dies durch deaktivierensetq password-cache nil)

Die Dokumentation für "password-cache" legt zwar den Schluss nahe, dass dadurch mein Problem behoben wird. Die Einstellung auf "nil" hat jedoch keine Auswirkungen auf das Verhalten. Selbst wenn "password-cache" auf "nil" gesetzt ist, speichert tramp Kennwörter, die nicht einmal mit "gnome-keyring-daemon" zusammenhängen. Wenn Sie beispielsweise mit tramp lokale Dateien mit "sudo" öffnen, scheint das sudo-Kennwort zwischengespeichert zu werden, bis ich die Verbindung explizit bereinige (sogar mit keinem "password-cache"). Vielleicht ist es ein Fehler? jarvisschultz vor 9 Jahren 0
Hmm, es gibt auch "password-cache-expiry", das Sie versuchen könnten, auf "t" zu setzen. Michael Albinus vor 9 Jahren 0
Gemäß dem Dokument dieser Variablen werden die Passwörter in Sekunden zwischengespeichert. Die Einstellung "Null" deaktiviert das Ablaufdatum. Meins ist global auf 16 eingestellt. Emacs lässt es nicht zu, 't' zu setzen. jarvisschultz vor 9 Jahren 0
Hoppla, ja. `password-cache-expiry` ist nicht der Ort zum Bearbeiten. Eine andere Quelle eines zwischengespeicherten Kennworts könnte auth-source.el sein, das in Tramp standardmäßig aktiviert ist. Schwer zu sagen, ob es im Spiel kommt, ohne Tramp zu debuggen. Sie können "tramp-verbose" auf 10 setzen und Ihre Tests mit "emacs -Q" wiederholen. Ich könnte dann versuchen, die Spuren zu überprüfen. Machen Sie sich keine Sorgen, Tramp wird ** NOT ** keine Kennwortzeichenfolge in die Spuren schreiben. Michael Albinus vor 9 Jahren 0
Ich habe gerade meine Frage mit einem Link zu den Tramp-Debug-Protokollen bearbeitet. jarvisschultz vor 9 Jahren 0
Ich habe die Spuren überprüft. Es gibt nur eine Verbindung zum Remote-Host, dokumentiert um 12: 12: 11.291237. Es gab keine Passwortabfrage. Wahrscheinlich, weil die gesamte Passwortbehandlung über den ssh-agent erfolgte. Tramp war nicht am Passwortversand beteiligt. Wenn Sie den ssh-agent wie beschrieben deaktivieren, ist die Tramp-Verbindung noch aktiv. Da es keine ** neue ** Tramp-Verbindung gibt, gibt es auch keine Kennwortabfrage. Deshalb wird die entfernte Datei geöffnet. Sieht für mich wie das erwartete Verhalten aus. Michael Albinus vor 9 Jahren 0

Verwandte Probleme