Почему я все еще получаю приглашение пароля с помощью ssh с аутентификацией с открытым ключом?

Я работаю с URL-адресом, который я нашел здесь:

http://web.archive.org/web/20160404025901/http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

  • Проблема с клиентской стороной SSH: зависание и синхронизация на некоторых хостах
  • su другому пользователю, использующему ключи ssh?
  • sshfs всегда запрашивает пароль в fstab?
  • убить пользователя, который простаивает более 3 часов
  • Никакая задержка между попытками входа ssh
  • дождитесь завершения подключения autossh
  • Мой клиент ssh – рабочий стол Ubuntu 64 бит 11.10, а мой сервер – 64-разрядный процессор Centos 6.2. Я следовал указаниям. Я все еще получаю запрос пароля на ssh.

    Я не уверен, что делать дальше.

  • Увеличьте SSH ConnectTimeout более 60 секунд
  • Как изменить результат поиска в vi?
  • Нет вывода из команды, выполненной поверх ssh на SUSE с помощью openBSD sshd
  • Вход SSH без пароля с kerberos
  • запустить локальный прокси-сервер SOCKS, туннелированный через SSH
  • ssh изменить пользователя и выполнить команду
  • 21 Solutions collect form web for “Почему я все еще получаю приглашение пароля с помощью ssh с аутентификацией с открытым ключом?”

    Убедитесь, что права на ~/.ssh и его содержимое являются правильными. Когда я впервые установил свой ssh ​​key auth, у меня не было правильно настроенной папки ~/.ssh , и она закричала на меня.

    • Ваш домашний каталог ~ , ваш ~/.ssh ~/.ssh/authorized_keys файл ~/.ssh/authorized_keys на удаленном компьютере должны быть доступны для записи только вам: rwx------ и rwxr-xr-x в порядке, но rwxrwx--- является хорошим¹, даже если вы единственный пользователь в своей группе (если вы предпочитаете числовые режимы: 700 или 755 , а не 775 ).
      Если ~/.ssh или authorized_keys является символической ссылкой, проверяется канонический путь (с расширением символьных ссылок) .
    • Ваш файл ~/.ssh/authorized_keys (на удаленном компьютере) должен быть доступен для чтения (не менее 400), но вам потребуется его перезаписывать (600), если вы добавите к нему больше ключей.
    • Ваш файл закрытого ключа (на локальном компьютере) должен быть доступен для чтения и записи только вам: rw------- , т.е. 600 .
    • Кроме того, если SELinux настроен на принудительное выполнение, вам может потребоваться запустить restorecon -R -v ~/.ssh (см., Например, ошибку Ubuntu 965663 и отчет об ошибке в Debian # 658675 , который исправлен в CentOS 6 ).

    ¹ За исключением некоторых дистрибутивов (Debian и дериваторов), которые исправили код, чтобы обеспечить возможность записи на группы, если вы единственный пользователь в своей группе.

    Если у вас есть root-доступ к серверу, простой способ решить такие проблемы – запустить sshd в режиме отладки, выпустив на сервере что-то вроде /usr/sbin/sshd -d -p 2222 (полный путь к исполняемому исполняемому файлу sshd, which sshd может помочь which sshd ), а затем соединение с клиентом с ssh -p 2222 user@host . Это заставит демон SSH оставаться на переднем плане и отображать отладочную информацию о каждом соединении. Ищите что-то вроде

     debug1: trying public key file /path/to/home/.ssh/authorized_keys ... Authentication refused: bad ownership or modes for directory /path/to/home/ 

    Если использовать альтернативный порт невозможно, вы можете временно остановить демон SSH и заменить его на один в режиме отладки. Остановка SSH-демона не убивает существующие соединения, поэтому можно сделать это через удаленный терминал, но несколько рискованно – если соединение каким-то образом сломается в то время, когда замена отладки не запущена, вы заблокированы из машины пока вы не сможете его перезапустить. Необходимые команды:

     service ssh stop /usr/sbin/sshd -d #...debug output... service ssh start 

    Зашифрован ли ваш домашний компьютер? Если это так, для вашей первой сессии ssh вам нужно будет предоставить пароль. Второй сеанс ssh на том же сервере работает с ключом auth. Если это так, вы можете перенести ваши authorized_keys в незашифрованный ~/.ssh/config и изменить путь в ~/.ssh/config .

    В результате я создал папку /etc/ssh/username , принадлежащую имени пользователя, с правильными разрешениями и разместил там файл authorized_keys . Затем изменилась директива AuthorizedKeysFile в /etc/ssh/config :

     AuthorizedKeysFile /etc/ssh/%u/authorized_keys 

    Это позволяет нескольким пользователям иметь этот доступ ssh без компрометации разрешений.

    После копирования ключей на удаленный компьютер и помещения их в authorized_keys вы должны сделать что-то вроде этого:

     ssh-agent bash ssh-add ~/.ssh/id_dsa or id_rsa 

    Я столкнулся с проблемами, когда домашний каталог на пульте дистанционного управления не имеет правильных привилегий. В моем случае пользователь изменил домашний каталог на 777 для некоторого локального доступа в команде. Аппарат больше не мог соединиться с ключами ssh. Я изменил разрешение на 744, и он снова начал работать.

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

    1. ssh-keygen

      Нажмите клавишу «Ввод», пока вы не получите приглашение

    2. ssh-copy-id -i root@ip_address

      (Он однажды попросит пароль хост-системы)

    3. ssh root@ip_address

      Теперь вы можете войти в систему без пароля

    SELinux на RedHat / CentOS 6 имеет проблемы с аутентификацией pubkey , возможно, когда некоторые из файлов созданы, selinux не устанавливает свои ACL правильно.

    Чтобы вручную установить ACL SElinux для пользователя root:

     restorecon -R -v /root/.ssh 

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

    Поэтому нам нужно было сделать еще один шаг. Запустив команду ssh в подробном режиме, вы получите много информации.

     ssh -vv user@host 

    Мы обнаружили, что ключ по умолчанию (id_rsa) не был принят, и вместо этого клиент ssh предложил ключ, соответствующий имени хоста клиента:

     debug1: Offering public key: /home/user/.ssh/id_rsa debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Offering public key: /home/user/.ssh/id_dsa debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Offering public key: user@myclient debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 277 

    Очевидно, что это не сработает ни с каким другим клиентом.

    Таким образом, решение в нашем случае состояло в том, чтобы переключить ключ rsa по умолчанию на тот, который содержал user @ myclient. Когда ключ по умолчанию, проверка имени клиента отсутствует.

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

     'Agent admitted failure to sign using the key' 

    Это было решено перезагрузкой ключей агенту ssh:

     ssh-add 

    Это будет SSH пропустить конфигурацию на сервере. Файл sshd_config на стороне сервера должен быть отредактирован. Расположен в /etc/ssh/sshd_config . В этом файле изменить переменные

    • 'yes' to 'no' для ChallengeResponseAuthentication, PasswordAuthentication, UsePAM

    • «нет» для «да» для PubkeyAuthentication

    На основе http://kaotickreation.com/2008/05/21/disable-ssh-password-authentication-for-added-security/

    Два комментария: это приведет к перезаписыванию исходного файла. Я бы просто скопировал открытый ключ и сделал что-то вроде:

     cat your_public_key.pub >> .ssh/authorized_keys 

    Это добавит ключ, который вы хотите использовать, в уже существующий список ключей. Кроме того, некоторые системы используют файл authorized_keys2 , поэтому неплохо сделать жесткую ссылку, указывающую между authorized_keys и authorized_keys2 , на всякий случай.

    В файле / etc / selinux / config, с помощью которого SELINUX отключается от принудительного выполнения, бездействующий ssh ​​работает успешно.

    Раньше я в состоянии сделать это на одном пути. Теперь с обеих сторон я могу сделать без пароля ssh.

    Мое решение состояло в том, что учетная запись была заблокирована. Сообщение, найденное в / var / log / secure: пользователь не разрешен, так как учетная запись заблокирована. Решение: дать пользователю новый пароль.

    Убедитесь, что AuthorizedKeysFile указывает на нужное место, используйте %u в качестве заполнителя для имени пользователя:

     # /etc/ssh/sshd_config AuthorizedKeysFile /home/%u/authorized_keys 

    Возможно, вам просто нужно раскомментировать строку:

    AuthorizedKeysFile .ssh / authorized_keys

    Имейте в виду, что вы должны перезагрузить службу ssh для изменений:

     service sshd reload 

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

     /usr/sbin/sshd -d 

    Это показало следующий результат:

     debug1: trying public key file /root/.ssh/authorized_keys debug1: fd 4 clearing O_NONBLOCK Authentication refused: bad ownership or modes for directory /root debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 0/0 (e=0/0) debug1: trying public key file /root/.ssh/authorized_keys2 debug1: Could not open authorized keys '/root/.ssh/authorized_keys2': No such file or directory debug1: restore_uid: 0/0 Failed publickey for root from 135.250.24.32 port 54553 ssh2 debug1: userauth-request for user root service ssh-connection method gssapi-with-mic 

    Это было действительно запутанно

     [root@sys-135 ~]# ls -l / drwxrwxrwx. 2 root root 4096 Dec 14 20:05 bin drwxrwxrwx. 5 root root 1024 May 6 2014 boot drwxrwxrwx. 2 root root 4096 Dec 2 2013 cgroup drwxrwxrwx. 10 root root 1024 Sep 25 23:46 data drwxrwxrwx. 124 root root 12288 Dec 16 10:26 etc drwxrwxrwx. 11 root root 4096 Jan 14 2014 lib drwxrwxrwx. 9 root root 12288 Dec 14 20:05 lib64 drwxrwxrwx. 2 root root 16384 Jan 10 2014 lost+found drwxrwxrwx. 2 root root 4096 Jun 28 2011 media drwxr-xr-x. 2 root root 0 Dec 10 14:35 misc drwxrwxrwx. 2 root root 4096 Jun 28 2011 mnt drwxrwxrwx. 4 root root 4096 Nov 24 23:13 opt dr-xr-xr-x. 580 root root 0 Dec 10 14:35 proc drwxrwxrwx. 45 root root 4096 Dec 16 10:26 root 

    Он показал, что корневой каталог имеет разрешения для каждого. Мы изменили его, чтобы у других не было разрешений.

     [root@sys-135 ~]# chmod 750 /root 

    Ключ аутентификации начал работать.

    Эти шаги должны помочь вам. Я использую это регулярно среди многих 64-битных машин Ubuntu 10.04.

     [ ! -f ~/.ssh/id_rsa.pub ] && ssh-keygen -t rsa; ssh <username>@<remote_machine> 'mkdir -p ~/.ssh' cat ~/.ssh/id_rsa.pub | ssh <username>@<remote_machine> 'cat >> ~/.ssh/authorized_keys' 

    вы можете поместить это в скрипт с некоторыми подсказками и вызвать его как

     script_name username remote_machine 

    У меня была аналогичная проблема с ssh. В моем случае проблема заключалась в том, что я установил hasoop cloudera (от rpm на centos 6) и создал пользовательские hdfs с домашним каталогом

    /var/lib/hadoop-hdfs (не стандартный /home/hdfs ).

    Я изменил в / etc / passwd /var/lib/hadoop-hdfs на /home/hdfs , переместил домашний каталог в новое место, и теперь я могу подключиться к аутентификации с открытым ключом.

    Одна вещь, в которой я ошибался, – это право собственности на мой домашний каталог на серверной системе. Системе сервера было установлено значение по умолчанию: по умолчанию я:

     chown -R root:root /root 

    И это сработало. Еще одно дешевое обходное решение – отключить StrictModes: StirctModes no. в sshd_config. Это, по крайней мере, скажет вам, хороши ли обмен ключами и протоколы соединения. Затем вы можете охотиться на плохие разрешения.

    Для меня решение было противоположным Wojtek Rzepala's : я не заметил, что все еще использовал authorized_keys2 , который устарел . Моя настройка ssh перестала работать в какой-то момент, предположительно, когда сервер был обновлен. Переименование .ssh/authorized_keys2 как .ssh/authorized_keys устранило проблему.

    D'о!

    У меня была такая же проблема, и для меня решение было установить UsePAM на no . Посмотрите, даже если PasswordAuthentication установлен на no , вы все равно получите keyboard-interactive , и в моем случае моя локальная ssh-программа по умолчанию по умолчанию не срабатывала.

    Дополнительный фон, чтобы помочь кому-либо с такой же ситуацией: я подключаюсь к хосту, работающему с Dropbear, к одному запущенному OpenSSH. Если PasswordAuthentication и UsePAM no установлены на удаленном компьютере, я получу следующее сообщение, если я введу ssh user@server :

     ssh: Connection to user@server:22 exited: Disconnect received 

    Предоставление файла идентификации с -i , все работает так, как ожидалось.

    Здесь может быть немного больше информации.

    После проверки разрешений и поиска нескольких других решений, перечисленных здесь, я, наконец, удалил каталог ssh на сервере, снова установив свой открытый ключ.

    Команды сервера:

     # rm -rf ~/.ssh 

    Локальные команды:

     # ssh-copy-id user@192.168.1.1 # where <user> is your username and <192.168.1.1> is the server IP 

    Раньше я сталкивался с некоторыми учебниками, в которых описывается, как достичь настройки без пароля ssh, но некоторые из них, к сожалению, неверны.
    Давайте начнем заново и проверим каждый шаг:

    1. ОТ КЛИЕНТА – Создать ключ: ssh-keygen -t rsa
      Открытый и закрытый ключ ( id_rsa.pub и id_rsa ) будут автоматически сохранены в каталоге ~/.ssh/ .
      Настройка будет проще, если вы используете пустую кодовую фразу. Если вы не хотите этого делать, продолжайте следовать этому руководству, но также проверьте приведенный ниже пункт.
    2. FROM CLIENT – копирование открытого ключа на сервер : ssh-copy-id user@server
      Открытый ключ клиента будет скопирован на адрес сервера ~/.ssh/authorized_keys .
    3. FROM CLIENT – Подключение к серверу: ssh user@server

    Теперь, если он не работает после описанных 3 шагов, попробуйте следующее:

    • Проверьте разрешения папки ~/ssh на клиентской и серверной машинах.
    • Проверьте /etc/ssh/sshd_config на сервере, чтобы убедиться, что параметры RSAAuthentication , PubkeyAuthentication и UsePAM не отключены, их можно включить по умолчанию с помощью yes .
    • Если вы ввели кодовую фразу при создании своего клиентского ключа, вы можете попробовать ssh-agent & ssh-add для ssh-add к сеансам без пароля.
    • Проверьте содержимое /var/log/auth.log на сервере, чтобы найти проблему, по которой пропущена аутентификация ключа.
    Linux и Unix - лучшая ОС в мире.