Дозволити користувачеві налаштувати тунель SSH, але нічого іншого


97

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

Я знаю, що мені потрібно відредагувати відповідний файл ~ / .ssh / санкціоновані_ключі, але я не впевнений, який саме вміст туди вкласти (крім відкритого ключа).

Відповіді:


91

В 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

Безрезультатно відключає більшість ssh-спроб, які хочуть відкрити термінал.

В дозвільному документі пояснюється, які порти дозволено пересилати, в цьому випадку порт 6379 - порт-сервер redis, який я хотів переслати.

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

З недавнього Ubuntu man sshd, авторизовані_keys / команда описана так:

command = "command" Вказує, що команда виконується кожного разу, коли цей ключ використовується для автентифікації. Команда, надана користувачем (якщо така є), ігнорується.

Спроби використовувати захищене копіювання файлів scp також не вдасться з відгомоном "do-not-send-command". Я знайшов, що sftp також не працює з цією конфігурацією.

Я думаю, що обмежена пропозиція оболонки, зроблена в деяких попередніх відповідях, також є хорошою ідеєю. Також я погодився б, що все детальне тут можна визначити з читання "man sshd" та пошуку в ньому "санкціонованих_кілій"


1
Хоча no-ptyне дозволяє відкривати інтерактивне бачення, воно нічого не запобігає виконанню команд, тому користувач може редагувати authorized_keysфайл, якщо у нього є доступ до чогось подібного ssh server 'sed -i -e s/no-pty// ~/.ssh/authorized_keys'.
синапс

4
@synapse command = "/ bin / echo do-not-send-команди", також перелічені вище, призначений для блокування команд. і надати повідомлення. Чи ви мали намір своїм прикладом перемогти всі налаштування вище, або ви лише коментуєте безжалісне?
Пол

Згадується, що адміністратори не зобов’язані надавати користувачам право власності на файл санкціонованих ключів або каталог, що містить каталог, а також що він навіть існує в домашньому каталозі користувачів (якщо припустимо, що сервер ssh налаштований належним чином для свого розташування)
Даніель Фаррелл,

?? @DanFarrell, чи буде .ssh / санкціоновані_кеї належати корінь, колесо чи хто?
Ендрю Вулф

@AndrewWolfe, як правило, ~user/.ssh/authorized_keysналежатиме userта userкеруватиме авторизованими ключами, що використовуються для доступу до облікового запису. SSH вимогливий до дозволів і може нав’язувати очікування щодо ~/.ssh/його вмісту. Я зробив це, sudo chown root: .ssh/authorized_keysі, здається, це не дозволило мені входити в систему, але я знаю, що з минулого досвіду, що користувачеві не потрібно володіти цим файлом - rootможна керувати ним, якщо хочете.
Даніель Фаррелл

18

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


1
Але це не заважає користувачеві вказати іншу команду в командному рядку ssh, наприклад ssh use@host "/bin/bash", чи не так?
Фріц

Так, це, припускаючи, що user@hostв якості оболонки є rbash. Дивіться Обмежений панцир
День Джейсона

Гаразд, я спробував це, і ти маєш рацію. Оскільки вказана команда виконується оболонкою входу, виконання /bin/bashне вдається, оскільки вона містить косої риски.
Фріц

3
Хоча слід сказати, що дозвіл less- це, мабуть, погана ідея, адже звідти ви можете втекти до необмеженої оболонки !/bin/bash. Дивіться pen-testing.sans.org/blog/2012/06/06/… для інших прикладів. Тому дозволяти окремим командам слід робити дуже, дуже обережно, якщо взагалі.
Фріц

17

Окрім опції санкціонованих_кейсів на зразок no-X11-переадресація, насправді є саме такий, про який ви просите: разрешение = "хост: порт". Використовуючи цю опцію, користувач може налаштувати тунель лише до вказаного хоста та порту.

