Разрешить пользователю устанавливать SSH-туннель, но больше ничего

Я хотел бы позволить пользователю настроить SSH-туннель для конкретной машины на определенном порту (скажем, 5000), но я хочу максимально ограничить этого пользователя. (Аутентификация будет с парой открытых / закрытых ключей).

Я знаю, что мне нужно отредактировать соответствующий файл ~ / .ssh / authorized_keys, но я не уверен, какой именно контент туда поместить (кроме открытого ключа).

11.08.2008 17:59:01
10 ОТВЕТОВ
РЕШЕНИЕ

В Ubuntu 11.10 я обнаружил, что могу блокировать команды ssh, отправляемые с ключом -T и без него, и блокировать копирование scp, одновременно разрешая переадресацию портов.

В частности, у меня есть redis-сервер на «somehost», связанный с localhost: 6379, которым я хочу безопасно поделиться через туннели ssh с другими хостами, которые имеют ключевой файл и будут использовать ssh с:

$ ssh -i keyfile.rsa -T -N -L 16379:localhost:6379 someuser@somehost

Это приведет к тому, что redis-сервер «localhost» порт 6379 на «somehost» будет отображаться локально на хосте, выполняющем команду ssh, переназначенном на «localhost» порт 16379.

На удаленном "somehost" Вот то, что я использовал для авторизованных ключей:

cat .ssh/authorized_keys   (portions redacted)

no-pty,no-X11-forwarding,permitopen="localhost:6379",command="/bin/echo do-not-send-commands" ssh-rsa rsa-public-key-code-goes-here keyuser@keyhost

No-pty отключает большинство попыток ssh, которые хотят открыть терминал.

В разрешении на открытие объясняется, какие порты разрешено пересылать, в этом случае порт 6379 - порт redis-сервера, который я хотел перенаправить.

Команда = "/ bin / echo do-not-send-команды" возвращает "do-not-send-команды", если кому-то или чему-то удается отправить команды на хост через ssh -T или другим способом.

В недавней Ubuntu man sshdкоманда author_keys / описана следующим образом:

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

Попытки использовать защищенное копирование файлов scp также потерпят неудачу с эхом «do-not-send-команды». Я обнаружил, что sftp также терпит неудачу с этой конфигурацией.

Я думаю, что предложение об ограниченной оболочке, сделанное в некоторых предыдущих ответах, также является хорошей идеей. Кроме того, я согласен, что все, что здесь подробно описано, можно определить по прочтению «man sshd» и поиску в нем «authorized_keys».

90
26.12.2013 04:08:01
Хотя no-ptyон не позволяет открыть интерактивный вид, он ничего не делает для предотвращения выполнения команды, поэтому пользователь может редактировать authorized_keysфайл, если у него есть доступ с чем-то вроде ssh server 'sed -i -e s/no-pty// ~/.ssh/authorized_keys'.
synapse 25.12.2013 14:06:34
@synapse command = "/ bin / echo do-not-send-команды", также перечисленная выше, предназначена для блокировки команд. и предоставить сообщение. Вы намеревались в своем примере победить все настройки выше или вы только комментируете no-pty?
Paul 26.12.2013 04:03:56
Следует упомянуть, что администраторы не обязаны предоставлять пользователям право собственности на файл author_keys или содержащий каталог, а также на то, что он даже существует в домашнем каталоге пользователей (при условии, что сервер ssh настроен правильно для своего местоположения)
Daniel Farrell 13.02.2014 00:37:34
?? @DanFarrell .ssh / authorized_keys будет принадлежать root, или wheel, или кому?
Andrew Wolfe 23.11.2015 14:35:05
@AndrewWolfe обычно ~user/.ssh/authorized_keysпринадлежит владельцам авторизованных ключей, используемых для доступа к учетной записи user, и userуправляет ими. SSH требователен к разрешениям и может навязывать ожидания ~/.ssh/и его содержимое. Я сделал, sudo chown root: .ssh/authorized_keysи, похоже, я не смог войти в систему, но из прошлого опыта я знаю, что пользователю не нужно владеть этим файлом - вы rootможете управлять им, если хотите.
Daniel Farrell 24.11.2015 18:34:43

