Как ограничить пользователя SSH, чтобы разрешить только SSH-туннелирование?

Как я могу ограничить пользователя на сервере SSH, чтобы разрешить ему только привилегии для SSH TUNNELING ? То есть они не могут запускать команды, даже если они входят в систему через SSH.

Мои Linux-серверы - это Ubuntu 11.04 и OpenWrt.

linux ssh account-restrictions

— LanceBaynes
источник

Ответы:

На стороне сервера вы можете ограничить это, установив для своей пользовательской оболочки значение /bin/true. Это позволит им аутентифицироваться, но на самом деле ничего не запускать, поскольку у них нет оболочки для запуска. Это означает, что они будут ограничены любым подмножеством возможностей, которые SSH может им предложить. Если он предлагает переадресацию портов, они все равно смогут это сделать.

На стороне клиента вы, вероятно, захотите соединиться с -N. Это останавливает запрос клиента на удаленную команду, такую как оболочка, и просто останавливается после завершения аутентификации. _{Спасибо комментаторам за указание на это.}

— Калеб
источник

Я попробую это: P thx!

— LanceBaynes

Чтобы добавить ответ Калеба, вам также может потребоваться сказать клиенту, чтобы он не выполнял оболочку. В командной строке openssh это делается с помощью флага -N. В PuTTY есть похожая опция, но я не помню точное название.

— Билл Б

хм, это в основном безопасность на стороне клиента, нет? Я ищу настройки безопасности на стороне сервера, но спасибо!

— LanceBaynes

Извините, мне было непонятно - я имел ввиду в сочетании с настройкой сервера. В прошлом я знал, что если вы установите оболочку на что-то, что не является оболочкой, вы не сможете подключиться вообще, потому что она пытается открыть оболочку, но не может. Таким образом, защита обеспечивается на стороне сервера (с использованием метода Caleb), но если после этого у вас возникают проблемы с подключением, вам может потребоваться установить переключатель на стороне клиента.

— Билл Б

Вы создаете такого пользователя с помощью useradd sshtunnel -m -d /home/sshtunnel -s /bin/true.

— fracz

Преимущество следующего заключается в том, что переадресация сокетов агентов X11 и SSH также запрещена, что может быть разрешено способом Calebs. Другое преимущество состоит в том, что если пользователь может изменить свою оболочку по умолчанию любым другим способом, это все равно ограничит его доступ по SSH только к пересылкам TCP.

Поместите следующее в свой /etc/ssh/sshd_config:

Match User that-restricted-guy
  AllowTcpForwarding yes
  X11Forwarding no
  AllowAgentForwarding no
  ForceCommand /bin/false

чтобы позволить пользователю that-restricted-guyперенаправлять любые TCP-соединения через ваш SSH-совместимый компьютер (соединение с этим компьютером, а также localhostи даже с этого компьютера на другие машины).

Если вы хотите, чтобы это было еще более ограничительным (что является хорошей идеей), вы также можете сделать следующее:

Match User even-more-restricted-guy
  PermitOpen 127.0.0.1:12345
  X11Forwarding no
  AllowAgentForwarding no
  ForceCommand /bin/false

Это позволит пользователю even-more-restricted-guyтолько перенаправлять соединения на 127.0.0.1 TCP-порт 12345 (как это видно на вашем компьютере с поддержкой SSH).

Когда пользователь обычно подключается, он теперь будет мгновенно отключен, потому что /bin/falseбудет запущена команда, которая ничего не делает, но мгновенно завершает работу с кодом 1. Если вы хотите избежать этого и оставить соединение для переадресации открытым, добавьте -Nфлаг в sshкоманду. Это не будет пытаться выполнить какую-либо команду, но все еще позволяет настроить переадресацию TCP.

Пример команды forward, которая должна работать в последней настройке:

ssh -L 12345:127.0.0.1:12345 -N even-more-restricted-guy@insert-your-machine

— Американские экспедиционные войска
источник

Я перефразировал ответ как улучшенное решение по сравнению с ответом Калебса.

— AEF

Конечно. Я тоже прибрался. Приятно видеть, что недоразумение разрешено. Доброй ночи.

— Jakuje

Вы можете контролировать, что люди могут делать в ssh, сопоставляя группы, предполагая, что ваша версия ssh достаточно новая, чтобы поддерживать ее (openssh 5.x +).

По сути, мы обращаемся с ними, как если бы они были пользователями sftp, но разрешаем переадресацию tcp и, при необходимости, указываем адресаты, на которые они могут пересылать Если вы даете им домашний каталог, но не создаете под ним никаких каталогов, они не могут передавать файлы, потому что у них не будет разрешения на это.

Match Group                     nicepeople
    PubkeyAuthentication        yes
    PasswordAuthentication      yes
    PermitEmptyPasswords        no
    GatewayPorts                no
    ChrootDirectory             /opt/dummy_location/%u
    ForceCommand                internal-sftp
    AllowTcpForwarding          yes
        PermitOpen              192.168.0.8:22
        PermitOpen              192.168.0.5:8080
    # Or leave out the PermitOpen to allow forwarding to anywhere.
    HostbasedAuthentication     no
    RhostsRSAAuthentication     no
    AllowAgentForwarding        no
    Banner                      none

Вы можете повторить эти блоки Match Group для каждой группы, для которой вы хотите задать различные режимы или ограничения.

Вы можете далее контролировать, куда этот человек может выходить в сеть, используя iptables

/sbin/iptables -I OUTPUT -m owner --gid-owner 500 -j REJECT
/sbin/iptables -I OUTPUT -m owner --gid-owner 500 -m tcp -p tcp -d 192.168.0.0/24 -j ACCEPT

Это предполагает, что группа "nicepeople" GID составляет 500.

Некоторые из приведенных выше опций ssh доступны в более старых версиях openssh, но не в разделе Match Group. Match Group очень ограничена в OpenSSH 4.x и более ранних версиях.

— Аарон
источник