Докладніше про формат файлу AUTHORIZED_KEYS див. У man sshd.


13
Вам також потрібно буде вказати "no-pty" як частину набору опцій. Якщо ви використовуєте лише "allowopen", тоді ви обмежите тунелі даним хостом / портом ... але ви все одно дозволите інтерактивні оболонки.
Джон Харт

Чи обмежує переадресація портів дозволом відкриття також блокує тип пересилання тунельних пристроїв, про який вимагає ssh -w?
flabdablet

5
@JohnHart: no-ptyне обмежує доступ до оболонки, ви все одно потрапите до оболонки, вона просто не покаже вам підказку; Ви все одно можете давати команди і бачити вихід просто чудово. Вам потрібна command="..."опція, якщо ви хочете обмежити доступ до оболонки .ssh/authorized_keys.
Алексі Торхамо

9

Моє рішення полягає в тому, щоб надати користувачеві, який може лише тунелювати, без інтерактивної оболонки , встановити цю оболонку в / 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
CTRL + Z втече від сценарію, що дає вам повний доступ до удару ... Спробуйте додати "пастку"
'20

1
дякую за підказку, я додав захоплення деяких сигналів переривання
Daniel W.

1
Я просто використовую / bin / cat для "оболонки". Здається, добре працює. Не знаючи жодних подвигів проти кота, і навіть якщо ви знайшли якусь схему введення, яка вдається її зламати, ваш ssh сеанс просто закінчиться.
flabdablet

4
@BigPapoo: Ви насправді це протестували? Я не бачу, куди воно втече. Якщо ви знаходитесь в оболонці, і ви біжите tunnel_shell, вам доведеться, shell -> /bin/bash tunnel_shellзвичайно, ви можете повернутися до оболонки, але якщо ви встановили tunnel_shell як оболонку користувача, у вас буде тільки /bin/bash tunnel_shellбіг, без оболонки, до якої можна втекти , наскільки я бачу. Я перевірив це і не зміг уникнути ctrl-z Якщо ви зробили спробувати і міг втекти, НЕ могли б ви опублікувати настройки? Так само, якщо ви знаєте будь-яку документацію, яка говорить про те, що вона повинна працювати так, чи можете ви це опублікувати?
Алексі Торхамо

3

Я можу налаштувати файл санкціонованих_кейсів з відкритим ключем для входу в систему. Що я не впевнений, це додаткова інформація, необхідна для обмеження того, що цей обліковий запис дозволено робити. Наприклад, я знаю, що можу ставити такі команди, як:

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

Ви хочете, щоб рядок у вашому файлі санкціонованих ключів виглядав приблизно так.

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


3

Ось вам приємний пост, який мені здався корисним: 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 (обмежений баш) для обмеження того, що може робити користувач: користувач не може cd (змінити каталог) і не може встановити будь-які змінні середовища.

Тоді ми редагуємо змінну PATH env користувача /home/sshtunnel/.profileдо нічого - трюк, який змусить bash не знайти жодних команд для виконання:

PATH=""

Нарешті, ми забороняємо користувачеві редагувати будь-які файли, встановлюючи такі дозволи:

chmod 555 /home/sshtunnel/
cd /home/sshtunnel/
chmod 444 .bash_logout .bashrc .profile

0

Я зробив програму на 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, тому що команди виконуються за допомогою оболонки, і ця оболонка нічого не виконує.



-3

Ви згенеруєте ключ на машині користувачів через будь-якого клієнта ssh, яким вони користуються. Наприклад, PUTTY має утиліту зробити цю точну річ. Він генерує як приватний, так і відкритий ключ.

Вміст створеного файлу відкритого ключа буде розміщений у файлі санкціонованих_кілей.

Далі потрібно переконатися, що ssh-клієнт налаштований на використання приватного ключа, який генерував відкритий ключ. Це досить прямо, але трохи відрізняється залежно від клієнта, який використовується.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.