emacs tramp working with gnome-keyring-daemon

Right now I have gnome-keyring-daemon set to start at login. If I run emacs -q and then open a file on a server using M-x find-file and then enter a file on a remote server such as /ssh:user@server:/home/user/.bashrc, then a GUI pops up and asks for my ssh private key password. I enter the correct password, and the file opens perfectly.

However, if the gnome-keyring-daemon password expires from the keyring, emacs still allows connection to the file without entering the password. For example, let's say I open a remote file, then kill the file with C-x k. Then I go to a terminal and type ssh-add -D. I can verify that this causes the keyring to forget the password by running ssh localhost (the GUI pops up and asks for the password.) But if I try and re-open the remote file in emacs using C-x C-f M-p RET, the file opens without requiring the password.

Running tramp-cleanup-all-connections fixes this issue i.e. the agent will correctly ask for a password if the key is not in the keyring. Setting tramp-persistency-file-name to nil does not seem to change the behavior.

What is an efficient way to fix this problem? Do I run tramp-cleanup-all-connections on some hook? Maybe on a timer? Does running this function have a negative impact on future tramp connections?

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

EDIT

I'm now on a different computer with new versions of the relevant packages, but I still see the same behavior.

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

I just ran the following steps:

Open emacs with emacs -Q
Eval (require 'tramp) and (setq tramp-verbose 10)
Open file on remote server using tramp; gnome-keyring-daemon GUI asked for SSH key password.
Killed the remote file using C-x k
In a terminal I ran ssh-add -D and verified that the password is no longer cached.
Re-opened remote file using C-x C-f M-p RET
Tramp opened file without asking for a password.

A copy of tramp's debug buffer is located at this pastebin.

jarvisschultz

Posted 2014-01-22T00:41:35.397

Reputation: 129

Answers

Tramp caches used passwords. You could disable this by setq password-cache nil)

Michael Albinus

Posted 2014-01-22T00:41:35.397

Reputation: 166

While the documentation for password-cache certainly suggests that it would fix my issue, setting it to nil has no effect on the behavior. In fact, even with password-cache set to nil tramp will still cache passwords that aren't even related to gnome-keyring-daemon. For example using tramp to open local files with sudo, the sudo password seems to be cached until I explicitly cleanup the connection (even with a nil password-cache). Perhaps it's a bug? – jarvisschultz – 2014-12-08T13:34:44.487

Hmm, there is also password-cache-expiry, which you could try to set to t. – Michael Albinus – 2014-12-09T22:31:51.950

According to that variable's doc, it is how many seconds passwords should be cached. Setting to nil disables expiring. Mine is globally set to 16. Emacs won't allow setting it to t. – jarvisschultz – 2014-12-10T23:40:45.773

Oops, yes. password-cache-expiry is not the place to edit. Another source of a cached password could be auth-source.el, which is always enabled by default in Tramp. Hard to say whether it comes in play, without debugging Tramp. You could set tramp-verbose to 10, and rerun your tests with emacs -Q. I could try then to check the traces. Don't worry, Tramp wil NOT write any password string into the traces. – Michael Albinus – 2014-12-11T08:58:15.780

I just edited my question with a link to the tramp debug logs. – jarvisschultz – 2014-12-11T18:37:04.147

I've checked the traces. There is just one connection to the remote host, documented at 12:12:11.291237. There was no password request; likely because all password handling was done via ssh-agent. Tramp was not involved in password sending. When you deactivate ssh-agent as described, the Tramp connection is still active. Since there is no new Tramp connection, there is also no password request, and that's why the remote file is opened. Looks to me like the expected behaviour. – Michael Albinus – 2014-12-11T21:03:58.147