1

When I ssh from my box (Arch Linux) to a remote box (Fedora server) using a key, it works with one user (user1) but don't with user2. Both users use the same ssh key: the one in user2 ssh home folder. (/home/user2/.ssh/id_rsa with correct modes).

On remote host, both users have a home directory with the same ~/.ssh/authorized_keys file.

EDIT

As per request, some config file:

On remote host:

/etc/ssh/sshd_config

Port XXXX Allowusers user1 user2 PermitRootLogin without-password #PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys #HostbasedAuthentication no PasswordAuthentication no ChallengeResponseAuthentication no UsePAM yes $ journalctl -u sshd Accepted publickey for user1 from XX.YY.XX.YY port XXXX ssh2: RSA SHA256:WT722lmf2CkXC8T6hGScDl+wZW71Ls3/U2W8FHh+vK4 <-- when connecting as user1 Connection closed by authenticating user user2 XX:YY:XX:YY port XXX [preauth] <-- when connecting as user2 

user2 (non working) home dir:

ls -la /home/user2 drwx------. 2 user2 user 4.0K Jan 31 19:18 .ssh/ ls -la /home/user2/.ssh -rw-------. 1 user2 user2 393 Jan 31 18:12 authorized_keys 

Selinux enabled on the server (default for fedora). Please note that user1 is the default existing user when server is new and user2 has been added by myself.

user1 (working)

ls -Za /home/user1 unconfined_u:object_r:ssh_home_t:s0 .ssh/ ls -Za /home/user1/.ssh unconfined_u:object_r:ssh_home_t:s0 ./ unconfined_u:object_r:user_home_dir_t:s0 ../ unconfined_u:object_r:ssh_home_t:s0 authorized_keys 

user2 (non working)

ls -Za /home/user2 unconfined_u:object_r:unlabeled_t:s0 .ssh/ ls -Za /home/user2/.ssh unconfined_u:object_r:unlabeled_t:s0 ./ unconfined_u:object_r:user_home_dir_t:s0 ../ unconfined_u:object_r:unlabeled_t:s0 authorized_keys 

diff: r:unlabeled vs r:ssh_home_

On local box:

user2@hortensia ➤➤ ~ % ls -al .ssh -rw------- 1 user2 user2 1.8K Jan 16 18:19 id_rsa -rw------- 1 user2 user2 396 Jan 16 18:19 id_rsa.pub user2@hortensia ➤➤ ~ % ls -al drwx------ 2 user2 user2 4.0K Feb 1 08:06 .ssh/ 

I can't figure out why ssh is working for user1 and not for user2. On remote host, I stoped sshguard and iptables, but it don't change anything. The sshd_config is very basic, has a line Allowusers with user1 and user2 and allow connection with key. When running ssh in verbose mode, I can see difference in message when user1 or user2 connect.

user1

 $ ssh -vv -p XX [email protected] .................... debug1: Next authentication method: publickey debug1: Offering public key: RSA SHA256:WT722lmf2CkXC8T6hGScDl+wZW71Ls3/U2W8FHh+vK4 /home/user2/.ssh/id_rsa debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg rsa-sha2-512 blen 279 debug2:input_userauth_pk_ok:SHA256:WT722lmf2CkXC8T6hGScDl+wZW71Ls3/U2W8FHh+vK4 debug1: Authentication succeeded (publickey). Authenticated to XX.YY.XX.YY ([XX.YY.XX.YY]:XXXX). debug1: channel 0: new [client-session] debug2: channel 0: send open debug1: Requesting [email protected] debug1: Entering interactive session. debug1: pledge: network debug1: client_input_global_request: rtype [email protected] want_reply 0 debug2: channel_input_open_confirmation: channel 0: callback start debug2: fd 3 setting TCP_NODELAY debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 debug2: channel 0: request shell confirm 1 debug2: channel_input_open_confirmation: channel 0: 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: Thu Feb 1 07:08:04 2018 from XX.YY.XX.YY [user1@dahlia ~]$ 

Now, when connecting with user2

$ ssh -vv -p XX [email protected] ........... debug1: Next authentication method: publickey debug1: Offering public key: RSA SHA256:WT722lmf2CkXC8T6hGScDl+wZW71Ls3/U2W8FHh+vK4 /home/user2/.ssh/id_rsa debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug1: Trying private key: /home/user1/.ssh/id_dsa debug1: Trying private key: /home/user1/.ssh/id_ecdsa debug1: Trying private key: /home/user1/.ssh/id_ed25519 debug2: we did not send a packet, disable method debug1: No more authentication methods to try. [email protected]: Permission denied (publickey,gssapi-keyex,gssapi-with-mic). 

After more than one day I am still unable to fix this error. Thank you for help/hints.

7
  • 2
    Don't tell what you have in your configuration files. Post the actual content of your configuration files, along with the permissions of the .ssh directories and files. The problem might be something you deem irrelevant. Commented Feb 1, 2018 at 8:11
  • Also, /var/log/auth.log on the server may tell you more. Commented Feb 1, 2018 at 8:40
  • post has been updated with more info Commented Feb 1, 2018 at 9:04
  • please also add ls -la for the non working user on the server. Commented Feb 1, 2018 at 9:12
  • post updated again as requested Commented Feb 1, 2018 at 9:27

1 Answer 1

2

Your ls -l output shows that additionally to the normal permissions selinux contexts are set:

ls -la /home/user2/.ssh -rw-------. 1 user2 user2 393 Jan 31 18:12 authorized_keys ^ this dot indicates additional selinux contextes 

Your ls -Z output shows that the type context of your .ssh directory and the files in it is set to unlabeled_t:

ls -Za /home/user2/.ssh unconfined_u:object_r:unlabeled_t:s0 ./ 

This context has to be set to ssh_home_t so sshd can use it.

Run

chcon -R -t ssh_home_t .ssh 

to set the context recursively on the .ssh directory.

1
  • # chcon -R -t ssh_home_t .ssh # ls -Za /home/user2/.ssh --> unconfined_u:object_r:ssh_home_t:s0 authorized_keys. Now I can ssh with user2 :-). Thank you so much for pointing this to me. Commented Feb 1, 2018 at 10:03

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.