Как разрешить ключи хоста SSH в Linux (Fedora 10 и CentOS 5.2)
Я пытаюсь настроить ключи хоста 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)'
Предложения?
5 ответов
Похоже, у вас есть правильные основы.
Наиболее распространенная причина сбоя - разрешения на удаленном компьютере. 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, которые могли произойти.