У меня есть сервер FreeBSD с включенным паролем SSH. Я хотел бы включить sudo, но я не хочу, чтобы потенциальный злоумышленник находился на расстоянии одного пароля от корневого доступа. Мое текущее решение - войти в систему как root с использованием открытого ключа (удаленная аутентификация по паролю отключена для root), а мой обычный пользователь не в колесе и sudo не установлен.
Раньше я использовал одноразовые пароли для доступа к sudo (я мог с открытым ключом войти в систему, но для sudo требовался OTP, и у меня был 30-минутный тайм-аут, чтобы я мог действительно выполнять работу без повторной аутентификации всех время). Однако это изрядная проблема, по крайней мере, с OPIE / S / Key. С аппаратным токеном все в порядке, но на данный момент у меня его нет.
Я искал что-то, что позволило бы мне аутентифицироваться в sudo с открытым ключом SSH через пересылку агента. pam_ssh входящий в состав FreeBSD, похоже, этого не делает - он только проверяет подлинность, проверяя, может ли пользователь расшифровать закрытый ключ на сервере. я нашел pam_ssh_agent_auth, но я нахожу очень мало ссылок на него в других местах. Сейчас он составляет 0,9, но я несколько не решаюсь доверять шлюз для получения root-прав для программы, которую я не могу найти много доказательств того, что люди действительно используют.
Итак, мои вопросы в основном 2:
pam_ssh_agent_auth б / у в дикой природе и надежно?Майкл,
То, чего вы хотите достичь, можно сделать двумя способами:
Один, как вы обнаружили, - использовать pam_ssh_agent_auth или вы можете использовать его "бедный кузен":
ssh на localhost, связанный с пересылкой ключей SSH. Пошаговые инструкции здесь указывают на сервер Ubuntu, но все команды должны подходить для вашей FreeBSD, поскольку они являются особенностями самого OpenSSH.
1. добавить ключ в ssh-agent:
user@workstation:~$ ssh-add
Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)
2. Скопируйте ключ в учетную запись пользователя на целевом сервере.
user@workstation:~$ ssh-copy-id destination-server
user@destination-server's password:
Now try logging into the machine, with "ssh 'destination-server'", and check in:
~/.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
3. Протестируйте вход на основе ключа:
user@workstation:~$ ssh -A destination-server
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-10-server x86_64)
* Documentation: http://www.ubuntu.com/server/doc
Last login: Mon Aug 8 20:38:48 2011 from 192.168.123.123
user@destination-server:~$
4. Теперь копируем ключи SSH в: /root/.ssh/
user@destination-server:~$ sudo cp ~/.ssh/authorized_keys /root/.ssh/
[sudo] password for user:
user@destination-server:~$ sudo ls -l /root/.ssh/au*
total 4
-rw------- 1 root root 392 2011-08-08 20:44 authorized_keys
5. Вернувшись к нормальной жизни пользователя, мы проверяем наличие SSH Auth Socket:
$ echo $SSH_AUTH_SOCK
/tmp/ssh-bUhwiw3004/agent.3004
6. Веселое время! Примечание: имейте в виду, что ваш SSHd может быть настроен на запрет корневого доступа. Не забудьте включить его
user@destination-server:~$ ssh root@localhost
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-10-server x86_64)
* Documentation: http://www.ubuntu.com/server/doc
Last login: Mon Aug 8 21:07:29 2011 from eedev.local
root@destination-server:~# id
uid=0(root) gid=0(root) groups=0(root)
7. Вечеринка не окончена ... Вы можете расслабиться и немного поиграть с настройкой, используя псевдонимы:
Примечание: Имейте в виду, что отношения SSH и tty могут быть проблемными
user@destination-server:~$ alias sshudo='ssh -4 -t root@localhost'
user@destination-server:~$ sshudo id
uid=0(root) gid=0(root) groups=0(root)
Connection to localhost closed.
user@destination-server:~$ sshudo vi /etc/sudoers
И вуаля!
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-10-server x86_64)
* Documentation: http://www.ubuntu.com/server/doc
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
"/etc/motd" 4 lines, 114 characters
8. Прежде чем идти ... Настройте его:
user@destination-server:~$ sshudo vi /root/.ssh/authorized_keys
Добавить from="localhost" перед ключом SSH, который вы используете. это ограничит доступ удаленных пользователей с помощью этого ключа и проверки:
user@destination-server:~$ sshudo id
user@destination-server:~$ uid=0(root) gid=0(root) groups=0(root)
user@destination-server:~$ Connection to localhost closed.
Выйдите из системы и проверьте ограничение
user@destination-server:~$ exit
Connection to destination-server closed.
user@workstation:~$ ssh root@destination-server
root@destination-server's password:
Надеюсь это поможет.
Вы уже решили эту проблему с помощью одноразовых паролей (больше безопасности = больше обручей), и я не могу комментировать pam_ssh_agent_auth. Но похоже, что вас действительно беспокоит не sudo, а доступ на уровне сети. Другими словами, вам кажется, что вас беспокоят привилегии, предоставленные пользователям с определенного хоста или хостов, а не с конкретной системной учетной записи. Если это так, подумайте о реализации схемы блокировки портов перед вашим демоном SSH, чтобы SSH был доступен только с определенных IP-адресов и кем-то, кто знает секретный удар. После этого обычной аутентификации с использованием старого открытого ключа от известных хостов должно быть достаточно. Если злоумышленник все еще может получить доступ к оболочке в этот момент, вы, вероятно, все равно проиграете.
Единственный другой сценарий, который я могу придумать, - это использовать прокси-сервер ssh на доверенном хосте, с которого вы можете отклонить свои соединения, когда вы находитесь в ненадежной сети (и поскольку вы находитесь в bsdworld, вы даже можете использовать тюрьму на ваш хост, который делает именно это). Насколько я понимаю, любой компьютер, к которому злоумышленник имеет доступ к оболочке, полностью скомпрометирован, точка. Получат ли они рут-кредиты или нет, это совершенно спорный вопрос. Лучше всего ваши усилия будут потрачены на предотвращение первого успешного вторжения.
Ура, -G