У меня есть программа, работающая на порте удаленного сервера 9999. Поскольку она не поддерживает никакого шифрования и аутентификации, я использую туннель ssh для доступа к нему.
Я использую эту команду:
ssh -L 9999:localhost:9999 user@remotehost
Чтобы сохранить этот туннель живым. Я пишу ssh-скрипт для отслеживания и перезапуска, если что-то пойдет не так. Итак, мне нужно сохранить пароль в скрипте.
Но, учитывая возможность взлома этого клиент-сервера. Я думаю, что будет лучше, если я смогу ограничить этот туннель минимальными полномочиями.
Итак, можно ли ограничить пользователя удаленного хоста, который может использовать только перенаправление туннеля ssh на порт 9999?
Чтобы сохранить этот туннель живым. Я пишу ssh-скрипт для отслеживания и перезапуска, если что-то пойдет не так.
Вы должны изучить использование автосш вместо.
Итак, мне нужно сохранить пароль в скрипте.
Вы должны использовать аутентификацию с открытым ключом вместо пароля.
Итак, можно ли ограничить пользователя удаленного хоста, который может использовать только перенаправление туннеля ssh на порт 9999?
Во-первых, убедитесь, что пользователь не может открыть интерактивную оболочку на сервер машина. Просто создайте конкретную учетную запись, которая будет использоваться только для открытия этого туннеля, если вы еще не используете его. Установите оболочку по умолчанию для этой учетной записи на /sbin/nologin (или /bin/false если первого не существует)
useradd tunnel
usermod -s /sbin/nologin tunnel
Вы должны пойти на клиент machine, сгенерируйте пару ключей ssh и скопируйте открытый ключ на сервер.
ssh-keygen
ssh-copy-id tunnel@server
Наконец, на сервер, ограничьте возможность туннелирования чего угодно, кроме localhost: 9999, с помощью файла authorized_keys. Добавить Добавьте следующее к авторизованному ключу, который был загружен с помощью ssh-copy-id.
no-pty,permitopen="localhost:9999"
No-pty - это еще один параметр безопасности, который запрещает открытие интерактивной оболочки. Результирующая строка выглядит примерно так:
no-pty,permitopen="localhost:9999" ssh-rsa AAAAB3NzaC1y...Rdo/R user@clientbox
Могут быть и другие полезные параметры, которые вы можете установить в authorized_keys file. Для получения дополнительной информации прочтите человек sshd.
Кроме того, вы также можете заблокировать учетную запись в /etc/ssh/sshd_config через блок Match для аккаунта:
Match User tunnel
ForceCommand /sbin/nologin # An additional configuration to disable any shell command, superfluous when the user's shell is already set to `/sbin/nologin`
AllowAgentForwarding no
AllowTcpForwarding local # Disallow port forwarding of remote ports, superfluous when using the `permitopen` restriction in authorized_keys
AllowStreamLocalForwarding no # Probably not necessary, as the user needs to have access rights to access the AF_UNIX port
X11Forwarding no # Because some default configuration files, e.g. from Debian, set it to yes
# Beware: Match does not end with indentation!
Это только советы по улучшению вашей текущей настройки туннеля ssh. Как предположил Деннис, вам следует рассмотреть и другие, более элегантные решения для туннелирования.
Нет, это невозможно. Вы можете отключить переадресацию портов, но это отключает переадресацию любого порта, нет настройки для каждого порта.
Да, это возможно, добавив permitopen="localhost:9999" к ключу в ~/.ssh/authorized_keys на сервере см. справочную страницу sshd (спасибо, Кенни!). Вы также захотите заставить команду, которая ничего не делает, кроме сна, чтобы убедиться, что любой злоумышленник не может получить оболочку (и, таким образом, снять это ограничение и сделать другие плохие вещи).
Тем не менее, ssh - неправильный способ сделать это. Почему бы не использовать станнель сделать сервис доступным по ssl? Или настройте VPN-соединение между двумя машинами с openvpn?
Я бы посмотрел на autossh инструмент.
Страница руководства доступна здесь:
Я использую его, чтобы держать открытыми порты к серверу IMAP и SMTP, которые находятся за брандмауэром. Например:
% autossh -M 0 -f -N -L 2025:localhost:25 -L 2143:localhost:143 \
myuser@remoteserver
Похоже, что есть и в большинстве крупных репозиториев дистрибутивов Linux.