Вопросы Теги

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

Стек TCP/IP может стать поврежденным в XP. Предыдущие версии Windows позволили Вам удалять и переустанавливать TCP/IP, который исправит различные связанные с TCP/IP проблемы. XP однако не позволяет это. Для ранних версий XP было нужно погружение реестра для срывания TCP/IP, позволяющего переустанавливание (или выполнять утилиту, названную winsockxpfix), но пакет обновления 2 решил эту проблему. Они добавили функциональность к netsh, чтобы вытереть и перезагрузить tcp/ip.

Выполните следующую команду от командной строки:

netsh winsock сброс

После того, как это работает, перезагрузите систему (этому даже, возможно, не понадобилась бы перезагрузка, чтобы начать работать),

Надеюсь, это поможет!

4
задан 27 December 2011 в 23:26
4 ответа

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

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

8
ответ дан 3 December 2019 в 02:27

Если у Вас есть проблемы аутентификации с 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 для получения дополнительной информации. Не забывайте возвращать свой уровень журнала снова (вероятно, к ИНФОРМАЦИИ) при решении проблемы.

3
ответ дан 3 December 2019 в 02:27

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

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

1
ответ дан 3 December 2019 в 02:27

Некоторые дистрибутивы предоставляют инструмент (на самом деле это сценарий оболочки) под названием 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 !

1
ответ дан 3 December 2019 в 02:27

Теги

Похожие вопросы