Наконец руки дошли, написать HOWTO в http://wiki.internet-tablet.com 
Замечания приветствуются.
Upd: ставил галочку "послать в блог", но в блог не ушло. Чей глюк? А если бы ушло, с каким тэгом?
я вот тоже недавно страдал подобным вопросом - и, мне кажется хорошо написано но сложновато...
переменная DST в приведённом виде будет работать только для компа у которого ip адрес таблетки прописан в hosts ?
я для себя уяснил простой алгоритм :
создать ssh-keygen -t rsa
скопировать
публичный ключ закинуть на сервер, на который собираюсь заходить и cat pubkey.pub >> ~/.ssh/authorized_keys
В debian с пару недель назад были серьёзные обновления пакета openssh... подробностей сейчас не вспомню
Насчёт блога : - так как новички часто отсылали в блог "заметки" типа "Поможите кто чем может - у меня виндовс икспи !!!" - сейчас заметка уходит в блог но зависает до одобрения.
Перечитал и проникся - всё клёво, это я тупил.
Вот только для новичков и для тупящих имхо стоит конкретно обозначить что скрипт выполняется на клиенте - и закидывает открытый ключ на сервер...
То есть "Чтобы заходить на компьютер, на котором запущен сервер ssh" начале
и далее :
"установите права и выполните следующий скрипт на компьютере:"
учитывая остроумные вопросы от новичков последнее время на форуме - думаю стоит обозначить оба варианта :
когда таблетка - сервер ssh
и когда - клиент.
я бы заменил таки "компьютер" на сервер и клиент соответственно.
проблема была в генераторе ключей - все сгенерированные ключи под определенный алгоритм были скомпрометированны - т е очень легко их можно было подобрать (65000 вариантов). Вот ссылка на новость - http://www.opennet.ru/opennews/art.shtml?num=15846 - Интересно а есть ли такая уязвимость на таблетке и исправлена ли она?
Может я и перестраховщик - но неплохо бы к этой статье добавить какую нить часть которая проверяет версию openssl длы debian-based систем - уязвимость то была как раз в ней - типа aptitude show openssl | grep version (не очень я силен в написании скриптов - только учусь :) ) и если версия пакета 0.9.8c-1 то рекомендовать обновить пакет перед тем как ключи генерить. Или проверять их потом эксплойтом отсюда - http://www.securityfocus.com/archive/1/492112 - подбирает за 20 минут.
7) По завершении можете заходить на таблетку командой ssh user@АДРЕС-ИЛИ-ИМЯ
Насчет ИМЯ - его нужно как то разрешать(резолвить) в адрес - я бы оставил в этой инструкции просто АДРЕС - или надо пояснить тогда что в /etc/hosts той машины откуда заходите прописывать строку соответствия имени адресу. Или в днс прописывать - или еще как-нибудь (не претендую на то что знаю все - может есть какой то еще способ)
Согласно этому DSA http://www.debian.org/security/2008/dsa-1571 этому эксплоиту подвержены ключи, сгенеренные openssl начиная с версии 0.9.8c-1. На таблетке этой версии никогда не было, там до сих пор 0.9.7e.
Так что расслабьтесь - ничего делать не нужно.
Это, кстати, один из примеров того, что следование за апстримом ноздря в ноздрю не всегда хорошо :)
ну тогда можно не опасаться если ключи генеряться на таблетке - а если их генерят на ББ тогда стоило бы проверить всеже версию пакета
Ну раз замечания приветствуются...
Третий пункт бредовый. Для начала dsa вообще не испльзуется для шифрования, это алгоритм подписи. Проверка подписи у него быстрее чем у rsa, но это только проверка. По стойкости он даже выше rsa при равной длине ключа.
А теперь насчет видеопотоков. Алгоритмы с открытым ключем используются *только* для выработки сеансового ключа и дальнейшее шифрование использует симметричный алгоритм (aes, blowfish, ...)
Можно явно указать приоритеты алгоритмов с помощью опции -c для open ssh client или в конфиге ~/.ssh/config опцией Ciphers.
Теперь по поводу файла .ssh/known_hosts. Удалять его очень не рекомендуется. Этот файл нужен для предотвращения атак типа Man-In-Middle. Можно его удалять если у вас феноменальная память и вы помните отпечатки ключей всех хостов на которые ходите по ssh ;)
Если изменился ключ удаленного хоста то новые строчки добавляться не будут, а будет предупреждение о изменении ключа удаленной машины и разрыв соединения. В предупреждении будет указано на основании какой строки из known_hosts оно выдано.
Если сильно не нравится хеширование имен и адресов хостов в known_hosts то его можно отключить опцией HashKnownHosts в конфиге .ssh/config
Вроде все что сразу в глаза бросается я прокоментировал :)
Еще поправочка
"При генерации ключа каждый авторизованный хост добавляется в файл ~/.ssh/authorized_keys"
не авторизированный хост, а ключ пользователя.
Насчет сохранения пароля ключа на таблетке. На таблетке есть ssh-agent. Скармливаете ему пароли и он их будет хранить. Так что ssh-agent + ssh-add решают эту проблему.
Wall говорит:
Согласно этому DSA http://www.debian.org/security/2008/dsa-1571
Так что расслабьтесь - ничего делать не нужно.
Это, кстати, один из примеров того, что следование за апстримом ноздря в ноздрю не всегда хорошо :)
Апстрим не имеет отношения к уязвимости со сломанным пулом энтропии в openssl. Это чисто Debian specific sechole. Просто некоторые маинтайнеры когда делают "патч" забывают подумать.
На таблетке этого "патча" обнаружено не было. Так что можно не волноваться.
Для работы с потоковым видео по ssh можно использовать алгоритм сжатия blowfish - он быстрее всего шифрует данны - взято отсюда - http://www.inference.phy.cam.ac.uk/saw2 … tions.html
Используется следующим образом
Код:
ssh -c blowfish user@hostname
тов. mrkooll прав - dsa алгоритм подписи а не шифрования - алгоритм шифрования мы выбираем (можем выбирать) при установке соединения
mrkooll говорит:
Апстрим не имеет отношения к уязвимости со сломанным пулом энтропии в openssl. Это чисто Debian specific sechole.
Я, собственно, и имел в виду Debian. Не openssl же является апстримом для Maemo.
alex2ndr говорит:
Для работы с потоковым видео по ssh можно использовать алгоритм сжатия blowfish - он быстрее всего шифрует данны - взято отсюда - http://www.inference.phy.cam.ac.uk/saw2 … tions.html
blowfish - алгоритм шифрования, а не сжатия (я занудный тип :)
А алгоритм сжатия используется gzip. Можно вообще сжатие выключить. Можно покрутить уровень сжатия. По моим прикидкам установка уровня сжатия в 1 будет более эффективна чем замена алгоритма шифрования. Но надо протестировать.
По скорости алгоритмов шифрования - это зависит от типа CPU. Можно не гадать, а точно проверить запустив openssl speed на таблетке. Blowfish на таблетке действительно быстрее
Код:
The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes md2 150.50k 339.98k 496.61k 555.79k 583.16k mdc2 0.00 0.00 0.00 0.00 0.00 md4 976.40k 3534.92k 10682.98k 21593.60k 30960.21k md5 770.84k 2764.50k 8278.34k 16665.77k 23682.83k hmac(md5) 1499.51k 4911.34k 12378.72k 19955.24k 24266.71k sha1 740.37k 2136.06k 4690.45k 6684.18k 7609.21k rmd160 679.73k 1968.68k 4356.90k 6223.11k 7076.90k rc4 8954.52k 9852.29k 10182.85k 10206.67k 10212.51k des cbc 1459.31k 1526.98k 1547.77k 1553.81k 1549.54k des ede3 531.89k 535.56k 540.25k 541.11k 539.13k idea cbc 0.00 0.00 0.00 0.00 0.00 rc2 cbc 2025.22k 2107.30k 2141.04k 2140.40k 2146.96k rc5-32/12 cbc 0.00 0.00 0.00 0.00 0.00 blowfish cbc 3640.45k 3999.29k 4083.54k 4090.38k 4142.73k cast cbc 2825.48k 3106.86k 3219.03k 3208.53k 3219.26k aes-128 cbc 2687.99k 2758.59k 2756.67k 2762.39k 2762.74k aes-192 cbc 2332.77k 2391.77k 2392.19k 2411.40k 2400.06k aes-256 cbc 2070.05k 2102.21k 2110.23k 2113.98k 2111.23k
А вот насчет RSA и DSA я ошибся. Наоборот оно. У DSA быстрее подпись и медленнее проверка. А вообще по совокупности на таблетке RSA быстрее
Код:
sign verify sign/s verify/s
rsa 512 bits 0.0173s 0.0017s 57.7 603.0
rsa 1024 bits 0.0990s 0.0054s 10.1 184.2
rsa 2048 bits 0.6431s 0.0191s 1.6 52.4
rsa 4096 bits 4.4433s 0.0700s 0.2 14.3
sign verify sign/s verify/s
dsa 512 bits 0.0158s 0.0190s 63.3 52.5
dsa 1024 bits 0.0524s 0.0635s 19.1 15.7
dsa 2048 bits 0.1846s 0.2252s 5.4 4.4mrkooll говорит:
Ну раз замечания приветствуются...
Третий пункт бредовый. Для начала dsa вообще не испльзуется для шифрования, это алгоритм подписи. Проверка подписи у него быстрее чем у rsa, но это только проверка. По стойкости он даже выше rsa при равной длине ключа.
Я знаю. Просто пытался сказать более простым языком для самых простодушных юзеров.
Насчёт слабого и сильного шифрования я погорячился, но написал же "шифрование с ключом RSA" а не "шифрование по алгоритму RSA" :)
Своё HOWTO я исправляю, спасибо всем за замечания. Вообще это детали, а суть (команды) верна. Главное, что я попытался донести - проблемы с неверными правами уже имеющихся директорий и файлов, из-за которых не получалось входить без пароля. Это то, на что я напоролся, и долго бился. Другое, чего я добивался - дать конкретные рабочие и проверенные лично команды, а не просто набор подсказок (и надежда, что юзер делает это на чистой машине, впервые), чем грешат многие HOWTO.
Кроме того, к сожалению, спецы не пишут HOWTO, приходится нам самим...
mrkooll говорит:
Насчет сохранения пароля ключа на таблетке. На таблетке есть ssh-agent. Скармливаете ему пароли и он их будет хранить. Так что ssh-agent + ssh-add решают эту проблему.
Опять же, за непонятной юзеру фразой о скармливании паролей ssh-agent стоят конкретные команды, которые и должны быть в HOWTO. Так что лезу в описания...
Исправления внёс, кроме ssh-agent. Это сделаю сегодня-завтра.
Я постарался сделать текст более понятным для новичков. Убрал излишек ненужных деталей, новичкам они ни к чему и только отпугивают. ssh-keygen сразу ставит на файлы нужные права, поэтому команды с правами убрал. ssh-copy-id при необходимости создаёт на удалённом хосте каталог ~/.ssh/ с правильными правами доступа, так что команды для его создания тоже убрал.
Надеюсь, что всем понравится. Если нет - откатите назад. Добавил аналогичную инфу для виндозников, бо такие тоже попадаются (всё ещё, к сожалению ;-))
А куда пропал собственно сам скрипт ? Имхо стоит параллельно разместить вашу и Dali статьи
http://wiki.internet-tablet.com/index.p … 9_from_Zap
http://wiki.internet-tablet.com/index.p … 0%B5%D0%B9
zap говорит:
Я постарался сделать текст более понятным для новичков. Убрал излишек ненужных деталей, новичкам они ни к чему и только отпугивают. ssh-keygen сразу ставит на файлы нужные права, поэтому команды с правами убрал. ssh-copy-id при необходимости создаёт на удалённом хосте каталог ~/.ssh/ с правильными правами доступа, так что команды для его создания тоже убрал.
Нехорошо-с
Вы же выхолостили весь мой HOWTO. Похоже, невнимательно прочитали его, да и в сообщении #16 я писал, что на некоторых уже существующих директориях и файлах неправильные права сохраняются. Так было у меня, и я долго разбирался, почему пароль всё равно спрашивается, хоть и делал всё как пишут. Именно для этого и нужны команды для установки прав. "Ненужные детали" - это комментарии для тех, кто хочет знать, но не хочет лезть в доки (т.е. почти для всех), либо у кого что-то не получилось. Всё, что нужно сделать юзеру по-моему - запустить скрипты. Они будут лежать на компьютере и таблетке, и ещё не раз понадобятся. Не придётся вспоминать команды для генерации, для дистрибуции, не забывать проконтролировать права нескольких директорий и нескольких файлов, ломать потом голову, почему пароль всё равно спрашивается, и т.д. Фактически Вы до предела упростили команды (чем привели HOWTO к множеству похожих, объясняющих только самые основы ssh для дальнейшего самостоятельного изучения), переложив всю работу на юзера.
У меня такое предложение - переделайте Ваш HOWTO с двумя частями. Первую назовите типа "упрощенное руководство для Линукса", второе и основное - "руководство для Windows" (ибо я не планирую покрывать этот вопрос).
Свою статью я вернул в первоначальный вид, с поправками, и принимаю любые конструктивные замечания, к пинкам тоже отношусь спокойно.
PS: в Вашей версии HOWTO фраза "При написании этой статьи не пострадал ни один HOWTO" уже неуместна.
Dali : я вернул твою статью к твоей последней редакции, а вариант от Zap разместил отдельной статьёй.
Думается что если правки небольщие и касаются уточнейний/ исправления ошибок - стоит править оригинал. В случае кардинальной переделки - лучше уж писать своё отдельно. имхо.
Каждый из подходов может подойти кому то в большей или меньшей степени. Ибо все мы люди разные.
dik говорит:
Dali : я вернул твою статью к твоей последней редакции, а вариант от Zap разместил отдельной статьёй.
Вернул с упущениями, так что я довернул до конца.
Думается что если правки небольщие и касаются уточнейний/ исправления ошибок - стоит править оригинал. В случае кардинальной переделки - лучше уж писать своё отдельно. имхо.
Каждый из подходов может подойти кому то в большей или меньшей степени. Ибо все мы люди разные.
Именно так. Это стандарт в open source. И даже кардинальные переделки может произвести автор, пока он поддерживает своё поделие, и если он соглашается с предложениями.
Прошу прощения, если наступил кому-то на хвост :) Просто wiki на то и есть вики, чтобы в нём не терялось ничего. Я предложил свой улучшенный вариант, Вам не понравилось, форкнулись :)
А скрипты имхо не нужны. Зачем нужен скрипт, в котором всего одна команда. Для новичков надо имхо проще, а опытным вики ни к чему, сами мануал почитают и разберутся.
ssh-copy-id установит права сам как полагается, я проверял.
Улыбнула фраза:
"Команда ssh-keygen спросит пароль для защиты создаваемого ключа (а не для логина). Крайне не рекомендуется оставлять его пустым, иначе кто-нибудь может просто скопировать ключ, имея физический доступ к компьютеру. Вводите пароль не менее 16 символов, включая пробелы, цифры, знаки, прописные и строчные буквы."
А статья называется "Как заходить по ssh без паролей", а тут такие ужасы - 16 символов, включая пробелы, цифры и ё-моё :). Ну и где логика? :)
P.S. Для алгоритма DES, который используется для защиты ключей достаточно длины 6 символов, 16 это перебор. Но вообще учитывая небольшую ценность данных на планшете, а также то, что к домашнему компьютеру обычно доступ весьма ограничен, можно не париться и жить без пароля, таким образом оправдав название статьи :)
Закончена в целом работа над HOWTO. Замечания всегда приветствуются.
zap говорит:
А скрипты имхо не нужны.
См. пост 19
Зачем нужен скрипт, в котором всего одна команда.
Это не про мой скрипт. У меня 4 + 3. Да ещё с опциями, нужными, чтобы не нажимать enter на кучу вопросов, меньше вводить руками, видеть меньше побочных сообщений, и.т.д
Для новичков надо имхо проще, а опытным вики ни к чему, сами мануал почитают и разберутся.
Повторю, что именно для новичков проще запустить скрипт, чем выполнить кучу действий руками и на компе, и на теблетке. Попутно уточняя права и т.д.
Я был новичком перед написанием этой статьи. Наткнулся на проблему (с правами, как оказалось), не помогли простые вики, которых во множестве. Копаться глубоко в доках было лениво. По проблеме сохранения пароля, большинство вики по таблеткам советует не задавать пароль, более сложные howto, где пишется "используйте ssh-agent и ssh-add", не решали проблему для таблетки (как конкретно?)
Только моя героическая ответственность и неисправимый перфекционизьм, проявленные при написании сего, заставили углубится в доки.
ssh-copy-id установит права сам как полагается, я проверял.
И я проверял. В любом случае, скрипты пишутся, чтобы работать в общем случае, а не только в Вашем частном, где всё ОК, где ранее Вас не угораздило, как меня, изменить права в директории ~.
Улыбнула фраза:
"Команда ssh-keygen спросит пароль для защиты создаваемого ключа (а не для логина). Крайне не рекомендуется оставлять его пустым, иначе кто-нибудь может просто скопировать ключ, имея физический доступ к компьютеру. Вводите пароль не менее 16 символов, включая пробелы, цифры, знаки, прописные и строчные буквы."
А статья называется "Как заходить по ssh без паролей", а тут такие ужасы - 16 символов, включая пробелы, цифры и ё-моё :). Ну и где логика? :)
"для защиты создаваемого ключа (а не для логина)"
Этот пароль на компьютере придётся ввести единожды с сохранением (путём нажатия галочки СОХРАНИТЬ в окне запроса пароля), или один раз за сессию (до перезагрузки) в худшем случае, если такой галочки нет, или это таблетка.
Ваши слова - это Ваше ИМХО, а в вики стоит придерживаться рекомендаций из фирменной документации (которую писали спецы по безопасности, не чета нам), что я и делаю.
В любом случае, уровень принятой безопасности каждый выбирает для себя сам. Если уверен, что с твоего компа невозможно скопировать ключи, и что нет дружков, готовящихся к 1 апреля, не ставь пароль. Но если он сохраняется, почему не поставить?
P.S. Для алгоритма DES, который используется для защиты ключей достаточно длины 6 символов, 16 это перебор. Но вообще учитывая небольшую ценность данных на планшете, а также то, что к домашнему компьютеру обычно доступ весьма ограничен, можно не париться и жить без пароля, таким образом оправдав название статьи :)
DES или DSA/RSA?
16 символов - это рекомендация из доки. Вы, как говорится, вольны...
Насчёт ценности можно согласиться в большинстве случаев, но имеется известная проблема, что на мобильных устройствах многие хранят закрытую корпоративную информацию в открытом виде.
ssh это не игрушка, это вопрос безопасности. Безопасность зависит от самого слабого звена. Из-за незапароленного ключа вся защита бессмысленна. Конечно, если ssh применяется только как консоль для подключения к таблетке в пределах локалки, тогда можно не париться. Но я не сужаю задачу.
Разрешите вмешаться в разговор благородных донов? 8-)
Dali говорит:
Но если он сохраняется, почему не поставить?
Я на первой своей таблетке (украденной в метро) насохранял паролей (ничего особенного - от форумов, личного кабинета на сайте провайдера). Это мне вылилось в часовую эпопею по смене всех паролей и попутно в разборки с техподдержкой. А Вы говорите пароль от ключей сохранять...
Не одно и то же.
Сохранение паролей в браузере таблетки - это упрощение жизни за счёт ослабления безопасности. Альтернатива одна - вводить каждый раз пароль.
Сохранение пароля от ключа - тоже упрощение и ослабление, но альтернативы две - вводить каждый раз, или отказаться от пароля вообще. Вы это предлагаете как более надёжный вариант?!!
Dali говорит:
Вы это предлагаете как более надёжный вариант?!!
Вынужден извиниться еще раз. Видимо надо изъясняться еще проще... 8-)) Я просто считаю, что сохранение пароля - дыра в безопасности, если она (безопасность) конечно волнует пользователя [b]ssh[/].