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.
Не буду спорить. DSA в случае с ssh-keygen хорош тем, что менее 2048 бит не задашь, кажется. А вот в PuTTY у нас некоторые нагенерили экстремально короткие RSA-ключи, по рассказам, раньше дефолтом было 2048, но теперь — 256 или около того.
Как это, разрешённая длина ключа? Она как-то ограничена законодательно???
$ ssh-keygen -t dsa -b 768
DSA keys must be 1024 bitsчто-то не то с разбивкой на строки
$ ssh-keygen -t dsa -b 768DSA keys must be 1024 bits
Я совсем рестерялся… Она для разных стран разная? Как это связано с ФСБ?
>Если ты разработчик системы использующую криптозащиту — тебе надо ещё сертификат разработчика получить
Да, это я знаю… там не совсем так, вроде бы, — если ты разрабатываешь систему, которая будет использоваться в структурах, связаных с гостайной. И с банками какие-то напряги ещё, но, скорее всего, чисто банковские. Разве нет? Прочие системы хоть заразрабатывайся :)
>сертификат на разрабатываемую систему!
Ну, здесь-то речь шла о ssh. Она уже есть.
>Вот здесь условия и появляются…
Точно? Вы говорите так, как будто вы в курсе — они там действительно ограничивают длину ключа сверху? Не верю!
>Опять же если вспомнить об американских запретах на экспорт криптосистем с длинной ключей превышающих определённую длину
Ну, это американские экспортные ограничения. Тем более, уже отменённые. Их вообще много было разных. К ФСБ отношения не имеют. Тем более, что лицензированием криптоделов всяких занимается у нас не ФСБ.
Да, это я знаю… там не совсем так, вроде бы, — если ты разрабатываешь систему, которая будет использоваться в структурах, связаных с гостайной. И с банками какие-то напряги ещё, но, скорее всего, чисто банковские. Разве нет? Прочие системы хоть заразрабатывайся :)
>сертификат на разрабатываемую систему!
Ну, здесь-то речь шла о ssh. Она уже есть.
>Вот здесь условия и появляются…
Точно? Вы говорите так, как будто вы в курсе — они там действительно ограничивают длину ключа сверху? Не верю!
>Опять же если вспомнить об американских запретах на экспорт криптосистем с длинной ключей превышающих определённую длину
Ну, это американские экспортные ограничения. Тем более, уже отменённые. Их вообще много было разных. К ФСБ отношения не имеют. Тем более, что лицензированием криптоделов всяких занимается у нас не ФСБ.
>Да, тебе не разрешено пользоваться 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.
А чем так плох вариант, с набором пароля каждый раз?
Он так же плох как и использование ключей. В первом случае это keylogger'ы или запись на видео, во втором — кража ключа, неважно, вместе с устройством или с устройства.
О_о ключ можно взять и передвинуть на десяток машин, подсмотреть 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 для частого использования