Почему ssh/sshd на сервере пытается получить доступ к /home/<user>/.ssh после того, как я переместил домашний каталог своих пользователей?

Question

Я переместил домашний каталог своих пользователей с usermod -m -d /path/to/new/home/username который, кажется, работал нормально.

Тем не менее, в моем [перемещенном] домашнем каталоге у меня есть папка «.ssh», которая настроена так, чтобы я мог подключаться с другого хоста, используя аутентификацию с открытым ключом, без пароля. Это (аутентификация открытого ключа без пароля) работало нормально при подключении с "клиентской" рабочей станции до того , как я переместил свой домашний каталог.

man sshd говорит , что расположение authorized_keys файл по умолчанию ~/.ssh/authorized_keys и мой sshd_config не отменяет его , потому что он не имеет директив AuthorizedKeysFile установить на всех.

Всякий раз, когда я подключаюсь к хосту с моего "клиента", он запрашивает пароль. Это не должно, это должно просто войти в систему прямо из-за открытого ключа аутентификации. Я подозреваю, что sshd на хосте все еще думает, что мой домашний каталог - /home/<user> , или, в худшем случае, настаивает на добавлении моего имени пользователя к некоторому предполагаемому префиксу, который больше не действителен.

Интересно, что если я создаю другой sshd -de -p 23 и подключусь к хосту через этот порт с помощью ssh -p 23 ... (та же командная строка, что и в противном случае, только с добавленным -p 23 ), он распознает мой новый Путь к домашнему каталогу на хосте и логинит меня в самом деле.

Я попытался перезагрузить и перезапустить sshd с помощью перезапуска service sshd reload и service sshd restart , и, наконец, даже перезагрузил хост. Ничего не изменилось в отношении sshd запрашивающего у меня пароль.

С чего начать отладку? Я на CentOS 6.5 x86-64.

Обновить

Теперь у меня есть четкое указание на то, что это связано с SELinux. Очевидно, что контекст безопасности в новом домашнем каталоге неверен, но это почти все, что я обнаружил. SELinux был установлен в системе без моего ведома, и я ничего не знаю об этом (и я не должен этого делать, поскольку я не трогал его, а полагался на usermod -m -d ... для выполнения работы, которую он должен был выполнить),

Answer 1

Одним из решений является изменение конфигурации SELinux, чтобы SELinux знал контекст, необходимый в этом контексте:

semanage fcontext -a -s unconfined_u -t ssh_home_t '/path/to/your/new/home/\.ssh(/.*)?'

Это вдохновлено выводом semanage fcontext -l | grep ssh , который в моей системе показывает, что /root также управляется таким образом.

Обратите внимание, что я выбрал пользователя SELinux без unconfined_u - если вы собираетесь использовать другого пользователя, например, если этот дом предназначен для службы, было бы разумно вместо этого выбрать system_u .