Я пытаюсь создать фейкового пользователя (пользователя, который может войти в систему через SSH, но не существует в системе), который имеет некоторые ограничения (например, он может использовать только одну команду, и когда он это делает, другая команда также будет выполнена). Есть ли способ добиться этого? Я не могу найти способ создать фейкового пользователя на openssh-server, не говоря уже об ограничениях.
решение1
Обычно SSH-серверы в Linux интегрируются с системой и не вводят еще один уровень пользователей. Это не похоже на Samba или FTP, где существует такой уровень пользователей, специфичных для Samba или FTP. Думаю, это нетривиальная задача — заставить sshdOpenSSH определить независимый набор пользователей (но, возможно, другой ответ меня удивит).
Возможно, ваше намерение создать фейкового пользователя проистекает из того факта, что вы не являетесь root на сервере SSH и не можете создать там настоящего пользователя. Если так, то вот что вы можете сделать в любом случае 1 :
Посмотрите, man 5 authorized_keysгде описывается формат. В моем Debian руководство гласит [выделено мной]:
AuthorizedKeysFileуказывает файлы, содержащие открытые ключи для аутентификации с открытым ключом; если этот параметр не указан, по умолчанию используется~/.ssh/authorized_keysи~/.ssh/authorized_keys2. Каждая строка файла содержит один ключ (пустые строки и строки, начинающиеся с '#', игнорируются как комментарии). Открытые ключи состоят из следующих полей, разделенных пробелами: параметры, тип ключа, ключ в кодировке base64, комментарий. Поле параметров является необязательным. […]Параметры (если есть) состоят из спецификаций параметров, разделенных запятыми. Пробелы не допускаются, за исключением двойных кавычек. Поддерживаются следующие спецификации параметров (обратите внимание, что ключевые слова параметров нечувствительны к регистру):
[…]
command="command"
Указывает, что команда выполняется всякий раз, когда этот ключ используется для аутентификации. Команда, предоставленная пользователем (если таковая имеется), игнорируется.Команда запускается на pty, если клиент запрашивает pty; в противном случае она запускается без tty. Если требуется 8-битный чистый канал, не нужно запрашивать pty или следует указатьno-pty. Кавычка может быть включена в команду, если заключить ее в кавычки с обратной косой чертой.Эта опция может быть полезна для ограничения определенных открытых ключей для выполнения только определенной операции. Примером может быть ключ, который разрешает удаленное резервное копирование, но ничего больше.Обратите внимание, что клиент может указать пересылку TCP и/или X11, если они явно не запрещены, например, с помощью
restrictопции ключа.[…]
Таким образом, как обычный пользователь, вы можете разрешить кому-то другому (с этого момента: гостю) войти в систему.как и тыи выполнить одну конкретную командукак и тыавтоматически. Просто зарегистрируйте их открытый ключ у себя ~/.ssh/authorized_keysна сервере, используя command="command"опцию.
Команда может быть пользовательской программой или скриптом, который позволяет гостю выбрать задачу из списка или ввести ключевое слово для выбора задачи; или ввести «внутреннюю» команду, которая будет проверена и разрешена или запрещена; затем программа выполнит что-то соответствующим образом. Вам решать, что это будет за команда/программа/скрипт.
Обратите внимание, что с точки зрения SSH-сервера и его администраторов гостьявляетсявы. Это ваша учетная запись запускает команду, и если ваша пользовательская программа или скрипт позволяет гостю каким-либо образом запустить произвольную команду (например, сначала создав оболочку), то это будет как если бытывыполните команду.
Также имейте в виду, что команда выполняется в неинтерактивной оболочке. Это будет ваша оболочка (та, которую вы выбрали с помощью chsh) с вашей конфигурацией. Оболочка может быть источником некоторых файлов (см.как ведет себя Баш), поэтому убедитесь, что они безопасны для использования, когда гость подключается.
В руководстве указано, что «команда, предоставленная пользователем (если таковая имеется), игнорируется». Тем не менее, в моих тестах принудительно исполняемый файл мог получить ее из своей среды, переменная называется SSH_ORIGINAL_COMMAND. Это означает, что вы можете разрешить гостю передавать некоторую информацию (например, параметры) непосредственно в своем вызове ssh; на стороне сервера ваша программа извлечет ее из переменной. В коде оболочкине evalпеременнаяине используйте $SSH_ORIGINAL_COMMANDбез кавычек, если вы предварительно не проверите его безопасность или не продезинфицируете его.
Пример строки, ~/.ssh/authorized_keysкоторая позволяет владельцу определенного ключа увидеть вывод, df -hвыглядит следующим образом:
command="df -h",no-pty ssh-rsa AAA…(public key here)…
(Описание no-ptyсм . в man 5 authorized_keysразделе . Существуют и другие параметры, которые могут оказаться полезными.) Теперь любой, кто использует этот конкретный ключ для подключения к серверу (используя ваш логин), увидит вывод df -hи будет отключен.
1. Вероятно. SSH-сервер может быть настроен на запрет различных вещей.
решение2
Вы можете рассмотреть вариант развертывания SSH honeypot. По сути, это фиктивный сервер, который выглядит уязвимым, но не имеет реального доступа ни к чему. Все регистрируется, и вы можете ограничить доступ к командам.
Настройка несложна, и в сети есть много ресурсов с инструкциями по развертыванию. Хотя ответ здесь может быть немного длинным!
РЕДАКТИРОВАТЬ :Superuser — это не совсем то место, где можно давать рекомендации, но, похоже, мы хорошо его использовали, и в сети есть множество руководств:https://github.com/cowrie/cowrie Из README:
Выберите запуск в качестве эмулируемой оболочки (по умолчанию):
- Поддельная файловая система с возможностью добавлять/удалять файлы. Включена полная поддельная файловая система, напоминающая установку Debian 5.0
- Возможность добавления поддельного содержимого файла, чтобы злоумышленник мог перехватывать файлы, такие как /etc/passwd. Включено только минимальное содержимое файла
- Cowrie сохраняет файлы, загруженные с помощью wget/curl или SFTP и scp, для последующей проверки