4

Я боролся с этой конкретной проблемой большую часть дня и добивался НЕКОТОРОГО прогресса, но я все еще немного застрял. Я хотел бы иметь возможность аутентифицировать сеанс SSH с использованием файла закрытого ключа, а затем использовать эту же аутентификацию для аутентификации запросов sudo. Система, к которой я подключаюсь, представляет собой Windows-коробку с использованием Putty и Pageant Система, к которой я подключен, представляет собой Ubuntu, работающий под управлением 13.10 Saucy (32-разрядная версия) и, в частности, сервер OpenSSH. Я успешно сгенерировал 4096-битный ключ RSA и могу использовать его для подключения к сеансам SSH без проблем.

Чтобы облегчить аутентификацию sudo, я пытаюсь установить и использовать libpam-ssh-agent-auth. Он находится на SourceForge и задокументирован здесь: http://pamsshagentauth.sourceforge.net/ В Интернете есть много информации и инструкций относительно этой библиотеки, но информация и руководства в основном устарели и / или относятся к конкретному дистрибутиву.

Некоторые из моих достижений: я обнаружил, что вы должны включить переадресацию агента пользователя и запустить Pageant в Putty, чтобы агент пользователя действительно появился на сервере Ubuntu. Мне также пришлось добавить "AllowAgentForwarding yes" в /etc /ssh /sshd_config и строку «Defaults env_keep += SSH_AUTH_SOCK» в /etc /sudoers (после трех других строк по умолчанию). Эти изменения, по-видимому, позволили сокету аутентификации SSH распространяться вплоть до команд sudo, как было протестировано в терминале следующим образом:

echo "$SSH_AUTH_SOCK"
/tmp/ssh-4LcT4GZtZ8/agent.6725
sudo echo "$SSH_AUTH_SOCK"
/tmp/ssh-4LcT4GZtZ8/agent.6725

До внесения этих изменений я вообще не получал SSH_AUTH_SOCK, а затем получал его только в обычной командной строке, а не в sudo. Внесенные в документацию изменения позволили сокету аутентификации пройти через sudo.

Последний шаг - установить libpam-ssh-agent-auth, а затем внести соответствующие изменения в конфигурацию /etc/pam.d/sudo. Я попытался скомпилировать его сам, а также установить предварительно скомпилированные .debs из двух разных PPA как часть моего квеста, чтобы заставить это работать (как я уже говорил, пытался весь день). Этот последний шаг - то, что застряло у меня. В принципе, несмотря на то, что все настроено правильно, я не добиваюсь успеха.

Насколько я понимаю, в моем тестовом примере должно быть выполнено «sudo -K», а затем sudo любая команда. -K сбрасывает таймер sudo, вызывая повторную аутентификацию при следующей попытке sudo.

У меня не было успеха.

Мой текущий файл /etc/pam.d/sudo:

#%PAM-1.0

auth    required        pam_env.so      readenv=1 user_readenv=0
auth    required        pam_env.so      readenv=1 envfile=/etc/default/locale user_readenv=0
auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys
auth requisite pam_unix.so nullok_secure
@include common-auth
@include common-account
@include common-session-noninteractive

Я подумал, что это может быть хорошим местом для публикации об этом материале.

1 ответ1

1

Я смог решить эту проблему самостоятельно.

Ключом к устранению неполадок было изучение файла /var/log/auth.log. Изучение этого журнала приведет меня к ошибке

pam_ssh_agent_auth: Authentication refused: bad ownership or modes for file

Это привело меня к первой проблеме: для продолжения аутентификации SSH необходимо правильно указать владельца файла и разрешения. Я специально должен был запустить «chmod 700 -R ~/.ssh». Это решило эту конкретную ошибку, но затем, когда я попытался выполнить sudo, я трижды получал "неправильный пароль", а затем произошел сбой sudo.

Чтобы решить эту проблему, я изменил файл /etc/pam.d/sudo, закомментировав все, кроме строки

auth       sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys debug allow_user_owned_authorized_keys_file

Это далеко от идеала, но дает мне место для начала. Дальнейшие изменения в файле /etc/pam.d/sudo должны позволять работать и другим видам аутентификации.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .