Я создал частную / публичную пару ключей dsa. Я поместил открытый ключ на сервер в
~/.ssh/authorized_keys
Все настроено так же, как и мой другой сервер, но похоже, что сервер просто игнорирует мои усилия.
Сервер проигнорирует ваш файл authorized_keys, если свойства владельца неверны. Изменение на это исправляет:
chmod 0700 ~/.ssh
chmod 0600 ~/.ssh/authorized_keys
Хотя ваша проблема, возможно, уже была решена другими ответчиками, я заблокировал себе доступ к достаточному количеству машин, чтобы не проверять изменения sshd_config перед выходом из системы, поэтому придумал следующий процесс, который может быть полезен для будущей отладки изменений конфигурации sshd:
НЕ ОТКЛЮЧАЙТЕ активное соединение ssh до тех пор, пока ПОСЛЕ тестирования не подтвердит, что поведение соответствует вашим ожиданиям.
а. проверьте, что, по вашему мнению, должен делать sshd
б. проверьте правильность конфигурации, используя "-t"
c. запустить подробную тестовую версию сервера, за которым вы можете следить в реальном времени
d. запустить подробное тестовое клиентское соединение, которое вы можете отслеживать в реальном времени
а. проверьте, что, по вашему мнению, должен делать sshd
Просмотрите файл конфигурации sshd без комментариев, используя что-то вроде следующего (при условии, что sshd_config - это правильный файл и находится в / etc / ssh)
$ grep -v "^ #" / etc / ssh / sshd_config | grep -v "^ $"
Это просто проясняет ситуацию, поэтому мы проверяем, что, по нашему мнению, мы меняем (не обязательно, правильно это или нет).
б. проверьте правильность конфигурации, используя "-t"
На странице руководства sshd, который я использую,
-t Тестовый режим. Только проверьте правильность файла конфигурации и работоспособность ключей. Это полезно для надежного обновления sshd, поскольку параметры конфигурации могут измениться.
Другие изменения могут иметь более тонкие обстоятельства. Например, не отключайте аутентификацию по паролю, пока не убедитесь, что аутентификация с открытым ключом работает правильно.
c. запустить подробную тестовую версию сервера, за которым вы можете следить в реальном времени
$ sudo / usr / sbin / sshd -ddd -p 9999
Это сохраняет ваш существующий рабочий сеанс активным, но дает вам еще один экземпляр sshd для проверки ваших новых изменений конфигурации. SSHD теперь работает на переднем плане с пользовательским портом (9999 в нашем примере) и отправляет много зашумленной отладочной информации, которую вы можете отслеживать в / var / log / authlog (или, возможно, /var/log/auth.log в зависимости от на вашей ОС.)
d. запустить подробное тестовое клиентское соединение, которое вы можете отслеживать в реальном времени
Запустите клиентское соединение ssh в подробном режиме, чтобы отобразить на экране больше информации, которая может помочь вам лучше отладить вашу ошибку.
$ ssh -vvv -p 9999 имя-сервера
Теперь у вас должно быть достаточно информации либо в файлах журнала сервера, либо на экране подключения клиента, чтобы изолировать вашу проблему.
Решение обычно сводится к разрешениям файлов (как показано Магнаром и сетатакахаши)
Удачи
$ chmod 700 ~
$ chmod 700 ~ / .ssh
$ chmod 600 ~ / .ssh / authorized_keys
Проверьте эти атрибуты в / etc / ssh / sshd_config
$ sudo grep PubkeyAuthentication / etc / ssh / sshd_config
$ sudo grep протокол / etc / ssh / sshd_config
Еще один важный подводный камень ..
Если ваш домашний каталог зашифрован sshd не будет иметь доступа к ~ / .ssh / authorized_keys ..
Видеть этот ответ