Misha Volodko подготовил (http://www.opennet.ru/base/sec/ssh_chroot.txt.html) руководство по настройке OpenSSH для помещения пользователей в chroot окружение.URL: http://www.opennet.ru/base/sec/ssh_chroot.txt.html
Новость: http://www.opennet.ru/opennews/art.shtml?num=10802
А вот пакет openssh-chroot для Arch Linux
> А вот пакет openssh-chroot
+1 замечательная весч
> К сожалению классический ftp передает логин и парольа слово scp автору неведомо... :) в результате чего появляется на свет велосипед с квадратными колесами.
и какой смысл совать пользователей в chroot? UNIX permissions вам мало? или не умеем готовить?
to squirLэто решение для провайдеров или чего-то подобного
а для баловства можно и scp и UNIX permissions
задумайтесь зачем вообще chroot придумали?
значит нужно это и востребовано :)
chroot придумали для разработки и отладки системных библиотек, в первую очередь - libc, а совсем не для того, о чем Вы подумали
Интересно, хронологию не знал.Значит потом уже прижился и для секурных целей: apache, mysqld, sshd, vsftpd, postfix, ...
к фтп можно прикрутить ссл/тлс
можно, но нужно ли? И часто ли оно прикручено? imho нет
я такого изврата не видел.
нужно
часто
а ты погляди повнимательней
разве scp умеет удалять файлы, создавать директории и менять права доступа на стороне сервера ?
ftp - это делать умеет.
sftp все умеет.
А я тут тоже подготовил руководство, специально для автора. Оно короткое, должен осилить:
man scp
для guest:
man ftp и особенное внимание уделить командам
chmod mode file-name
delete remote-file
mkdir directory-nameно лучше вообще весь man ftp внимательно прочитать и статью тоже.
Не хватало вот только ересь всякую читать на ночь глядя - ещё кошмар приснится...
Как по-твоему создаются и удаляются директории когда я к примеру использую sshfs для fuse?
Подсказка: посылкой соответствующих команду через ssh туннель.
А как копируются файлы?
Подсказка: с помощью scp.
Это называется unix-way. Его специально придумали, чтобы нормальные люди могли спокойно работать не тратя своё время на чтение писанины изобретателей велосипедов.
твоё оригинальное сообщение "man scp",
что можно перевести как "scp - есть полная замена ftp"
на что я тебе указал что scp не является полной заменой ftp
для полной замены требуются дополнительные шаги и утилиты
ты используешь sshfs для fuse и scp
автор статьи использует chroot ssh и scpтак что спи спокойно дорогой guest
>на что я тебе указал что scp не является полной заменой ftp
>для полной замены требуются дополнительные шаги и утилиты
>ты используешь sshfs для fuse и scp
>автор статьи использует chroot ssh и scpscp использует sftp-подсистему ssh и является к ней частным клиентским интерфейсом. другим штатным интерфейсом является sftp, и оно действительно ни в чём не уступает "обычному" ftp. внештатными -- lftp и rsync, которые тоже удобны.
спасибо автору за статью
порой сложно найти чтонить болееменее вменяемое по этому вопросуP.S.
народ если вы можете умнее написать - ВПЕРЕД
вплоть до перевода man scpguest -> ignore (из толпы проще орать)
т. е. вы активно этим пользуетесь и вам обидно не только за автора но и за себя?
отвечаю. я - не буду писать статью на подобную тему. потому что не вижу смысла загонять ssh юзеров в chroot. точка.
>т. е. вы активно этим пользуетесь и вам обидно не только за
>автора но и за себя?
>отвечаю. я - не буду писать статью на подобную тему. потому что
>не вижу смысла загонять ssh юзеров в chroot. точка.
подходы к безопасности для локального сервера на котором пасутся 3-5 знакомых админу юзеров
отличаются от подходов к безопасности для провайдерcкого сервера(ов)
примерно так же как запорожец от строительной спец. машиныесли у Вас "запорожец" - не следует отвечать так автору, цитирую
> а слово scp автору неведомо... :) в результате чего появляется на свет велосипед с квадратными колесами.
> и какой смысл совать пользователей в chroot? UNIX permissions вам мало? или не умеем готовить?так как его статья интересна только для серьезных и крупных решений
Серьезных и крупных? :) chroot - это иллюзия безопасности, а не "серьезное и крупное" решение.
"chroot - это серьёзное решение"
звучит так же смешно как и ваше
"chroot - это иллюзия безопасности"
необходимо добавить почему, но тут у нас у обоих пробел в образовании наверно :-)
вместо
>"chroot - это серьёзное решение"
было
>"статья интересна только для серьезных и крупных решенийну а почему?
наверно потому, что chroot(в том числе и на уровне других приложений http/proxy/smtp/ftp/database) или VM дополнительно повышают безопасность многопользовательской системы.
Лично я думаю так, со своей маленькой колокольни конечно :)
>"chroot - это серьёзное решение"
>звучит так же смешно как и ваше
>"chroot - это иллюзия безопасности"
>необходимо добавить почему, но тут у нас у обоих пробел в образовании
>наверно :-)потому что большинство юных админов пихают в chroot все сервисы подряд, при этом не заботятся об остальных аспектах и пренебрегая изучением матчасти. основной довод - "даже если чуваг получит рута - ничево ни сделаит в чруте". а это глупость, ибо вполне возможно вырваться из chroot.
Скажите как, я хочу это знать...
иллюзия безопасности если там рута давать или система дырявая. хотя с патчиками от grsec все выглядит намного лучше. а потребность такая есть и правами доступа решать намного сложнее. примерно по той же причине, почему всякие селинуксы и прочии rsbac внедряются с большим скрипом - гимороя много. я эту проблему частично закрыл виртуальными системами, но хочется еще простой и быстрый способ для ssh/scp/sftp. для ftp chroot есть давно и используется часто.
>иллюзия безопасности если там рута давать или система дырявая.Систему всегда нужно считать дырявой, ибо нет никакой гарантии, что админ узнает первым об очердной локальной дыре в ядре или работающей из-под рута программе. А дыры ой как часто появляются. Chroot с минимумом утилит сильно помогает, особенно если на машине крутятся разные сервисы. Упование на стандартные средства разделения привилегий и всякие gresecurity/openwall патчи, как раз и есть иллюзия безопасности.
А как насчет sftp ?
Лично я для таких целей использовал pam-chrootА так UNIX permissions не всегда можно везде проверить (и наблюдаем, например, дистр q3 в /tmp, где нет квот), кроме того iptables -m owner рулит
ИМХО, действительно проще сделать это при помощи pam-chroot. Использовал его во FreeBSD - работает с родным sshd и без дополнительный костылей-патчей. Работает один-в-один так же. Единственная проблема chroot - необходимость копирования библиотек и бинарников в домашнюю папку каждому пользователю. Хотя есть мысль использовать nullfs для этих целей, но как это будет работать для сотни-другой пользователей - хз :)
ой нульфс прекрасно помоему справляется со всем что надо :)
Согласен с большинством отметившихся выше. С одной стороны статья ничего, как Quick Guide для конкретного решения сойдет. С другой именно что велосипед с квадратными колесами. Если я хостинг-провайдер и даю рутовый доступ юзерам, я лично я бы выбрал более надежное решения, а главное более гибкое и настраиваемое чем chroot. Благо что есть Virtuozzo/OpenVZ. А для заливки контента на свой сайт связки ssh(scp/sftp) + WinSCP(это опционально) более чем достаточно.
apt-cache show scponlyDescription: Restricts the commands available to scp- and sftp-users
"scponly" is an alternative 'shell' (of sorts) for system
administrators who would like to provide access to remote users to
both read and write local files without providing any remote
execution priviledges. Functionally, it is best described as a
wrapper to the mostly trusted suite of ssh applications.
FTP - вообще дегенеративный протокол, скажем не предназначен для работы через фаерволл.А если к нему прикрутить SSL получится ужосн*х - мало того что ублюдочный протокол, так еще и нестандартно нифига.И смысл всего этого?
а мне jail нравится =)
>FTP - вообще дегенеративный протокол, скажем не предназначен для работы через фаерволл.А
>если к нему прикрутить SSL получится ужосн*х - мало того что
>ублюдочный протокол, так еще и нестандартно нифига.И смысл всего этого?В классическом FTP на сервер пытались возложить функцию управления нагрузкой для эффективного использования каналов и вычислительных ресурсов сервера. Отсюда и инициация от сервера. Теперь это пробуют решать с помощью bittorent и т.п. .
Разделение каналов на управляющий и данных тоже правильно.
>В классическом FTP на сервер пытались возложить функцию управления нагрузкой для эффективного
>использования каналов и вычислительных ресурсов сервера. Отсюда и инициация от сервера.
>Теперь это пробуют решать с помощью bittorent и т.п. .на мой взгляд, не совсем верно. расскажите мне, пожалуйста, в каком из "классических" FTP-серверов это было реализовано? ;) в те годы, когда придумывали FTP, никто ни о той, ни о другой эффективности даже и не думал. если вы видели внутренности хотя бы одного из ftp-серверов хотя бы пятнадцатилетней давности, вы бы такое не говорили. =)
>Разделение каналов на управляющий и данных тоже правильно.
это всё оправдание программисткой лени и нежелания менять криво работающие старые схемы на более корректные новые. но, если вы так настаиваете -- попробуйте рассказать, чем же именно выгодно такое разделение, особенно, в таком топорном и неграмотном виде, как это сделано в FTP?
Хе хе, у Таненбаума в его книге по сетям есть такое высказывание, что на заре интернета, некоторые протоколы придумывались студентами-недоучками, но потом все равно обрели свою популярность, так как сперва у них просто не было альтернатив, а потом к ним просто привыкли. Я вот все думаю - не FTP ли он имел ввиду?
>Хе хе, у Таненбаума в его книге по сетям есть такое высказывание,
>что на заре интернета, некоторые протоколы придумывались студентами-недоучками, но потом все
>равно обрели свою популярность, так как сперва у них просто не
>было альтернатив, а потом к ним просто привыкли. Я вот все
>думаю - не FTP ли он имел ввиду?И FTP тоже. Хотя, как по мне, так в последние лет восемь более актуальны врождённые дефекты того же SMTP (мы же все помним, что какое-то время в сетях с SMTP open relay был нормой вообще, и тому были причины).
Впрочем, к Танненбауму тоже много претензий по тому, что он, всё-таки, довольно поверхностно представляет себе суть причин успешности конкурирующих решений (в т. ч. причин популярности того или иного протокола). Ну неинтересны ему такие вещи, и он о них даже думать ленится.