QtPass does not honor $SSH_AUTH_SOCK env, requires running from terminal to sync via ssh/github

[Logicwax]

QtPass needs to be ran from terminal in order to honor the $SSH_AUTH_SOCK env variable in order to work with my yubikey for repo syncing (SSH connection to github)

This issue is present on my Ubuntu 20.04 and macOS catalina machines. For context:

1. I use GPG with a yubikey smartcard
2. I keep my pass db on my github account
3. I use my yubikey to auth all SSH sessions, such as to github (via gpg ssh auth socket)
4. I'm running GNOME on wayland, if that matters.

The solution is to just run qtpass from terminal. When it's ran from the GUI in any way (from gnome start-up applications in ubuntu, or gnome app launcher, or from the dock in macOS) then QtPass doesn't get the correct environment variables. Which is most likely the $SSH_AUTH_SOCK and $GPG_TTY environment variables. QtPass should have better handling for this IMHO.

I've tried editing the /usr/share/applications/qtpass.desktop file to include these vars when executing qtpass, but nothing seems to work. Any SSH sessions, git syncing, or pass commands at terminal work fine, its only QtPass that has this issue.

I've also tried
pinentry-program /usr/bin/pinentry-tty
pinentry-program /usr/bin/pinentry-gnome3

~/.gnupg/gpg-agent.conf:

pinentry-program /usr/bin/pinentry-gnome3
enable-ssh-support
write-env-file
use-standard-socket
default-cache-ttl 300
max-cache-ttl 1200
allow-loopback-pinentry

my env:

SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent.ssh

my ~/.bashrc or ~/.zshrc file

envfile="$HOME/.gnupg/gpg-agent.env"
if ( [[ ! -e "$HOME/.gnupg/S.gpg-agent" ]] && \
     [[ ! -e "/var/run/user/$(id -u)/gnupg/S.gpg-agent" ]] );
then
  killall pinentry > /dev/null 2>&1
  killall pinentry-tty > /dev/null 2>&1  
  gpgconf --reload scdaemon > /dev/null 2>&1
  pkill -x -INT gpg-agent > /dev/null 2>&1
  gpg-agent --daemon --enable-ssh-support > $envfile
fi

# Wake up smartcard to avoid races
gpg --card-status > /dev/null 2>&1
export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"

export GPG_TTY=$(tty)

Also I should note that decrypting/encrypting my passwords in QtPass works fine, makes my yubikey blink, and pops up the pin entry dialog. This is only for SSH repo syncing that QtPass has this problem. Also note, my yubikey is set to tap required mode (which is entirely the reason I even use pass/qtpass, as there is friction in decrypting my entire password store)

[issue-label-bot]

Issue-Label Bot is automatically applying the label bug to this issue, with a confidence of 0.59. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[tezeb]

If I understand correctly, when you run qtpass from terminal it uses environmental variables as expected(as do other apps like ssh or git). But when you start it from GUI it does not. If that's the case, than it does not seem to be a bug in QtPass. Instead you're probably not setting your variables correctly for the GUI, which makes them unavailable for QtPass when started from GUI. I would suggest looking into GNOME documentation for details on how to set environmental variables that are then passed on to the applications started from GUI.

…

On 04/09/2020 22:53, Matthew Brooks wrote: QtPass needs to be ran from terminal in order to honor the $SSH_AUTH_SOCK env variable in order to work with my yubikey for repo syncing (SSH connection to github) This issue is present on my Ubuntu 20.04 and macOS catalina machines. For context: 1. I use GPG with a yubikey smartcard 2. I keep my pass db on my github account 3. I use my yubikey to auth all SSH sessions, such as to github (via gpg ssh auth socket) 4. I'm running GNOME on wayland, if that matters. The solution is to just run qtpass from terminal. When it's ran from the GUI in any way (from gnome start-up applications in ubuntu, or gnome app launcher, or from the dock in macOS) then QtPass doesn't get the correct environment variables. Which is most likely the $SSH_AUTH_SOCK and $GPG_TTY environment variables. QtPass should have better handling for this IMHO. I've tried editing the /usr/share/applications/qtpass.desktop file to include these vars when executing qtpass, but nothing seems to work. Any SSH sessions, git syncing, or pass commands at terminal work fine, its only QtPass that has this issue. I've also tried pinentry-program /usr/bin/pinentry-tty pinentry-program /usr/bin/pinentry-gnome3 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#543>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGBHMYBLVEAUV5UFELF3LSEFHWLANCNFSM4QZLSHQA>.

