У меня есть новый ящик RHEL4 Linux, который я использую для копирования данных в старые ящики Solaris 2.6 и RHEL3 Linux с помощью scp. Я обнаружил, что при такой же настройке он работает для некоторых пользователей, но не работает для других. Для пользователя jane это отлично работает:
Джейн @ host1 $ ssh -v remhost
debug1: Next authentication method: publickey
debug1: Trying private key: /mnt/home/osborjo/.ssh/identity
debug1: Offering public key: /mnt/home/osborjo/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
для пользовательского разъема это не так:
Джек @ host1 ssh -v remhost
debug1: Next authentication method: publickey
debug1: Trying private key: /mnt/home/oper1/.ssh/identity
debug1: Offering public key: /mnt/home/oper1/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Я посмотрел разрешения для всех ключей и файлов, они выглядят одинаково. Поскольку я использую домашние каталоги, смонтированные с помощью NFS, ключи и для удаленного, и для локального хоста находятся в одном каталоге. Вот как обстоят дела с Джейн:
Джейн @ host1 $ ls -l $ HOME / .ssh
-rw-rw-r-- 1 jane operator 394 Jan 27 16:28 authorized_keys
-rw------- 1 jane operator 1675 Jan 27 16:27 id_rsa
-rw-r--r-- 1 jane operator 394 Jan 27 16:27 id_rsa.pub
-rw-rw-r-- 1 jane operator 1205 Jan 27 16:46 known_hosts
Для пользовательского разъема:
jack @ host1 $ ls -l $ HOME / .ssh
-rw-rw-r-- 1 jack engineer 394 Jan 27 16:28 authorized_keys
-rw------- 1 jack engineer 1675 Jan 27 16:27 id_rsa
-rw-r--r-- 1 jack engineer 394 Jan 27 16:27 id_rsa.pub
-rw-rw-r-- 1 jack engineer 1205 Jan 27 16:46 known_hosts
В качестве последней попытки я скопировал authorized_keys, id_rsa и id_rsa.pub с jill на jack и изменил имя пользователя в authorized_keys и id_rsa.pub с помощью vi. Это все еще не сработало. Кажется, что между двумя пользователями есть что-то разное, но я не могу понять, что это такое.
Я нашел ответ. Это было в разрешениях домашнего каталога пользователя jack. Пользователь jack имел права групповой записи в домашний каталог, а jane - нет. Проблема в том, что во всех обучающих материалах в Интернете указаны разрешения для каталога .ssh и файлов, но не упоминается, что в самом каталоге пользователя должно быть отключено разрешение на запись для группы.
Вы пытались ограничить разрешение .ssh каталог? Потому что в большинстве случаев это сработает. Не уверен, где находится эта «строгая» конфигурация, но я сталкивался с той же проблемой несколько раз раньше и менял разрешения на .ssh каталог исправил проблему.
У меня была та же проблема, но с пользователем ssh'ing другому пользователю, локальному в той же системе.
Все разрешения одинаковы для обоих пользователей.
Эксперименты показали, что пользователи A и B могут войти в систему как друг друга, но ни один из них не может подключиться как пользователь C.
Оказалось, что у пользователя C (который является системным пользователем) не было теневой записи, хотя у него была запись passwd.
Надеюсь, позже это поможет кому-то с той же проблемой.
Система: OpenIndiana oi_151a
Я использую CentOS, которая на самом деле является RHEL. Я оказался в ситуации, когда контекст SELinux для каталога / файлов .ssh был неправильным.
Подробную информацию о действиях SELiunx смотрите в /var/log/audit/audit.log.