Comments 120
Автор, спасибо! Потихоньку начинаю познавать дао SSH
Некоторые дополнения
1) Лучше использовать rsa
2) Для копирования ключа на удаленную машину ssh-copy-id скрипт есть
3) ssh-add ~/.ssh/id_dsa достаточно обычно ssh-add без параметра, по дефолту этот ключ и подгрузиться
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.
2. Я уже привык к cat ~/.ssh/id_dsa.pub| ssh alpha «cat >> ~/.ssh/authorized_keys». Но Вы предложили более корректный способ.
3. Fixed.
UFO just landed and posted this here
Не буду спорить. DSA в случае с ssh-keygen хорош тем, что менее 2048 бит не задашь, кажется. А вот в PuTTY у нас некоторые нагенерили экстремально короткие RSA-ключи, по рассказам, раньше дефолтом было 2048, но теперь — 256 или около того.
UFO just landed and posted this here
Как это, разрешённая длина ключа? Она как-то ограничена законодательно???
$ ssh-keygen -t dsa -b 768
DSA keys must be 1024 bitsчто-то не то с разбивкой на строки
$ ssh-keygen -t dsa -b 768DSA keys must be 1024 bitsЯ совсем рестерялся… Она для разных стран разная? Как это связано с ФСБ?
UFO just landed and posted this here
>Если ты разработчик системы использующую криптозащиту — тебе надо ещё сертификат разработчика получить
Да, это я знаю… там не совсем так, вроде бы, — если ты разрабатываешь систему, которая будет использоваться в структурах, связаных с гостайной. И с банками какие-то напряги ещё, но, скорее всего, чисто банковские. Разве нет? Прочие системы хоть заразрабатывайся :)
>сертификат на разрабатываемую систему!
Ну, здесь-то речь шла о ssh. Она уже есть.
>Вот здесь условия и появляются…
Точно? Вы говорите так, как будто вы в курсе — они там действительно ограничивают длину ключа сверху? Не верю!
>Опять же если вспомнить об американских запретах на экспорт криптосистем с длинной ключей превышающих определённую длину
Ну, это американские экспортные ограничения. Тем более, уже отменённые. Их вообще много было разных. К ФСБ отношения не имеют. Тем более, что лицензированием криптоделов всяких занимается у нас не ФСБ.
Да, это я знаю… там не совсем так, вроде бы, — если ты разрабатываешь систему, которая будет использоваться в структурах, связаных с гостайной. И с банками какие-то напряги ещё, но, скорее всего, чисто банковские. Разве нет? Прочие системы хоть заразрабатывайся :)
>сертификат на разрабатываемую систему!
Ну, здесь-то речь шла о ssh. Она уже есть.
>Вот здесь условия и появляются…
Точно? Вы говорите так, как будто вы в курсе — они там действительно ограничивают длину ключа сверху? Не верю!
>Опять же если вспомнить об американских запретах на экспорт криптосистем с длинной ключей превышающих определённую длину
Ну, это американские экспортные ограничения. Тем более, уже отменённые. Их вообще много было разных. К ФСБ отношения не имеют. Тем более, что лицензированием криптоделов всяких занимается у нас не ФСБ.
UFO just landed and posted this here
UFO just landed and posted this here
>Да, тебе не разрешено пользоваться RSA, но сдругой стороны и не запрещено… ;-)
Мне-то как раз разрешено. Запрещено организациям, связаным с гостайной. И это весьма разумно.
А алгоритм и длина ключа обосновывается тем пойдёт ли злоумышленник на затраты, связаные со взломом и во сколько времени ему это обойдётся. Если это сравнимо со стоимостью и временем актуальности шифруемой информации, то где-так и надо подбирать длину ключа. Чтобы было не меньше. Азы криптологии, вроде бы.
Мне-то как раз разрешено. Запрещено организациям, связаным с гостайной. И это весьма разумно.
А алгоритм и длина ключа обосновывается тем пойдёт ли злоумышленник на затраты, связаные со взломом и во сколько времени ему это обойдётся. Если это сравнимо со стоимостью и временем актуальности шифруемой информации, то где-так и надо подбирать длину ключа. Чтобы было не меньше. Азы криптологии, вроде бы.
кажется, продавать (внедрять, распространять) можно решения, содержащие только сертифицированные для гражданского использования алгоритмы шифрования. Алгоритмы с переменной длиной ключа как правило сертифицированы до определенной длины.
Это называют одной из причин, почему у нас до сих пор нет сервисов RIM Blackberry.
То есть, в частном порядке ты можешь пользоваться любыми своими разработками, но простой террорист Вася Пупкин не должен иметь возможность купить мобилу, которую госструктуры не смогут прослушать.
Это называют одной из причин, почему у нас до сих пор нет сервисов RIM Blackberry.
То есть, в частном порядке ты можешь пользоваться любыми своими разработками, но простой террорист Вася Пупкин не должен иметь возможность купить мобилу, которую госструктуры не смогут прослушать.
1. ЕМНИП RSA ключ по дефолту во всех дистрах генерится минимум 1024-битный. А параноики вроде меня используют 4096-битные ключи :)
> взламывается 24-мя Xeon-ами
… или одной вполне обычной однопроцессорной машиной за 1-2 суток.
… или одной вполне обычной однопроцессорной машиной за 1-2 суток.
Что следует из того, что в сутках 24 часа :)
Не совсем. Даже если работают 24 Xeon, они не обязаны активно обмениваться большими объёмами данных. Они их могут накапливать, после чего данные нужно слить на одну машину для дальнейшей обработки (хотя для этой обработки существуют и параллельные алгоритмы, нужна или многопроцессорная машина, или кластер с очень быстрой сетью; да и для таких маленьких чисел — 300 бит — эти алгоритмы не нужны).
Так что в принципе 24 Xeon, работающих в течении часа — это не то же самое что 1 Xeon, работающий сутки, особенно для алгоритмов оптимизированных для параллельного выполнения и требующих большого количества памяти на каждой ноде.
Так что в принципе 24 Xeon, работающих в течении часа — это не то же самое что 1 Xeon, работающий сутки, особенно для алгоритмов оптимизированных для параллельного выполнения и требующих большого количества памяти на каждой ноде.
300 бит факторизуется за пару часов на одном ядре Xeon 1.6 ггц
400 бит — 24-мя ядрами Xeon 3 ггц — за сутки +- 2 часа.
msieve, mpqs (не самый продвинутый алгоритм факторизации)
Вычисления на каждом ядре ведутся независимо.
Чем длиннее числа — тем хуже, 512 сейчас все еще достаточно сложно раскладывать…
400 бит — 24-мя ядрами Xeon 3 ггц — за сутки +- 2 часа.
msieve, mpqs (не самый продвинутый алгоритм факторизации)
Вычисления на каждом ядре ведутся независимо.
Чем длиннее числа — тем хуже, 512 сейчас все еще достаточно сложно раскладывать…
ssh-copy-id не дописывает владельца ключа на удаленной машине, что неудобно для управления ключами.
4.) После логина на машину с ключом -A на ней надо выставить переменную указывающую на SSH_AUTH_SOCK socket. Что-то не припомню, что бы она выставлялась автоматом, как минимум на OpenBSD.
А еще есть такая штука как Kerberos V. При ее настройке оно позволяет вводить пароль один раз без всяких ключей для ssh.
Было бы интересно почитать азы использования. Я пока не связывался с этим.
В пределах одной сети это может и прикольно, Microsoft AD так и делает, но в случае с машинками в разных сетях на разных площадках это не гуд.
А чем так плох вариант, с набором пароля каждый раз?
Он так же плох как и использование ключей. В первом случае это keylogger'ы или запись на видео, во втором — кража ключа, неважно, вместе с устройством или с устройства.
UFO just landed and posted this here
UFO just landed and posted this here
О_о ключ можно взять и передвинуть на десяток машин, подсмотреть passphrase — так же несложно, как подсмотреть пароль, а чаще они еще и одинаковые. Так что это автоматизация и не более.
Просто с консоли проще набрать пароль, истинное место применения — скрипты и девайсы с reduced-клавами, ИМХО.
Просто с консоли проще набрать пароль, истинное место применения — скрипты и девайсы с reduced-клавами, ИМХО.
Тем, что если надо быстро обойти две с лишним сотни машин, задолбаешься вводить :)
мне кажется задолбаешься и обходить тоже =)
Ничуть.
Или спиок из файла:
На самом деле, у нас есть скрипт, который умеет брать список из мускуля и обходить его в несколько потоков, попутно вводя рутовый пароль на каждой машине, но я не могу его опубликовать.
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 машинах, например.
Задача: В максимально короткие сроки перепустить апач на 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 можем запретить рута.
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 залогиненных.
Sudo очень гибко настраивается. В частности, можно запретить локальные команды от юзеров (я так понимаю, у вас хостинг и надо предусмотреть защиту от хостерюзеров?), только от внешних, по ssh залогиненных.
Нет. У нас есть админы и программисты. Практика показывает, что один программист может положить один проект, если сказать ему рутовый пароль. Все ходят на серверы с одной точки входа, так что разделить по способу логина невозможно.
Задача: препятствовать злоумышленнику, который смог пробраться под обычным юзером на какую-то машину.
Задача: препятствовать злоумышленнику, который смог пробраться под обычным юзером на какую-то машину.
> Все ходят на серверы с одной точки входа, так что разделить по способу логина невозможно.
Ух ты жесть какая… Это как?
Ух ты жесть какая… Это как?
Плюс ваш метод споткнется на первом же зависшем севере. Многопоточность необходима.
Машины сами по крону раз в N минут лезут на контрольный сервер, скачивают оттуда shell скрипт и запускают от рута
single point-of-failure, огромные лаги, огромные костыли для селективности.
Если мне надо перепустить апач на g3.pup и g19.pup, Ваш способ сделает это минут за 5, не меньше. Наш — за полминуты.
Если мне надо перепустить апач на g3.pup и g19.pup, Ваш способ сделает это минут за 5, не меньше. Наш — за полминуты.
А что ж вы условия задачи враз поменяли? Там про селективность ничего не было. Но и она решается хоть бы и тем же скриптом
Да и управляющий сервер может выдавать разные скрипты разным машинам. Я вообще к тому, что в мире Unix альтернатива есть масса решений для одной и той же задачи.
if $hostname == 'g3.pup'Да и управляющий сервер может выдавать разные скрипты разным машинам. Я вообще к тому, что в мире Unix альтернатива есть масса решений для одной и той же задачи.
UFO just landed and posted this here
ну… допустим, администртируете вы 50 серверов. ;) надо сделать последовательное действие на каждом. вводить пароль — руки отсохнут.
ключ во-первых намного удобнее (некоторые открывают сотни сессий в день, я десятки, к тому же есть еще scp), а во-вторых менее подвержен брутфорсу на уровне протокола.
Потом, ключи незаменимы для автоматического доступа, когда скрипт открывает ssh-сессию и что-то делает.
Недостатки ключа — невозможность залогиниться с чужой машины, если ключа нет под рукой (как правило, когда человек привык к ключам, авторизация по паролю или выключена, или он все равно его не помнит), опасность кражи ключа (частично компенсируется passphrase), возможность расшифровки публичного ключа (получить доступ к authorized_keys проще, чем к shadow) в случае если он слишком короткий или в результате ошибки дебиановского типа.
Потом, ключи незаменимы для автоматического доступа, когда скрипт открывает ssh-сессию и что-то делает.
Недостатки ключа — невозможность залогиниться с чужой машины, если ключа нет под рукой (как правило, когда человек привык к ключам, авторизация по паролю или выключена, или он все равно его не помнит), опасность кражи ключа (частично компенсируется passphrase), возможность расшифровки публичного ключа (получить доступ к authorized_keys проще, чем к shadow) в случае если он слишком короткий или в результате ошибки дебиановского типа.
Можно добавить про вылавливание ошибок: для клиента запуск ssh -vvv ..., для сервера запуск sshd -ddd, недавно выловил отказ авторизации с помощью ключей на паре машин — оказалось, что сгенерированный ключ сидел в rsa-blacklist
Автор, вы молодец. И да, еще неплохо было бы описать PPP over SSH.
UFO just landed and posted this here
PPP over SSH не использовал пока, а вот с упоминаемым в man VPN самому хотелось бы разобраться.
Возможно, Вы просто более четко определили понятие VPN.
Возможно, Вы просто более четко определили понятие VPN.
Ключи -L и -R практически полностью покрывают все надобности в PPP.
ога, а все остальное — от лукавого :-)
А лукавому ключ -w. Всё, на этом ppp окончен.
Пример из жизни:
У меня есть прокси-сервер, который обеспечивает мне доступ в Сеть. Мне необходимо было скачать торрент на маке. К сожалению, Transmission не поддерживает SOCKS-proxy, а мак не мог соединиться с PPTP-VPN, поднятым на сервере. Единственным VPN-решением в моем случае был PPP over SSH:
Он меня спас. Так что про «окончен» говорить рано.
У меня есть прокси-сервер, который обеспечивает мне доступ в Сеть. Мне необходимо было скачать торрент на маке. К сожалению, 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 :)
Тем же ssh пробросить 1 порт, а на клиенте поднять торрент, указав ему соответствующий «внешний» адрес. Подразумевается, что с внутренней машины есть NAT в инет.
Ну и про ключ -w стоит всё-таки в мане посмотреть. Он поднимает виртуальный интерфейс. Т.е. то, что вы сделали pppd'ой, только без pppd'ы :)
> Мне необходимо было скачать торрент на маке
Вам не нужно было качать торрент на маке, это должен был за вас сделать Стив Джобс и выложить на iTunes :)
интересно узнать, а как народ борется с проблемой подключения к машинам с разной кодировкой.
к примеру приходится администрировать несколько сотен машин с CP1251 и UTF8…
запарился каждый раз попав на машину и увидев нечитаемые файлы с русскими буквами переключаться на другую кодировку…
к примеру приходится администрировать несколько сотен машин с CP1251 и UTF8…
запарился каждый раз попав на машину и увидев нечитаемые файлы с русскими буквами переключаться на другую кодировку…
Это в рамках SSH не решается.
Если проблема с системными сообщениями, поможет
Если проблема в содержимом файлов, то сложнее. Некоторые настраивают vim для перекодирования на лету, я избегаю русских надписей при помощи LANG=C.
Если проблема с системными сообщениями, поможет
export LANG=en_US.utf8 или что-то подобное в .bash_profile.Если проблема в содержимом файлов, то сложнее. Некоторые настраивают vim для перекодирования на лету, я избегаю русских надписей при помощи LANG=C.
luit -encoding «KOI8-R» ssh ip
UFO just landed and posted this here
ssh также приколен потому, что есть scp
и не надо никакого фтп или samba
правда жутко гнетет совесть, когда качаю какой нибудь фильм на 2 гига с компа соседа, веть он бедный по дороге шифруется)
и не надо никакого фтп или samba
правда жутко гнетет совесть, когда качаю какой нибудь фильм на 2 гига с компа соседа, веть он бедный по дороге шифруется)
а я бы этот пост в системное администрирование перевёл, ведь SSH это не только линукс, но и куча других unix образных систем
Для этих целей я использую универсальный скрипт. Проверен в Linux, Mac OS X, Cygwin.
Это не очень корректный скрипт. На многие мелочи положен болт (можно было сделать pushd/popd, проверить наличие строки Protocol 2 в конфиге и дописать, если надо…), а некоторое сделано слишком аккуратно (нахрена на удаленной машине сначала делать touch, а потом запись ключа?)
Человек, много пользующийся SSH, может сделать примерно то же самое, но отдавая себе отчет в том, что происходит на каждом шаге.
Человек, много пользующийся SSH, может сделать примерно то же самое, но отдавая себе отчет в том, что происходит на каждом шаге.
UFO just landed and posted this here
А где рассказ о том как грамотно пользоваться ssh-agent'ом под SCREEN'ом — ведь это извечная проблема админов =)
Спасибо, интересная альтернатива стандартному вбиванию пароля.
UFO just landed and posted this here
ssh -A пробрасывет соединение к ssh-agent на удаленную машину. Имея root, к этому сокету можно получить доступ и я допускаю, что над агентом можно будет сильно надругаться (соответствующие эксплоиты были). Т.е. опасным может быть простой логин на взломанный сервер.
И, надеюсь, всем понятно, насколько увлекательными могут быть последствия утери приватного ключа :)
Это все к тому, что у каждого из вышеперечисленных способов ускорить вход есть свои противопоказания и помнить о них тоже нужно.
И, надеюсь, всем понятно, насколько увлекательными могут быть последствия утери приватного ключа :)
Это все к тому, что у каждого из вышеперечисленных способов ускорить вход есть свои противопоказания и помнить о них тоже нужно.
На мой взгляд замечательная серия статей на эту тему:
www.gentoo.org/doc/en/articles/openssh-key-management-p1.xml
www.gentoo.org/doc/en/articles/openssh-key-management-p2.xml
www.gentoo.org/doc/en/articles/openssh-key-management-p3.xml
www.gentoo.org/doc/en/articles/openssh-key-management-p1.xml
www.gentoo.org/doc/en/articles/openssh-key-management-p2.xml
www.gentoo.org/doc/en/articles/openssh-key-management-p3.xml
Ух ты… а что это такое вы с nc изобразили?
Вообще за п.4 большое человеческое спасибо, пошел стругать config.
Вообще за п.4 большое человеческое спасибо, пошел стругать config.
Сегодня заметил, что описанное использование ssh-proxy (nc based) приводит к порождению процессов nc на транзитной машине без их уничтожения по окончании сеанса работы.
Only those users with full accounts are able to leave comments. Log in, please.
SSH для частого использования