cannot ssh to localhost: Permission denied (publickey,gssapi-keyex,gssapi-with-mic)

[Frédéric Bron]

I have installed the sshd service but cannot do
ssh localhost
because I get the following error:
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Same error from another computer targeting this one.

The strange thing is that I have exactly the same sshd_config file and
.ssh directory (with all file permissions 600, copied id_rsa.pub into
authorized_keys...) on another machine with the same F25 and it works.

sshd_config is:
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
SyslogFacility AUTHPRIV
PermitRootLogin no
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys
PasswordAuthentication no
ChallengeResponseAuthentication no
GSSAPIAuthentication yes
GSSAPICleanupCredentials no
UsePAM yes
X11Forwarding yes
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
Subsystem       sftp    /usr/libexec/openssh/sftp-server


I tried to compare the logs of ssh -vvv targetting the machine where
it fails and targetting the machin where it works and here is where it
becomes different on the machine where it fails:
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

What was before is similar and can be found below.

Frédéric

ebug2: key: .ssh/id_rsa (0x55d3b2a1fa30), explicit, agent
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info:
server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic
debug3: start over, passed a different list
publickey,gssapi-keyex,gssapi-with-mic
debug3: preferred
gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred:
gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
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: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1000)

debug2: we did not send a packet, disable method
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: .ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

[Ed Greshko]

On 06/20/17 22:24, Frédéric Bron wrote:
>  I have installed the sshd service but cannot do
>  ssh localhost
>  because I get the following error:
>  Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
>
>  Same error from another computer targeting this one. 

If you have in your sshd_config

PasswordAuthentication no

and your ~/.ssh/authorized_keys file set to allow group or other access in any way
you will get that error.

Set to 600 which is -rw-------.   and it should be fine.

-- 
Fedora Users List - The place to go to speculate endlessly

[Frédéric Bron]

>  If you have in your sshd_config
>  PasswordAuthentication no 
yes, I have that

>  and your ~/.ssh/authorized_keys file set to allow group or other
> access in any way
>  you will get that error.
>  Set to 600 which is -rw-------.   and it should be fine. 
authorized_keys, id_rsa and id_rsa.pub are all 400. 600 does not improve.
.ssh is 700.

Thanks,

Frédéric

[Ed Greshko]

On 06/20/17 22:48, Frédéric Bron wrote:
> > If you have in your sshd_config
> > PasswordAuthentication no
>  yes, I have that
>
> > and your ~/.ssh/authorized_keys file set to allow group or other access in any way
> > you will get that error.
> > Set to 600 which is -rw-------.   and it should be fine.
>  authorized_keys, id_rsa and id_rsa.pub are all 400. 600 does not improve.
>  .ssh is 700.
>  
Yes, I just realized you really did say that in your original message.  Late here.

The only way I could reproduce, so far, the error you're getting is by changing
authorized_keys to allow group/other access.

Going to try a few more things before I retire.

-- 
Fedora Users List - The place to go to speculate endlessly

[Ed Greshko]

On 06/20/17 22:55, Ed Greshko wrote:
>  Going to try a few more things before I retire. 

OK.....   The only other way I could reproduce the error is if the key that was
copied into authorized_keys isn't the correct key for the sending system or if I
managed to copy into authorized_keys in such a way that it was mangled.  For example,
each key needs to be on a single line with no CR/LF sequence.  If I managed to
violate that I also get the error.

-- 
Fedora Users List - The place to go to speculate endlessly

[Frédéric Bron]

thanks for looking at it.

>  OK.....   The only other way I could reproduce the error is if the
> key that was
>  copied into authorized_keys isn't the correct key for the sending system or if I
>  managed to copy into authorized_keys in such a way that it was mangled.  For example,
>  each key needs to be on a single line with no CR/LF sequence.  If I managed to
>  violate that I also get the error. 
But it is not the case.
authorized_keys and id_rsa.pub are the same and also the same as they
are on the other computer where it works!
(diff outputs no difference).

Frédéric

[Frédéric Bron]

>  OK.....   The only other way I could reproduce the error is if the
> key that was
>  copied into authorized_keys isn't the correct key for the sending system or if I
>  managed to copy into authorized_keys in such a way that it was mangled.  For example,
>  each key needs to be on a single line with no CR/LF sequence.  If I managed to
>  violate that I also get the error. 
also I regenerated a key pair with no improvement:

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/fred/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/fred/.ssh/id_rsa.
Your public key has been saved in /home/fred/.ssh/id_rsa.pub.
The key fingerprint is:
...
The key's randomart image is:
+---[RSA 2048]----+
...
+----[SHA256]-----+

$ cp id_rsa.pub authorized_keys

$ ssh localhost
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Frédéric

[Alessio Ciregia]

