I use a CentOS 7.5 machine, set up with pubkey authentication to ssh to remote servers. Normally, as soon as I ssh to the first server, I get a GNOME graphical prompt asking to type my passphrase to unlock the secret key, so it is not asked anymore during the GNOME session.

However, sometimes I get asked for the passphrase directly in the terminal:

Enter passphrase for key '/home/dr01/.ssh/id_rsa': 

This is annoying as then I would have to type the passphrase every time I connect to a server. Therefore, in these cases I simply reboot the machine.

The GNOME Keyring daemon runs at boot as /usr/bin/gnome-keyring-daemon --start --components=pkcs11.

Restarting it has no effect:

[dr01@centos7 ~]$ /usr/bin/gnome-keyring-daemon -r 
** Message: Replacing daemon, using directory: /run/user/1001/keyring

as afterwards it still asks for the private key's password in the command line.

I've also tried to restart it with

/usr/bin/gnome-keyring-daemon -r --unlock

but it hangs. A strace prints this:

read(3, "\335{\232\316.\353\335\22\16\277\321\f\326A\334\272\2\342\227\246V`\262\265\300\213@\273>%\303\2"..., 120) = 120
getrusage(RUSAGE_SELF, {ru_utime={0, 2440}, ru_stime={0, 7321}, ...}) = 0
times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 429541253
futex(0x7f0889a5e548, FUTEX_WAKE_PRIVATE, 2147483647) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f088aa6a000
mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f088aa66000
mlock(0x7f088aa66000, 16384)            = 0

and it freezes after the read(0,.

How can I fix this issue?

  • You're using the CentOS 7.x box as the GUI to SSH into other boxes, right?
    – slm
    Aug 11 '18 at 21:48
  • @slm Yes, via gnome-terminal-server.
    – dr_
    Aug 13 '18 at 7:07

When the passphrase prompt appears in the terminal, it probably means the SSH_AUTH_SOCK environment variable has not been passed to the ssh command in that context.

When using the GNOME keyring daemon as a SSH agent (or, indeed, any SSH agent), then the SSH_AUTH_SOCK variable should point to a UNIX socket which is created by either the SSH agent program (the GNOME keyring daemon in your case) or sshd, if you're working through a SSH connection and agent connection forwarding is enabled.

In other words, perhaps you've done something that causes the user environment to be reset. Perhaps you've used sudo and the SSH_AUTH_SOCK is not on the list of environment variables sudo is allowed to preserve? Or perhaps you're running the shell escape function of some other program, and that program does not pass the SSH_AUTH_SOCK variable through to the shell it runs?

  • The SSH_AUTH_SOCK variable exists and is set to a socket file /tmp/ssh-AlrHnqy0e5iD/agent.1546, but ssh always asks for the key passphrase in the terminal. The process with PID 1546 is /usr/libexec/gnome-session-binary --session gnome-classic.
    – dr_
    Sep 11 '18 at 14:34
  • That looks like a path for ssh-agent, not gnome-keyring-daemon. Do you have an ssh-agent process running as well?
    – zackse
    Nov 12 '18 at 21:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.