Вопросы Теги

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

Я был однажды сталкивающийся с попыткой определить, какой процесс был позади конкретного порта (на этот раз, это было 8000). Я попробовал множество lsof и netstat, но затем рискнул и попытался поразить порт через браузер (т.е. http://hostname:8000/). О чудо экран-заставка приветствовал меня, и стало очевидно, чем был процесс (для записи, это был Splunk).

Еще одна мысль: "PS-e-o pid, args" (YMMV) может иногда показывать номер порта в списке аргументов. Grep является Вашим другом!

30
13.04.2017, 15:36
3 ответа

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

На стороне клиента Вы, вероятно, захотите соединиться с -N. Это мешает клиенту ПРОСИТЬ удаленную команду, такую как оболочка, она просто останавливается после того, как часть аутентификации сделана. Благодаря комментаторам для pointhing это.

34
27.01.2020, 19:38
  • 1
    я попробую этот out:P Спасибо! –  LanceBaynes 03.06.2011, 12:41
  • 2
    Для добавления к ответу Caleb Вы, возможно, также должны сказать клиенту не выполнить оболочку. С openssh командной строкой это сделано с флагом-N. В PuTTY существует подобная опция, но я не вспоминаю точное имя. –  Bill B 03.06.2011, 22:28
  • 3
    хм, это - в основном клиентская безопасность, нет? Я ищу серверную настройку безопасности, но спасибо! –  LanceBaynes 04.06.2011, 02:29
  • 4
    Извините, я не был ясен - я имел в виду в сочетании с настройкой сервера. Это был мой опыт в прошлом, что, если Вы устанавливаете оболочку на что-то, это не оболочка, Вы не можете соединиться вообще, потому что это пытается открыть оболочку, но не может. Таким образом, безопасность осуществляется на стороне сервера (использующий метод Caleb), но если у Вас есть проблемы, соединяющиеся после этого, Вы, возможно, должны установить клиентский переключатель. –  Bill B 04.06.2011, 07:44
  • 5
    Вы создаете такого пользователя с useradd sshtunnel -m -d /home/sshtunnel -s /bin/true. –  fracz 11.06.2016, 19:48

Вы можете контролировать то, что люди могут сделать в 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

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

Вы можете дополнительно контролировать, где этот человек может отправиться в сеть, используя 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

, это предполагает, что GID группы «NicePeople» 500.

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

1
27.01.2020, 19:38

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

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

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

, чтобы разрешить пользователю that-limited-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-limited-guy только когда-либо пересылать соединения на 127.0.0.1 TCP-порт 12345 (поскольку он виден на вашем компьютере с включенным SSH).

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

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

ssh -L 12345:127.0.0.1:12345 -N even-more-restricted-guy@insert-your-machine
13
27.01.2020, 19:38

Теги

Похожие вопросы