https://www.altlinux.org/api.php?action=feedcontributions&user=84.22.98.219&feedformat=atomALT Linux Wiki - Вклад [ru]2024-03-28T23:52:44ZВкладMediaWiki 1.38.2https://www.altlinux.org/index.php?title=Team/Join/Candidate&diff=58504Team/Join/Candidate2022-01-17T13:51:10Z<p>84.22.98.219: Ник должен состоять только из строчных букв</p>
<hr />
<div>Если вы считаете, что какого-то пакета в Сизифе не хватает, или что какой-то пакет заслуживает большего внимания и готовы заняться им — значит, настало время [[Team/Join|присоединиться]] к команде [[ALT Linux Team]].<br />
<br />
== Сбор информации ==<br />
<br />
Для принятия в Team необходима следующая информация:<br />
<br />
* имя ментора — участника команды, имеющего желание помогать в процессе приёма в Team. Менторов можно искать в [[Списки рассылки|списках рассылки]], канале [http://telegram.me/alt_linux Telegram] или на [[IRC]]-канале;<br />
* псевдоним (имя пользователя) участника, выбирается им самим. Имя должно начинаться с буквы, содержать только строчные буквы и цифры, быть не короче трёх символов;<br />
** Псевдоним — это, фактичеки, ваше второе имя в команде. Так вас будут называть в глаза и за глаза, по нему на вас будут ссылаться. Поэтому псевдоним лучше выбирать короткий, запоминающийся и не отягощённый мусором. Например, ''yoda'' — удобный псевдоним, а ''travellingwilburys1998'' — неудобный. Список уже занятых имён можно посмотреть в пакете [http://git.altlinux.org/gears/a/alt-gpgkeys.git?p=alt-gpgkeys.git;a=tree;f=keys alt-gpgkeys]<br />
* адрес почты, на который будет производиться пересылка с адреса <tt>псевдоним@altlinux.org</tt>;<br />
* SSH-ключ (ED25519 или RSA >= 4096bit). Принимающему нужна публичная часть ключа. Этот ключ будет использоваться для SSH-доступа на ресурсы Sisyphus ([[git.alt]] и другие);<br />
* GPG-ключ (RSA >= 4096bit). В ключе должны быть имя в формате "<First name> <Last name>" и uid вида <tt>псевдоним@altlinux.org</tt>. Принимающему нужна публичная часть ключа. Этот ключ будет использоваться для подписи пакетов и для удостоверения личности в почте.<br />
<br />
Если у вас еще нет ssh- или GPG-ключа, прочтите статью «[[Работа с ключами разработчика]]».<br />
<br />
== Создание заявки ==<br />
<br />
Заявка создаётся кандидатом в [[BugTracking/BugzillaMiniHowto|Bugzilla]]. Такие баги читает специальный член команды — секретарь.<br />
<br />
Баг должен быть оформлен следующим образом:<br />
<br />
* [http://bugzilla.altlinux.org/enter_bug.cgi?product=Team%20Accounts&component=join заведён] на компонент «join» в разделе «Development», где продуктом должен быть указан «Team accounts»,<br />
* в теле бага нужно указать псевдоним (имя пользователя) нового участника, адрес пересылки почты, имя ментора, а также несколько слов о том, чем кандидат намерен заняться в ALT Linux Team («собрать для начала такой-то пакет, а потом, если получится, ещё пакеты из такой-то области», «просто помочь со сборкой чего-нибудь», «научиться собирать пакеты», «у вас тут [http://bugzilla.altlinux.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=New%2Fproposed%20packages&query_format=advanced хотелка] висит» и т. п.),<br />
* e-mail ментора следует добавить в поле CC («Подписка»), чтобы он мог должным образом подтвердить своё менторство,<br />
* публичный SSH-ключ и публичный GPG-ключ нужно приложить к багу в виде отдельных приложений (attachments) обычными файлами. GPG-ключ необходимо приложить в экспортированном виде (<tt>gpg --export --armor <id ключа></tt>). Файлы можно прикладывать уже после создания бага.<br />
<br />
== Обработка заявки ==<br />
<br />
После получения необходимой информации секретарь проверяет приложенные ключи, создаёт e-mail адрес и выдаёт ограниченный доступ в git.alt (без возможности сборки пакетов).<br />
<br />
Помните, что и секретарь, и менторы являются добровольцами, и поэтому не всегда имеют время сразу ответить на ваши сообщения/письма/заявки — поэтому, пожалуйста, проявите терпение в случае задержки (но если не отвечают уже месяц, имеет смысл напомнить о себе).<br />
<br />
Секретарь ведёт процесс обработки заявки по [[Team/Join/Secretary|регламенту]]. При переходе на новый этап секретарь обычно указывает номер этапа в открытом кандидатом баге.<br />
<br />
== Работа с ментором ==<br />
<br />
* Ментор помогает новому участнику собирать пакеты, проверяя корректность пакетирования.<br />
* Ментор определяет момент, когда кандидат освоился с инструментарием и освоил основные правила пакетирования, после чего уведомляет об этом секретаря.<br />
* Секретарь добавляет GPG-ключ принимаемого в связку {{pkg|alt-gpgkeys}}.<br />
* С этого момента кандидат может отправлять в сборочницу тестовые задания, которые смогут попасть в репозиторий только после утверждения (approve) ментором (или любым другим членом Team).<br />
* Ментор определяет момент, когда кандидат научился совместно работать над пакетами (в частности, с ментором) и пользоваться сборочницей, и уведомляет об этом секретаря.<br />
<br />
Так как у ментора не всегда будет достаточно времени, чтобы оперативно отвечать на все вопросы, настоятельно рекомендуется подписаться на рассылку {{lists|devel-newbies}} и задавать возникающие вопросы там. Также будьте готовы к тому, что собеседник может покритиковать ваши коммиты в git, указать на ошибки; при сомнениях можно спросить, это техническая претензия или вопрос личных предпочтений (бывает и то, и другое).<br />
<br />
== Завершение процедуры ==<br />
<br />
После получения «отмашки» от ментора секретарь выдаёт полный доступ в [[git.alt]] и подписывает нового участника на {{lists|devel}}. Начиная с этого момента кандидат становится полноправным членом команды.<br />
<br />
[[Категория:Sisyphus]]<br />
[[Категория:Руководства]]<br />
{{Category navigation|title=Team|category=Team|sortkey=*}}</div>84.22.98.219https://www.altlinux.org/index.php?title=%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:Lineprinter&diff=39632Участник:Lineprinter2017-07-13T13:27:54Z<p>84.22.98.219: </p>
<hr />
<div>Hello!</div>84.22.98.219https://www.altlinux.org/index.php?title=Team/Join/Candidate&diff=36862Team/Join/Candidate2016-10-01T14:19:41Z<p>84.22.98.219: /* Сбор информации */ Document ECDSA rejection</p>
<hr />
<div>Если вы считаете, что какого-то пакета в Сизифе не хватает, или что какой-то пакет заслуживает большего внимания и готовы заняться им — значит, настало время присоединиться к команде ALT Linux Team.<br />
<br />
== Сбор информации ==<br />
<br />
Для принятия в Team необходима следующая информация:<br />
<br />
* имя ментора — участника команды, имеющего желание помогать в процессе приёма в Team. Менторов можно искать в [[Списки рассылки|списках рассылки]] или на [[IRC]]-канале.<br />
* псевдоним (имя пользователя) участника, выбирается им самим. Имя должно начинаться с буквы, содержать только буквы и цифры и быть не короче трёх символов.<br />
* адрес почты, на который будет производиться пересылка с адреса <tt>псевдоним@altlinux.org</tt>.<br />
* SSH-ключ (ED25519 или RSA >= 4096bit). Принимающему нужна публичная часть ключа. Этот ключ будет использоваться для SSH-доступа на ресурсы Sisyphus ([[git.alt]] и другие).<br />
* GPG-ключ (RSA >= 4096bit). В ключе должен быть uid вида <tt>псевдоним@altlinux.org</tt>. Принимающему нужна публичная часть ключа. Этот ключ будет использоваться для подписи пакетов и для удостоверения личности в почте.<br />
<br />
Если у вас еще нет ssh- или GPG-ключа, прочтите статью «[[Работа с ключами разработчика]]».<br />
<br />
== Создание заявки ==<br />
<br />
Заявка создаётся кандидатом путем добавления «бага» в [[BugTracking/BugzillaMiniHowto|Bugzilla]]. Такие «баги» читает специальный член команды — секретарь.<br />
<br />
Баг должен быть оформлен следующим образом:<br />
<br />
* Баг должен быть заведён на компонент «join» в разделе «Development», где продуктом должен быть указан «Team accounts»,<br />
* В теле бага нужно указать псевдоним (имя пользователя) нового участника, адрес пересылки почты, имя ментора, а также несколько слов о том, чем кандидат намерен заняться в ALT Linux Team («собрать для начала такой-то пакет, а потом, если получится, ещё пакеты из такой-то области», «просто помочь со сборкой чего-нибудь», «научиться собирать пакеты» и т. п.),<br />
* E-mail ментора следует добавить в поле CC ("Подписка") к создаваемому багу, чтобы он мог должным образом подтвердить своё менторство,<br />
* Публичный SSH-ключ и публичный GPG-ключ нужно приложить к «багу» в виде отдельных приложений (attachments), в виде обычных файлов. GPG-ключ необходимо приложить в экспортированном виде (<tt>gpg --export --armor <id ключа></tt>). Файлы можно прикладывать уже после создания баги.<br />
<br />
== Обработка заявки ==<br />
<br />
После получения необходимой информации секретарь проверяет приложенные ключи, создаёт e-mail адрес и выдаёт ограниченный доступ в git.alt (без возможности сборки пакетов).<br />
<br />
Помните, что и секретарь, и менторы являются добровольцами, и поэтому не всегда имеют время сразу ответить на ваши сообщения/письма/заявки, поэтому, пожалуйста, проявите терпение в случае задержки.<br />
<br />
== Работа с ментором ==<br />
<br />
* Ментор помогает новому участнику собирать пакеты, проверяя корректность пакетирования.<br />
* Ментор определяет момент, когда кандидат освоился с инструментарием и освоил основные правила пакетирования, после чего уведомляет об этом секретаря.<br />
* Секретарь добавляет GPG-ключ принимаемого в связку alt-gpgkeys.<br />
* С этого момента кандидат может отправлять в сборочницу тестовые задания, которые смогут попасть в репозиторий только после утверждения (approve) ментором (или любым другим членом Team).<br />
* Ментор определяет момент, когда кандидат научился совместно работать над пакетами (в частности, с ментором) и пользоваться сборочницей, и уведомляет об этом секретаря.<br />
<br />
Так как у ментора не всегда будет достаточно времени, чтобы оперативно отвечать на все вопросы, настоятельно рекомендуется подписаться на рассылку [https://lists.altlinux.org/mailman/listinfo/devel-newbies devel-newbies@] и задавать возникающие вопросы там. Также будьте готовы к тому, что собеседник может покритиковать ваши коммиты в git, указать на ошибки.<br />
<br />
== Завершение процедуры ==<br />
<br />
После получения «отмашки» от ментора секретарь выдаёт полный доступ в [[git.alt]] и подписывает нового участника на {{lists|devel}}. Начиная с этого момента кандидат становится полноправным членом команды.<br />
<br />
[[Категория:Sisyphus]]<br />
[[Категория:Руководства]]<br />
{{Category navigation|title=Team|category=Team|sortkey=*}}</div>84.22.98.219https://www.altlinux.org/index.php?title=%D0%A0%D0%B0%D0%B1%D0%BE%D1%82%D0%B0_%D1%81_%D0%BA%D0%BB%D1%8E%D1%87%D0%B0%D0%BC%D0%B8_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%87%D0%B8%D0%BA%D0%B0&diff=36861Работа с ключами разработчика2016-10-01T14:15:36Z<p>84.22.98.219: Document ECDSA rejection</p>
<hr />
<div>[[Категория:Devel]]<br />
[[Категория:Sisyphus]]<br />
При [[Процедура принятия в Team|приёме]] участник предоставляет два криптографических ключа, по которым он идентифицируется в дальнейшем. '''Берегите свои приватные ключи!'''<br />
<br />
При утере одного из ключей участник может заменить его, заверив вторым. При утрате обоих ключей участник обязан незамедлительно известить об этом принимающих. Его доступ в [[git.alt]] прекращается до восстановления ключей.<br />
<br />
Два ключа могут быть восстановлены либо посредством личной встречи с одним из принимающих, либо посылкой их письмом, заверенным ключом одного из участников ALT Linux Team. В последнем случае всю ответственность за дальнейшую безопасность репозитория несёт участник, заверивший ключи.<br />
<br />
== Создание SSH-ключа ==<br />
<br />
Если у вас нет SSH-ключа, то создать его можно, например, следующей командой:<br />
$ ssh-keygen [-t <тип ключа>] [-b <размер ключа (для RSA)>]<br />
(рекомендуется ключ ED25519, RSA >= 4096-bit)<br />
<br />
Ключ настоятельно рекомендуется сделать с паролем. Для упрощения работы с ключами с паролями можно воспользоваться [[SSH|SSH-агентом]].<br />
<br />
Публичная часть ключа — файл <tt>~/.ssh/id_ed25519.pub</tt> (для ED25519-ключа, <tt>~/.ssh/id_rsa.pub</tt> для RSA-ключа.<br />
<br />
== Создание GPG-ключа ==<br />
<br />
Создать новый GPG-ключ можно командой<br />
$ gpg --gen-key<br />
В процессе ответа на вопросы выберите тип ключа — RSA и RSA (можно выбрать RSA (sign only), но тогда этот ключ будет непригоден для шифрования), размер — не менее 4096 bit. В качестве email укажите <tt>псевдоним@altlinux.org</tt>. Где <tt>псевдоним</tt> - это тот псевдоним, под которым вы хотите быть в ALT Linux Team (желательно только латинские буквы нижнего регистра).<br />
<br />
== Модификация существующего GPG-ключа ==<br />
<br />
Проверьте, что тип ключа — RSA, размер не менее 4096bit. Добавьте идентификатор в ключ с помощью команд<br />
$ gpg --edit-key <key id><br />
Command> adduid<br />
Укажите своё имя и email вида <tt>псевдоним@altlinux.org</tt>, после чего сохраните изменения<br />
Command> save<br />
<br />
== Отправка публичной части GPG-ключа ==<br />
Экспортируйте публичную часть ключа для отправки:<br />
$ gpg --armor --export псевдоним@altlinux.org<br />
<br />
== Обновление существующего GPG-ключа в пакете alt-gpgkeys==<br />
Для замены просроченного или недействительного ключа, используемого для подписи пакетов, необходимо клонировать последнюю актуальную сборку пакета [http://git.altlinux.org/gears/a/alt-gpgkeys.git alt-gpgkeys.git], обновить в нём свой ключ и выложить модифицированную версию на git.alt в своё личное пространство (private repo) — этим вы подтверждаете аутентичность модификации. Далее необходимо (пере-)открыть заявку на пакет (компонент) alt-gpgkeys для продукта Sisyphus в [https://bugzilla.altlinux.org/enter_bug.cgi?product=Sisyphus багзилле] и ждать реакции мэйнтейнера.<br />
<br />
Также можно приложить новый ключ, экспортированный в текстовый файл, к заявке.<br />
<br />
== Обновление SSH-ключа==<br />
Для обновления SSH ключа (в случае, если он не был скомпрометирован), используемого для доступа к git.alt, можно воспользоваться процедурой, аналогичной обновлению GPG ключа - создать специальный репозиторий на git.alt (например, git.alt:private/ssh-key.git) в своём личном пространстве и выложить в нем новый ключ. Этим вы подтверждаете аутентичность модификации. После этого необходимо открыть заявку в Bugzilla на компонент git.altlinux.org для продукта Infrastructure со ссылкой на созданный репозиторий. В случае, если одновременно обновляются SSH и GPG ключи, ссылку на SSH ключ можно дать в одной заявке с GPG (компонент alt-gpgkeys). <br />
<br />
=== dsa ключи ===<br />
<br />
Начиная с версии 7.1p1 ssh-client отказывается работать с ssh-dss:<br />
<br />
[https://lists.altlinux.org/pipermail/sisyphus/2016-January/364679.html Обновление ssh от 13.01.16]<br />
<br />
рекомендуется обновить ключ, либо включить поддержку ssh-dss в конфигурации своего клиента, как указано в сообщении об обновлении ssh.<br />
<br />
== Ссылки ==<br />
* [http://www.opennet.ru/docs/RUS/gph/ch01.html Быстрый старт] с gpg-ключами на opennet (генерация новой пары ключей, обмен ключами, шифрование, цифровые подписи и их проверка).<br />
* [http://www.opennet.ru/docs/RUS/gph/ch03.html Управление ключами] там же (управление вашей парой ключей, проверка достоверности ключей, распространение ключей).<br />
{{Category navigation|title=Team|category=Team|sortkey=*}}</div>84.22.98.219https://www.altlinux.org/index.php?title=%D0%9B%D0%BE%D0%B3%D0%BE%D1%82%D0%B8%D0%BF%D1%8B&diff=36855Логотипы2016-09-30T12:54:46Z<p>84.22.98.219: </p>
<hr />
<div>== О заглавных и строчных буквах ==<br />
<br />
* ALT Linux<br />
* ALT<br />
* BaseALT<br />
* ALT Linux Team<br />
* но строчные буквы на логотипе<br />
<br />
* так делают все: [http://www.selenic.com/mercurial/wiki/index.cgi/ProductName Mercurial], [http://fedoraproject.org/ Fedora], [http://www.debian.org/ Debian], [http://www.ubuntu.com/ Ubuntu], [http://www.gentoo.org/ Gentoo], [http://www.mozilla.org/ Mozilla].<br />
<br />
== ALT Linux Team ==<br />
<br />
Логотипы с подписью «ALT Linux Team» - community-ресурсы, неофициальные сборки etc.<br />
<br />
{|<br />
|-<br />
| [[Image:Alt_linux_team.png]]<br />
| [[Image:Alt_linux_team_small.png]]<br />
|-<br />
| [[Image:Alt-linux-team-bar-small.png]]<br />
|}<br />
<br />
В svg: [[Изображение:Alt linux logo.svgz]]<br />
<br />
== ООО «Альт Линукс» ==<br />
<br />
ООО «Альт Линукс» пользуется логотипами без подписи «ALT Linux Team» (официальная информация, дистрибутивы ALT Linux):<br />
<br />
{|<br />
|-<br />
| [[Image:Logo_alt_company.png]]<br />
| [[Image:Logo_alt_company_small.png ]]<br />
|}<br />
<br />
== ООО «Базальт СПО» ==<br />
<br />
ООО «Базальт СПО» пользуется логотипом (официальная информация, дистрибутивы ALT и BaseALT):<br />
<br />
{|<br />
|-<br />
| [[Image:Basealt_logo.png]]<br />
<br />
|}<br />
<br />
[[Категория:Изображения]]<br />
{{Category navigation|title=ALT Linux|category=ALT Linux|sortkey=*}}</div>84.22.98.219https://www.altlinux.org/index.php?title=SSH&diff=35766SSH2016-03-28T11:38:59Z<p>84.22.98.219: dsa -> ed25519</p>
<hr />
<div>{{Stub}}<br />
{{span|font-size: 180%|Создание и настройка входа через ssh}}<br />
<br />
Рассматривается вопрос создания ключа пользователя и настройки для авторизации на сервере в ssh через ключ.<br />
Предполагается что ssh-сервер запущен и имеет настройки, принятые по умолчанию в ALT Linux.<br />
<br />
== Введение ==<br />
ssh (secure shell) — программа для входа на удалённую машину и выполнения на ней команд.<br />
<br />
== Создание ключа ==<br />
В ssh используется асимметричное шифрование, соответственно используется пара из закрытого и открытого ключа.<br />
Для создания ключа на компьютере пользователя нужно выполнить<br />
<pre>$ ssh-keygen -t ed25519</pre><br />
<br />
На вопрос о файле для сохранения ключа нажать Enter (по умолчанию). Далее будет задан вопрос о пароле к ключу. Пароль нужно указать.<br />
<br />
В каталоге {{path|~/.ssh}}<br />
появляются файлы<br />
* id_ed25519 — секретный ключ<br />
* id_ed25519.pub — публичный ключ<br />
<div style="display: inline; color: red;">Внимание! Никогда никому не пересылайте '''секретный''' ключ.</div><br />
<br />
== Настройка входа (на сервере) ==<br />
Для того, чтобы пользователь мог авторизоваться в системе через ssh-ключ, нужно в файл {{path|~/.ssh/authorized_keys}} добавить содержимое файла {{path|id_ed25519.pub}}. Если пользователь будет один входить под этой учётной записью, файл {{path|id_ed25519.pub}} можно просто скопировать, назвав authorized_keys.<br />
Также можно воспользоваться утилитой {{prg|ssh-copy-id}}, если копировать вручную не хочется: {{cmd|ssh-copy-id user@host}}<br />
<br />
'''Данные изменения проводятся в каталоге пользователя ''на сервере'''''.<br />
<div style="display: inline; color: red;">Обратите внимание на права файлов:</div><br />
<pre>-rw------- authorized_keys<br />
-rw-r--r-- config</pre><br />
и на каталог<br />
<pre>drwx------ .ssh</pre><br />
принадлежать файлы должны пользователю и его группе.<br />
<br />
Пользователям XFCE [https://bugzilla.altlinux.org/show_bug.cgi?id=27342 может потребоваться] включить явный запуск ssh-agent, чтобы его использовать:<br />
$ xfconf-query -c xfce4-session -p /startup/ssh-agent/type -s "ssh-agent" -t string -n<br />
Изменение вступит в силу после перелогина.<br />
<br />
Проверка того, что ключ работает:<br /><br />
1. $ ssh-add<br /><br />
2. $ ssh другая_машина<br /><br />
При подключении не должен запрашиваться пароль.<br />
<br />
== Использование ==<br />
$ ssh user@host.name<br />
<br />
== Конфигурационный файл (у пользователя) ==<br />
Для удобства в файле ~/.ssh/config можно указать сокращение<br />
<pre>Host myserv<br />
HostName host.name</pre><br />
<br />
и вызывать просто как<br />
$ ssh myserv<br />
<br />
Можно добавить ещё настроек:<br />
<pre>Host myserv<br />
...<br />
User user<br />
Protocol 2<br />
ForwardX11 yes<br />
ForwardAgent yes<br />
Compression yes</pre><br />
<br />
Чтобы не указывать пароль каждый раз при обращении к серверу, можно запустить<br />
$ ssh-add<br />
Будет спрошен пароль и расшифрованный ключ запомнится на время вашего сеанса. Это сработает если запущен ssh-agent (в ALT Linux он запускается автоматически при графическом входе в систему).<br />
<br />
== Настройка сервера ==<br />
<br />
=== Инструкция по установке и настройке сервера ssh для администратора ===<br />
Нужно установить пакет '''openssh-server''', включить автоматический запуск при загрузке системы:<br />
# chkconfig sshd on</pre><br />
В файле /etc/openssh/sshd_config укажите строку [[Документация/AllowUsers|AllowUsers]] с перечислением пользователей, имеющих право подключаться к системе.<br />
<br />
Например<br />
AllowUsers guest test best<br />
<br />
А также рекомендуется выключить аутентификацию по паролю (исправить строчку [[Документация/PasswordAuthentication|PasswordAuthentication]] на):<br />
PasswordAuthentication no<br />
<br />
Для вступления настроек в силу:<br />
# service sshd reload<br />
<br />
=== [[OpenLDAP|LDAP]] ===<br />
Чтобы sshd мог пускать пользователей из LDAP, нужно выполнить<br />
control system-auth ldap<br />
<br />
== Управление сессиями ==<br />
PAM session management в openssh той версии, которая находится в Сизифе и дистрибутивах, использует [http://www.citi.umich.edu/u/provos/ssh/privsep.html privilege separation] и потому исполняется с правами пользователя, а не root. Как следствие,<br />
* [[pam_mktemp]] не сможет создать подкаталог в /tmp/.private/ с нужными правами, если его там нет;<br />
* pam_mkhomedir не сможет создать подкаталог с нужными правами, если его там нет;<br />
* pam_limits не сможет увеличить лимиты сверх тех, что есть у процесса openssh.<br />
<br />
В качестве объезда можно помещать эти модули в PAM account management.<br />
<br />
== Полезные советы ==<br />
<br />
=== Предотвращение брутфорс-атак ===<br />
* Можно пересадить sshd на нестандартный порт<br />
* Целесообразно ограничить число «ожидающих» соединений, когда пароль еще не введен. Для этого, в файле /etc/openssh/sshd_config укажите строку<br />
MaxStartups 2:70:10<br />
В этом случае у вас будут разрешены только 2 «ожидающих» соединения, и каждое следующее будет сброшено с вероятностью 70 %<br />
* Для особо изощрённой защиты можно использовать [http://sisyphus.ru/srpm/knock knock].<br />
* Можно ограничить число попыток средствами iptables:<br />
iptables -A INPUT -p TCP --syn --dport 22 -m recent --name ssh_rate_limit --set<br />
iptables -A INPUT -p TCP --syn --dport 22 -m recent --name ssh_rate_limit --update --seconds 60 --hitcount 4 -j LOG<br />
iptables -A INPUT -p TCP --syn --dport 22 -m recent --name ssh_rate_limit --update --seconds 60 --hitcount 4 -j DROP<br />
Для оптимизации этого дела настроятельно рекомендуется завести цель LOGDROP.<br />
* Настроить {{pkg|fail2ban}}:<br />
В файл /etc/fail2ban/jail.d/customisation.local записать<br />
<pre><br />
[sshd]<br />
enabled = true<br />
filter = sshd<br />
logpath = /var/log/auth/messages<br />
maxretry = 3<br />
</pre><br />
В файле /etc/openssh/sshd_config параметру '''UseDNS''' задать значение <tt>no</tt>.<br />
<br />
* Либо настроить {{pkg|sshutout}}, см. [http://www.techfinesse.com/sshutout/sshutout.html описание].<br />
<br />
=== Настройка второго sshd ===<br />
Копируем /etc/init.d/sshd и указываем через -f другой конфигурационный файл?<br />
Практика показывает, что надо менять весь набор: копировать /etc/init.d/sshd, /etc/sysconfig/sshd; (факультативно делать ссылки или копировать сам sshd, /etc/pam.d/sshd); изменять посредством /etc/sysconfig/sshd переменные PIDFILE, LOCKFILE, EXTRAOPTIONS.<br />
<br />
=== Копирование ключа на сервер ===<br />
Если вам нужно добавить на сервер, куда вы имеете доступ, чей-то ключ, используйте<br />
$ ssh-copy-id<br />
Например:<br />
$ ssh-copy-id -i friends_pub_key myserver<br />
<br />
=== Cisco IOS и SSH 6.6p1 ===<br />
Ошибка при подключении:<br />
SSH2 0: Client DH key range mismatch with max built-in DH key on server!<br />
<br />
в ~/.ssh/config (что бы не переопределять глобально у остальных пользователей) добавить:<br />
<br />
<pre><br />
Host 192.168.1.*<br />
KexAlgorithms diffie-hellman-group14-sha1,curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,\<br />
diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1<br />
</pre><br />
<br />
т.е. diffie-hellman-group14-sha1 - на первое место.<br />
<br />
== Настройка входа по одноразовому паролю ==<br />
Вход по ключу - это, конечно хорошо (особенно если ключ ещё и защищён паролем), однако при входу из общественного места может не быть возможности использовать ключ (не дают тыкать свои флешки). А если такая возможность есть, то не факт, что ваш ключ не будет скопирован, а его пароль перехвачен во время ввода. В общем ключ - это просто более надёжный пароль: его тоже можно украсть и потом невозбранно использовать для входа под вашей учётной записью.<br />
<br />
Для общественных мест хочется такую технологию входа, чтобы потенциальная компрометация ''всех'' учётных данных не дала возможности злоумышленнику войти в систему. И такая технология есть - это [http://ru.wikipedia.org/wiki/%D0%9E%D0%B4%D0%BD%D0%BE%D1%80%D0%B0%D0%B7%D0%BE%D0%B2%D1%8B%D0%B9_%D0%BF%D0%B0%D1%80%D0%BE%D0%BB%D1%8C одноразовые пароли]. Подробнее о том, как это работает можно прочитать в [http://habrahabr.ru/post/154229/ этой статье]. Для вас же их использование будут означать, что при входе в систему, помимо пароля, нужно будет вводить некий числовой код, который будет каждый раз разным.<br />
<br />
В качестве инфраструктуры для одноразовых паролей мы возьмём [https://code.google.com/p/google-authenticator/ Google Authenticator], ибо всё необходимое уже есть в репозиториях. Нам понадобятся два пакета: libpam-google-authenticator и libqrencode (без последнего можно обойтись). Если пакета google нет в репозитории вашей платформы, то его несложно собрать самому в [[Hasher|хешере]], у него почти нет зависимостей.<br />
<br />
Итак, пакеты установлены. На время настройки рутовую консоль лучше держать открытой.<br />
Сначала создадим необходимые файлы у пользователя, который будет входить с одноразовым паролем. Входим под ним и выполняем:<br />
google-authenticator<br />
Будут заданы следующие вопросы:<br />
* Сделать токены зависимыми от времени - y<br />
* Здесь, если вы поставили libqrencode, вам будет показан QR-код. В приложении Google Authenticator а<br />
на телефоне нужно создать новый аккаунт и отсканить этот код. Если не ставили библиотеку, перебивайте показанный код руками. В результате вам тут же будет сгенерирован текущий одноразовый пароль.<br />
* Обновить файл ~/.google_authenticator? - y<br />
* Запретить использование одного кода несколько раз - y<br />
* Расширить время действия кода с 1,5 минут до 4? - n<br />
* Запретить попытки входа чаще, чем 3 раза за 30 сек? - y<br />
Всё, настройка для пользователя закончена. Идём ковырять систему (из-под рута, конечно).<br />
<br />
Сначала OpenSSH. В /etc/openssh/sshd_config включаем вопрос-ответ:<br />
ChallengeResponseAuthentication yes<br />
И просим демона перечитать конфиг:<br />
service sshd reload<br />
<br />
Отлично, с SSH закончили. Теперь правим соответствующие настройки PAM (они лежат в /etc/pam.d/sshd). Обычно рекомендуют просто добавить гугловый пам в начало файла. В нашем случае это не заработает. Проблема в том, что модуль pam_userpass не хочет нормально работать в паре с гуглом. Если просто добавить гугл в pam.d/sshd, то независимо от порядка следования модулей, будет выводится только запрос на одноразовый пароль и всегда будет access denied.<br />
<br />
Однако, не смотря на название, userpass не проверяет логин/пароль, он просто запрашивает их и сохраняет внутри стека pam. А проверяет их<br />
[http://docs.altlinux.org/manpages/pam_tcb.8.html pam_tcb], причём он и сам умеет запрашивать пароль!<br />
<br />
Решение очень простое - выкидываем userpass, вставляем на его место tcb<br />
без параметра use_first_pass. После этип манипуляций конфиг должен выглядеть так:<br />
#auth required pam_userpass.so<br />
auth required pam_tcb.so shadow fork prefix=$2y$ count=8 nullok<br />
auth required pam_google_authenticator.so echo_verification_code<br />
#auth include common-login-use_first_pass<br />
Весь остальной стек для auth выкидываем, ибо там тот же tcb и всякий ldap, который не нужен (если нужен, придётся перенести его сюда же).<br />
<br />
Порядок следования модулей auth важен, при таком как в примере, сначала запрашивается пароль, затем всегда одноразовый код. Так невозможно<br />
понять, что именно неверно, и это хорошо для безопасности. Если хотите, чтобы авторизация обламывалась сразу, замените required на requisite у<br />
pam_tcb.<br />
<br />
== Ссылки ==<br />
* [http://ftp.altlinux.org/pub/distributions/ALTLinux/2.4/Master/docs/ch06s05.html#distrib.setup.network.ssh Документация ALM2.4]<br />
* [http://www.nixp.ru/cgi-bin/go.pl?q=articles;a=ssh Настройка сервера SSH (теория и практика])<br />
* [http://www.opennet.ru/openforum/vsluhforumID14/179.html Настройка SSH в cygwin]<br />
* [http://www.linuxfocus.org/Russian/January2003/article278.shtml Автоматизация системного администрирования с помощью ssh и scp]<br />
* [http://www.securitylab.ru/analytics/216377.php Защита с помощью SSH ключей]<br />
* [http://www.stearns.org/doc/ssh-techniques-two.current.html Довольно интересные трюки] (в основном по работе с большим количеством систем, в том числе через одну из них)<br />
* http://www.linux.com/article.pl?sid=05/09/15/1655234<br />
* http://fail2ban.sourceforge.net/<br />
* http://www.csc.liv.ac.uk/~greg/sshdfilter/<br />
* http://tychoish.com/rhizome/9-awesome-ssh-tricks/<br />
* https://wiki.archlinux.org/index.php/Secure_Shell<br />
<br />
[[Категория:Admin]]<br />
{{Category navigation|title=Системному администратору|category=Admin|sortkey={{SUBPAGENAME}}}}</div>84.22.98.219