[giovi321]

I have the same issue #515

[cmol]

I made a quick branch to test the SSH_AUTH_SOCK: https://github.com/cmol/QtPass/tree/ssh_testing

cmol@7be4d7c

[Logicwax]

I would suggest looking into GNOME documentation for details on how to set environmental variables that are then passed on to the applications started from GUI.

I've tried this on GNOME and it didn't work, and this isn't possible on macOS it seems as well. This one feature (or lack of) is really holding back adoption of password-store/QtPass by a lot of people I know. password-store + QtPass + gpg + ssh/github account + yubikeys (Set to touch requirement mode) = the most secure way to handle password storage IMHO, so anything to help UX of this helps.

[Logicwax]

I made a quick branch to test the SSH_AUTH_SOCK: https://github.com/cmol/QtPass/tree/ssh_testing

cmol@7be4d7c

awesome! Thanks for taking on the task!

[cmol]

It seems like it would be possible on OSX to pick up the agent with launchctl getenv SSH_AUTH_SOCK.

https://www.packetmischief.ca/2016/09/06/ssh-agent-on-os-x/

I'm wondering if OSX issues stem from people not using the stock ssh-agent on OSX breaks things?

gnome-keyring usually has it's socket down in /run/user/1000/keyring/ssh, but having a way to verify this as the correct path would be preferable. Like a dbus interface from gnome or something. Not sure if it exists or not.

For KDE, it seems like you would need to set SSH_ASKPASS to where ksshaskpass is installed.

If you're on windows my guess would be that pageant could be talked with somehow to get the socket.

Basically it comes down to looking at other ways to use ssh if:

• SSH_AUTH_SOCK is not provided by the system
• (optional) AND, The ssh key used has a passphrase

Again, environments, should generally just export this for usage, it shouldn't be the up to all the applications individually tp pick this up.

[giovi321]

I fixed it with ksshaskpass

[Logicwax]

I made a quick branch to test the SSH_AUTH_SOCK: https://github.com/cmol/QtPass/tree/ssh_testing

cmol@7be4d7c

Tested on my ubuntu machine and I do not see the status message with my SSH_AUTH_SOCK.

While I agree that applications shouldn't have to individually pick this up, there doesn't seem to be ANY configuration options in QtPass to set the socket at all. This is a really bad UX problem IMHO, because QtPass is only functional if it's executed from terminal in OSX and Linux.

[cmol]

I made a quick branch to test the SSH_AUTH_SOCK: https://github.com/cmol/QtPass/tree/ssh_testing
cmol@7be4d7c

Tested on my ubuntu machine and I do not see the status message with my SSH_AUTH_SOCK.

While I agree that applications shouldn't have to individually pick this up, there doesn't seem to be ANY configuration options in QtPass to set the socket at all. This is a really bad UX problem IMHO, because QtPass is only functional if it's executed from terminal in OSX and Linux.

I think you are misunderstanding the job of SSH_AUTH_SOCK.

I run a stock Ubuntu. Here gnome-keyring sets SSH_AUTH_SOCK on login to SSH_AUTH_SOCK=/run/user/1000/keyring/ssh. Whenever any program (ssh itself, nautilus with sftp, qtpass, etc.) wants to use ssh, my SSH_AUTH_SOCK asks gnome-keyring (that acts as an ssh-agent) for ssh key access, then gnome pops up a GUI dialog asking for my password for my ssh key, and I get access to whatever I need over ssh. This also means that I can run QtPass without starting an ssh-agent myself by hand.

QtPass should not ever set SSH_AUTH_SOCK, the system should. If you for some reason don't have gnome-keyring setting this, you should find out why. If QtPass were to set this variable, it would also need to run a ssh-agent, which does not make sense as most people have their system making some kind of keyring that handles this.

What QtPass COULD do was to check for an auth sock and if it was not present run its own ssh-agent. This might however lead to bad UX, as the user could now be queried for ssh passphrases in multiple ways (one for the system, another for QtPass), and should very rarely be needed unless people are running with a non stock system, or are running a distro where you set up things by hand and should know what is going on anyway.

