ssh: Идентичные шаги генерации ключа rsa работают для одного пользователя, но не для другого.

Я только что создал ключи rsa, чтобы ноутбук с Windows 10, работающий под управлением cygwin, мог войти в систему CentOS без пароля. Это работает нормально. Однако тот же процесс не работал для настройки входа без пароля для другого удаленного пользователя. Меня по-прежнему просят ввести пароль.

Шаги для первого удаленного пользователя были следующими

На клиенте Windows10 (Cygwin):

ssh-keygen -t dsa 
chmod 600 /home/John/.ssh/id_dsa 
scp /home/John/.ssh/id_dsa.pub [email protected]:

На сервере CentOS (вошел в систему как UserA из каталога /home/UserA/):

cat id_dsa.pub >> .ssh/authorized_keys 
chmod 700 .ssh
chmod 600 .ssh/authorized_keys

Эти шаги сработали нормально, но те же самые шаги для другого удаленного пользователя по какой-то причине не сработали. ssh UserB@my_server.com по-прежнему запрашивает пароль после выполнения

те же действия для другого удаленного пользователя:

На клиенте Windows10 (Cygwin):

ssh-keygen -t dsa 
chmod 600 /home/John/.ssh/user_b_dsa 
scp /home/John/.ssh/user_b_dsa.pub [email protected]:

На сервере CentOS (вошел в систему как UserB из каталога /home/UserB/):

cat user_b_dsa.pub >> .ssh/authorized_keys 
chmod 700 .ssh
chmod 600 .ssh/authorized_keys

Любая идея, почему одни и те же шаги могут привести к таким разным результатам? Я проверил, что команды chmod работают, и проверил, что author_key был правильно обновлен.


git ssh rsa dsa
person John    schedule 18.08.2015    source источник
comment
Вещи, которые вам нужно включить для отладки: журнал запуска ssh -vvv -i ~/.ssh/user_b_dsa [email protected] и соответствующий фрагмент журнала из sshd со стороны сервера. Без этого мы можем только строить догадки. Одна вещь, которая не нужна (и может быть причиной), — это слишком большие ограничения на ваш authorized_keys — sshd нужен доступ к нему. Это должно быть 07:55 на ~/.ssh и 06:44 на ~/.ssh/authorized_keys. Только вашим закрытым ключам нужны права 0600.   -  person viraptor    schedule 18.08.2015

Ответы (1)


arrow_upward
0
arrow_downward

Таким образом, решение, похоже, заключалось в том, что права доступа к папке /home/UserB были установлены на 770, а должны были быть 700. Кроме того, как я изначально пытался, вам не нужен другой ключ id_dsa для другого пользователя. Простое копирование исходного файла id_dsa.pub в файл /home/UserB и продолжение тех же шагов работает нормально. Если вы попытаетесь использовать другой файл dsa, это также не сработает, если вы явно не укажете ssh использовать его с ssh -i /home/user/.ssh/my_dsa [email protected] Очевидно, ssh действительно разборчив в том, какие разрешения существуют, и даже не выдает сообщение об ошибке, чтобы сообщить вам в чем проблема. Вы должны волшебным образом знать, что где-то существуют журналы ssh, чтобы получить представление о проблеме.

person John    schedule 18.08.2015