8:37 a.m.
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
10:35 a.m.
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".
8:41 a.m.
On Mon, May 21, 2018 at 5:35 PM, Gordon Messmer <gordon.messmer(a)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
11:39 p.m.
On 05/22/2018 06:41 AM, Gianluca Cecchi wrote:
Do you have number of bugzilla?
https://bugzilla.gnome.org/show_bug.cgi?id=795699
https://bugzilla.redhat.com/show_bug.cgi?id=1568895
3:24 a.m.
On Wed, May 23, 2018 at 6:39 AM, Gordon Messmer <gordon.messmer(a)gmail.com>
wrote:
On 05/22/2018 06:41 AM, Gianluca Cecchi wrote:
>
> Do you have number of bugzilla?
>
https://bugzilla.gnome.org/show_bug.cgi?id=795699
https://bugzilla.redhat.com/show_bug.cgi?id=1568895
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(a)openssh.com
compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: umac-64(a)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(a)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(a)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
10:23 a.m.
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.
3:20 a.m.
On Tue, May 29, 2018 at 5:23 PM, Gordon Messmer <gordon.messmer(a)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
8:52 a.m.
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.
10:01 a.m.
On 30 May 2018 at 10:20, Gianluca Cecchi <gianluca.cecchi(a)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.
--
Ahmad Samir
10:02 a.m.
On 30 May 2018 at 17:01, Ahmad Samir <ahmadsamir3891(a)gmail.com> wrote:
On 30 May 2018 at 10:20, Gianluca Cecchi
<gianluca.cecchi(a)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
2152
days inactive
2161
days old
9 comments
3 participants
participants (3)
-
Ahmad Samir -
Gianluca Cecchi -
Gordon Messmer