What you CAN do, is run your own ssh-agent by hand, set SSH_AUTH_SOCK, and then run qtpass from a terminal, but that is definitely not the way it is supposed to be.

When it comes to OSX, I think there's issues if you have installed another bash via brew than the system one, and you will need to fix that yourself: https://www.packetmischief.ca/2016/09/06/ssh-agent-on-os-x/

When it comes to Windows, I think it is possible to set up gpg4win to act as an ssh-agent, though I have never done this successfully. I think putty and pagent uses another protocol for ssh-agent and so that will not work either.

I hope this helps you understand how ssh agents and auth sockets works on Linux/OSX/Windows, and helps you fix your installation.

[Logicwax]

I made a quick branch to test the SSH_AUTH_SOCK: https://github.com/cmol/QtPass/tree/ssh_testing
cmol@7be4d7c

Tested on my ubuntu machine and I do not see the status message with my SSH_AUTH_SOCK.
While I agree that applications shouldn't have to individually pick this up, there doesn't seem to be ANY configuration options in QtPass to set the socket at all. This is a really bad UX problem IMHO, because QtPass is only functional if it's executed from terminal in OSX and Linux.

I think you are misunderstanding the job of SSH_AUTH_SOCK.

I run a stock Ubuntu. Here gnome-keyring sets SSH_AUTH_SOCK on login to SSH_AUTH_SOCK=/run/user/1000/keyring/ssh. Whenever any program (ssh itself, nautilus with sftp, qtpass, etc.) wants to use ssh, my SSH_AUTH_SOCK asks gnome-keyring (that acts as an ssh-agent) for ssh key access, then gnome pops up a GUI dialog asking for my password for my ssh key, and I get access to whatever I need over ssh. This also means that I can run QtPass without starting an ssh-agent myself by hand.

QtPass should not ever set SSH_AUTH_SOCK, the system should. If you for some reason don't have gnome-keyring setting this, you should find out why. If QtPass were to set this variable, it would also need to run a ssh-agent, which does not make sense as most people have their system making some kind of keyring that handles this.

What QtPass COULD do was to check for an auth sock and if it was not present run its own ssh-agent. This might however lead to bad UX, as the user could now be queried for ssh passphrases in multiple ways (one for the system, another for QtPass), and should very rarely be needed unless people are running with a non stock system, or are running a distro where you set up things by hand and should know what is going on anyway.

What you CAN do, is run your own ssh-agent by hand, set SSH_AUTH_SOCK, and then run qtpass from a terminal, but that is definitely not the way it is supposed to be.

When it comes to OSX, I think there's issues if you have installed another bash via brew than the system one, and you will need to fix that yourself: https://www.packetmischief.ca/2016/09/06/ssh-agent-on-os-x/

When it comes to Windows, I think it is possible to set up gpg4win to act as an ssh-agent, though I have never done this successfully. I think putty and pagent uses another protocol for ssh-agent and so that will not work either.

I hope this helps you understand how ssh agents and auth sockets works on Linux/OSX/Windows, and helps you fix your installation.

I think you're misunderstanding me. I have never suggested QtPass to set the SSH_AUTH_SOCK environment variable, only to READ it. When I suggested there be an option in QtPass to set the socket, what I meant was to configure QtPass to read a specific socket path, such as setting it to something like /run/user/1000/gnupg/S.gpg-agent.ssh. I'm only suggesting this in case it's going to be too complex to figure out whatever SSH_AUTH_SOCK in the environment variables is set to.

for example, one can get QtPass to operate properly in a gnome environment on stock ubuntu by editing the file /usr/share/applications/qtpass.desktop
and setting the Exec line to something like this: Exec=env SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent.ssh qtpass and then from that point, simply clicking on QtPass will now work with my yubikey's, properly blinking them when it needs to SSH to github/wherever you host your password-store.

but now I have to tell everyone who downloads QtPass to do this. The deb package could automatically do this during install time, but what if the socket path changes? Ideally, it would be great if QtPass was able to grab SSH_AUTH_SOCK env var (from a UX standpoint, this would make this project polished for mainstream audience). A compromise would at least be to set its path in settings.

unfortunately, I haven't found a way to pass in environment variables to applications executed from the dock in macOS, and it's a pain having to instruct users to execute qtpass from terminal just so that they can operate it.

[Logicwax]

I guess at the very least, have the deb package install the following Exec line in the /usr/share/applications/qtpass.desktop file:

Exec=sh -c "SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket) qtpass"

that would insure it always grabs the latest.

[cmol]

I made a quick branch to test the SSH_AUTH_SOCK: https://github.com/cmol/QtPass/tree/ssh_testing
cmol@7be4d7c

Tested on my ubuntu machine and I do not see the status message with my SSH_AUTH_SOCK.
While I agree that applications shouldn't have to individually pick this up, there doesn't seem to be ANY configuration options in QtPass to set the socket at all. This is a really bad UX problem IMHO, because QtPass is only functional if it's executed from terminal in OSX and Linux.

I think you are misunderstanding the job of SSH_AUTH_SOCK.
I run a stock Ubuntu. Here gnome-keyring sets SSH_AUTH_SOCK on login to SSH_AUTH_SOCK=/run/user/1000/keyring/ssh. Whenever any program (ssh itself, nautilus with sftp, qtpass, etc.) wants to use ssh, my SSH_AUTH_SOCK asks gnome-keyring (that acts as an ssh-agent) for ssh key access, then gnome pops up a GUI dialog asking for my password for my ssh key, and I get access to whatever I need over ssh. This also means that I can run QtPass without starting an ssh-agent myself by hand.
QtPass should not ever set SSH_AUTH_SOCK, the system should. If you for some reason don't have gnome-keyring setting this, you should find out why. If QtPass were to set this variable, it would also need to run a ssh-agent, which does not make sense as most people have their system making some kind of keyring that handles this.
What QtPass COULD do was to check for an auth sock and if it was not present run its own ssh-agent. This might however lead to bad UX, as the user could now be queried for ssh passphrases in multiple ways (one for the system, another for QtPass), and should very rarely be needed unless people are running with a non stock system, or are running a distro where you set up things by hand and should know what is going on anyway.
What you CAN do, is run your own ssh-agent by hand, set SSH_AUTH_SOCK, and then run qtpass from a terminal, but that is definitely not the way it is supposed to be.
When it comes to OSX, I think there's issues if you have installed another bash via brew than the system one, and you will need to fix that yourself: https://www.packetmischief.ca/2016/09/06/ssh-agent-on-os-x/
When it comes to Windows, I think it is possible to set up gpg4win to act as an ssh-agent, though I have never done this successfully. I think putty and pagent uses another protocol for ssh-agent and so that will not work either.
I hope this helps you understand how ssh agents and auth sockets works on Linux/OSX/Windows, and helps you fix your installation.

I think you're misunderstanding me. I have never suggested QtPass to set the SSH_AUTH_SOCK environment variable, only to READ it. When I suggested there be an option in QtPass to set the socket, what I meant was to configure QtPass to read a specific socket path, such as setting it to something like /run/user/1000/gnupg/S.gpg-agent.ssh. I'm only suggesting this in case it's going to be too complex to figure out whatever SSH_AUTH_SOCK in the environment variables is set to.

for example, one can get QtPass to operate properly in a gnome environment on stock ubuntu by editing the file /usr/share/applications/qtpass.desktop
and setting the Exec line to something like this: Exec=env SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent.ssh qtpass and then from that point, simply clicking on QtPass will now work with my yubikey's, properly blinking them when it needs to SSH to github/wherever you host your password-store.

but now I have to tell everyone who downloads QtPass to do this. The deb package could automatically do this during install time, but what if the socket path changes? Ideally, it would be great if QtPass was able to grab SSH_AUTH_SOCK env var (from a UX standpoint, this would make this project polished for mainstream audience). A compromise would at least be to set its path in settings.

unfortunately, I haven't found a way to pass in environment variables to applications executed from the dock in macOS, and it's a pain having to instruct users to execute qtpass from terminal just so that they can operate it.

Ok, so I better understand you now but I am confused about why gpg-agent is controlling your ssh-agent on a stock ubuntu? I know that is is possible, but it is not stock, gnome-keyring is. You'll have to get your system to export the gpg-agent SSH_AUTH_SOCK system wide.

You can look at how gnome-keyring sets the SSH_AUTH_SOCK in: /usr/lib/systemd/user/gnome-keyring-ssh.service

[Logicwax]

for me personally, I use my GPG keys to supply my ssh keys. This is because I use yubikeys to hold my GPG key, which I then have gpg-agent supply for SSH operations.