Я пытаюсь настроить ключи хоста SSH с нашего центрального резервного сервера Mac OS X 10.5 Leopard Server на наши два Linux-сервера под управлением Fedora 10 и CentOS 5.2. Процесс, который мы обычно выполняем, работает и помещает ключ в ~ / .ssh / authorized_keys, но по-прежнему запрашивает пароль.
Я не являюсь обычным администратором этих ящиков и понимаю, что по умолчанию ключи хоста SSH отключены. Как включить ключи хоста SSH?
Обновить: Я уже раскомментировал «PubkeyAuthentication yes» в / etc / ssh / ssd_config и запустил service restart sshd, но это не сработало. Раскомментировал все три строки («RSAAuthentication», «PubkeyAuthentication» и «AuthorizedKeysFile»), исправил разрешения для ~ / .ssh и повторил попытку. По-прежнему нет любви.
Когда я бегу ssh -v user@host Перед запросом пароля и после некоторых ошибок GSS я получаю следующее:
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/shortname/.ssh/identity
debug1: Trying private key: /Users/shortname/.ssh/id_rsa
debug1: Trying private key: /Users/shortname/.ssh/id_dsa
debug1: Next authentication method: password
Дальнейшие предложения?
Еще одно обновление: Разрешения на ~/ и ~/.ssh/ 700.
Команда, которую я использовал для создания ключа хоста, выглядит следующим образом:
cat /blah/ssh_keys_for_shortname/id_dsa.pub | ssh -l shortname -o stricthostkeychecking=no -i /blah/ssh_keys_for_shortname/id_dsa host.domain.tld 'cat - >> ~/.ssh/authorized_keys'
И при попытке подключения я использую:
ssh --verbose -l shortname -o stricthostkeychecking=no -i /blah/ssh_keys_for_shortname/id_dsa host.domain.tld
Итак, очевидно, что мы используем ключи DSA. Я пробовал переименовать ~/.ssh/authorized_keys2, но это не помогает.
Я бы хотел хранить ключи в их местах по умолчанию вместо /blah/ssh_keys_for_shortname/, но это вне моего контроля.
Когда я смотрю /var/log/audit/audit.log и пытаюсь подключиться, получаю следующее:
type=CRED_DISP msg=audit(1249426114.642:128): user pid=10589 uid=0 auid=501 ses=14 msg='op=PAM:setcred acct="shortname" exe="/usr/sbin/sshd" (hostname=host.domain.tld, addr=192.168.1.149, terminal=ssh res=success)'
type=USER_END msg=audit(1249426114.647:129): user pid=10589 uid=0 auid=501 ses=14 msg='op=PAM:session_close acct="shortname" exe="/usr/sbin/sshd" (hostname=host.domain.tld, addr=192.168.1.149, terminal=ssh res=success)'
type=USER_LOGIN msg=audit(1249426129.524:130): user pid=10633 uid=0 auid=4294967295 ses=4294967295 msg='acct="shortname": exe="/usr/sbin/sshd" (hostname=?, addr=192.168.1.149, terminal=sshd res=failed)'
Предложения?
Похоже, ты правильно понял основы.
Самая частая причина, по которой это не удается, - это разрешения на удаленном authorized_keys файл и каталоги над ним. Прежде чем разрешить аутентификацию на основе ключей, sshd выполняет проверку разрешений; если ему не нравятся результаты, он запрещает аутентификацию. Я обычно устанавливаю ~/.ssh до 0700 и ~/.ssh/authorized_keys на 0600. Я считаю, что в фактическом $ HOME также не может быть записи группы или мира, хотя с чтением все в порядке.
Если это все еще не помогает, следующим шагом будет отладка на стороне сервера:
server$ /usr/sbin/sshd -d -p 2222
Затем подключитесь к серверу «отладки» со своего клиента:
client$ ssh -v user@host -p 2222
Вы получите обширную отладочную информацию на stderr на сервере. Я еще не сталкивался с проблемой авторизации, которую я не мог отследить.
Вот как я буду следовать.
Создайте пару открытого / закрытого ключей на сервере OS X. Я не указываю кодовую фразу при появлении запроса.
$ ssh-keygen -b 4096 -C "myusername @ myhostname" -t rsa
Скопируйте содержимое ~ / .ssh / id_rsa.pub на сервере OS X в ~ / ssh / authorized_keys в домашнем каталоге правильного пользователя на хостах CentOS / Fedora.
Убедитесь, что разрешения правильные на всех хостах. Каталог ~ / .ssh должен иметь режим 0700, файлы внутри должны быть 0600 (вы можете использовать 0644 для открытых ключей, но это не повредит быть более строгим).
Если аутентификация на основе ключей еще не работает, убедитесь, что следующие значения установлены в вашем файле sshd_config (/ etc / ssh / sshd_config) на каждом из хостов CentOS / Fedora. (Эти значения должны быть значениями по умолчанию.)
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
Если по-прежнему не работает, попробуйте ssh -v user@host чтобы увидеть, что происходит при подключении. Добавьте еще v, чтобы узнать больше о том, что происходит.
РЕДАКТИРОВАТЬ: Попробуйте проверить права доступа к полному дереву каталогов от / до рассматриваемого каталога .ssh. Если какой-либо из каталогов на этом пути доступен для записи для группы или всего мира, SSH выйдет из строя. Запустите это, чтобы распечатать разрешения для всех каталогов в пути:
j="" ; for i in `echo ~baumgart/.ssh | sed 's%/% %g'` ; do ls -ld $j/$i ; j=$j/$i ; done
Также - проверьте файл журнала на наличие сообщений от sshd в системах CentOS / Fedora - в нем должно быть полезное сообщение о том, что не так. Он должен быть в / var / log / messages или /var/log/auth.log. Если не можешь найти, сделай grep sshd /var/log/*.
Прежде всего следует отметить, что /var/log/audit.log ведёт журнал SELinux деятельность.
Я предполагаю, что если вы посмотрите немного дальше в том журнале, вы увидите еще одну запись, которая выглядит примерно так:
type=AVC msg=audit(xxxxxxxxx.xxx:xxxx): avc: denied { search } for pid=xxxxx comm="sshd" name="xxxxxx" dev=xxxx ino=xxxxxx scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=dir
Это означает, что ваш процесс sshd ограничен загруженной политикой selinux и не может получить доступ к пути файловой системы, в котором находится ваш файл авторизованных ключей.
Чтобы убедиться, что политика selinux активна, запустите sestatus , и вы увидите следующий результат:
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 23
Policy from config file: targeted
Чтобы быстро проверить, является ли это проблемой или нет, вы можете временно установить SELinux в разрешающий режим, выполнив setenforce permissive команда. После этого запустите sestatus снова, и вы должны увидеть следующий результат:
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: permissive
Mode from config file: enforcing
Policy version: 23
Policy from config file: targeted
Попробуйте еще раз ваше соединение ssh, и, учитывая, что все остальные настройки верны, оно должно работать.
В дальнейшем вам, вероятно, следует создать собственные правила, разрешающие доступ к выбранному вами пути, но это выходит за рамки данной справки.
Чтобы сделать это изменение постоянным (выжить после перезагрузки), вам необходимо изменить /etc/selinux/config файл и измените:
SELINUX=enforcing
к
SELINUX=permissive
Если вы уже правильно установили права пользователя / группы, возможно, вы столкнулись с проблемами SELinux. Самый простой способ исправить это с помощью restorecon -R /home/user/.ssh/. Ошибки будут зарегистрированы /var/log/audit/audit.log и вы можете использовать audit2why инструмент, позволяющий системе объяснить все возможные отказы SELinux.
'PubkeyAuthentication yes' в / etc / ssh / sshd_config?