Назад | Перейти на главную страницу

Почему мой открытый ключ не позволяет мне войти в систему без пароля?

В моей домашней сети у меня есть сервер под управлением Ubuntu и другой рабочий стол под управлением Windows 7. Я использую cygwin на машине с Windows, чтобы подключиться к серверу по ssh. Я попытался установить ключи между этими двумя машинами. На машине с Windows я создал ключи, используя ssh-keygen -t rsa. Затем я отправил полученный id_rsa.pub на сервер и поместил его в ~/.ssh/authorized_keys файл. Насколько я знаю, это должно быть все, что мне нужно для работы. Но, как вы уже догадались, это не так.

Я пытаюсь использовать ssh username@192.168.1.101. Мои предположения (о которых я не смог получить большую информацию) заключаются в том, что мне может потребоваться настроить что-то немного другое для использования cygwin или что это может иметь какое-то отношение к использованию IP-адреса, а не имени хоста .. Какие направления или идеи?

Вероятно, это проблема с разрешениями в вашем каталоге ~ / .ssh или в файле ~ / .ssh / authorized_keys.

Ваш каталог ~ / .ssh должен иметь chmod'd до 700, а ваш файл authorized_keys должен быть chmod'd как минимум до 644. Если вы проверите файл журнала / var / log / secure, он должен дать вам подсказку о причине сбоя.

Если у вас возникают проблемы с аутентификацией с помощью ssh, первое, что нужно исследовать, - это то, что говорит клиент при некоторой отладке:

% ssh -v host
...
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/david/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (publickey).
...

это успешное соединение с открытым ключом.

% ssh -v host
...
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/david/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/david/.ssh/identity
debug1: Trying private key: /home/david/.ssh/id_rsa
debug1: Next authentication method: password
david@ace's password: 
...

На самом деле это не дает много информации о том, почему в аутентификации с открытым ключом было отказано. Лучшая информация доступна на сервере. Sshd будет регистрироваться в системе системного журнала AUTH, поэтому вы можете найти информацию, где бы вы ни находились (в случае Debian /var/log/auth/).

Aug 19 08:18:36 ace sshd[10100]: Authentication refused: bad ownership or modes 
       for directory /home/david/.ssh

Это говорит нам о том, что разрешения для .ssh неверны, и мы можем легко это исправить.

Aug 19 08:26:41 ace sshd[12156]: error: key_read: uudecode
       ZAAAAB3NzaC1kc3MAAACBAIUuAmpj9FuE71EfqJDVAfI+pUZ++xSWbUvEh7U36WW/...

Это говорит нам, что он не смог прочитать этот конкретный ключ, поэтому мы знаем, как это исправить.

Если вы не получаете полезной информации из журналов, вы можете включить ведение журнала. редактировать /etc/ssh/sshd_config и изменить LogLevel строка к:

 LogLevel DEBUG

Тогда беги

 /etc/init.d/ssh reload

Теперь, когда вы попытаетесь подключиться, вы должны увидеть несколько журналов, например:

Aug 19 08:32:12 ace sshd[13537]: debug1: Checking blacklist file 
      /usr/share/ssh/blacklist.DSA-1024
Aug 19 08:32:12 ace sshd[13537]: debug1: Checking blacklist file 
      /etc/ssh/blacklist.DSA-1024
Aug 19 08:32:12 ace sshd[13537]: debug1: temporarily_use_uid: 1002/513 (e=0/0)
Aug 19 08:32:12 ace sshd[13537]: debug1: trying public key file 
      /home/david/.ssh/authorized_keys
Aug 19 08:32:12 ace sshd[13537]: debug1: fd 4 clearing O_NONBLOCK
Aug 19 08:32:12 ace sshd[13537]: debug1: matching key found: file 
      /home/david/.ssh/authorized_keys, line 1
Aug 19 08:32:12 ace sshd[13537]: Found matching DSA key: 
      1c:46:89:52:c1:79:c8:8f:43:3c:4e:77:ad:a1:5d:1b

Это был успешный вход.

Если вам нужна дополнительная информация, вы можете использовать DEBUG2 и DEBUG3 для получения дополнительной информации. Не забудьте снова изменить уровень журнала (возможно, на INFO), когда устраните проблему.

Разрешения важны для файла ~ / .ssh / authorized_keys. Сам файл не должен иметь разрешений, позволяющих кому-либо другому писать в него. chmod go-rwx ~/.ssh/authorized_keys Кроме того, каталог .ssh не должен разрешать запись в него. chmod go-rwx ~/.ssh Ваш домашний каталог также не должен разрешать запись chmod go-w ~/

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

Некоторые дистрибутивы предоставляют инструмент (на самом деле это сценарий оболочки), называемый ssh-copy-id. Я считаю, что с помощью этого можно избавиться от многих головных болей, связанных с копированием .pub часть ключа пользователя к удаленной учетной записи authorized_keys файл.

использование

$ ssh-copy-id user@remotehost

Вы даже можете указать ему разные ключи для копирования (по умолчанию id_rsa* ключи.

$ ssh-copy-id -i ~/.ssh/somekey.pub user@remotehost

Этот сценарий также заботится о создании пользовательского $HOME/.ssh каталог на удаленном хосте и правильно установите разрешения.

$ ssh-copy-id --help
Usage: /usr/bin/ssh-copy-id [-i [identity_file]] [user@]machine

У него есть базовая справочная страница. В моих дистрибутивах на базе Red Hat (Fedora, CentOS, RHEL) он был частью стандартного пакета openssh-client!