Начало понравилось. Поглядим что будет дальше.

кто бы ещё внятно сказал на кой эта фигня нужна...

Почитай-может поймешь?

Нужна-то она, нужна. Или ты про статью? SSH позволяет обойти хакеров с tcpdump, например. Другое дело, что их трясет сейчас сильно - что ни день новые серьезные баги :((

Зайки мои. ssh -- затычка в стиле мелгомягких. Советую почитать _внимательно_ и хорошенько подумать почему во _всех_ букварях про ssh написано только про _два_ компьютера: клиент и сервер.

2dsa почему? поясни плиз)) вроде всё так надёжно и секьурно?!

А можно конкретнее, дедушка Мазай? Альтернативы - VPN, Webmin/SSL или что? Неконструктивная критика - это простой 3.14здеж.

2 dsa: Просвети нас сирых и убогих в чем дело-то.

Мне наравятся люди, которые думают сами, а не послушно подставляют
уши под лапшепад.

Итак: в самом начале этой статьи, говорится, что ssh решает две
задачи. Любого настоящего юниксоида (а не сирого и убогого)
уже одно это должно насторожить: "кухонные комбайны" -- это
несколько из другого мира.

Дальше: я _подчеркнул_, что речь идёт всегда о сети с _одним_ сервером
и одним или нескольким клиентом. Что в юних сетях -- небывальщина.
Тяжело подумать -- почему так?

Поехали дальше: что _именно_ защищает ssh? И стоит оно того?
И какой процент сетвого траффика составляет? А сколько усилий
(читай -- денег) прийдется потратить, что бы защитить остальную часть?
Дак стоит ли городить огород ради одного несчастного 22-го порта?

И опять дальше: вторая задача -- аутентификация (надеюсь все
интересующиеся безопасностью понимают разницу между ней и
авторизацией). Тут вообще караул начинается, сразу же после
появления двух серверов, да еще с разными рутами, а если клиент
управляется третим рутом, то...

Какой идиот тратит время на эту мертворожденную технологию?

перед тем как слать возмущённые комментарии рекомендую прочесть
http://web.mit.edu/kerberos/www/dialogue.html

те, кто начнут тыкать меня носом в "ssh поддерживает авторизацию
по керберос'у" сразу идут лесом, пока не придумают ответ на
вопрос "зачем это надо"?

Все остальные поклонники ssh могут выступить с сочинениям на тему
"нафиг нужны новые сущности, если IPSec и Kerberos, гарантируют
ту же секьюрность, при бОльшием удобстве и меньшем гемморое для
администратора и пользователей"

OpenSSH vs. Kerberos

> Все остальные поклонники ssh могут выступить с сочинениям на тему 
> "нафиг нужны новые сущности, если IPSec и Kerberos, гарантируют 
> ту же секьюрность, при бОльшием удобстве и меньшем гемморое для 
> администратора и пользователей" 

Уболтал черт речистый.
Но если как работает Kerberos в гомогенной среде (юниксы) я еще 
представляю, то как все это запустить в среде где есть виндовые 
машины я найти не смог. 


Ткни носом в доки, буду крайне благодарен.

WBR, Alex Kuklin
alex@kuklin.ru

2 dsa: Так мы не голый пиар слушаем, а людей вроде Бернштейна, а также openbsd core-team... И все-таки я тебя не очень понял. Самое главное в ssh - это криптования трафика, что позволят относительно безопасно пароли передавать, да и просто данные. С этим-то вроде все в порядке? Удобство обслуживания дело десятое имхо.

>Какой идиот тратит время на эту мертворожденную технологию? Лечиться Вам надо, дедушка... ;-) Сами вот лучще почитайте: http://www.sdsc.edu/~schroede/ssh_cug.html

И это: > newbie a bit overwhelmed by terminology: > what is the difference between ssh vs. Kerberos? > they're security and crypto protocols, right?

Uh, apples and oranges. Kerberos is an authentication and access control mechanism. Traditionally based on shared symmetric keys between hosts, it employs the concept of a ticket granting service and encrypted credentials which are passed to hosts/processes to gain access. The most recent versions incorporate a lightweight PKI approach using certificate based identities.

SSH is a set of secure remote access programs which provide an encrypted tunnel, no cleartext passwords, X11 and other service forwarding,etc. There is no ticket granting ticket or any concept of credentials, only trusted public keys.

>Но если как работает Kerberos в гомогенной среде (юниксы) я еще
>представляю, то как все это запустить в среде где есть виндовые
>машины я найти не смог.
Как раз наоборот. В юнихах керберос работает через задницу.
Ни в одном, мне известном, он не поставляется в виде готовом для
использования из коробки (я говорю о пятой версии). А те фирменные адаптации, которые продаются, как довески к коммерческим юнихам, испохабленым "улучшениями и дополнениями" (у Microsoft были хорошие учителя).
В гомогенной windows-среде, если верить Microsoft Press :), всё
работает просто замечтаельно.
В смешанной среде... ну... Как и в случае ssh, клиенты нужны соответствующие. С win2000 скорее всего должно быть всё своё.

Что и бесит. В угоду никчёмному ssh брошена по настоящему классная технология.

what is the difference between ssh vs. Kerberos?>
А дальше пошло словоблудие. Легко распознаваемое, если думать над
прочитанным, а не благовейно внимать.

>Kerberos is an authentication and access control mechanism
базаранет. Кроме разве, что "access control". Я бы хотел услышать чёткое толкование этого термина, ну да ладно. Допустим. Не надо требовать от рекламного постера особой строгости в формулировках.

Итак поехали.

>SSH is a set
гм. "set", говоришь? Два-в-одном... так сказать.
Secure Visual Studio да и только.

>of secure
secure от чего? От прослушивания траффика? Окей. А как насчёт доступа
к ключам? Ах, его ещё и защитить дополнительной парольной фразой!
"Сара, а ты дверь закрыла? А замок повесила? А щеколдочку задвинула?
А крючок накинула? А гвоздик? -- Как нет?!! Ах! Ну вот! Приходи, кто хочешь, бери, что хочешь!"

>remote access programs
гм. telnet, rsh, rlogin? Мало?

>which provide an encrypted tunnel,
Для _одного_ определённого типа трафика (ну или нескольких, с возрастающей в геометрической прогрессией от количества машин и сервисов трудоемкостью администрирования этого хозяйства)

>no cleartext passwords,
Я плакалъ :)
Причём, этот "no cleartext password" нужно колотить по сто раз на
дню (мы же помним, что не защищённый secret phrase ключ -- туфта
голимая, годная только для однопльзовательских машин)

>X11
Вах! Какой пафос!!!
Кстати желательно не забыть отрубить шифрование, а то любимый
ssh сожрёт изрядную долю процессорных тактов, только для того, что бы
отдать X'ы на соседнюю тележку (Или будем настраивать разные криптования для ssh внутри LAN и наружу?), вместо того, что бы
поднять IPSec на исходящем интефейсе своего гайтвея и не напрягать и без того не ахти какие пеньки (мы, опять же, помним, что достоинство
линуха -- низкие требования к железу) в абсолютно безопасной
локалке.

>and other service forwarding,
А разве, когда речь шла об "an encrypted tunnel" подразумевалось,
что-то другое? Или так. Повтор для убедительности?

А теперь самое главное -- администрирование: kerberos -- это централизованная база паролей пользователей (подчеркиваю: не _пользователй_, а паролей), а значит легко контролируемая и управляемая. Это четкая процедура репликации и бэкапов . Это единый вход в сеть, с регулируемой степенью "доверия". Это система доверительных отношений между отдельными областями администрирования.
Ни о чём подобном в случае ssh и речи не идёт.

"Секъюрность траффика"... Ну не дело это системы _аутентификации_. Совсем. Для шифрации траффика есть совсем другие средства. Зачем мешать мух с котлетами?
...собственно впоследствии всё к тому же и пришло ssh, научился пользоваться kerberos'вским паролями (т.е. фактически отказался от своей аутентификации) и что осталось? remote access program и
шифровние траффика? И это стоит отдельного /etc/ssh на каждой машине?
Воистину: комсаомольцы трудностей не боятся.

>удобство обслуживания дело десятое
Во-во. Даешь UNIX для каждой кухарки.

>Советую почитать _внимательно_ и хорошенько подумать почему во _всех_ букварях про ssh написано только про _два_ компьютера: клиент и сервер.

Потому что больше не надо. В любой элементарной операции участвуют два компьютера, например за одним сидит человек, а на втором выполняется программа.

Либо на одном выполняется программа, а на другом лежат данные, которые она обрабатывает. Человек (который сидит за третим компом) тут уже нафиг не нужен, он сделал свое дело - запустил программу, и может отлогиниваться и идти домой пиво пить.

Что касается того, что ssh не делает ничего кроме удаленного выполнения программ (и перенаправления их ввода вывода), то больше ничего и не нужно.

Любую другую операцию можно свести к выполнению команд на удаленной системе. Нужно тебе файлик оттуда прочитать -

ssh otherhost cat

(или dd, если так больше нравится) Нужно к базе данных обратиться - ssh otherhost sqlplus

Это unix, он весь на пайпах построен.

Что же касается удобства администрирования, то как раз в ssh его сильно больше чем во всяких VPN-ах.

>А дальше пошло словоблудие. Легко распознаваемое, если думать над прочитанным, а не благовейно внимать.

Как раз этим Вы здесь и занимаетесь, милостивый государь. SSH - СТАНДАРТНАЯ технология. Далеко не всякую сеть будет дозволено построить с нуля. Поэтому знать как он работает- весьма полезно. Приходилось слышать термин "корпоративный стандарт"?

>SSH - СТАНДАРТНАЯ технология
Наименование организации утвердившей этот "стандарт" можно услышать?

>термин "корпоративный стандарт"?
Как правило он обозначет корпоративный дебелизм, насаждаёмый
малограмотным "Начальником IT-отдела" по совместительству
являющимся близким родственником начальника т.н. корпорации,
и в точности совпадает с содержимым последней прочитанной им
статьи в "Компьютер-пресс".

Хе-хе... хотел бы я посмотреть на "корпорацию", через три года после
того, как там начнут все, кто нипопадя раздавать, кому нипопадя,
какие нипопадя ключи, и при этом _никто_ не сможет контролировать
даже сроков их устаривания.

>>про ssh написано только про _два_ компьютера: клиент и сервер.
>Потому что больше не надо.
а. Ну-ну. (c)проф. Преображенский.

>Это unix, он весь на пайпах построен.
Уважаемый всё ещё под впечатлением недавно прочитанного
Робачевского?

Ваша фамилия случайно не Выбегалло?

>Как правило он обозначет корпоративный дебелизм, насаждаёмый >малограмотным "Начальником IT-отдела" по совместительству

>даже сроков их устаривания.

К сведению шибко грамотных: "дебИлизм" все-таки. По поводу "устаривания" тоже готов поспорить.

"Врачу, исцелися сам."

>>>про ssh написано только про _два_ компьютера: клиент и сервер. >>Потому что больше не надо. >а. Ну-ну. (c)проф. Преображенский.

Очень полезная идея - поскипать всю аргументацию и сказать "ну-ну". Добавлю еще аргументации.

Разбиение всего множества взаимодействующих компьютеров на пары очень способствует, когда все эти компьютеры не относятся к одному security домену. Представим себе что я захожу из дома (системный администратор я) на машину в офисе (системный администратор - сисадмин нашего офиса) и запускаю там программу, скажем vim, которая работает с файлом, лежащим на сервере, стоящим на хостигне (системный администратор - сотрудник провайдера). На чей, спрашивается, керберос-сервер мне ходить за тикетами? А ssh в этой ситуации работает просто замечательно.

>>Это unix, он весь на пайпах построен. >Уважаемый всё ещё под впечатлением недавно прочитанного Робачевского?

Советую почитать архивы fido7.ru.unix и fido7.ru.linux, где я неоднократно высказывал свое мнение о качестве книги Робачевского. Что не означает, естественно, того что я не согласен в этой книге с _каждым_ словом.

>всё поскипать
я и так уже перебрал лимит времени на развлечения

>Советую почитать архивы fido7.ru.unix и fido7.ru.linux,
Я хорошо знаю Витуса Вагнера :)

>Разбиение всего множества взаимодействующих компьютеров на
>пары очень способствует
...бардаку.

В описанном тобой примере, ты просто получишь два тикета.
Если админы не договряться о форвардинге.

> я и так уже перебрал лимит времени на развлечения так не пиши ваще тогда, чего ж разошелся?

никак не могу понять, почему до сих пор человечество не осознало всей бессмыслицы и бесполезности SSH? Юзают его, проги пишут, а смысла бытия все никак уловить не могут...

>>Советую почитать архивы fido7.ru.unix и fido7.ru.linux, >Я хорошо знаю Витуса Вагнера :)

Штирлиц знал Наверняка. Но Наверняк не знал Штирлица. (c) Народ

>>Разбиение всего множества взаимодействующих компьютеров на >>пары очень способствует >...бардаку.

Следует различать бардак и анархию. Ситуация когда мой доступ к ресурсу зависит не от договоренности между некими "высокими договаривающимися сторонами" а от лично моих прав в каждом из независимых security-доменов - больше напоминает анархию, чем бардак. А ситуация когда над высокими договаривающимися сторонами есть еще главный Большой Брат, например Microsoft Passeport напоминает тоталитаризм, от которого, как известно, бардака всяко больше, чем от любой анархии. Но похоже это уже тема для Московского Либертариума, а не для ЛОР.

>никак не могу понять, почему до сих пор человечество
>не осознало всей бессмыслицы и бесполезности SSH?

Ну если под "человечеством" понимать красноглазых, то я тоже не
могу понять. За пределами линукс-комьюнити, эта "стандартная
технология", я бы осторожно сказал, малознакома.

Да вы что, с ума все посходили что-ли? Никто и не спорит, что для больших сетей нужно что-то централизованное, вроде кербероса. А если у меня 5 серверов, зачем мне весь этот огоррод? SSH взводится за пять минут вместе со скачиванием. Вот будет у меня 50 серверов - так это совсем другое, там не только от SSH придётся отказаться, но и от локальных файловых систем (в применении к хранению данных), к примеру. Надо будет что-то распределённое взводить. А так... Можно ещё микроскопом гвозди заколачивать.

>Ситуация когда мой доступ к ресурсу зависит не от договоренности между >некими "высокими договаривающимися сторонами" а от лично моих прав в >каждом из независимых security-доменов

"Сон длинною в параною"(с)

>А если у меня 5 серверов

и ты -- единственный их пользователь :)

А что такого "микроскопичного" в керберосе? Его конфиг как бы
покороче ssh'ного будет. Если вообще будет. И при этом не потребуется никаких модификаций на в telnet/expect ни rsh/sh скриптах.

Нет, я один из двух админов. А SSH мне нравится именно как простое и интегрированное решение конкретной задачи руления сервером на расстоянии. Больше мне ничего не нужно. Когда станет нужно - поставлю.
Так что этот спор абсолютно не о чём. Вы пытаетесь всем доказать, что надо выкинуть все малолитражки нафиг и срочно пересесть на гусеничные вездеходы - они, де, безопаснее на пересечённой местности.

С каких пор kerberos стал гусеничным вездеходом?

В правильном дистре, нужно было бы всего лишь переключится на
соответсвующие PAM'ы. Щелчком мыши. Все настроки клиент возьмет
из DNS.

2 админа на пять серверов... Кучеряво живёте :)

И зачем шифровать (тратить вычислительные ресурсы) в локалке?

>2 админа на пять серверов... Кучеряво живёте :)

Так ведь на серверах-то жизнь не заканчивается.

>И зачем шифровать (тратить вычислительные ресурсы) в локалке?

Потерями вычислительных ресурсов на шифрование потока максимальной ширины в 5 кб/с можно пренебречь.
Я же говорю - у меня конкретная задача: рулить серверами на расстоянии. И такие потребности, IMHO, у большинства пользователей SSH.

to:anonymous (*) (2002-04-26 10:38:46.014) На 100% согласен. Но Вы мистера dsa не переубедите, ибо: Совершенно очевиден максимализм и недостаток практики. Пусть попытается заставить 50 админов сети из ~300 серверов перейти с ssh на kerberos. Хочу насладиться зрелищем.

А dsa говорил, что времени на развлечения мало... Максимализм-экстримиз не есть круто, никогда не бывает "выбросить все кроме этого". Гибкость теряется.

"А говорил, что романтик..." (с) Вертер

>Потерями вычислительных ресурсов на шифрование потока максимальной >ширины в 5 кб/с можно пренебречь.
А если "клиент" -- 486/25Mгц?

>Я же говорю - у меня конкретная задача: рулить серверами на >расстоянии.
А когда прийдет время реально работать? Что-то сомнваюсь,
что тогда админ "поумнеет" и начнет делать так как надо,
а не так как "проще".

>И такие потребности, IMHO, у большинства пользователей SSH.

А подумать?

Твой трафик бежит от твоей машины до шлюза, потом "ныряет" в сеть
общего пользования, а потом опять по локалке до сервера. Нафига
тратить ресурсы твое локальной машины на шифрацию, если опасность
представляет только участок между маршрутизаторами? Подними там
IPsec и _забудь_ про всякие ключи и ssh-клиенты на каждой виндузовой
телеге, на которой ты можешь когда нибудь выйти на свой сервер.
_Всё_. Проблема конфидициальности решена раз и навсегда. Даже
при использовании штатного c:\windows\telnet.exe. И администрить
ты будешь только два рутера, а не каждую тележку в двух сетях.
Причем шифроваться будет _всё_, а не только твои команды
vi-редактора.

>Пусть попытается заставить 50 админов сети из ~300 серверов перейти с >ssh
"Ужас!"(с)Земфира Рамазанова.

>на kerberos
Их не надо заставлять переходить, нужно просто немедленно выгнать
начальника службы безопасности. С волчьим билетом.

Ещё раз: секъюрность это (в основном) -- аутентификация, достоверность, конфидициальность и авторизация. Какие функции
выполняет ssh? ...кроме, того, что создаёт иллюзию якобы
"защищённости".

На закуску: у меня есть хостинг, я хочу дать Васе Пупкину возможность
удалённого доступа с свему серверу, причём его root, мне нафиг не сдался в качестве гостя на моем сервере. Ваш ход?

"А если "клиент" -- 486/25Mгц?"
А если прочесть ман и узнать, что шифрацию можно вообще отключить ??? Или ты думаешь, что ssh дороже IPsec будет ??? :-))))) Если четверка у тебя в безопасной локалке и тебе нужен выход через чужую сеть к другой машине, то 1. Это проще сделать с сервера/роутера, 2. если это действительно нужно делать ТОЛЬКО с 4-еки то ssh съедает отнюдь не какие то там астрономические ресурсы и несколько кило зашифрует мгновенно. Если же тебе нужно только из локалки, только с четверки, только через чужую сеть, только конфиденциально с/за-качать несколько порнушных дивиксов, то тогда, конечно, лучше воспользоваться IPsec :-)))))
Кто ж спорит, что IPsec рульная весчь. Но в подавляющем большинстве случаев он не нужен. А вот если тебе нужен доступ к серверу не из безопасного места (твоей локалки), то ssh тебе очень даже может пригодиться. В отличии от кербероса. А описанный мною случай встречаеться куда как чаще, чем указанный тобой :-)))

"Какие функции выполняет ssh?"
Конфиденциальность и "достоверность", а если запретить вход машинам без ключей - то и аутентификацию.

"На закуску: ... я хочу дать Васе Пупкину возможность
удалённого доступа с свему серверу... Ваш ход?"
Дать ему соответствующего юзера. Причем тут ssh или керберос ???

Скажи честно, ты подрядился доказать, что ssh никому не нужная вещь ???? :-))))))

>"А если "клиент" -- 486/25Mгц?"
>А если прочесть ман и узнать, что шифрацию можно вообще отключить ???
А если прочитать тред?

>ТОЛЬКО с 4-еки то ssh съедает отнюдь не какие то там астрономические >ресурсы
Попробуй

>А описанный мною случай встречаеться куда как чаще,
Красноглазый

>Дать ему соответствующего юзера
Ответ неправильный. Перечитай вопрос

>Скажи честно, ты подрядился доказать, что ssh никому не нужная вещь >???? .
ssh -- мало кому нужная затычка, рождающая в результате большой
бардак