On Jun 20, 2017 17:52, "Frédéric Bron" <frederic.bron(a)m4x.org&gt; wrote:

>  OK.....   The only other way I could reproduce the error is if the
> key 
that was
>  copied into authorized_keys isn't the correct key for the sending
> system 
or if I
>  managed to copy into authorized_keys in such a way that it was
> mangled. 
For example,
>  each key needs to be on a single line with no CR/LF sequence.  If I
managed to
>  violate that I also get the error. 
also I regenerated a key pair with no improvement:


How many key pairs do you have in .ssh? Is this the only one?

Ciao
A.

[Frédéric Bron]

>  How many key pairs do you have in .ssh? Is this the only one? 
only one.

Frédéric

[Ed Greshko]

On 06/20/17 23:51, Frédéric Bron wrote:
> > OK.....   The only other way I could reproduce the error is if
> the key that was
> > copied into authorized_keys isn't the correct key for the sending system or if I
> > managed to copy into authorized_keys in such a way that it was mangled.  For
> example,
> > each key needs to be on a single line with no CR/LF sequence.  If I managed to
> > violate that I also get the error.
>  also I regenerated a key pair with no improvement:
>
>  $ ssh-keygen -t rsa
>  Generating public/private rsa key pair.
>  Enter file in which to save the key (/home/fred/.ssh/id_rsa):
>  Enter passphrase (empty for no passphrase):
>  Enter same passphrase again:
>  Your identification has been saved in /home/fred/.ssh/id_rsa.
>  Your public key has been saved in /home/fred/.ssh/id_rsa.pub.
>  The key fingerprint is:
>  ...
>  The key's randomart image is:
>  +---[RSA 2048]----+
>  ...
>  +----[SHA256]-----+
>
>  $ cp id_rsa.pub authorized_keys
>
>  $ ssh localhost
>  Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
>  
OK...  Well you didn't show the part where you change the permissions on
authorized_keys but I'll assume you did....

I still can't reproduce doing it this way on a new VM.   How about checking the
selinux contexts?

[egreshko@f26-b14 .ssh]$ ll -Z *
-rw-------. 1 egreshko egreshko unconfined_u:object_r:ssh_home_t:s0  398 Jun 21 01:35
authorized_keys
-rw-------. 1 egreshko egreshko unconfined_u:object_r:ssh_home_t:s0 1675 Jun 21 01:34
id_rsa
-rw-r--r--. 1 egreshko egreshko unconfined_u:object_r:ssh_home_t:s0  398 Jun 21 01:34
id_rsa.pub
-rw-r--r--. 1 egreshko egreshko unconfined_u:object_r:ssh_home_t:s0  171 Jun 21 01:35
known_hosts


-- 
Fedora Users List - The place to go to speculate endlessly

[Frédéric Bron]

>  I still can't reproduce doing it this way on a new VM.   How
> about checking the
>  selinux contexts?
>
>  [egreshko@f26-b14 .ssh]$ ll -Z *
>  -rw-------. 1 egreshko egreshko unconfined_u:object_r:ssh_home_t:s0  398 Jun 21 01:35
>  authorized_keys
>  -rw-------. 1 egreshko egreshko unconfined_u:object_r:ssh_home_t:s0 1675 Jun 21 01:34
>  id_rsa
>  -rw-r--r--. 1 egreshko egreshko unconfined_u:object_r:ssh_home_t:s0  398 Jun 21 01:34
>  id_rsa.pub
>  -rw-r--r--. 1 egreshko egreshko unconfined_u:object_r:ssh_home_t:s0  171 Jun 21 01:35
>  known_hosts 
Interesting, I have home_root instead of ssh_home. What does that
mean? Does it mean that I created the .ssh directory as root, then
chown it which is possible?
I am totally unaware about selinux. Each time I hear about it, it is
because I have a problem. I guess when it is useful, I do not see it.

-r--------. 1 fred fred unconfined_u:object_r:home_root_t:s0  386
2017-06-20 17:59 authorized_keys
-r--------. 1 fred fred unconfined_u:object_r:home_root_t:s0 1.8K
2016-11-17 08:44 fred-rsa
-r--------. 1 fred fred unconfined_u:object_r:home_root_t:s0  386
2017-06-20 14:16 fred-rsa.pub
lrwxrwxrwx. 1 fred fred unconfined_u:object_r:home_root_t:s0    8
2017-06-20 17:59 id_rsa -> fred-rsa
lrwxrwxrwx. 1 fred fred unconfined_u:object_r:home_root_t:s0   12
2017-06-20 17:59 id_rsa.pub -> fred-rsa.pub
-rw-------. 1 fred fred unconfined_u:object_r:home_root_t:s0  882
2017-06-20 15:19 known_hosts

Frédéric

[Frédéric Bron]

