Hello, I'm starting here in F28 to use gnome session again, after some Fedora versions...
I was in Mate up to some days ago and the ssh passphrase was in need to be inserted only once in mater-terminal, because I had this in my .bashrc (I think)
export SSH_ASKPASS="/usr/bin/ksshaskpass"
Now I see that my gnome-terminal continues to ask my passhprase without giving chance to save it into its keyring.
I read this https://wiki.gnome.org/Projects/GnomeKeyring/Ssh but I haven't completely understood it (if it is current)
It seems gnome-keyring-daemon is running
[g.cecchi@ope46 ~]$ ps -ef|grep keyr g.cecchi 1972 1 0 08:44 ? 00:00:13 /usr/bin/gnome-keyring-daemon --daemonize --login g.cecchi 16480 14954 0 15:11 pts/8 00:00:00 grep --color=auto keyr [g.cecchi@ope46 ~]$
but is there any other setting to do not to insert every time my passhrase?
Thanks, Gianluca
On 05/21/2018 06:37 AM, Gianluca Cecchi wrote:
I was in Mate up to some days ago and the ssh passphrase was in need to be inserted only once in mater-terminal, because I had this in my .bashrc (I think)
export SSH_ASKPASS="/usr/bin/ksshaskpass"
Not exactly. The "askpass" setting only controls which UI will be used to prompt you for your passphrase when adding a key to the agent. It doesn't determine whether or not an agent is running.
In GNOME, you should see a process named gnome-keyring-daemon, and a child process named ssh-agent. The agent process is the one that holds your keys in memory temporarily and handles public key authentication.
Now I see that my gnome-terminal continues to ask my passhprase without giving chance to save it into its keyring.
It seems there is a bug in the current release of gnome-keyring which will cause you to be unable to use any ssh keys if you have one or more "bad" public keys in ~/.ssh. Check that directory for any file whose name ends in ".pub". If you find any that don't have a matching private key, or any in the old RSA1 format, move them to a different directory or delete them.
If you don't see any bad public keys, check the output of the "echo $SSH_AUTH_SOCK" command in a terminal, as well as the output of "ssh-add -l".
On Mon, May 21, 2018 at 5:35 PM, Gordon Messmer gordon.messmer@gmail.com wrote:
On 05/21/2018 06:37 AM, Gianluca Cecchi wrote:
I was in Mate up to some days ago and the ssh passphrase was in need to be inserted only once in mater-terminal, because I had this in my .bashrc (I think)
export SSH_ASKPASS="/usr/bin/ksshaskpass"
Not exactly. The "askpass" setting only controls which UI will be used to prompt you for your passphrase when adding a key to the agent. It doesn't determine whether or not an agent is running.
In GNOME, you should see a process named gnome-keyring-daemon, and a child process named ssh-agent. The agent process is the one that holds your keys in memory temporarily and handles public key authentication.
Hello, thanks for answering.
Yes, I have
g.cecchi 1940 1 0 08:30 ? 00:00:02 /usr/bin/gnome-keyring-daemon --daemonize --login
and
g.cecchi 1937 1924 0 08:30 ? 00:00:00 /usr/bin/ssh-agent -a /run/user/1000/ssh-agent.socket
(this one is child of: g.cecchi 1924 1 0 08:30 ? 00:00:00 /usr/lib/systemd/systemd --user )
Now I see that my gnome-terminal continues to ask my passhprase without
giving chance to save it into its keyring.
It seems there is a bug in the current release of gnome-keyring which will cause you to be unable to use any ssh keys if you have one or more "bad" public keys in ~/.ssh. Check that directory for any file whose name ends in ".pub". If you find any that don't have a matching private key, or any in the old RSA1 format, move them to a different directory or delete them.
If you don't see any bad public keys, check the output of the "echo $SSH_AUTH_SOCK" command in a terminal, as well as the output of "ssh-add -l".
Inside my .ssh dir I have two public/private keys and if I run "ssh-keygen -l -f" against the 2 private key files, I get
2048 SHA256:omS0TcBvEGXvRL6IdOv+JRkbnBavXDxKCjTzzENcyFY no comment (RSA)
and
1024 SHA256:EyG8zjKsHLLbHGsG5hewWh5m2iX9WIyB4XkIKcndq6w no comment (DSA)
They should be ok, so.
And also:
$ echo $SSH_AUTH_SOCK /run/user/1000/keyring/ssh $
Do you have number of bugzilla? Gianluca
On 05/22/2018 06:41 AM, Gianluca Cecchi wrote:
Do you have number of bugzilla?
On Wed, May 23, 2018 at 6:39 AM, Gordon Messmer gordon.messmer@gmail.com wrote:
On 05/22/2018 06:41 AM, Gianluca Cecchi wrote:
Do you have number of bugzilla?
Thanks for the links, I'll observe them and eventually contribute. Actually latest updates brought in better (if you mind usability) or worse (if you mind security) behavior, not covered in the two bugs...
In fact now if I connect to a system with the key that has a passphrase from gnome-terminal, I can log in without even being asked about passphrase the first time??? I supposed at least across reboots there should be any cache maintained in this sense, if this is the case.... How can I check and eventually delete thsi cache to test and replicate behavior?
Example ssh session:
[g.cecchi@ope46 ~]$ ssh target_system Last login: Thu May 24 10:05:26 2018 from ope46.mydomain [g.cecchi@target_system ~]$
[g.cecchi@ope46 ~]$ ssh -v target_system OpenSSH_7.7p1, OpenSSL 1.1.0h-fips 27 Mar 2018 debug1: Reading configuration data /home/g.cecchi/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 54: Applying options for * debug1: Connecting to target_system [10.4.5.157] port 22. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file /home/g.cecchi/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/g.cecchi/.ssh/id_rsa-cert type -1 debug1: identity file /home/g.cecchi/.ssh/id_dsa type 1 debug1: key_load_public: No such file or directory debug1: identity file /home/g.cecchi/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/g.cecchi/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/g.cecchi/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/g.cecchi/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/g.cecchi/.ssh/id_ed25519-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/g.cecchi/.ssh/id_xmss type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/g.cecchi/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_7.7 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000 debug1: Authenticating to target_system:22 as 'g.cecchi' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: diffie-hellman-group-exchange-sha256 debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes128-ctr MAC: umac-64@openssh.com compression: none debug1: kex: client->server cipher: aes128-ctr MAC: umac-64@openssh.com compression: none debug1: kex: diffie-hellman-group-exchange-sha256 need=16 dh_need=16 debug1: kex: diffie-hellman-group-exchange-sha256 need=16 dh_need=16 debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<3072<8192) sent debug1: got SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: got SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: ssh-rsa SHA256:Q7lZSzT+e8X2W8vBlb/oF54JLfMdWwPbUtNwnLlOvBU debug1: Host 'target_system' is known and matches the RSA host key. debug1: Found key in /home/g.cecchi/.ssh/known_hosts:334 debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 4294967296 blocks debug1: Skipping ssh-rsa key g.cecchi@ope46.mydomain - not in PubkeyAcceptedKeyTypes debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available (default cache: KEYRING:persistent:1000)
debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available (default cache: KEYRING:persistent:1000)
debug1: Next authentication method: publickey debug1: Offering public key: DSA SHA256:EyG8zjKsHLLbHGsG5hewWh5m2iX9WIyB4XkIKcndq6w /home/g.cecchi/.ssh/id_dsa debug1: Server accepts key: pkalg ssh-dss blen 434 debug1: Authentication succeeded (publickey). Authenticated to target_system ([10.4.5.157]:22). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: pledge: network debug1: Sending environment. debug1: Sending env LANG = en_US.utf8 debug1: Sending env XMODIFIERS = @im=ibus Last login: Thu May 24 10:09:58 2018 from ope46.mydomain [g.cecchi@target_system ~]$
Possible relevant updates between others, from this morning:
gnome-terminal.x86_64 3.28.2-1.fc28 pam.x86_64 1.3.1-1.fc28
Gianluca
On 05/24/2018 01:24 AM, Gianluca Cecchi wrote:
Actually latest updates brought in better (if you mind usability) or worse (if you mind security) behavior, not covered in the two bugs...
In fact now if I connect to a system with the key that has a passphrase from gnome-terminal, I can log in without even being asked about passphrase the first time??? I supposed at least across reboots there should be any cache m
When you enter your passphrase for an ssh key in GNOME, there is a checkbox labeled something like "unlock this key automatically at login". If you click on that box, the passphrase for your key will be stored in the GNOME keyring, and the key will be unlocked without prompting you. You can use "seahorse" (aka "Passwords and Keys") to find and remove that stored passphrase if you prefer not to have that stored.
On Tue, May 29, 2018 at 5:23 PM, Gordon Messmer gordon.messmer@gmail.com wrote:
On 05/24/2018 01:24 AM, Gianluca Cecchi wrote:
Actually latest updates brought in better (if you mind usability) or worse (if you mind security) behavior, not covered in the two bugs...
In fact now if I connect to a system with the key that has a passphrase from gnome-terminal, I can log in without even being asked about passphrase the first time??? I supposed at least across reboots there should be any cache m
When you enter your passphrase for an ssh key in GNOME, there is a checkbox labeled something like "unlock this key automatically at login". If you click on that box, the passphrase for your key will be stored in the GNOME keyring, and the key will be unlocked without prompting you. You can use "seahorse" (aka "Passwords and Keys") to find and remove that stored passphrase if you prefer not to have that stored.
Thanks, indeed I find it in the section "OpenSSH Keys" of the Gnome Tool you referred. I don't remember to have chosen to store it anyway...
I would have preferred the chance to store for "session" as I was able to do with Mate. Instead here it seems it lasts forever.... This way the first time after power on you are asked the passphrase and until you power off the laptop you are not.
Gianluca
On 05/30/2018 01:20 AM, Gianluca Cecchi wrote:
Thanks, indeed I find it in the section "OpenSSH Keys" of the Gnome Tool you referred.
There is an ssh keys section, but I'm actually not sure that's used any more. As far as I know, the newest release of GNOME has actually done away with internal ssh key support rather than add support for ED25519 keys. GNOME keyring now simply runs the system ssh-agent for SSH key support.
The passphrase to unlock keys is one of those in the Passwords/login section, I just don't remember what it was labeled.
On 30 May 2018 at 10:20, Gianluca Cecchi gianluca.cecchi@gmail.com wrote:
Thanks, indeed I find it in the section "OpenSSH Keys" of the Gnome Tool you referred. I don't remember to have chosen to store it anyway...
I would have preferred the chance to store for "session" as I was able to do with Mate. Instead here it seems it lasts forever.... This way the first time after power on you are asked the passphrase and until you power off the laptop you are not.
Gianluca
The "login" gnome keyring is unlocked automatically at login if it has the same password as the user account.
I think that simply changing the password of that particular keyring, to a different password than your user account, will make it not get unlocked at login, and you'll have to enter the password after you login. I haven't tested this, but I think it's worth a shot.
Good luck.
On 30 May 2018 at 17:01, Ahmad Samir ahmadsamir3891@gmail.com wrote:
On 30 May 2018 at 10:20, Gianluca Cecchi gianluca.cecchi@gmail.com wrote:
Thanks, indeed I find it in the section "OpenSSH Keys" of the Gnome Tool you referred. I don't remember to have chosen to store it anyway...
I would have preferred the chance to store for "session" as I was able to do with Mate. Instead here it seems it lasts forever.... This way the first time after power on you are asked the passphrase and until you power off the laptop you are not.
Gianluca
The "login" gnome keyring is unlocked automatically at login if it has the same password as the user account.
I think that simply changing the password of that particular keyring, to a different password than your user account, will make it not get unlocked at login, and you'll have to enter the password after you login. I haven't tested this, but I think it's worth a shot.
Good luck.
Err... I forgot to add that you can change the keyring password using seahorse.
-
Ahmad Samir -
Gianluca Cecchi -
Gordon Messmer