View Full Version : SSH с ограниченным набором команд
Коллеги, возник такой вопрос: потребовали от меня создать CVS repositories для студентов (так чтобы каждый руководитель вместе со своими студентами решали какие репозотории создавать и что там хранить). Давать всем этим студентам полный SSH доступ к серверу не хочется, среди них попадаются "особо умные", которые ну точно постараются намудрить чего-нибудь нестандартного.
Теперь собственно вопрос: можно ли и как настроить сервер чтобы он а) в принципе пускал бы этих юзеров по ССШ, но б) позволял только выполнять команду cvs и ничего другого.
В сети нашел вариант подменить их shell на скрипт, который проверяет если выполняется cvs - то пустить, если нет - но послать, но хочется узнать мнение массы.
Pochemu bi ne soedenitsia s serverom priamo iz workstation-ov?
TortoiseCVS, WinCVS.
Как вариант можно синсталлировать CVS в отдельную директорию, сделать PATH=$CVS_INSTALL_DIR/bin и использовать rbash (man bash).
Pochemu bi ne soedenitsia s serverom priamo iz workstation-ov?
TortoiseCVS, WinCVS.
Чтобы соединиться с сервером из workstation-а у юзера должен быть ssh account на сервере... Если юзер умный - он может и каким-нибудь putty залезть на тот-же сервер. Использовать cvs-овский pserver не катит так как он пароли не кодирует...
Как вариант можно синсталлировать CVS в отдельную директорию, сделать PATH=$CVS_INSTALL_DIR/bin и использовать rbash (man bash).
и chroot их туда? по моему с chroot надо много чего внутрь этой директории пихать, или линки содавать. например что случается с /home директорией юзера?
вопрос по rbash - а он позволяет ограничивать набор разрешенных команд? (сеогндя уже RTFM не получится, других дел навалилось).
и chroot их туда? по моему с chroot надо много чего внутрь этой директории пихать, или линки содавать. например что случается с /home директорией юзера?
вопрос по rbash - а он позволяет ограничивать набор разрешенных команд? (сеогндя уже RTFM не получится, других дел навалилось).
rbash не позволяет менять $PATH, делать cd итд. Т.е. в принципе можно залить все нужные команды в одну директорию, и сделать PATH=/allowed/bin LD_LIBRARY_PATH=/allowed/lib а в /etc/passwd поставить /bin/rbash. Я так понял что можно вполне обойтись без chroot - a.
вот кусок из 'man bash'
RESTRICTED SHELL
... It behaves identically to bash with the exception that the following are disallowed or not performed:
* changing directories with cd
* setting or unsetting the values of SHELL, PATH, ENV, or BASH_ENV
* specifying command names containing /
* specifying a file name containing a / as an argument to the . builtin command
* specifying a filename containing a slash as an argument to the -p option to the hash builtin command
* importing function definitions from the shell environment at startup
* parsing the value of SHELLOPTS from the shell environment at startup
* redirecting output using the >, >|, <>, >&, &>, and >> redirection operators
* using the exec builtin command to replace the shell with another command
* adding or deleting builtin commands with the -f and -d options to the enable builtin command
rbash не позволяет менять $PATH, делать cd итд. Т.е. в принципе можно залить все нужные команды в одну директорию, и сделать PATH=/allowed/bin LD_LIBRARY_PATH=/allowed/lib а в /etc/passwd поставить /bin/rbash. Я так понял что можно вполне обойтись без chroot - a.
вот кусок из 'man bash'
RESTRICTED SHELL
... It behaves identically to bash with the exception that the following are disallowed or not performed:
* changing directories with cd
* setting or unsetting the values of SHELL, PATH, ENV, or BASH_ENV
* specifying command names containing /
* specifying a file name containing a / as an argument to the . builtin command
* specifying a filename containing a slash as an argument to the -p option to the hash builtin command
* importing function definitions from the shell environment at startup
* parsing the value of SHELLOPTS from the shell environment at startup
* redirecting output using the >, >|, <>, >&, &>, and >> redirection operators
* using the exec builtin command to replace the shell with another command
* adding or deleting builtin commands with the -f and -d options to the enable builtin command
А, да, спасибо, похоже на то, что нужно...
Хотя есть у меня идея при которой не надо трогать /etc/passwd.
сервер получает инфо о юзерах не из /etc/passwd а с центрального LDAP-a. Подменять bash в LDAP нельзя, юзеров в лабах в юникс не пустит, а дергать локальный /etc/passwd каждый раз когда создаются/стираются юзера в LDAP-e - точно разсинхронизируемся очень быстро.
Завтра проверю, если получится - доложу здесь!
А, да, спасибо, похоже на то, что нужно...
Хотя есть у меня идея при которой не надо трогать /etc/passwd.
сервер получает инфо о юзерах не из /etc/passwd а с центрального LDAP-a. Подменять bash в LDAP нельзя, юзеров в лабах в юникс не пустит, а дергать локальный /etc/passwd каждый раз когда создаются/стираются юзера в LDAP-e - точно разсинхронизируемся очень быстро.
Завтра проверю, если получится - доложу здесь!
Насчет LDAP-а, а может стоит поставить PAM, включить модуль который делает authentication через LDAP и забыть об /etc/passwd ?
Насчет LDAP-а, а может стоит поставить PAM, включить модуль который делает authentication через LDAP и забыть об /etc/passwd ?
Я предыдущий пост невнимательно прочел, т.е. то что я предлагаю явно в этом случае (когда нельзя менять shell в LDAP) непокатит.
Может сделать slave LDAP сервер (специально для CVS машины), который будет синхронизироватся с центральным, но будет имет rbash к качестве shell-a ?
Я предыдущий пост невнимательно прочел, т.е. то что я предлагаю явно в этом случае (когда нельзя менять shell в LDAP) непокатит.
Может сделать slave LDAP сервер (специально для CVS машины), который будет синхронизироватся с центральным, но будет имет rbash к качестве shell-a ?
Про PAM - у меня как раз так и работает все. А /etc/passwd используется если надо перехитрить LDAP, например имя пользователя поменять или как раз shell. На паре серверов shell как раз так и подменяется на scp-only (на эти сервера юзера только sftp делают).
Про slave LDAP - можно в основном LDAP -е на дереве сделать ветку, в которой будут сидеть юзера с подмененным shell-ом, и PAM на CVS сервере настроить так чтобы он только на эту ветку смотрел. Но опять же надо следить за их синхронизацией...
Все это пока - запасные варианты, я пока все никак свой основной не проверю :)
Так как я хотел сделать - не получилось.
Основная загвоздка - версия sshd не самая последняя, и не поддерживает функциональностей последней версии. Компилировать новый sshd (от OpenSSH) и ставить его на сервер не хочется, я все таки предпочитаю инсталлировать на Дебиане то что уже под него скомпилировано. Думаю на FreeBSD все получилось бы как я задумывал. Но все равно в двух словах обьясню: в доках OpenSSH 4.5 сказано что в конфигурационном файле sshd.conf можно задать какую команду насильно выполнять для юзера когда он логинится (директива ForceCommand). В той же документации написано что в конфигурационном файле можно использовать директиву Match чтобы переопределить некоторые директивы для тех кто попадает под критерий этого Match (например для группы юзеров, или для всех кто приходит с одного домейна, или для конкретного юзера).
Идея была: для конкретного юзера посатвить ForceCommand некий скрипт, который проверяет если юзер пытается делать cvs - то пустить, если юзер пытается делать что-то другое - то не пустить. Таким образом а) юзеру shell никогда не открывается и b) только некоторые ограниченные команды доступны юзеру. Минусы - надо очень аккуратно писать этот самый скрипт чтобы юзер не сумел "вывалиться" в shell передавая "хитрые" символы в команде которую он пытается выполнить. (команда юзера передается через переменную SSH_ORIGINAL_COMMAND, так что все очень легко).
Для более старых версий OpenSSH то же самое можно сделать если юзеру создать файл authorized_keys (так чтобы юзер логинился без пароля, только по паре ключей).
Реально что я реализовал: я нашел shell под названием rssh http://www.pizzashack.org/rssh/
этот shell позвояет ограничить юзеров выплонением одной (или всех, или любой комбинации) из комманд cvs, scp, rsync, rdist (и кажется sftp).
Все юзера у меня в LDAP-е. NSS натроен искать юзеров сначала в локальных файлах, потом в LDAP-e, PAM настроен проверять пароли точно так же. В LDAP-е у юзеров стоит нормальный shell (кому какой нравится). В локальном /etc/passwd создается запись для юзера с идентичными uid, gid, username, но с rssh вместо шелла (само собой :x: вместо пароля). В /etc/shadow ничего про этого юзера не создается. Проблема рассинхронизации остается, буду писать аккуратные скрипты создания/удаления юзеров.
Когда юзер логинится, NSS находит запись в локальном /etc/passwd про юзера, и в LDAP больше не лезит, а посему юзер получает rssh как shell. Пароль по /etc/shadow не проверяется, PAM лезет в LDAP, юзер впускается в систему. Если юзер пытается сделать что-то что ему длеать запрещено - создается лог файл и юзер выкидывается. После того как команда отработала - юзер выкидывается. При попытке сделать ssh без команды и попасть в shell - юзер выкидывается. ТortoiseCVS радостно работает в этом раскладе.
Буду ждать когда OpenSSH 4.5 попадет в Дебиан.
...isk
ssh -l usanoghlogin qoserver /bin/bash -i
dzevov miacogh usanoghneri hamar inch a anum qo server-@?
http://www.securityfocus.com/infocus/1575
а если почитать малость?
поставь sudo попиши что какому юзеру что мона делать и запрети все остальное
Ektich
Dec 14, 2006, 16:54
...isk
ssh -l usanoghlogin qoserver /bin/bash -i
dzevov miacogh usanoghneri hamar inch a anum qo server-@?
Aselu ya /bin/bash iravunq chuni execute ani. Tak chto da brnvum a.
поставь sudo попиши что какому юзеру что мона делать и запрети все остальное
я упорно не хотел идти в этом направлении (создавая 300 юзеров модифицировать sudo файл и все такое), но может в итоге именно это и сделаю (по группам). Хотя вопрос: для sudo юзер должен сначала shell получить, разве нет? А именно этого я не хочу.
http://www.securityfocus.com/infocus/1575
а если почитать малость?
да начитался уже! кернел трогать не хочу, ресурсы лимитить тоже - так что остается restricted shell.
vBulletin® v3.6.8, Copyright ©2000-2008, Jelsoft Enterprises Ltd.