Авторизация SSH-ключа

Покажи выхлоп

ssh -vv -i /srv/cloud/one/.ssh/ключ bar

Такое ощущение что ты перепутал ключи :)

мммм... нескромный вопрос, а хрена ты логинишься под пользователем oneadmin, а ключи ищутся в /home/eveel/.ssh(строка №37)? в passwd точно домашняя папка для oneadmin прописана верно?

> хрена ты логинишься под пользователем oneadmin, а ключи ищутся в /home/eveel/.ssh

Ничего криминального в этом нет. Ключ пользователя eveel@foo (строка 37) прекрасно входит в eveel@bar, но не пускается в oneadmin@bar. Домашний каталог прописан верно, насколько я могу об этом судить:

oneadmin:x:502:502::/srv/cloud/one:/bin/bash

Куда ещё стоит копать?

Куда ещё стоит копать?

В сторону PAM.

> ssh -vv -i /srv/cloud/one/.ssh/ключ bar

На тазике foo нет ничего, связанного с OpenNebula и oneadmin, там только пользователь eveel и его ключи. При попытке подключиться к eveel@bar всё работает, а при попытке подключиться к oneadmin@bar ничего не работает (ключи в порядке).

Сейчас попробовал вот ещё какую штуку. Зашёл от рута на сервер bar, переключил пользователя на oneadmin и сгенерировал ключ с пустым паролем в ~/.ssh/id_rsa. Прописал его же в ~/.ssh/authorized_keys и проставил нужные права. Пытаюсь дёрнуть ssh -vv -i /srv/cloud/one/.ssh/id_rsa localhost (то есть будучи oneadmin@bar зайти на oneadmin@bar). Забудем о сервере foo, дело не в нём.

Не получилось: http://pastie.org/private/nw13xw5fs4ck4tosfqntg

Чёрт возьми, видит же ключ! Пути в порядке, права на ~/.ssh, список авторизованных ключей, а также на пару ключей id_rsa тоже вполне себе правильные.

Меня троллят ребята из CERN? :)

> В сторону PAM.

Ни разу с ним не возился. Что именно там стоит проверить?

Кстати, а не может ли это ограничиваться какой-нибудь дефолтной политикой SELinux (enforcing, targeted)? Типа, не пускать чуваков по SSH, если у них домашняя директория не расположена внутри /home?

>eveel@foo

eveel@bar

а, ну так бы сразу и сказал. Скопируй содержимое /home/eveel/.ssh с сервера bar поверх в /home/oneadmin/.ssh(на сервер bar естественно) и проверь, все ли работает...

Сообщения Selinux надо искать в /var/log/audit/audit.log

И можно попрбовать посмотреть контекст файлов и сравнить с тем, что в /home.

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

> Сообщения Selinux надо искать в /var/log/audit/audit.log

Здесь чисто и ничего интересного :(

И можно попрбовать посмотреть контекст файлов и сравнить с тем, что в /home.

Пробовал, не помогло.

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

Указал DEBUG_3 в конфиге основного sshd, перезагрузил конфиг, никаких вменяемых сообщений об ошибках не увидел.

> а, ну так бы сразу и сказал. Скопируй содержимое /home/eveel/.ssh с сервера bar поверх в /home/oneadmin/.ssh(на сервер bar естественно) и проверь, все ли работает...

Не помогло.

Стыдно признаться, но решение найдено: несмотря на все мои попытки менять контекст SELinux, играться с правами, отключать SELinux насовсем и тупо копировать содержимое ~/.ssh, ничего не помогло.

Это ужасное решение. Просто отвратительное. Я создал нового юзера, снёс старого, переименовал нового в oneadmin, скопировал туда ~/.ssh и всё заработало. Какого чёрта?! :(

Вот ещё интересная особенность:

root@bar# usermod -d /home/crap -m oneadmin
eveel@foo$ ssh oneadmin@bar => работает

Стоит только вернуть его обратно и...

root@bar# usermod -d /srv/cloud/one -m oneadmin
eveel@foo$ ssh oneadmin@bar => не работает

...и ваше очко переходит в зрительный зал! Вообщем, всем спасибо, проблема решилась окончательно.

Для работы в директории /srv/cloud/one нужно было прописать соответствующий контекст SELinux:

# cd /srv/cloud/one
# chcon -R unconfined_u:object_r:user_home_t:s0 .
# chcon unconfined_u:object_r:user_home_dir_t:s0 .