Description of problem: For security reasons, it is advisable to use `ssh-add -c`, so that each usage of the key is confirmed, when using ssh agent forwarding. `man ssh-add`: -c Indicates that added identities should be subject to confirmation before being used for authentication. Confirmation is performed by ssh-askpass(1). Successful confirmation is signaled by a zero exit status from ssh-askpass(1), rather than text entered into the requester. Unfortunately, using `ssh-add -c` results in ssh no longer working on fedora 31. This is a security concern as without this, a compromised remote host could use your ssh key to compromise all other hosts you have access to. Version-Release number of selected component (if applicable): openssh.x86_64 8.1p1-1.fc31 openssh-askpass.x86_64 8.1p1-1.fc31 How reproducible: always Steps to Reproduce: 1. ssh-add -D to remove keys if you've already unlocked them 2. ssh-add -c 3. ssh user@host Actual results: sign_and_send_pubkey: signing failed: agent refused operation user@host: Permission denied (publickey). Expected results: ssh to user@host works Additional info: A very similar issue has already been reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1719338 $ echo $SSH_ASKPASS /usr/libexec/openssh/gnome-ssh-askpass Executing '/usr/libexec/openssh/gnome-ssh-askpass' manually works just fine.
Debug log: debug1: Offering public key: /home/yannik/.ssh/id_rsa RSA SHA256://xxx agent debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 60 debug1: Server accepts key: /home/yannik/.ssh/id_rsa RSA SHA256://xxx agent debug3: sign_and_send_pubkey: RSA SHA256://xxx debug3: sign_and_send_pubkey: signing using rsa-sha2-256 sign_and_send_pubkey: signing failed: agent refused operation
Does it work if you start ssh-agent manually? Do you remember when it was working last time? I would be interested in debug logs from the ssh-agent, what is going on there. The referenced bug was missing the askpass binary, but your issue looks different.
@Jakob Jelen: Are you able to reproduce this? It does indeed work if I manually start the ssh-agent. So it seems like it is an issue with the ssh-agent started by gnome-keyring. I found a similar bug in the ubuntu bugtracker: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1812247
Right. It seems like there were some changes recently in the way how gnome-keyring is started and it looks like it no longer has DISPLAY environment variable set so ssh-agent can not issue askpass dialog. This is something that will need to be fixed in gnome-keyring invocation. Moving there.
I can confirm that this is caused by the missing DISPLAY variable. I was able to work around this by creating /etc/environment with content "DISPLAY=:1" and adding "session required pam_env.so" to "/etc/pam.d/gdm-password" before the "pam_gnome_keyring.so" line.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This is still broken.
Any chance you could look into this, Matthias?
I just confirmed this is still broken on a fresh fedora 33 install. The cause is still the missing $DISPLAY variable, which can be fixed using the workaround I mentioned on may 15th, 2020.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13. Fedora Linux 35 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.