Смотрите этот пост по аутентификации открытых ключей .

Две основные вещи, которые вы должны запомнить:

  1. Убедись, что ты chmod 700 ~/.ssh
  2. Добавить блок открытого ключа к авторизованным ключам
-1
28.01.2013 18:50:38

Вы будете генерировать ключ на компьютере пользователя через любой ssh-клиент, который они используют. Например, у pUTTY есть утилита, которая делает именно это. Он будет генерировать как закрытый, так и открытый ключ.

Содержимое сгенерированного файла открытого ключа будет помещено в файл author_keys.

Далее необходимо убедиться, что клиент ssh настроен на использование закрытого ключа, который сгенерировал открытый ключ. Это довольно просто, но немного отличается в зависимости от используемого клиента.

-3
11.08.2008 18:04:01

Возможно, вы захотите установить оболочку пользователя на ограниченную оболочку . Удалите переменную PATH в ~ / .bashrc или ~ / .bash_profile пользователя, и они не смогут выполнять какие-либо команды. Позже, если вы решите, что хотите разрешить пользователям выполнять ограниченный набор команд, например lessили, tailнапример, вы можете скопировать разрешенные команды в отдельный каталог (например, /home/restricted-commands) и обновить PATH так, чтобы он указывал на этот каталог.

18
12.08.2008 00:16:38
Но это не мешает пользователю указать другую команду в командной строке ssh, например ssh use@host "/bin/bash", не так ли?
Fritz 31.08.2015 10:31:01
Да, при условии, что user@hostв качестве оболочки используется rbash. Увидеть Ограниченную Оболочку
Jason Day 31.08.2015 13:23:10
Хорошо, я попробовал это, и вы правы. Поскольку указанная команда выполняется оболочкой входа в систему, выполнение /bin/bashзавершается неудачно, поскольку содержит косые черты.
Fritz 1.09.2015 17:29:10
Хотя следует сказать, что разрешение less, вероятно, плохая идея, потому что оттуда вы можете перейти в неограниченную оболочку с помощью !/bin/bash. См. Pen-testing.sans.org/blog/2012/06/06/… для других примеров. Таким образом, разрешение отдельных команд должно быть сделано очень, очень осторожно, если вообще.
Fritz 1.09.2015 17:33:58

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

no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding

Вы бы хотели строку в вашем файле author_keys, которая выглядит следующим образом.

permitopen="host.domain.tld:443",no-pty,no-agent-forwarding,no-X11-forwardi
ng,command="/bin/noshell.sh" ssh-rsa AAAAB3NzaC.......wCUw== zoredache 
3
4.05.2012 22:47:17

Помимо опции author_keys, такой как no-X11-forwarding, на самом деле есть именно тот, который вы запрашиваете: allowopen = "host: port". Используя эту опцию, пользователь может настроить туннель только для указанного хоста и порта.

Подробнее о формате файла AUTHORIZED_KEYS см. Man sshd.

17
17.11.2010 08:52:05
Вам также необходимо указать «no-pty» как часть набора параметров. Если вы используете только «allowopen», то вы будете ограничивать туннели для данного хоста / порта ... но вы все равно будете использовать интерактивные оболочки.
John Hart 14.08.2012 19:53:10
Ограничивает ли переадресация портов с помощью allowopen и тот тип переадресации туннельного устройства, который запрашивает ssh -w?
flabdablet 29.05.2014 19:20:09
@JohnHart: no-ptyтоже не ограничивает доступ к оболочке, вы все равно попадете в оболочку, она просто не покажет вам подсказку; Вы все еще можете давать команды и видеть вывод просто отлично. Вам нужна command="..."опция, если вы хотите ограничить доступ к оболочке из .ssh/authorized_keys.
Aleksi Torhamo 1.01.2015 20:35:02

Если вы хотите разрешить доступ только для определенной команды, например svn, вы также можете указать эту команду в файле авторизованных ключей:

command="svnserve -t",no-port-forwarding,no-pty,no-agent-forwarding,no-X11-forwarding [KEY TYPE] [KEY] [KEY COMMENT]

С http://svn.apache.org/repos/asf/subversion/trunk/notes/ssh-tricks

3
6.04.2013 01:05:31

Мое решение состоит в том, чтобы предоставить пользователю, который может только туннелировать, без интерактивной оболочки , установить эту оболочку в / etc / passwd в / usr / bin / tunnel_shell .

Просто создайте исполняемый файл / usr / bin / tunnel_shell с бесконечным циклом .

#!/bin/bash
trap '' 2 20 24
clear
echo -e "\r\n\033[32mSSH tunnel started, shell disabled by the system administrator\r\n"
while [ true ] ; do
sleep 1000
done
exit 0

Полностью объяснено здесь: http://blog.flowl.info/2011/ssh-tunnel-group-only-and-no-shell-please/

9
30.10.2013 16:47:50
CTRL + Z выйдет из сценария, предоставляя вам полный доступ к bash ... Попробуйте добавить «trap '' 20» (без кавычек) в самом начале сценария
Big Papoo 1.10.2013 08:50:19
спасибо за подсказку, я добавил перехват некоторых сигналов прерывания
Daniel W. 30.10.2013 16:48:13
Я просто использую / bin / cat для «оболочки». Кажется, работает нормально. Не подозревая о каких-либо подвигах против cat, и даже если вы нашли какой-то шаблон ввода, который может его вызвать, ваш ssh-сеанс просто завершится.
flabdablet 29.05.2014 19:17:26
@ BigPapoo: Вы действительно проверяли это? Я не вижу, куда это убежит. Если вы работаете в оболочке и запускаете ее tunnel_shell, вы, shell -> /bin/bash tunnel_shellконечно, можете вернуться обратно в оболочку, но если вы установили tunnel_shell в качестве оболочки пользователя, у вас будет только /bin/bash tunnel_shellзапуск, без оболочки, в которую можно было бы уйти. , насколько я вижу. Я проверил это и не смог убежать с Ctrl-Z. Если вы сделали попробовать и мог убежать, не могли бы вы опубликовать настройки? Аналогичным образом, если вам известна какая-либо документация, в которой говорится, что она должна работать таким образом, не могли бы вы опубликовать это?
Aleksi Torhamo 1.01.2015 21:00:12

Я сделал C программу, которая выглядит так:

#include <stdio.h>
#include <unistd.h>
#include <signal.h>
#include <stdlib.h>
void sig_handler(int signo)
{
    if (signo == SIGHUP)
        exit(0);
}

int main()
{
    signal(SIGINT, &sig_handler);
    signal(SIGTSTP, &sig_handler);

    printf("OK\n");
    while(1)
        sleep(1);
    exit(0);
}

Я установил оболочку ограниченного пользователя для этой программы.

Я не думаю, что пользователь с ограниченными правами может выполнить что-либо, даже если он это сделает ssh server command, потому что команды выполняются с использованием оболочки, а эта оболочка ничего не выполняет.

0
29.03.2017 04:21:15

Здесь у вас есть хороший пост, который я нашел полезным: http://www.ab-weblog.com/en/creating-a-restricted-ssh-user-for-ssh-tunneling-only/

Идея такова: (с новым ограниченным именем пользователя как «sshtunnel»)

useradd sshtunnel -m -d /home/sshtunnel -s /bin/rbash
passwd sshtunnel

Обратите внимание, что мы используем rbash (limited-bash), чтобы ограничить то, что может делать пользователь: пользователь не может cd (изменить каталог) и не может устанавливать переменные окружения.

Затем мы изменяем переменную PATH env пользователя на пустую /home/sshtunnel/.profile- трюк, который заставит bash не находить команды для выполнения:

PATH=""

Наконец, мы запрещаем пользователю редактировать любые файлы, устанавливая следующие разрешения:

chmod 555 /home/sshtunnel/
cd /home/sshtunnel/
chmod 444 .bash_logout .bashrc .profile
3
13.05.2015 21:13:35