> > -rw-------. 1 egreshko egreshko
> unconfined_u:object_r:ssh_home_t:s0  398 Jun 21 01:35
> > authorized_keys
>
>  Interesting, I have home_root instead of ssh_home. What does that
>  mean? Does it mean that I created the .ssh directory as root, then
>  chown it which is possible?
>  I am totally unaware about selinux. Each time I hear about it, it is
>  because I have a problem. I guess when it is useful, I do not see it.
>
>  -r--------. 1 fred fred unconfined_u:object_r:home_root_t:s0  386
>  2017-06-20 17:59 authorized_keys 

that was the problem:
I removed .ssh, I let it be created by the system while try to ssh
localhost, then I created all the files again inside.
They now have unconfined_u:object_r:ssh_home_t:s0 context and I can ssh.

Could you explain me what was the issue and how I could change it
without having to recreate everything?

Thanks a lot, I was becoming totally crazy!!

Frédéric

[Paul W. Frields]

On Tue, Jun 20, 2017 at 08:36:22PM +0200, Frédéric Bron wrote:
>  >> -rw-------. 1 egreshko egreshko
> unconfined_u:object_r:ssh_home_t:s0  398 Jun 21 01:35
>  >> authorized_keys
>  >
>  > Interesting, I have home_root instead of ssh_home. What does that
>  > mean? Does it mean that I created the .ssh directory as root, then
>  > chown it which is possible?
>  > I am totally unaware about selinux. Each time I hear about it, it is
>  > because I have a problem. I guess when it is useful, I do not see it.
>  >
>  > -r--------. 1 fred fred unconfined_u:object_r:home_root_t:s0  386
>  > 2017-06-20 17:59 authorized_keys
>  
>  
>  that was the problem:
>  I removed .ssh, I let it be created by the system while try to ssh
>  localhost, then I created all the files again inside.
>  They now have unconfined_u:object_r:ssh_home_t:s0 context and I can ssh.
>  
>  Could you explain me what was the issue and how I could change it
>  without having to recreate everything?
>  
>  Thanks a lot, I was becoming totally crazy!! 
This command is probably the one you'd need:

  restorecon -rv ~/.ssh

You should see output for any file getting relabled for SELinux.

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
    The open source story continues to grow: http://opensource.com

[stan]

On Tue, 20 Jun 2017 20:36:22 +0200
Frédéric Bron <frederic.bron(a)m4x.org&gt; wrote:

>  >> -rw-------. 1 egreshko egreshko
>  >> unconfined_u:object_r:ssh_home_t:s0  398 Jun 21 01:35
>  >> authorized_keys  
>  >
>  > Interesting, I have home_root instead of ssh_home. What does that
>  > mean? Does it mean that I created the .ssh directory as root, then
>  > chown it which is possible?
>  > I am totally unaware about selinux. Each time I hear about it, it is
>  > because I have a problem. I guess when it is useful, I do not see
>  > it.
>  >
>  > -r--------. 1 fred fred unconfined_u:object_r:home_root_t:s0  386
>  > 2017-06-20 17:59 authorized_keys  
>  
>  
>  that was the problem:
>  I removed .ssh, I let it be created by the system while try to ssh
>  localhost, then I created all the files again inside.
>  They now have unconfined_u:object_r:ssh_home_t:s0 context and I can
>  ssh.
>  
>  Could you explain me what was the issue and how I could change it
>  without having to recreate everything? 
Another way, to change just a single file, or a few, you can use the
command chcon. It has a man page, but the command you would have used
in this case is
chcon -t home_t [file name]

If you ever suspect that selinux might be the issue, you can issue the
following command as root,
setenforce 0
and it will put selinux in permissive mode, warning about errors,
instead of aborting the process.
To return to enforcing mode, 
setenforce 1

[Ed Greshko]

On 06/21/17 02:36, Frédéric Bron wrote:
>  Thanks a lot, I was becoming totally crazy!! 

You're welcome.

I would have taken the route suggested by Paul to resolve the problem as it takes
care of all the files and directory at once.

-- 
Fedora Users List - The place to go to speculate endlessly

[Tom Horsley]

On Tue, 20 Jun 2017 16:24:59 +0200
Frédéric Bron wrote:

>  Same error from another computer targeting this one. 
Are the systems that work older systems? They recently
changed sshd to disable a lot of older encryption
and hash algorithms and wot-not. Perhaps it doesn't
like your old keys?

[Frédéric Bron]

>  Are the systems that work older systems? They recently
>  changed sshd to disable a lot of older encryption
>  and hash algorithms and wot-not. Perhaps it doesn't
>  like your old keys? 
no because I regenerated the key and got the same result.

I wonder if the users need to be part of a group to be able to connect by ssh?

Frédéric