thebeetlebum 06.02.2012 19:45
Переводы — 20 наилучших способов обеспечения безопасности OpenSSH
Не на каждом сервере есть ftp, samba или какая-либо другая программа, предоставляющая удаленные возможности, однако, на большинстве UNIX хостов мы встретим OpenSSH. OpenSSH предоставляет нам широкие возможности, однако, любые излишние возможности могут дать несколько дверей взломщику. Я же хочу показать как прикрыть некоторые из них, чтобы ваши UNIX хосты были защищены по протоколу SSH. Эта переведенная статья 2009го года, однако даже сегодня она актуальна в полной мере.OpenSSH это реализация протокола SSH. OpenSSH используется для удаленного входа, создания бекапов, удаленного файлового трансфера через scp или sftp и многое другое. SSH идеально подходит для того, чтобы сохранить конфиденциальность и целостность данных, передаваемых между двумя сетями или системами. Однако, основным преимуществом является сервер аутентификации, который может работать с помощью публичных ключей. Время от времени появляются новости о 0-day exploit для OpenSSH. Здесь же изложены несколько методов, которые позволят вам повысить безопасность OpenSSH сервера, не смотря на такие новости.
Стандартные файлы настроек и порт SSH
- /etc/ssh/sshd_config - конфигурационный файл сервера OpenSSH
- /etc/ssh/ssh_config - конфигурационный файл клиента OpenSSH
- ~/.ssh/ - пользовательские конфигурационные директории
- ~/.ssh/authorized_keys и ~/.ssh/authorized_keys2 - списки публичных ключей (RSA или DSA), которые могут быть использованы для авторизации в пользовательский аккаунт
- /etc/nologin - если этот файл существует, то система будет отказываться пускать кого-либо кроме root-пользователя. Лучше удалить и не использовать.
- /etc/hosts.allow и /etc/hosts.deny - списки контроля доступа (ACL)
- SSH стандартный порт : TCP 22
#1: Отключите OpenSSH сервер
Рабочие станции и ноутбуки могут работать без OpenSSH сервера. Если вам не нужна удаленная авторизация или возможности файлового трансфера, отключите или удалите SSH сервер. Закройте лишнюю дверь, если вы её не используете. CentOS / RHEL / Fedora Linux - пользователи могут отключить или удалить openssh-server с помощью этих комманд:
1 |
|
Debian / Ubuntu Linux пользователи могут отключить и удалить с помощью утилиты apt-get:
1 |
|
Так же вам вероятно потребуется обновить настройки вашего firewall'а (iptables), чтобы удалить правила для ssh. Для CentOS / RHEL / Fedora редактируйте файлы /etc/sysconfig/iptables и /etc/sysconfig/ip6tables. После окончания перезапустите iptables:
1 |
|
Для пользователей Debian / Ubuntu это, как правило, один файл — /etc/init.d/iptables. После редактирования которого смело перезапускаем firewall.
1 |
|
#2: Используйте только второй протокол SSH
SSH протокол первой версии (SSH-1) подвержен проблемам и уязвимостям безопасности с помощью атак вида man-in-the-middle. SSH-1 полностью устарел и его не стоит использовать. Откройте файл sshd_config и проверьте, что подобная строка имеет место:
1 |
|
#3: Ограничьте пользователям SSH доступ
Изначально все пользователи системы могут входить через SSH используя свои пароли или публичные ключи. Порой вы создаете UNIX / Linux пользователей для ftp или email. Однако, такие пользователи тоже могут зайти в систему через ssh. Они будут иметь полный доступ к системным инструментам, включая компиляторы и скриптовые языки, такие как Perl, Python, которые могут открыть сетевые порты и удовлетворить множество других капризов. Один из моих клиентов имел устаревший php-скрипт и атакующий воспользовался возможностью и создал новый аккаунт в системе через этот php-скрипт. И тем не менее, атакующий не смог проникнуть через ssh, потому что его пользователь не был указан в директиве AllowUsers. Доступ к системе через SSH имели только пользователи root, vivek и jerry и это было указано в файле sshd_config:
1 |
|
В качестве альтернативы, вы можете разрешить доступ всем пользователям через SSH, но ограничить лишь нескольким с помощью следующей строки:
1 |
|
Вы также можете настроить Linux PAM, разрешающий или запрещающий авторизацию через sshd-сервер. Вы можете создать список имен групп для авторизации или же запрета авторизации через данный протокол.
#4: Настройте время ожидания при простое для выхода
Пользователь может зайти на сервер через ssh и если вы настроите таймаут простоя, то сможете избежать необслуживаемой ssh сессии. Откройте sshd_config и проверьте следующие значения определены:
1 |
|
Здесь выставлено время ожидания(простоя) в секундах (300 с = 5 мин.). Когда это время пройдет, простаивающая сессия пользователя будет закрыта, и пользователь автоматически выйдет из системы.
#5: Отключите .rhosts файлы
OpenSSH сервер может использовать протокол Rlogin для авторизации, и подобное стоит пресекать. Отключите чтение пользовательских файлов ~/.rhosts и ~/.shosts. Обновите sshd_config со следующими настройками:
1 |
|
SSH может имитировать поведение устаревшей комманды rsh, просто отключите небезопасный доступ через RSH.
#6: Отключите аутентификацию на основе хоста.
Для отключения подобной аутентификации, обновите sshd_config со следующей опцией:
1 |
|
#7: Отключите доступ root через SSH
Это означает что доступ пользователя root через ssh поверх сети не нужен. Обычные пользователи могут использовать утилиты su или sudo(предпочтительней) чтобы повысить права до уровня root. Это позволяет быть уверенным в получении информации о том, кто запускал привилегированные команды на системе через sudo. Для отключения входа root пользователя через SSH обновите sshd_config со след. строкой:
1 |
|
#8: Включите предупреждающий баннер
Установка предупреждающего баннера сводится к редактированию следующей строки и создания соотв. файла:
Banner /etc/issue
Пример файла /etc/issue:
----------------------------------------------------------------------------------------------
You are accessing a XYZ Government (XYZG) Information System (IS) that is provided for authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
+ The XYZG routinely intercepts and monitors communications on this IS for purposes including, but not limited to,
penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM),
law enforcement (LE), and counterintelligence (CI) investigations.
+ At any time, the XYZG may inspect and seize data stored on this IS.
+ Communications using, or data stored on, this IS are not private, are subject to routine monitoring,
interception, and search, and may be disclosed or used for any XYZG authorized purpose.
+ This IS includes security measures (e.g., authentication and access controls) to protect XYZG interests--not
for your personal benefit or privacy.
+ Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching
or monitoring of the content of privileged communications, or work product, related to personal representation
or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work
product are private and confidential. See User Agreement for details.
----------------------------------------------------------------------------------------------
You are accessing a XYZ Government (XYZG) Information System (IS) that is provided for authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
+ The XYZG routinely intercepts and monitors communications on this IS for purposes including, but not limited to,
penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM),
law enforcement (LE), and counterintelligence (CI) investigations.
+ At any time, the XYZG may inspect and seize data stored on this IS.
+ Communications using, or data stored on, this IS are not private, are subject to routine monitoring,
interception, and search, and may be disclosed or used for any XYZG authorized purpose.
+ This IS includes security measures (e.g., authentication and access controls) to protect XYZG interests--not
for your personal benefit or privacy.
+ Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching
or monitoring of the content of privileged communications, or work product, related to personal representation
or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work
product are private and confidential. See User Agreement for details.
----------------------------------------------------------------------------------------------
Выше представлен стандартный образец, проконсультируйтесь с юридическим отделом для более точного приветствия.
#8: Настройте firewall на порту ssh(22)
Вы должны настроить firewall для ssh порта(22) обновив конфигурации iptables или же pf firewall. Обычно, сервер OpenSSH должен принимать только входящие соединения вашей сети или другой удаленной сети.
Настройка iptables
Измените ваш /etc/sysconfig/iptables (для пользователей Redhat) для подтверждения соединений только с сетями 192.168.1.0/24 и 202.54.1.5/29:
1 |
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 22 -j ACCEPT
|
Если вы используете IPv6, не забудьте отредактировать /etc/sysconfig/ip6tables (для пользователей Redhat):
1 |
|
Заменив ipv6network::/ipv6mask вашим IPv6 диапазоном.
В случае других дистрибутивов, таких как Debian, ничего принципиально не меняется. Нужно также добавить подобные правила в INPUT цепочку.
Настройка *BSD PF Firewall
Если вы используете PF firewall настройте /etc/pf.conf следующим образом:
1 |
pass in on $ext_if inet proto tcp from {192.168.1.0/24, 202.54.1.5/29} to $ssh_server_ip port ssh flags S/SA synproxy state
|
#9: Измените порт SSH и ограничьте используемый IP
Первоначально SSH слушает все доступные интерфейсы и IP адреса доступных на системе и ограничение прослушивания порта и смена самого порта может повысить безопасность (Обычно bruteforce скрипты пытаются соединиться только на порту #22). Для того чтобы привязать OpenSSH слушать только ip 192.168.1.5 и 202.54.1.5 на порту #300, просто подправьте вашу конфигурацию:
1 |
|
#10: Используйте сильные пароли и ключи
Невозможно оценить насколько важно использовать сильные пароли и ключи. Brute-Force атака работает если вы используете пароли, которые основываются на данных из словарей. Есть также специальные расширенные "словари", которые могут содержать наиболее популярные пароли. Они называются rainbow tables. Вы можете заставить пользователей избегать пароли подверженные подобным атакам и выявлять слабые пароли с помощью утилиты John the Ripper. Вот пример генератора случайных паролей, написанных на баше (положите его в ваш ~/.bashrc):
1 |
genpasswd() {
|
Если вы совсем параноик, то вместо /dev/urandom используйте /dev/random
Запустите в консоли:
1 |
|
#11: Используйте публичные ключи для аутентификации
Используйте пару ключей публичный/приватный с парольной защитой для приватного ключа. Посмотрите как использовать аутентификацию основанную на RSA и DSA и никогда не используйте пустой ключ (без passphrase) для логина.
#12: Используйте Keychain для аутентификации
Keychain это специальный bash-скрипт созданный для удобства и гибкости использования аутентификации на ключах. Он может дать некоторые фишки безопасности даже на ключи без passphrase. Узнайте как установить и использовать keychain утилиты.
#13: Ограничьте SSHD с помощью chroot (Заприте пользователей в их домашних директориях)
По умолчанию пользователям разрешено гулять по директориям сервера, даже таким как /etc, /bin/ и другим. Вы можете защитить ssh используя chroot или специальные утилиты вроде rssh. Но с выходом OpenSSH версий 4.8p1 или 4.9p1 вам больше не нужно надеяться на такие сторонние решения. Посмотрите в этот пост чтобы узнать о новой директиве ChrootDirectory блокирующей пользователей в их собственных домашних директориях.
#14: Используйте TCP Wrapper'ы
TCP Wrapper это сетевая ACL система (использующая списки контроля доступа), основанная на хостах, используемая для фильтрации доступа в сеть и OpenSSH поддерживает TCP wrapper'ы. Просто обновите ваш /etc/hosts.allow для разрешения SSH только с адресов 192.168.1.2 172.16.23.12 :
1 |
|
Просмотрите этот FAQ о настройке и использованию TCP wrapper'ов под Linux / Mac OS X и другими UNIX-подобными операционными системами.
#15: Запретите пустые пароли
Вы должны явно запретить удаленный логин для аккаунтов с пустыми паролями, обновив sshd_config следующей строкой:
1 |
|
#16: Препятствуйте SSH взломщикам (Brute Force Attack)
Brute force это способ положить крипто-систему на лопатки используя большое количество возможностей одиночных систем или распределенных компьютерных сетей. Для препятствия таким атакам на SSH просто используйте следующие программные решения:
- DenyHosts утилита для безопасности SSH серверов, написанная на Python. Она предназначена для предотвращения BF-аттак анализируя неудачные попытки аутентификации из лога и последующей блокировки ip адресов, с которых и производилась попытка входа.
- Fail2ban программа работающая аналогичным образом, и также написанная на Python. Имеет большую популярность, так как защищает от BF-аттак не только SSH-сервер, но и другое ПО.
- security/sshguard-pf защищает от BF атак как ssh так и другие сервисы, используя pf firewall
- security/sshguard-ipfw защищает от BF атак как ssh так и другие сервисы, используя ipfw firewall
- security/sshguard-ipfilter защищает от BF атак как ssh так и другие сервисы, используя ipfilter firewall
- security/sshblock блокирует abusive попытки ssh входа/
- security/sshit проверяет SSH/FTP на BF-атаки и блокирует полученные IP.
- BlockHosts утилита автоматической блокировки abusive IP
- Blacklist тоже самое что и BlockHosts
- Brute Force Detection Модульный shell-скрипт для парсинга логов приложения и проверки на неудачные попытки аутентификации. Стоит использоваться на системах, где логи приложений имеют свой уникальный формат, и под каждый лог нужены свои уникальные регулярные выражения.
- IPQ BDB filter Может рассматриваться как легкая версия fail2ban.
#17: Входящие ограничения соединений порта #22
Оба firewall'а, и netfilter и pf, позволяют устанавливать простые регулирующие опции на входящие соединения #22 порта.
Пример с использованием iptables
Следующий пример режет все входящие соединения, у которых было более 5 попыток на #22 порт за 60 секунд:
Другой пример с iptables:
Для больших деталей смотрите man iptables.
Пример с использованием *BSD PF
Следующие ограничения представляют из себя всего 20 максимальных соединений от источника за все время или 15 попыток за 5 секундный интервал. Если кто-то нарушает наши правила, то он попадает в нашу таблицу abusive_ips и блокируется на дальнейшие соединения. И в окончание стоит упомянуть о flush. Он просто обнуляет заполненные таблицы, если нам это потребуется.
#18: Используйте Port Knocking
Одним из первых способов защиты была показана смена порта на нестандартный. Однако, простым nmap можно его найти, и начать BF-атаку. Но что, если закрывать сначала все порты, и лишь при определенных обстоятельствах открывать порт ssh. И какие же можно использовать обстоятельства? Можно использовать попытки соединений по какому-то определенному набору, или последовательности портов. И лишь после таких действий открывать порт для ssh, и разрешать соединение с клиентом, потому что он знает в какие двери нужно было постучать(knocking). Для такой техники нам ничего не потребуется кроме вашего firewall'а:
Сначала мы стучимся в порт #1234, потом в #3456, затем в #2345 и входим по #22 порту, который открылся.
#19: Используйте анализаторы логов
Читайте ваши логи используя logwatch или logcheck. Эти утилиты могут упростить вам жизнь. Они будут проходить по логом по данным интервалам времени и сообщать об участках и деталях, которые вы хотите видеть. И удостоверьтесь что директива LogLevel имеет значение INFO или DEBUG в sshd_config:
1 |
|
#20: Обновляйте OpenSSH и операционные системы
Это лучше всего делать через такие инструменты как yum, apt-get, freebsd-update или другие для использования последних security-патчей.
Иные способы
Чтобы скрыть версию openssh, вы должны обновить исходный код и заново скомпилировать openssh. Проверьте что такие опции включены:
Проверяйте файл настроек перед перезапуском sshd:
1 |
|
Есть и другие техники, но о них стоит поговорить в отдельности:)
Оригинальная статья: http://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.html
Мой перевод: http://michael.nomanlab.org/?p=25
UPD# В статье обнаружилось 2 пункта #8. Не думаю что стоит менять нумерацию, потому что тогда заглавие не будет соответствовать действительности количества способов. В оригинале допущена та же ошибка с двумя пунктами #8.
UPD2# Обнаружилось что подобная статья уже была переведена на русский язык до меня. Можете ознакомиться с другим переводом на http://rus-linux.net/nlib.php?name=/MyLDP/sec/openssh.html. На некоторых пунктах перевод серьезно отличается, но лучше ознакомьтесь с оригиналом. К слову, здесь тоже допущена та же ошибка с двумя пунктами #8.

+ 0 -
Привет параноикам!
Это стандартные методы, и они совсем не параноидальные) Если вы используете ssh на продакшане, то стоит использовать там хотя бы такие методы. Есть еще хоней споты, но вот это точно на любителя)
Кстати, я бы некоторые советы назвал здесь "вредными", но это все же перевод) Да и помню как меня тут на лялихе минусовали за мою критику fail2ban)
Кстати, я бы некоторые советы назвал здесь "вредными", но это все же перевод) Да и помню как меня тут на лялихе минусовали за мою критику fail2ban)
Вообщем, пусть меня снова заминусуют, но я все же скажу это снова. Здесь представлены 20 методов. На деле же, какой-то из них более эффективен, какой-то менее. Так вот пару слов про fail2ban и метод #17 из этой статьи. Дело в том, что fail2ban это довольно удобно с точки зрения пользования. Набрал команду apt-get и забыл. Его можно даже натравить читать логи не только ssh, но и других сервисов вроде ftp и отрезать возможность BF-атак на другие протоколы. Однако, стоит упомянуть, что он написан на питоне, и он читает логи с диска. А диск зачастую самое медленное место в системе. Если же говорить про firewall, то все происходит без участия диска, и на деле намного быстрее и надежнее=)
На фоне недавно обнаруженной уязвиомсти, когда имея локального юзера в системе можно получить права root в три команды, эти меры не выглядят столь параноидально!
Я не большой адепт iptables, но могу сказать, что до этой статьи мне в голову даже не приходили подобные инсинуации с фаерволом =)
Один из моих клиентов имел устаревший php-скрипт и атакующий воспользовался возможностью и создал новый аккаунт в системе через этот php-скрипт.
После этой цитаты сперва даже хотел бросить читать. Странно слышать советы по настройке ssh от человека, который держит web-сервер с рутовыми правами и/или не следит за такими критичными апдейтами, как повышение привилегий. Но всё же дочитал, и поэтому возникло пару замечаний(не переводчику, а читателям, так сказать к сведению).
#4: Настройте время ожидания при простое для выхода
- не понятна логика этого пункта. Раньше на некоторых системах это было включено по умолчанию, так наоборот приходилось отключать - неудобно же. Может быть открыто несколько сессий к разным серверам и 5 минут это не время. А я вообще сутками коннекты могу держать, пока работаю иногда. Неудобство эта опция доставит. Защиту - нет.
#8: Включите предупреждающий баннер
Бессмысленно, имхо.
Кстати, почему два восьмых пункта? :)
#11: Используйте публичные ключи для аутентификации
Вот тут стоит посоветовать настроить для каждого сервера свой ключ.
#12: Используйте Keychain для аутентификации
Не совсем понял смысла этого скрипта из описания в интернетах.
#13: Ограничьте SSHD с помощью chroot (Заприте пользователей в их домашних директориях)
Это да. В своё время мне этой возможности очень не хватало и приходилось городить костыли. Вот только подобная схема не всегда полезна.
#18: Используйте Port Knocking
Имхо, очень гемморно и необходимо только в случае тяжёлой стадии паранойи. :)
/etc/nologin - если этот файл существует, то sshd будет отказываться пускать кого-либо кроме root-пользователя.
Если этот файл существует, то система откажется пускать всех кроме рута. Т.е. и локальный логин, и любой другой логин не будет работать. Я бы не советовал такие вещи на серверах пробовать. Особенно если предварительно отключить логин по ssh для root на удалённом сервере. Будет радостно, ага.
Остальные советы в принципе стандартны и присоединяюсь к рекомендации их использовать. На боевых серверах большинство их них нужны. Только вот сперва стоит внимательно почитать маны, потому что, судя по всему, и сам автор статьи читал их лишь поверхностно и всех тонкостей не понимает. С таким подходом в настройке столь критичных сервисов как ssh ничего хорошего не выйдет. Но для общего ознакомления - отлично подойдёт.
#4: Настройте время ожидания при простое для выхода
- не понятна логика этого пункта. Раньше на некоторых системах это было включено по умолчанию, так наоборот приходилось отключать - неудобно же. Может быть открыто несколько сессий к разным серверам и 5 минут это не время. А я вообще сутками коннекты могу держать, пока работаю иногда. Неудобство эта опция доставит. Защиту - нет.
- не понятна логика этого пункта. Раньше на некоторых системах это было включено по умолчанию, так наоборот приходилось отключать - неудобно же. Может быть открыто несколько сессий к разным серверам и 5 минут это не время. А я вообще сутками коннекты могу держать, пока работаю иногда. Неудобство эта опция доставит. Защиту - нет.
Ну скажем так, такая политика актуальна если людей, у которых есть аккаунт на сервере относительно много. Когда вы выходите из своего рабочего места, вы лочите систему каким-то хоткеем. Здесь примерно также. Порой я не могу быть уверенным что все over 30+ людей будут отключать сессию и лочить свой экран. Кто-то может через их машины и профили натворить делов. Хотя по большей части абсолютно согласен. Эффективность подобного метода не очень высока, а неудобства может доставить. Сам ставлю большой timeout, чтобы мог отойти выпить кофе, или сделать что-то еще.
#8: Включите предупреждающий баннер
Бессмысленно, имхо.
Кстати, почему два восьмых пункта? :)
Бессмысленно, имхо.
Кстати, почему два восьмых пункта? :)
Ну порой даже взгляд человека может отпугнуть от каких-то действий. Но да, это скорее психологическая защита, она не столь эффективна сколько остальные. Просто она была в оригинале, и я не мог её пропустить. Про восьмой пункт — мой косяк, сейчас исправлю.
#11: Используйте публичные ключи для аутентификации
Вот тут стоит посоветовать настроить для каждого сервера свой ключ.
Вот тут стоит посоветовать настроить для каждого сервера свой ключ.
Ну так и написано, используйте ключИ, а не ключ.
#12: Используйте Keychain для аутентификации
Не совсем понял смысла этого скрипта из описания в интернетах.
Не совсем понял смысла этого скрипта из описания в интернетах.
Ну смысл в том, чтобы охранять ключи так же как и пароли. Чтобы к ним никто кроме вас не имел доступа. Keychain просто хранит пароли в зашифрованном виде, и оттдает вам определенный ключ, после того как вы ему сообщите определенный пароль. Просто безопасность сервера не ограничивается сервером. Я смогу увести ваш лаптоп, и с лаптопа пользуюсь вашими ключами залогиниться на ваш сервер. При использовании keychain подобное не произойдет. И шифрования всей системы, не требуется. Шифруется лишь то, что нужно защитить.
#13: Ограничьте SSHD с помощью chroot (Заприте пользователей в их домашних директориях)
Это да. В своё время мне этой возможности очень не хватало и приходилось городить костыли. Вот только подобная схема не всегда полезна.
Это да. В своё время мне этой возможности очень не хватало и приходилось городить костыли. Вот только подобная схема не всегда полезна.
Ну конечно не всегда полезна. Но вот опять же, если у вас много пользователей на хосте, причем не судо-пользователей, то, что называется, мастхев. И подобное просто обязано быть у хостеров. К слову, бывали такие, что чрута не было)
#18: Используйте Port Knocking
Имхо, очень гемморно и необходимо только в случае тяжёлой стадии паранойи. :)
Имхо, очень гемморно и необходимо только в случае тяжёлой стадии паранойи. :)
ну вообще да, в несколько проходов nmap'ом можно так себе открыть порт. Но и от nmap'а можно защититься лишь правилами firewall'а, и банить таких умников=)
Просто прелесть подобного решения в том, что нам ничего кроме firewallа не нужно, а он к слову шустрый. А про геморой... Можно спокойно в .bashrc написать скрипт, который сам будет стучаться предварительно, и ваш геморрой снимет как рукой и без ректальных свеч)
/etc/nologin - если этот файл существует, то sshd будет отказываться пускать кого-либо кроме root-пользователя.
Если этот файл существует, то система откажется пускать всех кроме рута. Т.е. и локальный логин, и любой другой логин не будет работать. Я бы не советовал такие вещи на серверах пробовать. Особенно если предварительно отключить логин по ssh для root на удалённом сервере. Будет радостно, ага.
Если этот файл существует, то система откажется пускать всех кроме рута. Т.е. и локальный логин, и любой другой логин не будет работать. Я бы не советовал такие вещи на серверах пробовать. Особенно если предварительно отключить логин по ssh для root на удалённом сервере. Будет радостно, ага.
Окей, спасибо не знал, поправлю.
Вообщем-то я расчитывал на аудиторию "для начинающих". Огромное спасибо за критику, её то мне и не хватло. Сейчас исправлю косяки.
Ну смысл в том, чтобы охранять ключи так же как и пароли. Чтобы к ним никто кроме вас не имел доступа. Keychain просто хранит пароли в зашифрованном виде, и оттдает вам определенный ключ, после того как вы ему сообщите определенный пароль. Просто безопасность сервера не ограничивается сервером. Я смогу увести ваш лаптоп, и с лаптопа пользуюсь вашими ключами залогиниться на ваш сервер. При использовании keychain подобное не произойдет. И шифрования всей системы, не требуется. Шифруется лишь то, что нужно защитить.
Таким образом этот скрипт спрашивает пароль и подставляет вместо него ключ? Чем тогда это лучше обычной авторизации по паролю или по запароленному ключу? Это-то как раз мне и не ясно. :)
Не буду врать, не пользовался) Чаще всего работаю с чужими машинами, поэтому вся работа в основном ограничивается выданными паролями)
ну вообще да, в несколько проходов nmap'ом можно так себе открыть порт.
Можно настроить интервал между "стуками".
2 восьмых потому что автор в оригинале допустил такую же ошибку, а я не заметил=)
Перевод был опубликован еще в 2009 году:
http://rus-linux.net/nlib.php?name=/MyLDP/sec/openssh.html
http://rus-linux.net/nlib.php?name=/MyLDP/sec/openssh.html