Bug 1256381
| Summary: | git signed commit : gpg-agent fails without asking the password, no prompt | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Andrei Stepanov <astepano> |
| Component: | git | Assignee: | Ondřej Pohořelský <opohorel> |
| Status: | CLOSED WONTFIX | QA Contact: | RHEL CS Apps Subsystem QE <rhel-cs-apps-subsystem-qe> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.1 | CC: | astepano, branto, hhorak, opohorel, pcahyna, tmraz |
| Target Milestone: | rc | Flags: | opohorel:
needinfo-
|
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-01-28 14:03:10 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Andrei Stepanov
2015-08-24 12:50:00 UTC
Do you have a proper pinentry package installed? $ rpm -qa | grep pinentry pinentry-gtk-0.8.1-14.el7.x86_64 pinentry-0.8.1-14.el7.x86_64 It is probably starting pinentry-gtk but it fails. What happens if you uninstall pinentry-gtk or run the ssh with X forwarding - ssh -Y <host> # yum remove pinentry-gtk Loaded plugins: langpacks, product-id, subscription-manager This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register. Resolving Dependencies --> Running transaction check ---> Package pinentry-gtk.x86_64 0:0.8.1-14.el7 will be erased --> Processing Dependency: pinentry-gui for package: seahorse-3.8.2-3.el7.x86_64 --> Running transaction check ---> Package seahorse.x86_64 0:3.8.2-3.el7 will be erased --> Finished Dependency Resolution Dependencies Resolved ============================================================================================================================================================================ Package Arch Version Repository Size ============================================================================================================================================================================ Removing: pinentry-gtk x86_64 0.8.1-14.el7 @anaconda/7.1 108 k Removing for dependencies: seahorse x86_64 3.8.2-3.el7 @anaconda/7.1 6.4 M Transaction Summary ============================================================================================================================================================================ Remove 1 Package (+1 Dependent package) Installed size: 6.5 M Is this ok [y/N]: y Downloading packages: Running transaction check Running transaction test Transaction test succeeded Running transaction Erasing : seahorse-3.8.2-3.el7.x86_64 1/2 Erasing : pinentry-gtk-0.8.1-14.el7.x86_64 2/2 Verifying : seahorse-3.8.2-3.el7.x86_64 1/2 Verifying : pinentry-gtk-0.8.1-14.el7.x86_64 2/2 Removed: pinentry-gtk.x86_64 0:0.8.1-14.el7 Does not help: $ git commit -s -S -F file You need a passphrase to unlock the secret key for user: "Andrei Stepanov (main) <astepano>" 2048-bit RSA key, ID 9A82842F, created 2015-06-10 ^C gpg: signal Interrupt caught ... exiting stanv:~ astepano$ ssh -Y -vvv aws OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011 debug1: Reading configuration data /Users/astepano/.ssh/config debug1: /Users/astepano/.ssh/config line 47: Applying options for * debug1: Reading configuration data /etc/ssh_config debug1: /etc/ssh_config line 20: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to aws [10.34.73.9] port 22. debug1: Connection established. debug3: Incorrect RSA1 identifier debug3: Could not load "/Users/astepano/.ssh/astepano.ssh-rsa" as a RSA1 public key debug1: identity file /Users/astepano/.ssh/astepano.ssh-rsa type -1 debug1: identity file /Users/astepano/.ssh/astepano.ssh-rsa-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.2 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1 debug1: match: OpenSSH_6.6.1 pat OpenSSH* debug2: fd 3 setting O_NONBLOCK debug3: load_hostkeys: loading entries for host "aws" from file "/Users/astepano/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /Users/astepano/.ssh/known_hosts:2 debug3: load_hostkeys: loaded 1 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01,ssh-rsa-cert-v00,ssh-rsa debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa-cert-v01,ssh-rsa-cert-v00,ssh-rsa,ssh-dss-cert-v01,ssh-dss-cert-v00,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm,aes256-gcm,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm,aes256-gcm,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc.se debug2: kex_parse_kexinit: hmac-md5-etm,hmac-sha1-etm,umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-ripemd160-etm,hmac-sha1-96-etm,hmac-md5-96-etm,hmac-md5,hmac-sha1,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-etm,hmac-sha1-etm,umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-ripemd160-etm,hmac-sha1-96-etm,hmac-md5-96-etm,hmac-md5,hmac-sha1,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib,zlib debug2: kex_parse_kexinit: none,zlib,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: curve25519-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm,aes256-gcm,chacha20-poly1305,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm,aes256-gcm,chacha20-poly1305,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc.se debug2: kex_parse_kexinit: hmac-md5-etm,hmac-sha1-etm,umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-ripemd160-etm,hmac-sha1-96-etm,hmac-md5-96-etm,hmac-md5,hmac-sha1,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-etm,hmac-sha1-etm,umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-ripemd160-etm,hmac-sha1-96-etm,hmac-md5-96-etm,hmac-md5,hmac-sha1,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5-etm debug1: kex: server->client aes128-ctr hmac-md5-etm none debug2: mac_setup: found hmac-md5-etm debug1: kex: client->server aes128-ctr hmac-md5-etm none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 126/256 debug2: bits set: 484/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: RSA 5a:b6:11:d8:63:58:11:09:0f:07:e2:8a:7b:37:d5:08 debug3: load_hostkeys: loading entries for host "aws" from file "/Users/astepano/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /Users/astepano/.ssh/known_hosts:2 debug3: load_hostkeys: loaded 1 keys debug3: load_hostkeys: loading entries for host "10.34.73.9" from file "/Users/astepano/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /Users/astepano/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug1: Host 'aws' is known and matches the RSA host key. debug1: Found key in /Users/astepano/.ssh/known_hosts:2 debug2: bits set: 523/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /Users/astepano/.ssh/astepano.ssh-rsa (0x7f9d79d01cf0), debug2: key: /Users/astepano/.ssh/astepano.ssh-rsa (0x0), explicit debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /Users/astepano/.ssh/astepano.ssh-rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 279 debug2: input_userauth_pk_ok: fp 39:b5:82:86:0b:36:4e:82:17:6f:7f:64:b7:08:5b:2a debug3: sign_and_send_pubkey: RSA 39:b5:82:86:0b:36:4e:82:17:6f:7f:64:b7:08:5b:2a debug1: Authentication succeeded (publickey). Authenticated to aws ([10.34.73.9]:22). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting no-more-sessions debug1: Entering interactive session. debug2: callback start debug2: fd 3 setting TCP_NODELAY debug3: packet_set_tos: set IP_TOS 0x10 debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 debug1: Sending environment. debug3: Ignored env TERM_PROGRAM debug3: Ignored env SHELL debug3: Ignored env TERM debug3: Ignored env TMPDIR debug3: Ignored env Apple_PubSub_Socket_Render debug3: Ignored env TERM_PROGRAM_VERSION debug3: Ignored env TERM_SESSION_ID debug3: Ignored env USER debug3: Ignored env SSH_AUTH_SOCK debug3: Ignored env __CF_USER_TEXT_ENCODING debug3: Ignored env PATH debug3: Ignored env PWD debug1: Sending env LANG = en_US.UTF-8 debug2: channel 0: request env confirm 0 debug3: Ignored env XPC_FLAGS debug3: Ignored env PINENTRY_USER_DATA debug3: Ignored env XPC_SERVICE_NAME debug3: Ignored env GPG_TTY debug3: Ignored env SHLVL debug3: Ignored env HOME debug3: Ignored env LOGNAME debug3: Ignored env SECURITYSESSIONID debug3: Ignored env _ debug2: channel 0: request shell confirm 1 debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel_input_status_confirm: type 99 id 0 debug2: PTY allocation request accepted on channel 0 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_status_confirm: type 99 id 0 debug2: shell request accepted on channel 0 Last login: Mon Aug 24 16:51:36 2015 from an.brq.redhat.com [astepano@aws ~]$ cd git/avocado-vt/ [astepano@aws avocado-vt]$ git commit -s -S -F file You need a passphrase to unlock the secret key for user: "Andrei Stepanov (main) <astepano>" 2048-bit RSA key, ID 9A82842F, created 2015-06-10 ^C gpg: signal Interrupt caught ... exiting That was exclusive or above - running the ssh with X forwarding makes sense with pinentry-gtk installed - it should show the GUI pinentry dialog. Okay, without pinentry-gtk on remote-machine and without X forwarding. Same result. Host aws.* HostName aws.spice.brq.redhat.com ForwardAgent yes ForwardX11 no User astepano Port 22 stanv:~ astepano$ ssh -vvv aws OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011 debug1: Reading configuration data /Users/astepano/.ssh/config debug1: /Users/astepano/.ssh/config line 48: Applying options for * debug1: Reading configuration data /etc/ssh_config debug1: /etc/ssh_config line 20: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to aws [10.34.73.9] port 22. debug1: Connection established. debug3: Incorrect RSA1 identifier debug3: Could not load "/Users/astepano/.ssh/astepano.ssh-rsa" as a RSA1 public key debug1: identity file /Users/astepano/.ssh/astepano.ssh-rsa type -1 debug1: identity file /Users/astepano/.ssh/astepano.ssh-rsa-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.2 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1 debug1: match: OpenSSH_6.6.1 pat OpenSSH* debug2: fd 3 setting O_NONBLOCK debug3: load_hostkeys: loading entries for host "aws" from file "/Users/astepano/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /Users/astepano/.ssh/known_hosts:2 debug3: load_hostkeys: loaded 1 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01,ssh-rsa-cert-v00,ssh-rsa debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa-cert-v01,ssh-rsa-cert-v00,ssh-rsa,ssh-dss-cert-v01,ssh-dss-cert-v00,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm,aes256-gcm,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm,aes256-gcm,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc.se debug2: kex_parse_kexinit: hmac-md5-etm,hmac-sha1-etm,umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-ripemd160-etm,hmac-sha1-96-etm,hmac-md5-96-etm,hmac-md5,hmac-sha1,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-etm,hmac-sha1-etm,umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-ripemd160-etm,hmac-sha1-96-etm,hmac-md5-96-etm,hmac-md5,hmac-sha1,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib,zlib debug2: kex_parse_kexinit: none,zlib,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: curve25519-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm,aes256-gcm,chacha20-poly1305,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm,aes256-gcm,chacha20-poly1305,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc.se debug2: kex_parse_kexinit: hmac-md5-etm,hmac-sha1-etm,umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-ripemd160-etm,hmac-sha1-96-etm,hmac-md5-96-etm,hmac-md5,hmac-sha1,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-etm,hmac-sha1-etm,umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-ripemd160-etm,hmac-sha1-96-etm,hmac-md5-96-etm,hmac-md5,hmac-sha1,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5-etm debug1: kex: server->client aes128-ctr hmac-md5-etm none debug2: mac_setup: found hmac-md5-etm debug1: kex: client->server aes128-ctr hmac-md5-etm none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 127/256 debug2: bits set: 504/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: RSA 5a:b6:11:d8:63:58:11:09:0f:07:e2:8a:7b:37:d5:08 debug3: load_hostkeys: loading entries for host "aws" from file "/Users/astepano/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /Users/astepano/.ssh/known_hosts:2 debug3: load_hostkeys: loaded 1 keys debug3: load_hostkeys: loading entries for host "10.34.73.9" from file "/Users/astepano/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /Users/astepano/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug1: Host 'aws' is known and matches the RSA host key. debug1: Found key in /Users/astepano/.ssh/known_hosts:2 debug2: bits set: 504/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /Users/astepano/.ssh/astepano.ssh-rsa (0x7fb9cb700170), debug2: key: /Users/astepano/.ssh/astepano.ssh-rsa (0x0), explicit debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /Users/astepano/.ssh/astepano.ssh-rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 279 debug2: input_userauth_pk_ok: fp 39:b5:82:86:0b:36:4e:82:17:6f:7f:64:b7:08:5b:2a debug3: sign_and_send_pubkey: RSA 39:b5:82:86:0b:36:4e:82:17:6f:7f:64:b7:08:5b:2a debug1: Authentication succeeded (publickey). Authenticated to aws ([10.34.73.9]:22). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting no-more-sessions debug1: Entering interactive session. debug2: callback start debug2: fd 3 setting TCP_NODELAY debug3: packet_set_tos: set IP_TOS 0x10 debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 debug1: Sending environment. debug3: Ignored env TERM_PROGRAM debug3: Ignored env SHELL debug3: Ignored env TERM debug3: Ignored env TMPDIR debug3: Ignored env Apple_PubSub_Socket_Render debug3: Ignored env TERM_PROGRAM_VERSION debug3: Ignored env TERM_SESSION_ID debug3: Ignored env USER debug3: Ignored env SSH_AUTH_SOCK debug3: Ignored env __CF_USER_TEXT_ENCODING debug3: Ignored env PATH debug3: Ignored env PWD debug1: Sending env LANG = en_US.UTF-8 debug2: channel 0: request env confirm 0 debug3: Ignored env XPC_FLAGS debug3: Ignored env PINENTRY_USER_DATA debug3: Ignored env XPC_SERVICE_NAME debug3: Ignored env GPG_TTY debug3: Ignored env SHLVL debug3: Ignored env HOME debug3: Ignored env LOGNAME debug3: Ignored env SECURITYSESSIONID debug3: Ignored env _ debug2: channel 0: request shell confirm 1 debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel_input_status_confirm: type 99 id 0 debug2: PTY allocation request accepted on channel 0 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_status_confirm: type 99 id 0 debug2: shell request accepted on channel 0 Last login: Mon Aug 24 16:54:19 2015 from dhcp130-209.brq.redhat.com [astepano@aws ~]$ cd git/avocado-vt/ [astepano@aws avocado-vt]$ git commit -s -S -F file You need a passphrase to unlock the secret key for user: "Andrei Stepanov (main) <astepano>" 2048-bit RSA key, ID 9A82842F, created 2015-06-10 gpg: signal Interrupt caught ... exiting And that is not the case I was asking for. Most probably the git commit -s obscures the tty and the curses pinentry dialog cannot be spawn. But the pinentry-gtk could still work. So, is it a bug or not ? It is a bug however it is not quite clear whether the bug is in git commit -s, or gnupg2 or pinentry. I have found that pinentry ate all cpu time PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19721 astepano 20 0 245220 4092 2968 R 9.4 0.1 272:00.54 pinentry-gtk-2 20210 astepano 20 0 245220 4092 2968 R 9.4 0.1 266:47.86 pinentry-gtk-2 21740 astepano 20 0 245220 4092 2968 R 9.4 0.1 252:40.43 pinentry-gtk-2 23920 astepano 20 0 114644 1216 876 R 9.4 0.0 234:55.77 pinentry-curses 19604 astepano 20 0 245220 4092 2968 R 9.1 0.1 275:12.29 pinentry-gtk-2 19633 astepano 20 0 245220 4092 2968 R 9.1 0.1 273:48.68 pinentry-gtk-2 19675 astepano 20 0 245220 4092 2968 R 9.1 0.1 272:43.26 pinentry-gtk-2 20153 astepano 20 0 245220 4092 2968 R 9.1 0.1 268:01.67 pinentry-gtk-2 20207 astepano 20 0 245220 4092 2968 R 9.1 0.1 266:55.80 pinentry-gtk-2 20337 astepano 20 0 245220 4092 2968 R 9.1 0.1 266:22.80 pinentry-gtk-2 20341 astepano 20 0 245220 4092 2968 R 9.1 0.1 266:22.74 pinentry-gtk-2 20810 astepano 20 0 245220 4088 2968 R 9.1 0.1 264:11.28 pinentry-gtk-2 23835 astepano 20 0 114644 1220 876 R 9.1 0.0 235:15.74 pinentry-curses 23910 astepano 20 0 114644 1220 876 R 9.1 0.0 235:01.79 pinentry-curses 24091 astepano 20 0 114644 1220 876 R 9.1 0.0 234:13.21 pinentry-curses 24357 astepano 20 0 114644 1220 876 R 9.1 0.0 233:14.87 pinentry-curses 19599 astepano 20 0 245220 4092 2968 R 8.8 0.1 275:47.68 pinentry-gtk-2 19915 astepano 20 0 245220 4092 2968 R 8.8 0.1 271:19.86 pinentry-gtk-2 20409 astepano 20 0 245220 4092 2968 R 8.8 0.1 266:33.21 pinentry-gtk-2 20421 astepano 20 0 245220 4092 2968 R 8.8 0.1 265:06.57 pinentry-gtk-2 24027 astepano 20 0 114644 1216 876 R 8.8 0.0 234:26.89 pinentry-curses 24144 astepano 20 0 114644 1220 876 R 8.8 0.0 234:08.90 pinentry-curses 21880 astepano 20 0 130024 1844 1260 R 0.7 0.0 0:00.22 top Let's reassign then to pinentry. I was able to reproduce and tap into the running pinentry (-curses) process. The process seems to be stuck waiting on input (waiting for password entry). It looks like the pinentry process was spawned in a way that does not attach a proper tty/stdin/stdout. Hence, I suspect this is not a pinentry issue. The wait should not be a busy-wait and pinentry should return proper error so at least the gnupg2 process is not stuck. Yeah, it should not and it was indeed already fixed upstream [1]. I can backport the patch as it is fairly simple [2] but it won't fix the underlying issue and the signing procedure still won't work [3]. It should work just fine with pinentry-gtk or pinentry-qt(4) though. Considering the quite late phase of 7.2 development cycle, I doubt the patch will make it into 7.2, though. We should probably have two separate bugzillas for this and aim it towards rhel 7.3. [1] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=commit;h=3803fd15942f2f25108e400be6cd6faef791c8f7 [2] the patch just checks whether we are on a tty and err out if we are not [3] I backported the fix and reran the command: # git commit -s -S -am 'meh' You need a passphrase to unlock the secret key for user: "Boris Ranto (Meh) <branto>" 2048-bit RSA key, ID 6BD56F5C, created 2015-08-26 gpg: cancelled by user gpg: skipped "6BD56F5C": Operation cancelled gpg: signing failed: Operation cancelled error: gpg failed to sign the data fatal: failed to write commit object # Yes, unfortunately I do not see too big chance to resolve the issue with the tty not being present. I suppose it would require changes to git. However I am still curious why the pinentry-qt or pinentry-gtk does not work if installed and the ssh is run with X forwarding. That case actually works fine on my test machine (at least for pinentry-gtk). However, there might be some wilder corner case where the auto-detection of the correct pinentry binary fails (I worked on fixing these corner cases and it should be properly fixed in recent fedoras). Anyway, if the auto-detection indeed fails, you can always run PINENTRY_BINARY=/usr/bin/pinentry-gtk git commit -s -S and that should fix that. btw: There is also a rhbz to backport the fix for corner cases back to rhel 7: https://bugzilla.redhat.com/show_bug.cgi?id=1231229 Also, there is bz1058972 for the issue discussed here (waiting indefinitely for input on something that is not a tty) so we can move this one back to gpg-agent/gnupg2. btw: There are also some hints in the bz on how this could be fixed in gpg-agent (setting ttyname OPTION). I suppose the gpg-agent does not know about the ttyname at the point it invokes pinentry unfortunately. Hmm, that sounds weird. Every program should know (be able to query via ttyname syscall) its tty, at least if it was invoked from a tty. If gpg-agent can't then this is probably a bug in git that runs gpg-agent in a non-tty environment. Note that gpg-agent is usually running in a non-tty environment however that is not a problem here. It should be informed about the tty by the gpg2 which does the signing. However the problem is that in this case even the gpg2 is probably being run by git in a non-tty environent and that needs to change. I do not think there is much that can be done with gpg here - it needs a tty for the agent to ask for the passphrase or there has to be a X DISPLAY. Reassigning to git for consideration. Hi folks! I was also able to reproduce this problem, however according to https://help.github.com/articles/telling-git-about-your-gpg-key/ it is sufficient to set GPG_TTY variable to value of the current running terminal. Can you please confirm that `GPG_TTY=$(tty) git commit -s -S` works for you as well? Setting the environment variable to current tty solved it for me, although I am currently not sure if there is a better solution than setting it manually. git could certainly set the GPG_TTY when invoked with stdin on terminal. (In reply to Tomas Mraz from comment #21) > However the problem is that in this case even the gpg2 is > probably being run by git in a non-tty environent and that needs to change. No, skisela verified (using "ps") that the gpg process spawned by git has a controlling terminal (same as the git process itself). The problem probably is that discovering the controlling terminal is not simple (see https://github.com/emptymonkey/ctty) so GPG does not do it. In the user manual of GPG (https://www.gnupg.org/documentation/manuals/gnupg/Invoking-GPG_002dAGENT.html), it is recommended to always set GPG_TTY in .bashrc. SCL do that for you if you use git from SCL. To clarify by non-tty environment I meant it with stdin to be something else than the controlling tty. Yes, it is a pipe, because git gives data to gpg on stdin. I failed to reproduce this bug under RHEL-8. Therefore I close this bug. Feel free to reopen it if it's still a valid bug. Red Hat Enterprise Linux version 7 entered the Maintenance Support 1 Phase in August 2019. In this phase only qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. Other errata advisories may be delivered as appropriate. This bug has been reviewed by Support and Engineering representative and does not meet the inclusion criteria for Maintenance Support 1 Phase. If this issue still exists in newer major version of Red Hat Enterprise Linux, it has been cloned there and work will continue in the cloned bug. For more information about Red Hat Enterprise Linux Lifecycle, please see https://access.redhat.com/support/policy/updates/errata/ |