3

I am setting up passwordless ssh from a client to a server.

I have two users, called user1 and user2. Both on the client and on the server, user1 has a home folder at /home/user1, i.e. the default folder when you create an account using the command useradd user1.

Both on the client and on the server, user2 has a home folder at /home2/user2. This was done by creating the user with the command useradd -m -d /home2/user2 user2. The reason for this is, I mounted /home2 on a larger 16TB disk and wished to give user2 more storage at its home folder.

I set up according to all recommendations. and I set /home2, /home2/user2, and /home2/user2/.ssh to the correct 700 permissions.

I found that after all these, passwordless ssh works for user1 from the client to the server, but does not work for user2. It still asks for password after I applied ssh-keygen and ssh-copy-id with user2 on the client to the server.

It puzzles me. Does it mean the home folder for user2 has to be /home/user2 and cannot be in other locations (e.g. /home2/user2)? Unfortunately I just got 100GB for the /home folder and I want more space for user2.

In response to requests for further information, I have just looked up into the server ssh log (/var/log/messages) after I issued an auto login from the client. The log says this:

Jan 20 09:42:55 SERVER dbus-daemon[2502]: [system] Activating service name='org.fedoraproject.SetroubleshootPrivileged' requested by ':1.39048' (uid=977 pid=2794759 comm="/usr/libexec/platform-python -Es /usr/sbin/setroub" label="system_u:system_r:setroubleshootd_t:s0") (using servicehelper)
Jan 20 09:42:55 SERVER dbus-daemon[2502]: [system] Successfully activated service 'org.fedoraproject.SetroubleshootPrivileged'
Jan 20 09:42:58 SERVER setroubleshoot[2794759]: SELinux is preventing /usr/sbin/sshd from read access on the file authorized_keys. For complete SELinux messages run: sealert -l 6b9fec5b-5b03-460b-8199-393d5863256b
Jan 20 09:42:58 SERVER setroubleshoot[2794759]: SELinux is preventing /usr/sbin/sshd from read access on the file authorized_keys.#012#012*****  Plugin catchall_labels (83.8 confidence) suggests   *******************#012#012If you want to allow sshd to have read access on the authorized_keys file#012Then you need to change the label on authorized_keys#012Do#012# semanage fcontext -a -t FILE_TYPE 'authorized_keys'#012where ...`

Please help me sort this out.

3
  • 1
    Is the authorized_keys file set up properly for user2 regardless of the home directory? Does the SSH server give any errors about it in the logs?
    – ilkkachu
    Jan 19, 2023 at 6:17
  • What does "not work" actually mean? Does it fail due to authentication issues, or due to permission issues, or is there some issue with starting the user's login shell on the remote host? What do you see if you run ssh -vv to try to connect? Is the user with the home2 home directory able to log in locally?
    – Kusalananda
    Jan 19, 2023 at 9:12
  • "not working" meaning it asks me to input password, despite me having completed the two steps of setting up passwdless ssh: (1) ssh-keygen (2) ssh-copy-id from the client to the server.
    – Swatow
    Jan 20, 2023 at 1:57

1 Answer 1

3

Which Linux distribution is used at the server, and does it use SELinux (check with sestatus)?

If it does, you would also need to do something like:

semanage fcontext -a -t home_root_t '/home2'
semanage fcontext -a -t user_home_dir_t '/home2/[^/]+'
semanage fcontext -a -t user_home_t '/home2/[^/]+/.+'
restorecon -rv /home2

to assign proper SELinux labels to /home2, the actual user home directories below it, and the users' files under /home2/<username> directories.

(The example labeling applies to RHEL9: older releases may have slightly different SELinux label structure. If unsure, use ls -ldZ /home; ls -lZ /home to verify the existing labels under /home and adjust the labels on /home2 to match.)

3
  • Thank you for the reply. My CentOS is 8 stream.
    – Swatow
    Jan 20, 2023 at 1:30
  • Thank you very much. I tried your four lines of commands, and all issues now resolved!
    – Swatow
    Jan 20, 2023 at 5:14
  • Your situation was basically identical to the issue I had to solve recently. Whenever you are using RHEL or other SELinux-enabled distribution and place e.g. user home directories in a non-standard location, you must also update the SELinux labelling rules to cover that location, or else the standard system services (or any services that have non-trivial SELinux rules applied to them) may have trouble accessing files in that location.
    – telcoM
    Jan 20, 2023 at 11:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .