Pull to refresh

Comments 120

Автор, спасибо! Потихоньку начинаю познавать дао SSH
вот так крупные серверы и ломают с незапамятных времен — через доверенные хосты
Некоторые дополнения
1) Лучше использовать rsa
2) Для копирования ключа на удаленную машину ssh-copy-id скрипт есть
3) ssh-add ~/.ssh/id_dsa достаточно обычно ssh-add без параметра, по дефолту этот ключ и подгрузиться
1. Специалист по безопасности, работающий в нащей конторе, рекомендовал DSA. Да и в случае с RSA можно по незнанию сгенерить 300-битный ключ, который (по экспериментальным данным) взламывается 24-мя Xeon-ами (не скажу, какой мощности, не мой эксперимент) за несколько часов.
2. Я уже привык к cat ~/.ssh/id_dsa.pub| ssh alpha «cat >> ~/.ssh/authorized_keys». Но Вы предложили более корректный способ.
3. Fixed.
UFO landed and left these words here
Не буду спорить. DSA в случае с ssh-keygen хорош тем, что менее 2048 бит не задашь, кажется. А вот в PuTTY у нас некоторые нагенерили экстремально короткие RSA-ключи, по рассказам, раньше дефолтом было 2048, но теперь — 256 или около того.
UFO landed and left these words here
Как это, разрешённая длина ключа? Она как-то ограничена законодательно???
что-то не то с разбивкой на строки
$ ssh-keygen -t dsa -b 768
DSA keys must be 1024 bits
чтобы сгенерить свежий DSA-4096 ключик, мне пришлось отыскать диск с довольно старым дебиановским релизом, ssh-keygen которого не имел нынешних ограничений.
Я совсем рестерялся… Она для разных стран разная? Как это связано с ФСБ?
UFO landed and left these words here
>Если ты разработчик системы использующую криптозащиту — тебе надо ещё сертификат разработчика получить
Да, это я знаю… там не совсем так, вроде бы, — если ты разрабатываешь систему, которая будет использоваться в структурах, связаных с гостайной. И с банками какие-то напряги ещё, но, скорее всего, чисто банковские. Разве нет? Прочие системы хоть заразрабатывайся :)

>сертификат на разрабатываемую систему!
Ну, здесь-то речь шла о ssh. Она уже есть.

>Вот здесь условия и появляются…
Точно? Вы говорите так, как будто вы в курсе — они там действительно ограничивают длину ключа сверху? Не верю!

>Опять же если вспомнить об американских запретах на экспорт криптосистем с длинной ключей превышающих определённую длину
Ну, это американские экспортные ограничения. Тем более, уже отменённые. Их вообще много было разных. К ФСБ отношения не имеют. Тем более, что лицензированием криптоделов всяких занимается у нас не ФСБ.
UFO landed and left these words here
UFO landed and left these words here
>Да, тебе не разрешено пользоваться RSA, но сдругой стороны и не запрещено… ;-)

Мне-то как раз разрешено. Запрещено организациям, связаным с гостайной. И это весьма разумно.

А алгоритм и длина ключа обосновывается тем пойдёт ли злоумышленник на затраты, связаные со взломом и во сколько времени ему это обойдётся. Если это сравнимо со стоимостью и временем актуальности шифруемой информации, то где-так и надо подбирать длину ключа. Чтобы было не меньше. Азы криптологии, вроде бы.
кажется, продавать (внедрять, распространять) можно решения, содержащие только сертифицированные для гражданского использования алгоритмы шифрования. Алгоритмы с переменной длиной ключа как правило сертифицированы до определенной длины.
Это называют одной из причин, почему у нас до сих пор нет сервисов RIM Blackberry.
То есть, в частном порядке ты можешь пользоваться любыми своими разработками, но простой террорист Вася Пупкин не должен иметь возможность купить мобилу, которую госструктуры не смогут прослушать.
1. ЕМНИП RSA ключ по дефолту во всех дистрах генерится минимум 1024-битный. А параноики вроде меня используют 4096-битные ключи :)
> взламывается 24-мя Xeon-ами

… или одной вполне обычной однопроцессорной машиной за 1-2 суток.
Что следует из того, что в сутках 24 часа :)
Не совсем. Даже если работают 24 Xeon, они не обязаны активно обмениваться большими объёмами данных. Они их могут накапливать, после чего данные нужно слить на одну машину для дальнейшей обработки (хотя для этой обработки существуют и параллельные алгоритмы, нужна или многопроцессорная машина, или кластер с очень быстрой сетью; да и для таких маленьких чисел — 300 бит — эти алгоритмы не нужны).

Так что в принципе 24 Xeon, работающих в течении часа — это не то же самое что 1 Xeon, работающий сутки, особенно для алгоритмов оптимизированных для параллельного выполнения и требующих большого количества памяти на каждой ноде.
странно, по моему совсем недавно взлом 128 битного ключа брутфорсом был достижением для нехилой распределенной сети.
Вы путаете симметричные и асимметричные шифры.
300 бит факторизуется за пару часов на одном ядре Xeon 1.6 ггц
400 бит — 24-мя ядрами Xeon 3 ггц — за сутки +- 2 часа.

msieve, mpqs (не самый продвинутый алгоритм факторизации)
Вычисления на каждом ядре ведутся независимо.

Чем длиннее числа — тем хуже, 512 сейчас все еще достаточно сложно раскладывать…

Ну, когда я этим занимался пару лет назад, то использовал ggnfs (msieve ещё не было) и процессор у меня был далеко не 1.6 Ghz… Спасибо за актуальную информацию!
ssh-copy-id не дописывает владельца ключа на удаленной машине, что неудобно для управления ключами.
4.) После логина на машину с ключом -A на ней надо выставить переменную указывающую на SSH_AUTH_SOCK socket. Что-то не припомню, что бы она выставлялась автоматом, как минимум на OpenBSD.
А еще есть такая штука как Kerberos V. При ее настройке оно позволяет вводить пароль один раз без всяких ключей для ssh.
Было бы интересно почитать азы использования. Я пока не связывался с этим.
Нет, Дэвид Блейн, нет! Хочу небольшую статейку на родном языке. Толстые книги и длинные маны читаются тяжко.
В пределах одной сети это может и прикольно, Microsoft AD так и делает, но в случае с машинками в разных сетях на разных площадках это не гуд.
В пределах одной сетки и большом количестве серверов и машин очень полезная штука.
только такая схема имеет единую точку отказа — в виде керберос сервера. что не всегда приемлемо.
Для тех кто не в курсе серверов может быть больше одного :)
а, ну если фолт-толерантность может быть реализована таким образом…
Может. Может. Оно еще по SRV записям искать может.
А чем так плох вариант, с набором пароля каждый раз?
Он так же плох как и использование ключей. В первом случае это keylogger'ы или запись на видео, во втором — кража ключа, неважно, вместе с устройством или с устройства.
UFO landed and left these words here
UFO landed and left these words here
О_о ключ можно взять и передвинуть на десяток машин, подсмотреть passphrase — так же несложно, как подсмотреть пароль, а чаще они еще и одинаковые. Так что это автоматизация и не более.
Просто с консоли проще набрать пароль, истинное место применения — скрипты и девайсы с reduced-клавами, ИМХО.
для ключа у сервера можно указать что мол только с таких-то адресов действует:
[root@server ~]# cat .ssh/authorized_keys
from=«192.168.0.23,192.168.0.25,127.0.0.1» ssh-dss <...>
Тем, что если надо быстро обойти две с лишним сотни машин, задолбаешься вводить :)
мне кажется задолбаешься и обходить тоже =)
Ничуть.
for i in `seq 1 170`; do ssh gamma$i.pup uptime; done
Или спиок из файла:
for i in `cat serverlist`; do echo -n $i" "; ssh $i "uname |grep -q FreeBSD && uname -r"; done

На самом деле, у нас есть скрипт, который умеет брать список из мускуля и обходить его в несколько потоков, попутно вводя рутовый пароль на каждой машине, но я не могу его опубликовать.
хм, то есть рутовый пароль вы храните в плейнтексте в базе? ай-ай-ай.
Нет, в базе хранятся данные о серверах — имя, назначение, ось. Пароли хранятся в GPG-ванном файле, пароль к которому вводится при запуске обходилки.
мм, понятно.
А почему бы в таком случае не использовать как раз ключи? все-таки псевдо-ручной ввод пароля — это костыль.
Под обычным юзером оно заходит по ключам. Сразу под рута не позволяет политика безопасности. Поэтому не костыль.
И чем это отличается от дефолтной схемы ssh с паролированными ключами? :)
Тем, что, введя один раз пароль, под рутом выполняешь команду на большом количестве машин, имеющих PermitRootLogin no в конфиге.
Откуда же берется рут-доступ, если его нету?
Не поверите. Команда su. Делается это через spawn и expect, кажется.
Какой затейливый 5-колёсный велосипед вы изобрели. Проходимость, небось, фантастическая. А если б колёса были не квадратные — летал бы!
Изобрел не я, я только пользуюсь. Будем благодарны, если предложите более адекватную и столь же защищенную схему.
man ssh, man ssh-keygen, man sudo.

Изложите задачу конкретнее.
Имеется большое количество серверов, требующих регулярного обновления софта и починки разного рода косяков. ssh под рутом запрещено. Кроме ssh попасть никак нельзя (так сложилось, да и менять незачем)
Задача: В максимально короткие сроки перепустить апач на 200 машинах, например.
Ну и чем моё решение не устраивает? Распишу тогда…

ssh-keygen'ом создаем ключ на машине-пускателе.
список сервером держим в файле-базе-гденитьеще.
публичные ключи раскидываем по серверам.
там же создаем юзера, делаем

echo «user ALL=(ALL) NOPASSWD: /etc/init.d/apache2 restart» >> /etc/sudoers

В итоге команда будет типа так:

for i in 'выборка серверов';
do ssh $i sudo /etc/init.d/apache2 restart;
done;

в sshd_config можем запретить рута.
Не, sudo не рулит. Во-первых, его у нас нет (или не везде), во-вторых, это потенциальная уязвимость — команды надо выполнять очень разнообразные, поэтому разрешать надо все, в том числе и bash, способный запустить что угодно.
Начать зачитывать man по sudo? :)
Sudo очень гибко настраивается. В частности, можно запретить локальные команды от юзеров (я так понимаю, у вас хостинг и надо предусмотреть защиту от хостерюзеров?), только от внешних, по ssh залогиненных.
Нет. У нас есть админы и программисты. Практика показывает, что один программист может положить один проект, если сказать ему рутовый пароль. Все ходят на серверы с одной точки входа, так что разделить по способу логина невозможно.
Задача: препятствовать злоумышленнику, который смог пробраться под обычным юзером на какую-то машину.
> Все ходят на серверы с одной точки входа, так что разделить по способу логина невозможно.

Ух ты жесть какая… Это как?
Вот так. Есть библиотека, есть демон, слинкованный с ней. Этот демон — основная часть проекта. Он очень чувствителен к версии библиотеки. То есть, при малейшем обновлении либы надо пересобрать демон. А этот товарищ взял и обновил только либу.
При плановом перепуске демона проект упал.
Это называется — неправильная организация рабочего процесса. Архтитектора — уволить, программистов — разогнать, админов — учить матчасть.
если продолжить цепочку, то получается прибыль — в задницу?
Плюс ваш метод споткнется на первом же зависшем севере. Многопоточность необходима.
Ну заскриптуйте на тысяче и одном скриптовом языке многопоточность.
Машины сами по крону раз в N минут лезут на контрольный сервер, скачивают оттуда shell скрипт и запускают от рута
single point-of-failure, огромные лаги, огромные костыли для селективности.
Если мне надо перепустить апач на g3.pup и g19.pup, Ваш способ сделает это минут за 5, не меньше. Наш — за полминуты.
А что ж вы условия задачи враз поменяли? Там про селективность ничего не было. Но и она решается хоть бы и тем же скриптом
if $hostname == 'g3.pup'
Да и управляющий сервер может выдавать разные скрипты разным машинам. Я вообще к тому, что в мире Unix альтернатива есть масса решений для одной и той же задачи.

UFO landed and left these words here
ну… допустим, администртируете вы 50 серверов. ;) надо сделать последовательное действие на каждом. вводить пароль — руки отсохнут.
ключ во-первых намного удобнее (некоторые открывают сотни сессий в день, я десятки, к тому же есть еще scp), а во-вторых менее подвержен брутфорсу на уровне протокола.
Потом, ключи незаменимы для автоматического доступа, когда скрипт открывает ssh-сессию и что-то делает.
Недостатки ключа — невозможность залогиниться с чужой машины, если ключа нет под рукой (как правило, когда человек привык к ключам, авторизация по паролю или выключена, или он все равно его не помнит), опасность кражи ключа (частично компенсируется passphrase), возможность расшифровки публичного ключа (получить доступ к authorized_keys проще, чем к shadow) в случае если он слишком короткий или в результате ошибки дебиановского типа.
Можно добавить про вылавливание ошибок: для клиента запуск ssh -vvv ..., для сервера запуск sshd -ddd, недавно выловил отказ авторизации с помощью ключей на паре машин — оказалось, что сгенерированный ключ сидел в rsa-blacklist
Да, забыл о первом (пользуюсь часто), а второго не знал. В следующий раз как-нибудь — ниже просят еще фичей.
Автор, вы молодец. И да, еще неплохо было бы описать PPP over SSH.
UFO landed and left these words here
UFO landed and left these words here
Это разные вещи. Хорошо, я понял: Вам интересны сервисы типа something-over-ssh. Надеюсь скоро написать продолжение.
UFO landed and left these words here
UFO landed and left these words here
Тссс, никому не говорите… Нет в MacOSX ядра от FreeBSD. Есть ядро Mach.
Часть обвязки да, из BSD, а вот ядро никак нет. Ядро там тоже самое, что у GNU/Hurd.
PPP over SSH не использовал пока, а вот с упоминаемым в man VPN самому хотелось бы разобраться.
Возможно, Вы просто более четко определили понятие VPN.
Ключи -L и -R практически полностью покрывают все надобности в PPP.
ога, а все остальное — от лукавого :-)
А лукавому ключ -w. Всё, на этом ppp окончен.
Пример из жизни:
У меня есть прокси-сервер, который обеспечивает мне доступ в Сеть. Мне необходимо было скачать торрент на маке. К сожалению, Transmission не поддерживает SOCKS-proxy, а мак не мог соединиться с PPTP-VPN, поднятым на сервере. Единственным VPN-решением в моем случае был PPP over SSH:

/usr/sbin/pppd updetach noauth silent nodeflate pty «/usr/bin/ssh root@myserver.net /usr/sbin/pppd nodetach notty noauth» ipparam vpn 192.168.0.1:192.168.0.2


Он меня спас. Так что про «окончен» говорить рано.
Вас могло спасти знание основ :)

Тем же ssh пробросить 1 порт, а на клиенте поднять торрент, указав ему соответствующий «внешний» адрес. Подразумевается, что с внутренней машины есть NAT в инет.

Ну и про ключ -w стоит всё-таки в мане посмотреть. Он поднимает виртуальный интерфейс. Т.е. то, что вы сделали pppd'ой, только без pppd'ы :)

> Мне необходимо было скачать торрент на маке

Вам не нужно было качать торрент на маке, это должен был за вас сделать Стив Джобс и выложить на iTunes :)
интересно узнать, а как народ борется с проблемой подключения к машинам с разной кодировкой.
к примеру приходится администрировать несколько сотен машин с CP1251 и UTF8…
запарился каждый раз попав на машину и увидев нечитаемые файлы с русскими буквами переключаться на другую кодировку…
Это в рамках SSH не решается.
Если проблема с системными сообщениями, поможет export LANG=en_US.utf8 или что-то подобное в .bash_profile.
Если проблема в содержимом файлов, то сложнее. Некоторые настраивают vim для перекодирования на лету, я избегаю русских надписей при помощи LANG=C.
UFO landed and left these words here
ssh также приколен потому, что есть scp
и не надо никакого фтп или samba
правда жутко гнетет совесть, когда качаю какой нибудь фильм на 2 гига с компа соседа, веть он бедный по дороге шифруется)
Практика показывает, что в гигабитной сети Athlon64 3000+ упирается именно в сеть.
Моя практика скачивания торрента через ssh показывает, что упирается он в полную загрузку одного ядра Core2 Duo на скорости свыше трех мегабайт в секунду.
Да, я гоню. Упиралось оно в 30Мб/с, скорость доступа к диску.
а я бы этот пост в системное администрирование перевёл, ведь SSH это не только линукс, но и куча других unix образных систем
Не думаю, что тем, кто всерьез занимается администрированием, будет интересно что-либо кроме 4-го пункта.
Это не очень корректный скрипт. На многие мелочи положен болт (можно было сделать pushd/popd, проверить наличие строки Protocol 2 в конфиге и дописать, если надо…), а некоторое сделано слишком аккуратно (нахрена на удаленной машине сначала делать touch, а потом запись ключа?)
Человек, много пользующийся SSH, может сделать примерно то же самое, но отдавая себе отчет в том, что происходит на каждом шаге.
UFO landed and left these words here
А где рассказ о том как грамотно пользоваться ssh-agent'ом под SCREEN'ом — ведь это извечная проблема админов =)
Я бы сам такой рассказ почитал…
Сам просто закрываю все вкладки восстановленного скрина как можно скорее.
Спасибо. Первый вариант мне кажется наиболее правильным, а если алиас сделать умнее, то вообще замечательно будет.
Спасибо, интересная альтернатива стандартному вбиванию пароля.
«PubkeyAuthentication no» — наверное, имелось в виду «PubkeyAuthentication yes»?
Спасибо. Неправильно выразил свою мысль. Исправил.
Лучше напишите «если не работает — добавьте строку PubkeyAuthentication yes».

А то с Вашими двойными отрицаниями черт ногу сломит:)
ssh -A пробрасывет соединение к ssh-agent на удаленную машину. Имея root, к этому сокету можно получить доступ и я допускаю, что над агентом можно будет сильно надругаться (соответствующие эксплоиты были). Т.е. опасным может быть простой логин на взломанный сервер.

И, надеюсь, всем понятно, насколько увлекательными могут быть последствия утери приватного ключа :)

Это все к тому, что у каждого из вышеперечисленных способов ускорить вход есть свои противопоказания и помнить о них тоже нужно.
Ух ты… а что это такое вы с nc изобразили?

Вообще за п.4 большое человеческое спасибо, пошел стругать config.
Сегодня заметил, что описанное использование ssh-proxy (nc based) приводит к порождению процессов nc на транзитной машине без их уничтожения по окончании сеанса работы.
Да, известное баго. Единого решения нет, о том, как обходить, планирую вскоре написать в еще одной статейке.
в двух словах, к конкретному nc надо найти флаг, который заставит его отмирать по EOF на пайпе.
Only those users with full accounts are able to leave comments. Log in, please.