I am connecting using ssh to a server. I have set up SSH Key-Based Authentication to this server.
After typing in a terminal ssh user@server.tld I will be ask in GUI to enter my passphrase to my private key (.ssh).
I don’t want to store the passphrase in the gnome-keyring.
When poping up this small GUI window I cannot switch any more to my KeePassXC password safe to get my passphrase. The display is fully blocked when the small GUI window shows up.
So I would like to be asked directly in my terminal instead in a separate GUI window.
It looks like the ssh command has configuration options to do what you want (ie: SSH_ASKPASS_REQUIRE). It looks like it is possible to make these setting on the command line or in ~/.ssh/config.
I already consult the man pages for ssh, ssh_config, etc. I did many try and error for ex. SSH_ASKPASS_REQUIRE="force" ssh user@server.tld or unset SSH_ASKPASS ssh user@server.tld or SSH_TTY=$(tty) ssh user@server.tld
…
Now to find where that gets configuration as removing the ssh component might do the trick.
It looks like one option is to set the environment variable
SSH_ASKPASS_REQUIRE="never"
for the gnome-keyring-daemon that pam starts on gdm login.
Another option would be to configure gnome-keyring-daemon to not include the ssh component but I have not found a way to get that done as it seems the way pam starts gnome-keyring-daemon is not configurable.
When I add
SSH_ASKPASS_REQUIRE="never"
to /etc/environment the gui prompt is not presented anymore. But the prompt in the terminal is for the user’s password on the remote machine. To use the sshkey I have been setting the identity in ~/.ssh/config but that is skipped.
To use sshkey I now have to supply the ssh command with the identity as well
ssh -i ~/.ssh/id hostname
and I am prompted on the command line in the terminal for the passphrase. In this case the ssh-agent is not used.
This is a pretty brute force method and information on how to configure the ssh-agent built into gnome-keyring-daemon is scarce. I like the idea of keeping the agent that is integrated in the gnome-keyring-daemon but keep all interactions on the command line.
On my systems I only need to properly configure the keys on both the client and the host.
Since I am working with a local network at home I simply copy all the files from ~/.ssh on the client to the same location on the server then when I log in it never asks for a password but automatically allows connection without the password. I use the same ~/.ssh/* files on all my systems and can use rsync and ssh interchangeably (bidirectional) from any host to any other host that has the same keys.
The only files that sometimes may present a problem are the ~/.ssh/known-hosts files which may have incorrect UUIDs and possibly require editing to remove offending entries. Other than that it requires nothing except copying the keys.
Yes I can avoid to be ask for the passphrase. Simply I could mark the checkbox “Unlock the key on Login” to True in GUI. Then the Password is stored in Gnome key-ring. Then I will never be ask for the passphrase.
But for some good reason I would like to be ask always for the passphrase in the terminal.
I am not sure it is possible to have it both ways. Only with the gnome key-ring (which is a separate function) could the gui perform differently than a terminal. If you do not set the ssh keys then it should always ask for the password and the key-ring could provide it from the gui while you manually enter it in the terminal.
I had one user who used the key-ring and forgot his master key to unlock the key-ring. Those entries were lost forever, even with running a system for months to attempt to recover his master key.
I think I achieved some success by installing pinentry-tty and exporting PINENTRY_BINARY=“/usr/bin/pinentry-tty” before I spawned gpg-agent and ssh-agent.
The relevant section of my ~/.bash_profile:
# Run Sway on TTY1
if [[ -x /usr/bin/sway ]] && [[ $(tty) == /dev/tty1 ]]; then
printf 'launching sway ...\n'
exec 0<&- &> /dev/null
export PINENTRY_BINARY="/usr/bin/pinentry-tty"
export GPG_TTY='/dev/tty1'
if [[ -z $SSH_AUTH_SOCK_GPG ]]; then
export SSH_AUTH_SOCK_GPG="$(gpgconf --list-dirs agent-ssh-socket)"
fi
if [[ -x /usr/bin/ssh-agent ]]; then
exec /usr/bin/ssh-agent -a "$XDG_RUNTIME_DIR/ssh.socket" /usr/bin/sway
else
exec /usr/bin/sway
fi
fi
Then, after signing out and back in, I got the following (redacted):
$ ssh example.com
Please unlock the card
Number: XX XXX XXX
Holder: Your's Truely
PIN:
But in that case, it was going through gpg-agent and I have pinentry-program /usr/bin/pinentry in ~/.gnupg/gpg-agent.conf.
I consult all the man pages a bit more in detail - so I got it now.
The GUI window to enter the passphrase is managed by the gnome-keyring-daemon.
gnome-keyring-daemon is working as default and act also as “agent” for GnuPG and ssh.
I assume that there is no easy way to avoid the input of the passphrase by the GUI window and to bypass to a terminal.
So all my tries with SSH_... ssh user@server.tld were more or less useless.
But we have ssh-agent.
eval $(ssh-agent -t 15m) && ssh-add will ask for the passphrase in the terminal. And with -t 15m I can control the lifetime of the given passphrase w/o entering again in the next 15 minutes.
Ah, right, what agent ssh will connect to is controlled by the SSH_AUTH_SOCK variable. You’d need to make sure that is pointing at the socket created by ssh-agent, not the one that goes to gnome-keyring-daemon.
Adding IdentityAgent $SSH_AUTH_SOCK (or IdentityAgent $SSH_AUTH_SOCK_GPG as the case may be) to your ~/.ssh/config might also help.
Giving up on using the agents built into gnome-keyring-daemon is a fine choice. I would be interested in seeing any comparison of the relative safety/security of other daemon choices.
Are you using gnome-keyring-daemon for anything else? It is possible to remove it from the PAM stack with authselect.
Then it looks like gnome-keyring-daemon can be started a couple of other ways: a user systemd unit or via xdg autostart. With those you can make configuration changes as desired rather than the restrictions that come with running it in the PAM stack.
systemctl --user cat gnome-keyring-daemon.service
ls -l /etc/xdg/autostart/gnome-keyring-*
Yes, the password gnome-keyring to store my evolution mail account passwords for autologin in evolution accounts.
I am interesting to avoid the gnome-keyring ssh agent funcs only.
No. authselect disable-feature with-pam-gnome-keyring -b
has no effect. authselect list-features local shows the same list as before.
gnome-keyring is still active.
I am not sure how to manage them safely. I am not a fan of editing the files manually. They would probably get overwritten on the next gdm update as well.
Since you still use gnome-keyring-daemon, running additional agents and setting environment variables to use them instead where appropriate is a quite workable solution.
Sorry for the misinformation! I need to improve my testing.
To disable ssh “agent” from gnome-keyring: mkdir -p ~/.config/autostart cd ~/.config/autostart cp /etc/xdg/autostart/gnome-keyring-ssh.desktop . vim gnome-keyring-ssh.desktop
Add at the end of the file:
X-GNOME-Autostart-enabled=false
reboot
Then $SSH_AUTH_SOCK is empty then and ssh-agent and ssh-add can be used.
The stored passwords in gnome-keyring (ex. to evolution emails) still exists and will be triggered when launching evolution w/o entering the password.
To delete the gnome-keyring identities (like ssh-add -D): rm -rf ~/.local/share/keyrings
Maybe there are better ways, but this is what I found out …
I did not find out how to customize the configuration of the gnome-keyring-daemon that is started via the PAM stack that is traversed with a gdm login on my own. I should be able to make this a system wide customization by editing /etc/xdg/autostart/gnome-keyring-ssh.desktop but they would get overwritten with a gnome-keyring package update. Still, very helpful.
There is so much going on with gnome, gdm, pam and systemd that the login process is daunting. Thanks for starting this topic.