Назад | Перейти на главную страницу

Могу ли я отключить интерактивный доступ к оболочке при туннелировании веб-трафика через SSH?

Я изучаю реализацию SSH-туннелирования в качестве дешевого решения VPN для внешних пользователей для доступа к веб-приложениям, работающим только в интрасети.

В настоящее время я использую Ubuntu Server 10.04.1 64 бит с установленным OpenSSH.

Я использую Putty в ящиках Windows, чтобы создать туннель на локальном порту для моего ssh-сервера.

start putty -D 9999 mysshserver.com -N

Затем я использую команду Firefox использовать прокси-сервер SOCKS на localhost: 9999.

Флаг -N отключит интерактивную оболочку на стороне клиента. Есть ли способ сделать это на стороне сервера?

Помимо отключения корневого доступа, использования аутентификации по ключу rsa и изменения порта по умолчанию; есть ли другие очевидные методы обеспечения безопасности, которым я должен следовать для этой цели? Моя цель - просто иметь возможность туннелировать веб-трафик.

Через четыре года этот ответ заслуживает обновления. Хотя изначально я использовал authorized_keys я и, вероятно, все еще буду использовать его в некоторых избранных случаях, вы также можете использовать центральный sshd_config файл конфигурации сервера.

sshd_config

Вы можете назначить (для вашего конкретного случая использования) группу, например proxy-only или Match отдельные пользователи. В sshd_config. Это делается после глобальных настроек и отменяет, повторяет или уточняет некоторые настройки, указанные в глобальных настройках.

Примечание: некоторые из синтаксиса / директив, используемых в sshd_config(5) задокументированы в man страница для ssh_config(5). В частности, обязательно прочтите УЗОРЫ раздел ssh_config(5).

Для группы это означает ваше Match блок будет начинаться так:

Match group proxy-only

Ты можешь Match следующие критерии: User, Group, Host, LocalAddress, LocalPort и Address. Чтобы соответствовать нескольким критериям, просто разделите запятыми пары шаблон-критерий (group proxy-only выше).

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

В no-pty установка из authorized_keys будет отражено PermitTTY no установка и command="/sbin/nologin" станет ForceCommand /sbin/nologin.

Кроме того, вы также можете установить дополнительные параметры, чтобы удовлетворить паранойю администратора, например chroot-загружаем пользователя в его домашнюю папку и получаем что-то вроде этого:

Match group proxy-only
    PermitTTY no
    ForceCommand /sbin/nologin
    ChrootDirectory %h
    # Optionally enable these by un-commenting the needed line
    # AllowTcpForwarding no
    # GatewayPorts yes
    # KbdInteractiveAuthentication no
    # PasswordAuthentication no
    # PubkeyAuthentication yes
    # PermitRootLogin no

(проверьте себя, нужны ли вам закомментированные строки и при необходимости раскомментируйте)

В %h - токен, который заменяется домашним каталогом пользователя (%u даст имя пользователя и %% знак процента). я обнаружил ChrootDirectory особенно полезно ограничить мои sftp-only пользователи:

Match group sftp-only
    X11Forwarding no
    AllowTcpForwarding no
    ChrootDirectory %h
    ForceCommand internal-sftp
    PasswordAuthentication no

Учтите, что только определенный директивы могут использоваться в Match блок. Проконсультируйтесь с man страница sshd_config(5) для подробностей (ищите Match).

authorized_keys

NB: Часть под этим замечанием была моим первоначальным ответом. Между тем - но это также зависит от особенностей вашего точного sshd версия - в большинстве случаев я бы выбрал метод, описанный выше.

Да, вы можете, настолько детально, насколько вы можете назначать открытые ключи. В дополнение к nologin, рекомендованному ajdecon, я бы предложил установить следующее перед ключевой записью в authorized_keys:

no-pty ssh-rsa ...

No pty сообщает стороне сервера, что для этого ключа не следует выделять псевдотерминал.

Вы также можете принудительно выполнить что-то вроде nologin для определенного ключа, добавив это:

command="/sbin/nologin",no-pty ssh-rsa ...

Для любого пользователя, использующего только туннелирование, измените оболочку входа в систему на / sbin / nologin. Таким образом, ваш пользователь не сможет получить доступ к оболочке на сервере, но по-прежнему сможет запускать настроенные туннели ssh со своего клиента.

Если вы готовы отказаться от аутентификации пользователя / прохода и использовать ключи для входа в систему, вы можете указать параметрs для каждого открытого ключа.

Примечательные параметры:

command = "команда"

Указывает, что команда выполняется всякий раз, когда этот ключ используется для аутентификации. Команда, предоставленная пользователем (если есть), игнорируется.

и

ограничивать

Включите все ограничения, то есть отключите перенаправление порта, агента и X11, а также отключите выделение PTY и выполнение ~ / .ssh / rc.

и наконец

Перенаправление порта Включить переадресацию портов, ранее отключенную параметром ограничения.

С их помощью вы можете в значительной степени ограничить пользователя этой конкретной пары ключей, что (я) он может делать с сеансом SSH.

Это выглядело бы так:

restrict,port-forwarding,command="/sbin/nologin" ssh-rsa <base64-encoded key>

Я знаю, что это может быть не тот ответ, который вы ищете, но рассматривали ли вы возможность использования OpenVPN в качестве альтернативы?

Рекомендую попробовать Tunnelier. Настроить / управлять им намного проще.