3

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 GNOME_KEYRING_CONTROL=/run/user/1001/keyring SSH_AUTH_SOCK=/run/user/1001/keyring/ssh

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 read(0,

and it freezes after the read(0,.

How can I fix this issue?

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

1 Answer 1

Reset to default
2
+50

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?

Improve this answer
2
  • 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. Commented Sep 11, 2018 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? Commented Nov 12, 2018 at 21:53

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.