dsa, вроде в редхатах в поставке всегда был керберос - что ты о нем (который в RH) скажешь? Что в нем не хватает с твоей точки зрения?
Ну а вообще - спасибо тебе за то, что трезво смотришь на вещи и делишься с другими своим (правильным) взглядом.

>dsa, вроде в редхатах в поставке всегда был керберос - что ты о нем >(который в RH) скажешь?

Запости что-то типа "kerberos -- рулёз" в другом треде :)

Строго говоря, главный недостаток MIT'овской реализации -- штатовские экспортные ограничения и завязываться на него просто страшно. А
европейский Heimdal по состоянию на январь был в неюзабельном
состоянии.
Ну и слабая/никакая поддержка/интеграция в стандартных
конфигурациях --
посчитай сколько чего надо будет в RedHat поправить чтобы он
заработал, умножь на количество машин, подели на возможность
клонирования конфигураций, возведи в степень количества разных
платформ и реши, как будешь жить с самбовскими клиентами
(проблему аутентификаци надо решать для всех сервисов, а не
для одного только "remote access"), которые посылают пароль
уже в зашифрованном виде...

И помолись, что бы штатовские лойры не добрались до этого
странного дистрибутива.

Вообщем --- "гладко было на бумаге... "

Ну, посмотрел krb в RH72. Есть модуль для PAM, есть переписанные под krb стандартные файлы для //etc/pam.d (хочется надеяться, что напильником махать от этого меньше надо). Якобы их src.rpm пам-модуля может собираться с heimdal.. В курсе обо всем этом?
А heimdal в каком имено состоянии (написано все, но глючит/ написано не все (но необх. минимум есть), что написано глючит/написано не все, но не глючит?
А в win2k какая реализация kerberos? Уж наверно MIT'овская - а как тогда ее в россию допускают?

Еще - я глянул сейчас в suse7.3 (вышло в сент. 2001)- там heimdal идет на 1ом и 3ем дисках. Может у них он доработан напильником до рабочего состояния?

>Якобы их src.rpm пам-модуля может собираться с heimdal.. В курсе обо >всем этом?

Понятия не имею. Для меня первичен AIX, потому, что DCE'шный уже не толком не поддерживается, а проблемы с другими создаёт.

Под линухом всё скорее всего будет работь без проблем, потому, что
в OPenBSD, начиная с 3.0 Heimdail

>хочется надеяться, что напильником махать от этого меньше надо
В простых случая скорее всего действительно проблем не будет и
заработает буквально с полпинка.
Проблемы могут возникнуть при форвардинге тикетов (а без него
kerberos имеет мало смысла, так как не получится единого входа в сеть),
при работе с DNS записями (а это тоже важно, чтобы не раскаладывать
krb5.conf по каждой машине), при обратном разрешении IP-адресов
в DNS-имена: может быть и неправильно настроенная реверсная зона,
и проблемы с несколькими ip-адресами... В heimdail'е с этим
что-то совсем уж заумное накрутили.
MIT'овский login помню не удалось запинать, чтобы он forwardable tickets с первого раза получал, а как это будет делат PAM'овский
модуль в линухе -- ума не приложу. В OBSD бинарник сразу
сделан "с прицелом", а тут...

>А в win2k какая реализация kerberos?поставляется штатно.
Своя наверное... Или относительно своя :)

dsa
"Красноглазый"
Сказал бы сразу. :-))))))))

>"Красноглазый"
>Сказал бы сразу. :-))))))))

Да. Есть узловые места в которых копатьcя приходится, для того, чтобы
потом уже больше не иметь проблем никогда, а не лепить затычки
абы как.

...а вообще забавно, насколько линух-тусовка не готова к восприятию
тех проблем, которые после приличных юнихов глаза режут. Видимо поэтому
и керберос у вас в таком загоне :)

btw, как ты мог заметить проблемы начинаются за пределами той
функциональности, которую обеспечивает керберос. Уж, что-что а
телнет, кторому на каждый чих надо пароль колотить в любом керберосе
поднимется без малейших проблем.

>потом уже больше не иметь проблем никогда, а не лепить затычки "Never say never"