Я хотел бы разрешить пользователю настроить SSH-туннель на конкретную машину на определенном порту (скажем, 5000), но я хочу максимально ограничить этого пользователя. (Аутентификация будет с парой открытых / закрытых ключей).
Я знаю, что мне нужно отредактировать соответствующий файл ~ / .ssh / authorized_keys, но я не уверен, какой именно контент туда поместить (кроме открытого ключа).
Ответы:
В 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-server, порт "localhost" 6379 на "somehost" появится локально на хосте, выполняющем команду ssh, переназначенную на порт "localhost" 16379.
На удаленном "somehost" Вот что я использовал для authorized_keys:
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-server, который я хотел перенаправить.
Команда = "/ bin / echo do-not-send-commands" повторяет "do-not-send-commands", если кому-то или чему-то удается отправить команды на хост через ssh -T или иным образом.
Из недавнего Ubuntu man sshd команда authorized_keys / описывается следующим образом:
command = "command" Указывает, что команда выполняется всякий раз, когда этот ключ используется для аутентификации. Команда, предоставленная пользователем (если есть), игнорируется.
Попытки использовать безопасное копирование файлов scp также будут неудачными с эхом «do-not-send-commands». Я обнаружил, что sftp также терпит неудачу с этой конфигурацией.
Я думаю, что предложение ограниченной оболочки, сделанное в некоторых предыдущих ответах, также является хорошей идеей. Кроме того, я согласен, что все, что здесь подробно описано, можно определить, прочитав "man sshd" и выполнив поиск в нем "authorized_keys"
~user/.ssh/authorized_keysпринадлежит userи userуправляет авторизованными ключами, используемыми для доступа к учетной записи. SSH требователен к разрешениям и может налагать определенные ожидания на ~/.ssh/свое содержимое. Я сделал, sudo chown root: .ssh/authorized_keysи это, кажется, помешало мне войти в систему, но по прошлому опыту я знаю, что пользователю не обязательно владеть этим файлом - он rootможет управлять им, если хотите.
Вы, вероятно, захотите установить оболочку пользователя на ограниченную оболочку . Отключите переменную PATH в ~ / .bashrc или ~ / .bash_profile пользователя, и они не смогут выполнять никакие команды. Позже, если вы решите, что хотите разрешить пользователю (-ам) выполнять ограниченный набор команд, например lessили, tailнапример, вы можете скопировать разрешенные команды в отдельный каталог (например, /home/restricted-commands) и обновить PATH, чтобы указать на этот каталог.
ssh use@host "/bin/bash", не так ли?
user@hostв качестве оболочки используется rbash. Смотрите The Restricted Shell
/bin/bashзавершается неудачно, поскольку она содержит косые черты.
less- это, вероятно, плохая идея, потому что оттуда вы можете уйти в неограниченную оболочку с помощью !/bin/bash. См. Pen-testing.sans.org/blog/2012/06/06/… для других примеров. Так что разрешение отдельных команд должно выполняться очень и очень осторожно, если вообще.
Помимо параметра authorized_keys, такого как no-X11-forwarding, на самом деле есть именно тот, который вы запрашиваете: allowopen = "host: port". Используя эту опцию, пользователь может установить туннель только к указанному хосту и порту.
Подробные сведения о формате файла AUTHORIZED_KEYS см. В man sshd.
no-ptyтакже не ограничивает доступ к оболочке, вы все равно попадете в оболочку, она просто не покажет вам приглашение; Вы по-прежнему можете отдавать команды и прекрасно видеть результат. Вам понадобится command="..."опция, если вы хотите ограничить доступ к оболочке из .ssh/authorized_keys.
Мое решение - предоставить пользователю, который может выполнять только туннелирование, без интерактивной оболочки , установить эту оболочку в / 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/
tunnel_shell, вы будете иметь , shell -> /bin/bash tunnel_shellтак что вы можете, конечно , бежать обратно к раковине, но если вы установите в tunnel_shell качестве оболочки пользователя, вы только уже /bin/bash tunnel_shellработаете, без оболочки , чтобы избежать в , насколько я вижу. Я проверил это и не смог убежать с помощью ctrl-z. Если бы вы все же попробовали и смогли сбежать, не могли бы вы опубликовать настройку? Точно так же, если вы знаете какую-либо документацию, в которой говорится, что это должно работать именно так, не могли бы вы опубликовать это?
Я могу настроить файл authorized_keys с открытым ключом для входа в систему. В чем я не уверен, так это в дополнительной информации, необходимой мне для ограничения разрешенных действий этой учетной записи. Например, я знаю, что могу использовать такие команды, как:
no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding
Вам нужна строка в вашем файле authorized_keys, которая выглядит так.
permitopen="host.domain.tld:443",no-pty,no-agent-forwarding,no-X11-forwardi
ng,command="/bin/noshell.sh" ssh-rsa AAAAB3NzaC.......wCUw== zoredache
Если вы хотите разрешить доступ только для определенной команды, например 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
Вот хороший пост, который я нашел полезным: 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 /home/sshtunnel/.profileдо нуля - трюк, который заставит bash не найти никаких команд для выполнения:
PATH=""
Наконец, мы запрещаем пользователю редактировать любые файлы, установив следующие разрешения:
chmod 555 /home/sshtunnel/
cd /home/sshtunnel/
chmod 444 .bash_logout .bashrc .profile
Я сделал программу на 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, потому что команды выполняются с использованием оболочки, а эта оболочка ничего не выполняет.
См. Этот пост об аутентификации открытых ключей .
Вам нужно помнить о двух основных вещах:
chmod 700 ~/.sshВы сгенерируете ключ на машине пользователя через любой ssh-клиент, который они используют. У pUTTY, например, есть утилита для выполнения именно этого. Он сгенерирует как закрытый, так и открытый ключ.
Содержимое сгенерированного файла открытого ключа будет помещено в файл authorized_keys.
Затем вам нужно убедиться, что клиент ssh настроен на использование закрытого ключа, сгенерировавшего открытый ключ. Это довольно просто, но немного отличается в зависимости от используемого клиента.
no-ptyон не позволяет открывать интерактивные окна, он ничего не делает для предотвращения выполнения команд, поэтому пользователь может редактироватьauthorized_keysфайл, если у него есть доступ с чем-то вродеssh server 'sed -i -e s/no-pty// ~/.ssh/authorized_keys'.