SSH: безопасный доступ и автоматизация в Linux // Курс "Администратор Linux. Базовый уровень"

Итак, всем добрый вечер. Просьба написать в чат единицу, если меня хорошо слышно, видно. Есть презентация. Угу. Ещё буквально полминуты, мы уже официально начинаем. Да, вижу плюсы. Спасибо. Сейчас дождёмся официального начала, и тогда пойдём по теме.

Итак, московское время 19:00. Ээ, всем добро пожаловать на открытый урок курса Administrator Linux Basic. Сегодня мы говорим про SSH. У нас, ээ, часть темы - это безопасный доступ и автоматизация в Linux. Но на самом деле, это действительно основы работы с любым Линуксом. И важная часть, поэтому будем сегодня какие-то вещи разбирать. Понятно, что это открытый урок курса Basic. Это значит, что мы будем заниматься базовыми, основными вещами. Ну, если вы уже что-то знаете, тоже можно участвовать. Можете какие-нибудь там дополнительные вопросы задавать. По возможности всё отвечу, разберу, если успеем, если я смогу это сделать на ходу.

Итак, всё в порядке, меня, видимо, видно и слышно. Если что не так, сразу пишите в чат. Я за чатом слежу, он у меня здесь открыт. И будем решать проблемы на ходу. Меня зовут Лавлинский Николай. Я технический директор компании Methoddab. И, в принципе, довольно давно занимаюсь вопросами веб-разработки на разных уровнях. И, собственно, и программированием, и администрированием, и руководством. И, ээ, также параллельно я преподавал, сейчас это онлайн. И есть соответствующие соцсети, где можно найти материалы с моим участием. А поэтому, пожалуйста, можете всё это себе где-то отметить. И если интересны вот эти темы: оптимизация производительности, Linux администрирования, ускорение сайтов, то вот это можно там посмотреть.

Ээ, презентацию я вам пришлю в виде ссылки ближе к концу. Мы разберём основной материал. Я вам скину в чат ссылку, чтобы вы её могли скачать, если она вам будет полезна. Не сказать, чтобы она была какая-то суперобъёмная. Всё-таки у нас открытый урок, поэтому мы, а, ну, довольно сокращённый формат сегодня будем разбирать по отношению к полноценным занятиям курса. То есть это примерно половина одного занятия на курсе в OTUS Administrator Linux Basic. А правило одно основное - это задавайте вопросы. Как только они у вас появляются, пишите в чат. А, постараюсь за ними следить. Если будет слишком много сообщений, ну, иногда я их пропускаю, опять же, можно повторить, если я что-то там не ответил, что-то важное для вас. Ну а как обычно, запись у вас будет, она придёт. И сразу вам рекомендую подписаться на соцсети OTUS, там вам будет доступен поток всех открытых уроков, записи. И вполне возможно, что вас ещё какие-нибудь вещи заинтересуют.

Итак, а к вам базовые вопросы. Если не сложно, напишите, чем вы сейчас занимаетесь, какая у вас должность и какая основная цель на сегодня на наше занятия. Ну, это просто, чтобы мы ориентировались и планировали будущие занятия. А, то есть должность и какая цель. Вы пока пишите, я расскажу про компанию OTUS. И, ээ, в общем, это, как вы понимаете, образовательная организация, занимается онлайн-обучением, в основном в айтишной сфере. И сейчас это совершенно разные уровни, начиная от Junior уровни, вот как сегодня мы как раз ээ такой курс разбираем, до тимлидов. А есть B2B заказчики - это компании, которые отправляют своих сотрудников на обучение. Ну и обычные люди тоже в индивидуальном порядке приходят повысить квалификацию. А у вас м на выходе получится полноценный образовательный документ, потому что в OTUS есть лицензия на образование, и у вас получится либо удостоверение повышения квалификации, либо диплом о профпереподготовке. Это зависит от уровня курса. Некоторые дают один документ, другие другой. Это абсолютно серьёзная бумага, её можно везде предъявлять. Это а не какая-то просто распечатана на принтере там очередная бумажка, а направления практически любые в области IT существуют. Вот сегодня мы находимся в разделе архитектура, то есть системное администрирование уходит. Вернее, извините, инфраструктура всё-таки, да? Архитектура - это немножко другое. Вот в инфраструктуре мы как раз ээ занимаемся администрированием. Туда же DevOps включается. Вот всё, что с этим связано.

Так, я вижу, вы пишете ответы. Ага, отлично. Так, системный аналитик, а, поменьше воды про OTUS. А, ну это обязательно наша часть, потому что мы здесь все благодаря компании OTUS, и без этого никак не получится. Это основная программа, так что я постараюсь быстро, но это обязательно. Поэтому вам контент доступен бесплатно, поэтому вы потратьте пару минут послушать.

Итак, а Windows Admin, ээ, так, VJS. Ага, отлично. Так, вот, а что касается нашей сегодняшней темы, а мы сейчас подошли к основной теме. Реклама закончилась. В конце мы ещё поговорим про сам курс, ээ, ну, это уже будет после контентной части. Так вот, а сегодня мы поговорим про SSH, что это такое, зачем применяется. Поговорим про аутентификацию по ключам, а, немножко понастраиваем Demon SSHD. Ну, и, как я говорил про курс, ээ, какие-то ваши ответы. На самом деле, там есть ещё внутри всякие мелкие моменты. Ну и, конечно, я на ваши вопросы тоже буду ориентироваться, там, что вам интересно, какие-то вещи будем смотреть.

Итак, а цель у нас познакомиться с SSH, узнать возможности аутентификации и познакомиться с курсом и командой. Вот. Начинаем мы, собственно, с базовых вопросов. Ну вот представьте, что если вы подходите к администрированию Линукса, только-только вступаете в эту тему, то у вас возникает вопрос: какой будет основной интерфейс для взаимодействия с Линуксом? Особенно, если вы раньше были в Windows мире, то, наверное, вы подразумеваете какой-то графический интерфейс, потому что в Windows стандарт - это графический интерфейс. Мы куда-то логинимся, у нас есть графическое окружение, окна, там мы запускаем приложение, всё это понятно. Ну, в Линуксе у нас система другая. И если мы говорим про серверный Linux, то это именно, скорее всего, для вас будет подключение по SSH. Это Secure Shell Protocol, то есть мы подключаемся к оболочке и делаем это в безопасной форме. Ну почему? Это называется Secure. Дело в том, что есть и не Secure вариант, классический такой. То есть, например, типичный. Мы по Telnet можем подключиться к какому-то порту и отдавать какие-то команды, но проблема в том, что у нас нет безопасного метода, мы не шифруем трафик по умолчанию. То есть это подход для каких-то примитивных, ну или каких-то заведомо доверенных задач. То есть, если у вас есть железка, вы прямо к ней проводом подключились, там иногда бывает Telnet доступен для каких-то сервисных вещей, но для удалённого подключения, по-настоящему удалённого, например, через интернет ни в коем случае, конечно, не используется, только поверх каких-то средств защиты. А вот SSH он позволяет нам подключиться, в принципе, из любой сети. И сразу нам предоставляет шифрование. Это нам даёт как раз вот это слово secure. Ну, shell - это оболочка. Понятно, что мы говорим про какую-то оболочку. Оболочка для нас - это текстовый интерфейс. И это может быть любая оболочка, которая у вас настроена. Это уже просто то, как мы подключаемся, да, что мы там будем использовать. А, и, собственно, самое главное, что современная версия SSH нам даёт достаточно надёжное шифрование всего трафика. Это значит, что мы можем безопасно передавать всё, что нам нужно, и управлять, в том числе по публичным сетям. Если мы сравниваем Telnet и каким-нибудь Remote Shell какой-нибудь, вдруг если у вас встретится, то это совсем другая вещь, гораздо более защищённая.

Ну и мы можем не только логиниться, использовать оболочку, а мы можем его использовать как транспорт. А то есть можем по нему передавать файлы, можем использовать туннели. То есть SSH на самом деле это такой универсальный транспорт в Линуксе. То есть SSH почти всегда есть. Его можно использовать для многих задач, не только для вот прямого подключения, как мы сейчас будем использовать. А в любом случае с SSH подключение, скорее всего, будет начинаться работа с конкретным сервером.

Так, вижу, э ваши комменты. А можно окно пробросить через SSH? Причём графики на сервере вообще не надо. Библиотеки. А, но тут Иван предлагает, ээ, сделать с графикой. Да, можно, но не нужно. То есть вам на сервере графика, ну, никогда не нужна, а реально это не используется, поэтому и не надо ничего пробрасывать. А вам на сервере достаточно текстового интерфейса, и абсолютно весь софт у вас настроен именно на это. А так что то, что можно, не обязательно делать. А так вот Дмитрий пишет: "Windows в 2008 есть Server Core GUI на серверах. Идея так себе". А, ну вполне возможно. Я не работаю с Windows уже очень давно, поэтому не слежу. Вполне возможно, что это есть. И если говорить про Windows из того, что я знаю, то Windows сейчас тоже следует как раз тенденциям Линукса. То есть он внедряет древние фишки, которые в Линуксе стандартные, а в Windows они вот только-только появляются. Но если я не прав, поправьте меня там в чате. То есть те же самые команды PowerShell, это же всё как раз расширение ээ консольного интерфейса, и он там всё больше и больше внедряется. Ну, вплоть до того, что там там Windows Subsystem for Linux, вот эти все интеграции, они как раз туда идут. А так SSH передача на основе TCP. Да, совершенно верно. TCP порт 22 стандартный для SSH. Так, на сервере сами иксы не будут запущены, только библиотеки удобнее управлять VirtualBox на сервере. Ну, возможно, Иван, я не спорю, но ээ тоже VirtualBox на сервере, я думаю, не очень часто применяется, но если нужно, Linux много чего позволяет сделать.

Так вот, ну давайте, чтобы далеко не теоретизировать, вот у меня есть пару виртуальных машин. Мы с ними будем тренироваться. Насчёт SSH подключения. Я уже сейчас к этой машине подключён. Ну давайте вернёмся в мою хостовую машину. Вот вот это моё приглашение, это мой родной терминал. У меня хостовая машина, то есть на которой я сейчас вещаю, это Ubuntu 24. Это мой терминал вот с таким приглашением цветным. Это вот я просто открыл терминал, штатный GNOME Terminal без всяких там ухищрений. И вот мне нужно управлять виртуалкой. У виртуалки есть адрес. Вот он здесь высветился, и мы к нему подключаемся. Ну, подключиться, понятное дело, можно командой SSH. Кстати, если раньше это была прерогатива именно Unix-подобных систем, то сейчас в Windows тоже есть стандартный SSH клиент. Ну, если он, конечно, у вас установлен. То есть точно такая же команда будет работать в Windows. Ну и обычно, что мы делаем? Мы вводим пароль, вводим логин и вводим вот этот IP-адрес нашей машины. А это будет, собственно, базовая команда, достаточная для подключения. Если мы не будем вводить пользователя, то пользователь будет браться из моей системы основной. То есть это будет пользователь, но мне это не нужно. У меня там есть пользователь DB, и я знаю, что вот машина имеет такой адрес. То есть базово всё происходит именно так. Стандартный запрос пароля. А если у меня нет пока что ни одной сессии с этой виртуалкой, тогда у меня будет предупреждение, что это неизвестный хост, и мне нужно разрешить ээ для него подключение. То есть я начинаю доверять этой машине. Мы ещё сегодня, я думаю, это увидим, когда между виртуалками будем подключаться. Ну, я уже подключался к этой машине, поэтому у меня здесь проблем нет. Ещё, кстати, что может произойти, это вот при этом подключении будет ошибка. То есть мне скажут, что, а, товарищ, вот на вот этом IP-адресе с этим пользователем, ну, точнее просто с этим IP-адресом мы уже подключались, но там была другая машина. Это бывает, кстати, часто с виртуалками. И при этом, а если у вас будет проблема проверки ключей, тогда вам SSH запретит подключение. То есть это защита от подлога хоста. Если кто-то, допустим, внедрился в вашу сеть и вот к этому IP-адресу смог привязаться, но при этом там стоит другая машина. У машины есть свои ключи, и, соответственно, возникают ээ из-за этого всякого рода проблемы. Вот нам тогда просто предложат удалить вот эту запись. И, соответственно, дальше мы просто-напросто переподключимся, то есть заново разрешим подключение к этому хосту, и всё пойдёт дальше. Ну, то есть SSH он заточен под безопасность, поэтому не удивляйтесь, если вас будут там запрашивать эти подтверждения. Это всё связано с тем, что мы сейчас начинаем передавать пароли, и мы начинаем уже доверять этому хосту в каком-то смысле.

Ключ удалённого хоста будет добавлен в known_hosts. В общем, да, known_hosts есть такой файл. Я могу в Линуксе его показать. Ну, здесь, я думаю, он тоже есть. Давайте посмотрим. В домашней директории пользователя .ssh это как раз вот такой каталог, в котором есть всякого рода настройки и в том числе есть known_hosts. Он и в Windows тоже есть, просто там нужно уточнить, где он находится. Обычно там вам об этом расскажут, ну, покажут, где это всё есть. Ну, давайте я покажу здесь тоже, а, куча подключений. И вот здесь видно, что а это такая простенькая база данных, где каждая строчка - это один хост. Вот здесь будет указано, какой ключ хоста. Есть определённые хэши. И вот по вот этой информации, собственно, виртуальные машины и будет определять, а какие хосты она уже видела. И если что не так, вам скажут удалить конкретную строчку здесь. Да, в Windows тоже есть папка .ssh. Имею в виду, что она где-то тоже вашей в пользовательской директории, а там своей системы. То есть, если у нас здесь всё очень просто, это /home/user/.ssh, то у вас там будут какие-нибудь там пользователи, Users или что-то такое. В общем, known_hosts тоже иногда вам придётся работать. Ну, скажем так, если уж прямо совсем плохо, вы ничего не понимаете, куда куда бежать, что делать, вы можете его вообще зачистить этот файл, он забудет абсолютно все хосты. Всё начнётся сначала. Вы будете подтверждать каждый хост, и всё будет работать. Вот. Поэтому, кстати говоря, если вы первый раз подключаетесь по SSH, вам нужно будет это сделать и проверить, а перед тем, как вы будете, допустим, а запускать какие-то задачи по расписанию. Ну, потому что если вы, например, поставите в какую-нибудь крон-задачу, то есть регулярный бэкап какой-нибудь по SSH, то первый раз вы же должны будете ручками согласиться и добавить хост в known_hosts. Поэтому первый раз подключаемся, а, вручную, всё это подтверждаем и только потом даём на фон на автоматику.

Так вот, Денис тут настойчиво спрашивает, как баннер приветствия при подключении поменять. А я думаю, что это либо настройки SSH, либо, скорее всего, bashrc, но это настройки оболочки, собственно, там тоже можно что-нибудь такое подкрутить. Так, LL - это ls -l? Ну, не совсем, Дмитрий. Давайте посмотрим, что у нас здесь есть из алиасов. L - это ls -l. Вот он. Ну, посмотреть можно команда alias. Alias - это псевдонимы команд. То есть мы из коробки в Ubuntu имеем набор, ну, таких довольно удобных сокращений, чтобы не набирать кучи параметров. То есть обычно ls нам покажет только стандартные файлы в коротком формате, и смотреть это довольно неудобно. Вот поэтому LL, ну, это удобно посмотреть именно список файлов в длинном формате с указанием там директорий. Ну, можете отдельно вот эти все параметры посмотреть. Это все файлы. Это длинный формат. Это, по-моему, что связанное с флагами, как показывать директории. Вот видите, директории показываются с финальным слешем, чтобы их было более заметно. Ну вот всё. А это мы посмотрели немножко на структуру SSH-директории. Это мы, может быть, даже вперёд немного забегаем. Пока нам это не очень нужно, но я сказал про alias. А это к вопросу о решения проблем, если вы будете подключаться и вот что-то не проходит. Ну, и, кстати говоря, а я думаю, вы поняли, что при подключении по SSH мы оказались внутри оболочки, привязанной к пользователю, с которым мы подключались. То есть мы находимся здесь как пользователь DB. Это можно проверить командой ID. Это пользователь DB, у которого UID 1000, группа такая же. Он входит в какие-то другие группы. И, а, к вопросу о портах, о процессах, давайте тоже это сейчас разберём. То есть куда мы на самом деле попали. А я для этого использую дерево процессов. Это ps aux. И давайте найдём нашу сессию, то есть где мы сейчас находимся. Вот, на самом деле, набор процессов, которые отвечает за нашу сессию. И, как видите, SSH Demon SSHD, он запускает, порождает там дочерний процесс для пользователя DB. А дальше мы подключаемся к псевдотерминалу pts/0. Вот он. И, соответственно, вот эти вот наши процессы bash, ID и ps находятся на этом терминале. То есть это означает, что если мы закроем вот эту окно или я выйду из оболочки, то, собственно, на этом сессия закончится. Она будет закрыта, в том числе, как и все программы, которые работают из-под этой оболочки. Например, если я запущу какой-то там длительный процесс, и, соответственно, здесь будет определённая проблема.

Так, Андрей пишет, что звук пропадает. Угугу. Ну, у меня мигает "плохое подключение". Я могу отключить видеокамеру. Это может быть поможет. Давайте сейчас в таком варианте. Ну вот пишут всё нормально. Если у всех нормально, это может быть связано именно с, да, с отдельным подключением. Попробуйте перезагрузить в браузере закладку с вебинаром. Такое бывает. Может помочь. А, всё нормально, да? Ну ладно. Нет, ну бывает у этих систем, бывает всякое, поэтому я уже не удивляюсь. У меня был случай, когда вообще, а, скриншот шёл с каким-то дико низким разрешением, ничего нельзя было прочитать. Я надеюсь, что текст читается и, да, всё в порядке.

Так вот, смотрите, мы вот находимся в этих процессах, и SSH Demon а нам в итоге породил оболочку. То есть мы сейчас находимся в оболочке Bash. Из неё выполняются команды, в том числе из неё запустился ps aux как вложенный процесс. То есть это дочерний процесс от оболочки. Он пока работал, он существовал. Как только ps отработал, его больше нет. То есть у нас остался вот этот процесс. Это вот ровно, где мы сейчас находимся. А зачем я это показываю? А это может быть полезно для понимания, э если вы захотите запускать долгоиграющие процессы. Вот как решить эту проблему, вот как сделать, чтобы они продолжали работать, а мы м чуть позже поговорим. А есть довольно простые решения, чтобы защититься от разрыва соединения нашей сессии. Ээ, да, вот Андрей пишет правильно, tmux и screen. Вот если будет время, мы, ээ, их тоже посмотрим, немного поковыряем.

Ну так вот, я надеюсь, у вас появилось ощущение, что такое SSH. Это, собственно, наш основной интерфейс, ээ, подключиться к системе, получить оболочку и там исполнять команды. То есть мы находимся уже в совершенно другой системе. И, ээ, мы работаем по защищённому протоколу. То есть он зашифрован надёжно, хорошо и делаем там всё, что мы хотим. А, в общем, базово подключились теперь. А, да, если есть вопросы, задавайте, как обычно, но есть один минус. То, что мы делали, мы подключались с использованием пароля. То есть, если мы вводим пароль вручную, во-первых, это значит, что пароль должен быть установлен, то есть у пользователя есть какой-то пароль, и значит, что его кто-то может подобрать, особенно если он не очень длинный и надёжный. Используйте безопасные пароли. Не надо делать, как у меня на виртуалке, там пароль из одной буквы. Это неправильно. Это исключительно виртуалка. Она никогда не доступна снаружи. Поэтому нам нужно использовать какой-то более безопасный способ подключения к этой виртуалке. А, так, можно ли менять порт SSH? Да, конечно, можно. Мы сейчас дойдём до настроек. Если я не покажу, напомните мне ещё раз. Ну, это в настройках мы разберём. А как это работает?

Так вот, мы можем вместо пароля использовать аутентификацию по ключам. Ну, вообще слово аутентификация обозначает как раз идентификацию пользователя. То есть мы должны понять, что вот я, кто пришёл, это я конкретный Вася Пупкин. И, соответственно, мне на этом, на этой основе дают подключение. А мы можем для этой задачи использовать ключи. А ключи создаются в виде пары. Пара будет состоять из публичного ключа и приватного. Публичный - это открытый ключ, другими словами, private ключ - это секретный ключ. Мы их генерируем вместе, они взаимозависимы, но из одного другой не получается. И, естественно, так как публичный ключ безопасный, то есть он не секретный, мы его раздаём куда угодно, можем повесить у себя на сайте, и, соответственно, всё это будет работать. А вот если нам нужно, а, подключиться, то у себя мы храним приватный ключ, а публичный ключ мы выкладываем как раз на удалённую систему, к которой нам нужно подключиться. То есть на сервере есть публичный ключ, и не страшно, если он там есть, если его кто-то увидит, это совершенно безопасно. А вот секретную часть ключа нужно хранить при себе. И, соответственно, мы здесь ничего больше не раздаём никуда.

Дмитрий пишет: "Из приватным можно получить, ээ, публичные?" Ну, возможно, но из публичного секретные точно нельзя получить. А так вот, что мы сейчас будем делать? Мы сейчас настроим аутентификацию между двумя виртуалками. И для этого нам нужно будет на клиенте нагенерировать пару ключей, а на сервер доставить публичный ключ и прописать его в authorized_keys. Это специальный файл, который, собственно, тоже должен находиться в нужном месте. И мы поговорим про нюансы, которые там могут возникать. То есть, как только мы настроим аутентификацию по ключам, и если у этих ключей не будет пароля защитного, тогда мы сможем подключаться автоматически, в том числе в скриптах. То есть нам не нужно будет вводить пароль, не нужно будет городить какие-то сложные там механизмы ввода этого пароля, всё будет гораздо проще. Ну и кроме того, считается безопаснее, потому что ключ - это достаточно длинная секретная строка, которую подобрать, ну, по сути, невозможно. Ключ можно украсть, откуда-то его достать, но подобрать ключ - это совершенно не тривиальная задача. Поэтому мы сейчас, собственно, это настроим, и вы увидите, что у нас подключение станет как раз более простым и в чём-то более безопасным. А так там вопрос: ключи RSA? Ключи бывают разные. Какой тип вы захотите, такое и получится. А, ну давайте это сделаем. Сейчас мы берём две машины. Вот у меня одна. Давайте мы туда вернёмся. Пусть это будет у нас, ну, например, пусть это будет клиент. А сервером будет выступать вот эта машина. Это виртуалка с IP-адресом 119. Вот. Давайте посмотрим, есть ли здесь чего-нибудь про SSH. Ну, здесь есть файл authorized_keys, но он пока пустой. Вот здесь длина ноль, поэтому достаточно нормально для нас подойдёт.

Так вот, а какой алгоритм ключа самонадёжный? Денис, ну на самом деле вы здесь можете не переживать. Те, которые стандартно используются сегодня, они все условно надёжные. И здесь суть не в том, какой тип, а какая длина для каждого типа считается сейчас на данный момент безопасной. То есть вы можете взять RSA более-менее такой старый формат, но просто сделать больше длину ключа, и он будет тоже вполне безопасным. Допустим, 4096 бит это будет более чем безопасно с запасом. А можно и Ed25519 использовать тоже. Там просто будет гораздо меньше длина ключа, потому что там другая, другой тип криптографии. То есть здесь важно не только алгоритм, а плюс ещё и длина ключа. Ну, используйте рекомендуемые, не переживайте по этому поводу. Поверьте, вас ломать будут не по стойкости криптографии ваш сервер. Есть гораздо более простые пути. Так. Так, Дмитрий, всё, я не успеваю просто отвечать. А есть ли ограничение транзитное подключения внутри открыто и подключать к следующему? А, да, есть такая настройка, она, ээ, есть такое ограничение, что можно, это называется форвардинг, вот его можно в настройках SSH запрещать, если нужно. То есть ключевое слово форвардинг - всякого типа. Ну, мы в настройках, наверное, увидим что-то поэтому.

Так вот, а что нам нужно? Вот наша Debian система, это будет наш клиент. И что здесь важно? А мы берём именно того пользователя, который будет подключаться. Если мы от пользователя DB подключаемся, значит, мы работаем в нём. Если мы хотим подключаться от пользователя root, то мы должны перейти в пользователя root и от него создавать эти ключи. Ну, например, sudo меня переключит в пользователя root. И, соответственно, теперь у меня есть другая домашняя директория. И там есть только known_hosts и authorized_keys пустой. То есть здесь ключей пока нет. Ну, допустим, а что мы решили подключаться от пользователя root к пользователю DB на удалённой машине. Вот я являюсь рутом. Почему от рута? Ну, потому что обычно, например, регулярные задачи, какие-то там бэкапы или что-нибудь ещё происходит от пользователя root такое общее системное. М. Так, там спрашивал? Ну нет, конечно, такого не будет. Ну и, собственно, не очень понятно про какую именно атаку man-in-the-middle вы имеете в виду и как вы её собираетесь реализовывать. При нормальных настройках ээ она не должна быть возможна, в принципе. Ну, максимум, что это вот если вам подставят другой IP-адрес, да, то есть прикинуться, ну тогда у вас будет, а, просто ошибка, проверка ключей хоста. ключа хоста, потому что known_hosts у вас, собственно, будет записан, что ваш тот хост имеет такой-то ключ. Если это первое подключение, ну, в идеале вы должны, конечно, сверять эти ключи, но вообще это не самая такая реалистичная штука.

Так вот, собственно, что мы здесь имеем? Вот пользователь root, а, у него пока нет ключей. И, ээ, давайте начнём с

генерации ключа. То есть мы говорим SSH-GEN. SSH-KGEN, если мы не укажем тип, то будет тип RSA. То есть у меня сейчас две Linux системы. Вот эта система, кстати, у бунта 22, а на которую мы подключаемся, это будет у бунту 24. То есть это, ну, более-менее актуальные LTS-версии у бунты. Ну, давайте для разнообразия укажем тип более модный, а, потому что у него будут более короткие ключи. Выглядит это всё приятно. Ну и в целом они должны работать пободрее. А, ED2519. И дальше, собственно, нам больше ничего не требуется. Можем указать дополнительные параметры типа там длины ключа, всяких там названий, но оставим всё по дефолту. А вот нам предлагают создать вот такой ключ. А это будет секретная часть, собственно, куда мы его сохраняем. Дальше мы можем защитить этот ключ паролем. Ну, вы скажете: "Зачем нам? Мы же делаем ключ. Здесь ещё получается пароль". Так вот, пароль нужен для того, чтобы не хранить вот этот закрытый ключ в открытом виде. То есть, чтобы его ещё закрыть шифрованием с определённым ключом. Это на случай, если у вас кто-то его похитит, и он не сможет его напрямую им пользоваться. Но если мы поставим сейчас пароль, тогда мы теряем фичу подключения без пароля в наших скриптах. Поэтому мы оставим пустую вот эту pass phrase, то есть пароль ключу мы не ставим. А так тоже можно. И вот секретный ключ здесь, открытый ключ здесь. У открытых ключей обычное расширение .pub, их легко найти. Ну что там в этом ключе? Да просто вот такая строчка. Сначала указан тип, потом есть, собственно, сам ключ. Это произвольные произвольная строчка определённая в своём формате и комментарии. То есть это пользователь root на хосте DE. Так вот, Денис пишет: "Я слышал, что отключает доступ рута по SSH". А, ну, на самом деле, в Убунте он по умолчанию и так отключен. То есть, если вы его не включите, он у вас по умолчанию всегда отключен. А для того, чтобы переходить в суперпользователя, как Александр написал, м, да, используется sudo, но это не значит, что вы не можете открыть доступ по ключам к руту. Вполне можете без проблем. Но мы сейчас делаем не это. Мы сейчас делаем как раз обратную ситуацию. То есть у нас пользователь root подключается к обычному пользователю на другой машине. То есть мы здесь root не открываем, мы наоборот отсюда будем подключаться в другую машину.

Теперь нам нужно как-то этот ключ туда доставить. Самое удобное - это SSH Copy ID. Такая команда в винде. Она тоже вроде как появилась. И дальше мы говорим куда. То есть мы говорим DB. И дальше вставляем айпишник вот этой машины 119. А что сейчас будет происходить? Мы подключаемся к удалённой машине. Он нашёл, что у нас есть наш ключ. У нас может быть, кстати, множество ключей, но вот этот стандартный путь, что с ним удобно? Его не нужно будет отдельно указывать. То есть он и так его будет использовать в списке поисков. Каких ключей он будет найти там для подключения? Вот. И он говорит, что как раз вот что у нас есть fingerprint ключа. Это тот ключ, который на удалённом сервере. И как раз происходит то, что я вам говорил. То есть мы, э, должны довериться ему сейчас или подождать, там проверить то, что ключ именно тот, что система та, которую мы ожидаем там. То есть вот этот элемент доверия, добавления сейчас систему в список hosts происходит. Если мы согласны, мы говорим yes. И, э, после этого а нам говорят, что мы сейчас попытаемся скопировать вот этот ключ туда. И чтобы это сделать, мы должны залогиниться по SSH, то есть ввести пароль. Мы вводим пароль, и наш ключ добавлен. И нам говорят: "Всё, теперь можете подключаться вот такой командой без ввода пароль". То есть, э, наша задача завершена.

Андрей пишет: "Из чего получается fingerprint?" А fingerprint, ну, насколько я понимаю, из того же ключа, то есть это просто некий хэш его, э, значение. Вот и всё. Может быть, секретной части, но это надо посмотреть. Ну, fingerprint - это хэш-функция. SHA256 - это одна из хэш-функций. Соответственно, по нему вы можете однозначно определить э принадлежность системы, вот которую которая вам нужна. Если он не совпадает, значит идём дальше. Так, но а там был вопрос, а что делать, если нет? Где-то был вопрос, да, как передать публичный ключ, если есть запрет на авторизацию по паролю. То есть мы сейчас использовали пароль. А действительно, если мы не можем зайти по паролю, что нам делать? А в этом случае мы можем напрямую, ну, имеется в виду, что у нас и нет на этой машине нет ключа, да, пока что, который даёт доступ, а мы можем взять и напрямую просто вписать нам требуемый вот этот ключ. Смотрим, что произошло на этой стороне. Эта сторона у бунту 24, то есть куда мы сейчас целимся подключиться. Идём в SSH пользователя DB, именно DB. И мы видим, что authorized_keys теперь не пустой, он 90 байт. Что там написано? А там ничего особенного как раз просто-напросто содержимого нашего публичного ключа. То есть ровно то, что было в нашем файле. Хотите добавить вручную, открываете этот файл и добавляете ещё одну строчку с любым ключом. То есть ключи добавляются, удаляются элементарно. Это строчки в этом файле. Никаких тут спецформатов, каких-то мудрёных вариантов не требуется. Так. Угу. Вот спрашивает, сколько строк добавляется в known_hosts при подключении. А known_hosts должна добавляться одна. Ну, насколько я знаю, при обычном хосте, потому что если у вас будет конфликт, то вам тоже вас попросят удалить одну строчку. По такой логике она будет одна. Так, в дефолтном pub-файле может быть несколько ключей. В одном pub-файле несколько ключей, но я такого не видел. Обычно pub-файл - это как раз один ключ. Ну, туда несколько ключей добавлять не очень понятно зачем. Так, можно ли задать ключ самостоятельно, чтобы он не генерился? Ну, если у вас уже есть ключ, конечно, можно. Почему нет? Ну, в чём смысл вот этого ключа? В том, что у нас есть директория .ssh, и он у нас здесь теперь находится. Вот его секретная часть, вот его публичная. А так как он имеет стандартное название, он будет использоваться по умолчанию при подключении. Это удобно. То есть его не надо будет указывать, он автоматом будет по умолчанию использоваться. Вот если вы имеете какой-то отдельный ключ свой, да, пожалуйста, конечно, можно параметром указать, какой нам нужен. Мы просто сейчас идём самым простым путём.

Так вот, а нам обещали, что мы теперь можем подключиться к удалённой машине без пароля. Ну давайте проверим. Делаем SSH DB. Вот это 119 айпишник. Всё, мы попали на эту машину. Как видите, название хоста поменялось. Ровно тот пользователь DB, который нам нужен. То есть, да, всё, всё логично, всё нормально. Выйти теперь отсюда можно. Команда exit. Закрывается SSH сессия. Мы возвращаемся в свою изначальную сессию на хосте DEП. Так, я сталкивался с тем, что при добавлении ключа вручную не работал. А мы сейчас про это, Андрей, поговорим. Почему он может не работать? Так. А где указывать сейчас будет? Мы сейчас наберём команду для подключения по SSH. Так, чтобы на несколько хостов логиниться с одним и тем же ключом. Так, мы можем с этим ключом логиниться на бесконечное количество хостов. То есть с этим ключом теперь главное просто его везде прописать на всех хостах, и он будет у нас одним на все хосты. Ноль проблем. Так, в дефолтном pub-файле может быть несколько ключей. Ну, я про это уже говорил. Так вот, а, а это вы имеете в виду, что за этим? Не, нет, так не надо делать. Как указать конкретный ключ для подключения, мы сейчас поговорим. Это, собственно, параметр -i. Ну, давайте сейчас посмотрим команды. С этим мы разобрались. А у нас, собственно, схема передачи ключа. Либо автоматически команды удобной, либо вручную при создании файла. Но а, собственно, что здесь может пойти не так? Ну, давайте сейчас посмотрим. Во-первых, вот эта директория .ssh, это не просто директория какая-то произвольная, а у неё крайне серьёзные требования. В чём заключается подвох? Как видите, у неё права в восьмеричной форме называется 700. А это значит, что чтение, запись, исполнение доступно только владельцу. Во-первых, она принадлежит мне и моей группе, как пользователю DB. Во-вторых, права 700. Если вы нарушите эти права, то есть сделаете более открытые права, то, э, здесь авторизация по ключам работать не будет. Это первая проблема. Почему у вас может не сработать? Следующее. Если права на authorized_keys у вас тоже шире, чем 600, то есть чтение, запись для владельца, он тоже работать не будет. А, поэтому вы можете взять себе какую-нибудь референсную систему, где вот эта директория и вот этот файл созданы автоматически через ssh-copy-id. Вот сейчас мы руками ничего не делали, и система для вас всё сделает корректно. Если вы будете делать руками, то, естественно, права будут другие. Вам нужно будет их назначать вручную, ровно такие, как здесь показано. Нарушаете владельцев и права. у вас SSH автоматически откажется использовать вот этот кейс. Это к вопросу, что кто-то у нас Андрей добавлял ручками ключ и он не работал. Скорее всего, из-за прав. Поэтому права критически важны вот здесь и для директории, и для файла, для всего, что там есть. Так что первое, куда мы смотрим - это на директорию .ssh, на права доступа. Вот. Если забыли какие, не страшно. Возьмите гарантированно рабочую систему и просто сверьтесь. Просто помните в голове, что права критически важны. Аа, ну а внутри файла, как я говорил, там сложно ошибиться. Одна строчка, один ключ. Собственно, как есть, вот в таком виде и копируете. Главное, не разбивайте её на строчки. То есть она должна быть всегда одной длинной строчкой. Это первое, что может пойти не так. А другое, это касается конфигурации. Ну, например, у вас может быть запрещена аутентификация по ключам и в настройках. Такое тоже может быть. И тогда вот тоже вы будете долго-долго отлаживать и не понимать, что происходит. Но до настройки мы дойдём, и я, наверное, вам тоже эту настройку покажу. В Убунте так случилось, что по умолчанию аутентификация по ключам разрешена. Ну, это разумные настройки, поэтому они так сделаны. Но в любой другой системе кто-то может специально это запретить. Вот, может быть, вы пытаетесь подключиться к пользователю, который тоже не имеет, допустим, оболочки, и вы не можете залогиниться из-за этого. То есть причин проблем со подключением может быть большое количество. Они выглядят по-разному, поэтому, в общем, это можно там сверять и проверять.

Ну давайте подумаем. Если у нас подключение не происходит, что мы будем делать? То есть есть какая-то ошибка. Мы сейчас не понимаем причины, просто нет подключения. А первое, что мы можем сделать - это вызвать команду SSH с опциями -v. -v - это verbose, то есть это отладка, работа с ошибками и, соответственно, сделать э то же самое, там 192.168.122.119. То есть мы говорим: "Подключись и включи разговорчивый режим". А у нас здесь всё прошло успешно. Ну, давайте я вам отмотаю назад, покажу, что здесь нам говорят. Вот. А говорят нам много всего. Во-первых, мы видим приветствие сервера, а нам дают библиотеки и версию OpenSSH. Почему это важно? Дело в том, что в разных поколениях OpenSSH а бывают разные настройки. Допустим, если у вас супердревняя система и новая клиентская система, они могут не договориться по протоколам шифрования, например, а вам придётся добавлять дополнительные настройки, чтобы вас пускало на эту древнюю систему. То есть, а, поэтому, если будете гуглить, то вы можете вбивать дополнительную версию OpenSSH сервера и версию клиента тоже. Вот эта libssl библиотека, она тоже отвечает за шифрование, поэтому она тоже может влиять на поддержку протоколов, тех же ключей и всё остальное. А дальше нам говорят, что вот мы читаем config клиентский, вот этот вот нашли какую-то настройку, ищем там файлы, а дальше подключаемся к айпишнику такому-то. на порт 22 установлено соединение на уровне TCP. То есть, да, у нас получилось. Если мы этого не получаем, значит, какая-то сетевая проблема. Может быть, Firewall state какой-нибудь, может, там просто недоступен сервер, там, всякое бывает. Вот. И мы начинаем здесь искать ключи. То есть помните, что мы сейчас пытаемся по ключам э подключиться. И вот эти ключи - это стандартные имена ключей, которые у нас могут быть. И вот здесь, видите, у многих идёт проверка, видите, по умолчанию, и у них стоит -1, то есть их нет. А вот этот ключ нам сказали тройка, то есть что-то отличное. И мы знаем, что этот ключ у нас есть. То есть мы попробовали, нашли какой-то ключ. Вот. Потом нам говорят, что вот у нас локально, наша локальная строчка там клиента будет вот такая. Используем версию 2.0. Ну, это тоже стандарт, нормально. И дальше вот есть какой-то compatibility banner. Это как раз согласование протоколов с двух сторон, потому что мы сейчас будем шифровать данные. Нам нужно договориться о каких-то общих стандартах. И вот мы пытаемся аутентифицироваться на этом хосте как пользователь DB. Вот посмотрели known_hosts. Ну, это, видимо, тоже для каких-то кастомных ключей. Идёт обмен туда-сюда и так далее. Вот у нас начинается использоваться ключ SSH ED2519, его тип. А, идут всякого рода настройки, там вот эти все подробности и так далее, и так далее, и так далее. Вот. И мы дошли до проверки known_hosts. Вот. То есть написано, что мы нашли ключ от этой системы, э, поняли, что всё в порядке, то есть нет никакого предупреждения, мы уже были здесь, всё нормально. А вот и дальше идём проверять ключи, которые у нас могут быть локально. Нашли вот этот ключ вот с таким fingerprint, то есть с отпечатком. Поехали. Дальше мы обмениваемся вот этими информацией о ключах. Опять проверяем приватный ключ. А нашли ED25519. И всё. Вот на этой строчке нам сказали, что мы успешно аутентифицировались там.

Так, Алекс спрашивает: "Серт - это какой-то сертификат?" Ну да, Серт - это сертификат. Это, скорее всего, сертификат со стороны сервера. То есть он себя тоже как-то представляет. А, ну и, собственно, дальше это такие второстепенные уже сообщения, что вот мы начинаем подключаться, обмениваться данными, в конце концов выставляем какие-то переменные окружения. Вот с этого момента мы уже подключились к оболочке. Вот это тот самый баннер, про который спрашивали, да, приветственный. В данном случае нам выдаёт вот эту информацию про обновление и так далее. То есть, если у вас будет проблема, то вы на каком-то моменте увидите ошибку. Может быть, она будет не на последней строчке, а чуть-чуть раньше. То есть идём от конца вверх и ищем проблему. Ошибка непонятная, ничего страшного. Начинаем гуглить её, можно её забивать в какой-нибудь там чат. А, то есть собираете исходные данные. То есть, допустим, я пытаюсь подключиться по SSH и ошибка такая-то. Ну, с вероятностью 90% вы очень быстро найдёте причину. Как я говорил, это может быть несовместимость, это может быть там какие-нибудь права доступа или ещё чего-нибудь. Если вы здесь не увидите своего ключа, например, то это тоже повод задуматься, почему он не предлагает вот этот ключ, почему он его не находит и так далее. Так, а, ну вот, собственно, это был вопрос про отладку -v. Ээ, если вам недостаточно одного -v, можете сделать два или три -v, но, скорее всего, это уже будет слишком подробно. А так что, если что, мы к этой отладке тоже будем возвращаться. Давайте оставим как есть. Так, а сертификат SSL нет, Алекс, там нет SSL как такового там. Но вообще аутентификация по ключам - это асимметричное шифрование, которое внутри сходно к процессу установления SSL-соединения, но всё-таки это не то же самое. То есть там нет ээ тех же самых принципов, как в SSL. Здесь мы немного по-другому работаем, но криптография примерно та же. То есть логика такая, что на этапе аутентификации, когда мы себя определяем как пользователя, у нас происходит асимметричное шифрование. То есть у нас есть вот этот публичный ключ, секретный ключ. То есть у нас всегда два разных типа ключа. А потом, когда мы установили соединение, то дальше идёт симметричное шифрование. Точно так же, кстати, как и HTTPS, когда вы ходите по сайтам. Сначала асимметричное шифрование для аутентификации, а потом уже поехали на симметричном шифровании, потому что симметричное шифрование на порядок быстрее, и весь основной трафик шифруется симметричным ключом. Вот. Но здесь переживать не стоит. У вас ключ генерируется вот в этой в этом процессе. То есть, когда вы начинаете подключаться, вы сервером выбираете друг с другом единый секретный ключ, и ваша сессия им шифруется каждый раз с другим ключом.

Так, а есть вообще аутентификация типа с использованием стороннего доверенного сервера? Стороннего доверенного, но в HTTPS там не сторонний доверенный только центр аутентификации, но, наверное, можно, да, но не не в стандартном режиме, не не в таком, который мы сейчас рассматриваем. Через какого-то посредника есть такое понятие, как Bastion hosts, то есть это определённый хост, который находится между сервером и клиентами. То есть у вас есть, э, бастион, а здесь ваша инфраструктура, у вас тут куча серверов, а, внутри. И, соответственно, все, а, клиенты они приходят через Бастион, и он уже определяет, кому куда можно, а при этом логируя ещё по попутно все ваши действия. И только через этот хост вы можете попасть на сервера, которые у вас есть. И там, собственно, в этой машинке, в этой коробочке можете реализовать любые там хитрые схемы, управление доступом и так далее. Или ещё его называть jump host иногда, то есть через который вы подключаетесь и закрываете доступ. Мм, так это оба по алгоритмам с открытым ключом. М, не, не, не понял насчёт это оба. Так, расскажите про обратный тоннель. Как его вызвать, использовать. А будет у нас сейчас про это дело поговорим. Так вот, а давайте конфиг посмотрим. А и собственно config у нас делится на две части. То есть у нас есть SSH-клиент и SSH-сервер. Сервер классический в Linux обозначается буковкой D от слова Demon. То есть SSHD - это сервер, SSH просто - это клиент. Ну, иногда, конечно, мы просто говорим про SSH, да, как в целом про систему, но конкретно sshd_config означает, естественно, конфиг сервера, поэтому, собственно, он этим и будем. Так вот, Дмитрий спрашивает про альтернативы SSH. Они не очень понятно, что значит современные. А SSH считается для вас несовременным или чем он вам не нравится? Да, собственно, он вполне себе современный. Поче почему бы нет? Так вот, собственно, что мы здесь найдём в конфиге? Найдём конфиг сервера. Можно подключать файлы из вот этой директории /etc/ssh/sshd_config.d/. Обычно так делается в Linux для директории с какими-то маленькими кусочками конфигов, которые пишет сам администратор. То есть это системное у нас и так есть по умолчанию, а мы ещё дописываем вот в эти файлики. То есть, в принципе, это нормальная практика, но если вам лень, открывайте стандартный конфиг и его можете поправить. А 22 порт - это порт для сокета, тот самый стандартный. Его можно менять без проблем. Listen address - это IP-адреса для этого сокета. Вообще сокет - это соотношение IP-адрес плюс порт. Ну, ещё можно добавить протокол. То есть, например, мы говорим, что у нас Socket - это все IPv4 адреса и TCP порт 22. Это будет для, например, SSHD. И, э, если мы определяем address и port, то в сумме мы получаем, э, как раз сокет. Ну, сам протокол по умолчанию TCP без вариантов здесь. А дальше мы можем, а, как раз разрешить логин root отдельной настройкой. PermitRootLogin. И в том числе, э, вот такой параметр, когда мы запрещаем логиниться по паролю, это будет, э, возможность подключения только по ключам, ну или по каким-то там другим факторам, но не с помощью обычного пароля. Ну, вообще, как я говорил, в Убунте у нас и так у root по умолчанию пароля нет, поэтому по паролю подключиться и не получится. Но в других системах, если у вас есть всё-таки root пароль, то можно сделать вот так. А можно ограничить количество попыток входа MaxAuthTries. И это нужно, чтобы когда вы смотрите в интернет, когда у вас есть публично доступный порт, чтобы вас не, ну, не слишком жёстко долбили подборами паролей. Это не сильно поможет, но ограничить это можно, чтобы хотя бы был какой-то лимит. А PasswordAuthentication - это, собственно, возможность зайти по паролю. Если мы это отключим, то это будет недоступно. А дальше у нас есть ещё способ доступа по SSH для файлов. Это называется SFTP. И вот здесь есть вот такая строчка Subsystem sftp. Дальше идёт путь к SFTP-серверу и LINFO. Вот этот LINFO - это как раз включение логирования всех событий, потому что по умолчанию SFTP у вас будет работать, и при этом у вас не будет никаких логов. То есть у вас кто-то подключается к вам, начинает общаться с вашей файловой системой, но логов при этом не будет, как мы привыкли, например, у FTP, там какие-то логи. Так вот, чтобы с FTP включить логирование, запомните вот этот параметр. Тогда у вас будет хотя бы в системном логе об этом сообщения. Ну и дальше есть ещё возможность ограничить список пользователей. То есть помимо вообще всех пользователей, которые у нас есть в системе, которым можно логиниться, мы можем конкретно по SSH выбрать другой более узкий круг, к которым можно подключаться именно по SSH. И, собственно, здесь указать список юзернеймов через пробел просто там, допустим, Вася, Петя, там DB, root и так далее. А так, давайте почитаю чат, там что-то идёт активное обсуждение. Так, ага. Так. Есть, ээ, реализация DGN. Ага, это про SSH. Ну, SSH-серверов существует несколько. У нас стандартный OpenSSH, но есть и другие, да, но это ничего не меняет. Протокол тот же самый. Так, а поверх SSH можно IPsec прикрутить. А так, если двухфакторка для SSH есть, так же как и для всего остального, всё это можно настроить. Ну, э, это вопрос немножко продвинутый. Если кратко отвечать, там есть PAM. А в PAM есть всё, что угодно. Вы можете через PAM аутентифицироваться в SSH, а в PAM настраиваете аутентификацию вообще как угодно. Там хотите двухфакторку, трёхфакторку, там не вопрос. Так что делать, если MaxAuthTries закончилась и подключиться ты сам не сможешь? А, насколько я помню, там есть определённый тайм-аут. То есть это просто ограничение в рамках одной сессии. То есть вот вы установили соединение и начинаете вводить пароль. Ввели один раз, второй раз, третий, четвёртый, пятый, шестой, получили ошибку и вас отключают. Потом вы заново подключаетесь, можете заново заходить. Так что там ничего страшного не произойдёт. Но с другой стороны это и особой защиты вам не даст. Так. А, ага, вот там пошли плагины PAM. Ну да, да, там можно всё это подключить. А как прописать подключение с российских IP? Ну, ээ, смотрите, в принципе, вы можете элементарно подключение SSH ограничивать с помощью файрвола, но для этого вам нужны списки российских IP, а это вопрос не самый тривиальный, то есть что считать российскими IP, что вы туда будете включать, из какой GeoIP базы их будете брать и так далее. А так самое логичное - это firewall, да, туда прописать нужные подсети и вот оттуда вы будете подключаться. Ну это довольно сомнительная мера. Вряд ли стоит это делать, потому что в GeoIP базе куча ошибок. Если вдруг какой-нибудь ваш там пограничный провайдер признается нероссийским или наоборот какой-нибудь иностранный станет российским, то это ваша защита уже не работает. Так, в чём отличие при использовании SSH сертификатов и как их получать? А, Дмитрий, я не понял, про какие SSH сертификаты вы говорите и что значит их получать. Мы никакие сертификаты не использовали. Мы с вами сделали просто пару ключей. Один публичный, второй секретный. Никаких сертификатов мы не делали, не получали и не использовали. А так что, если вы видели какой-то сертификат, это автоматический сгенерированный сертификат на стороне сервера. Вот и всё. Да. Так что пытаться вот такими методами типа российская IP, но это сомнительная тема. Если вас волнует защита от перебора паролей, её можно решить не очень сложно другим методом. Так, а давайте зайдём в конфиге, посмотрим, что там написано. Что я вам обещал показать? Вот давайте посмотрим. А в /etc/ssh находится конфиг. Ну, опять же, самое главное, не путайте настройки клиента и настройки сервера. Настройки сервера находятся вот здесь. Так, Дмитрий пишет: "SSH ключи подписаны УЦ, SSH сертификаты". А, Дмитрий, ну я не знаю, что у вас за SSH ключи. Я с такими не работал. Если они вообще существуют такие, да, для TLS, естественно, они есть. А вот для SSH, э, что это за ключи, не очень понял. >> Нет, ну в теории я могу представить, но скорее всего вы здесь имеете в виду Mutual TLS, то есть когда у вас браузер подключается к сайту на

основе сертификата. Вот эта тема более-менее непонятна, но она к ССШ не относится никак. Ну или мы просто о разных вещах говорим.

Так вот, а у нас всего в конфиге есть настройки демона, как я говорил, директория, куда можно положить маленькие файлики с расширением `conf`. Ну давайте сразу в `config` сервера пойдём. `SSHD config`, потому что есть ещё `SSH config` – это клиент.

Так вот, зашли. И здесь можно увидеть, во-первых, `include`, это стандартная для `Linux` директива, которая подключает всё, что там написано. Звёздочка – это `Wildcard`-подстановка такая, которая найдёт все файлики с расширением `conf`.

Вот как раз настройка порта. И если вдруг вы хотите скрыть ваш сервер, вы можете поменять порт. Ну, например, поставить какой-нибудь порт, который стандартно не будет подходить под сканирование из высокого диапазона, допустим, 35002.

А, в общем, это, конечно, так себе мера безопасности, но на самом деле на практике это резко сократит количество сканирования и подбора паролей для вашего ССШ. То есть, естественно, мы можем отсканировать этот порт, но этим нужно будет заниматься специально. То есть вы должны будете стать реальной целью для атаки. Тогда этот порт найдут, и тогда вас будут долбить туда подборами паролей.

Вот. Но если вы просто находитесь в диком интернете, то есть вы всего лишь один из каких-то там маленьких серверов с сайтами, скорее всего, такой целевой атаки на вас не будет, поэтому это будет уже определённая мера защиты от излишнего внимания.

Из минусов: вам при подключении придётся указывать этот порт во всех местах. Это может быть не совсем комфортно.

А, и, ну, ещё, конечно же, всякие файрволы могут быть. Ну, в общем, это не самое удобное, но это мера такая немножко сокращения видимости того, что у вас есть `SSH`. Потому что `SSH` с двадцать вторым портом – это красная тряпка для всех ботов, которые сканируют.

То есть представьте: вы запустите сервер, в течение первых нескольких минут, как только он у вас запустился, у него будет просканирован двадцать второй порт, на вас сразу же через эти же пару минут начнут долбиться боты и подбирать пароли. Не дай бог, если у вас будет простой логин и пароль для этого сервера. То есть этот сервер уже будет не ваш буквально через пару минут.

Поэтому, а, аккуратно вот с паролями и с доступом, если у вас есть публичный сервер в интернете. Это очень опасно.

А так как подключаться? Да, совершенно верно, Сергей пишет `p` в нижнем регистре, да, мы можем его указать в команде `SSH`.

Так вот, а что здесь? Мм, ещё так. Дмитрий, э, настаивает на `SSL`-сертификатах. Ну, э, мы сейчас не будем гуглить, давайте, а то наши темы просмотреть не успеем сейчас.

Так вот, а когда подключение по ключу? Пароль отключён. Брутфорс возможен. А, смотрите, что значит возможен. А вам никто не запретит попытки. То есть попытки будут, просто они не смогут залогиниться по ключу, но сами попытки будут происходить, у вас будут заполняться логи.

То есть он невозможен в плане успеха, но сами попытки будут происходить точно так же. То есть, понимаете, да, вам будут пытаться подключаться, все они будут неуспешные, но всё равно сам факт этих попыток вам тоже неприятен, потому что у вас постоянно запускаются `sshd`-демоны, вы тратите на это какие-то ресурсы, и хотелось бы как-то от этого избавиться, скорее всего.

Так, а можно указать несколько портов сразу? Алекс: нет. А зачем? Смотрите, здесь у вас есть возможность указать разные семейства. То есть вы можете слушать, например, на `IPv4` и на `IPv6`. То есть у вас получается два сокета на `IPv4`, `IPv6`, но порт у вас один. Зачем вам несколько портов? Не очень понятно. Это уже как-то многовато получается.

Так, а, угу. Нашли и сканируют с нестандартным портом. Может быть, да, но, скорее всего, будут меньше всё-таки сканировать. Ну и, может быть, вы действительно являетесь какой-то суперценной целью, что на вас запустили сканирование всех портов. Потому что стандартное сканирование, оно будет всё-таки по стандартным портам. Это гораздо быстрее. То есть не перебирать 65 тысяч портов, а просканировать там, ну, сколько, 100 тысяч портов, это гораздо быстрее.

Угу. Так, вот кто-то ловил уже майнера. Так. Так. У `SSHD` порядок важен? Каким по счёту параметром надо указать порт? А, Денис, нет, обычно не важно. Если у вас есть настройки, то, в общем, главное, чтобы она здесь была. Какой-то здесь порядок не так уж и важен.

В общем, с `ListenAddress`, если вы, например, хотите поменять его, вы можете написать, что вы будете слушать, допустим, только `192.168.100.2:180`. И это ограничит сокет. То есть, э, если у нас по умолчанию все `IPv4`-адреса, то это будет только один.

Например, у вас есть интерфейс, который смотрит в интернет, и вторая ваша локальная управленческая сеть. И вы можете повесить его только на внутреннем интерфейсе. И таким образом сразу отсекаете потенциальную возможность подключения из интернета. То есть вы изнутри своей инфраструктуры через какие-то там безопасные пути подключаетесь. А вот извне уже это будет невозможно.

Вот. Ну я про сокеты ещё вам покажу, как это проверить. Какие сокеты вы сейчас слушаете. Вот. Ну по умолчанию пусть будет так вот.

`AddressFamily` – это, собственно говоря, `IPv4`, `IPv6`. То есть здесь можно включить вот так, и тогда будет всё. Кстати, многие вот из вот этих параметров, видите, они были закомментированы. И вот эти значения, которые указаны, – это значения по умолчанию. То есть они и так уже настроены.

Вот это настройки как раз тех самых хост-ключей, про которые мы видели, вот эти отпечатки при подключении. А что ещё полезного? Настройки логирования можно поменять, куда и как мы будем логировать.

И вот как раз безопасность. То есть `LoginGraceTime` – это сколько вы даёте на одну сессию подключения времени, 2 минуты. То есть не успеваете ввести в это время правильный логин-пароль, вас отключает.

А, собственно, `PermitRootLogin` с запретом пароля. А дальше `MaxAuthTries` и `MaxSessions` – это сколько всего параллельно будет запускаться `SSH`-сессий. Это важно для защиты от `DoS`-атак, чтобы вас не пооткрывали миллион сессий параллельных, чтобы как-то это держать в рамках, потому что это тоже будет потребление ресурсов.

Вот как раз разрешение публичной аутентификации по ключам. А, как видите, она закомментирована, но работает. Ну, поверьте, что это дефолтный конфиг, да, там она тоже закомментирована, куда мы подключались. Так что отдельно можно не подключать.

Вот можно отдельно определить, какие файлы являются `keys`. Ну, вообще по классике это `keys` просто и с двоечкой. То есть вы можете два таких файла использовать, но находятся они в точке `.ssh`. Опять же, можно поменять.

Что ещё из интересного здесь есть? А всякие другие типы, допустим, вот `PasswordAuthentication`, можно `PermitEmptyPasswords`, там запретить пустые пароли, а всякие `Kerberos` там варианты аутентификации, `GSSAPI`, а `PAM` – это та самая расширяемая система аутентификации, то есть всякие хитрости, а, типа двухфакторки, каких-то там хитрых вариантов. Вот всё здесь вам надо изучать, а как работает `PAM`.

Вот эта возможность как раз проброса графики `X11Forwarding`. А и был вопрос насчёт сквозных подключений, можно ли это разрешать? А вот, например, `PermitTunnel`, но это туннели, да? И где-то здесь был форвардинг. Это `X11`, да, обычный. `AllowTcpForwarding`, `AllowAgentForwarding`, вот что-то из этого. Посмотрите, пожалуйста, описание вот этих настроечек. И тогда можете явным образом это отключить.

Ну, это к вопросу, чтобы не было там сквозных подключений, потому что, да, это тоже определённая опасность. А можно `TCP` отдельно подключать, а всякую настраивать компрессию, а `DNS` при подключении разрешать, но это всё так дополнительно, чтобы при подключении вы оказывались в какой-то конкретной директории и так далее.

И вот как раз `SFTP`, помните, я говорил про логирование. И вот здесь как раз логирование отключено, то есть здесь ничего нет. Так. Так. Там идёт. Ага. Тут идёт про `SSH`-сертификаты. Угу. Так, понятно, да? Ну, это, видимо, какой-то ещё один способ подключения.

Так, а есть забавный `port knocking` – постучать в определённом порядке? А, Сергей, да, есть, но это скорее тоже такой хак. То есть это не так, чтобы прямо легитимный способ защиты. Ну есть, да, `port knocking` – это скрытие порта.

Так, основная проблема `SSH` – ротация ключей. Забытые ключи, `SSH`-сертификаты позволяют решать проблемы. Ну, возможно, да, есть внешняя система, вы её туда подключаете, но я с этим не работал, поэтому здесь вам ничего не скажу.

Так, если делать, чтобы сервер не пинговался, это повысит защиту? А, да, не особо. Ну какой в этом смысл? Но он не пингуется, он отвечает по остальным портам, по там восьмидесятому, 443-му, 22-му, а если он не пингуется, вы сами не сможете его пропинговать. То есть вы себе сокращаете возможность диагностики. Зачем делать, не очень понятно.

Так, маски можно в `ListenAddress` задавать и диапазоны? Валерий, ну вот, наверное, можно, надо почитать доки, но по крайней мере можно указать вот универсально – это вот эти вот нули. Также явно можно указать айпишник насчёт масок. Не уверен, надо смотреть доку.

Так, 16 дополнительный и так далее. Ну давайте сейчас я покажу, где это отображается. Мы сейчас про сокет тоже поговорим. Вот с `SFTP` дошли, и вот `PasswordAuthentication` отдельно здесь включён.

Так, хорошо, с настройками разобрались. Теперь как нам проверить, что у нас двадцать второй порт где-то слушается? Ну, это команда `ss -nlp`. Мы можем всё это профильтровать командой `grep` на двадцать второй порт. И вот наша запись. Мы сейчас слушаем все адреса `IPv4` на двадцать втором порту, а также на `IPv6` тоже сокет есть.

А это к вопросу диагностики, если вы не можете по `SSH` подключиться, как вообще определить. Если у вас здесь сокета нет, то мы начинаем смотреть `systemctl status sshd`. И здесь мы ожидаем посмотреть статус нашего сервиса: проверить, что он слушает определённый сокет, но это сообщение лога, и в целом, что он запущен, с ним всё хорошо.

Что ещё здесь важно? А важно, что `SSH` он немножко хитро работает при обновлении конфигурации. Вот, например, если мы поменяем сейчас порт, то в любом другом сервере, допустим, при веб-сервере или в чём-то таком, была бы проблема. Ну, допустим, `30022`. Я сейчас делаю порт, говорю сохранить и делаю страшную вещь. Я говорю `service sshd restart`. То есть я рестартовал сейчас всю службу.

Но что произошло? У меня моя сессия не разорвалась. С ней ничего не произошло. А в чём дело? А дело в том, что наш процесс находится отдельно. Наша сессия, она уже не привязана к демону, не является к нему подчинённой. И поэтому нас спокойно оставили вот здесь, вот мы живём спокойно и работаем.

А вот, но на самом деле, а так кто-то пишет: «Порт не меняется». Почему не меняется? Вот, пожалуйста, порт поменялся. `30022`. Можно сделать `reload`, обновление, но мы сделали `restart`. `Restart` обычно разрывает подключение, но `SSHD` не делает так. Он делает это специально, чтобы мы не потеряли нашу сессию, наше подключение. Мало ли что мы там напортачили, да, не то сделали.

Ну вот следующее подключение уже будет на новый порт `30022`. То есть я как был на двадцать втором порту, так и сижу сейчас. А вот новые будут подключаться уже вот сюда. А поэтому `SSHD` здесь нас немного спасает.

Но это же опасно. То есть вы сделали `restart`, но в этом плане здесь есть опасность. Например, вы не настроили `Firewall`, у вас порт закрыт, и повторно вы подключиться не сможете. Поэтому после таких манипуляций проверяйте отдельно из `SSH`-консоли, не разрывая эту сессию, что вы можете всё ещё подключиться к серверу.

То есть вы можете, например, зайти вот сюда с портом, какой у нас там был? `30022` на вот этот хост `192.168.100.180` и всё успешно подключается. То есть да, всё работает, всё хорошо. Вот если не работает, ну тогда, соответственно, исправляйтесь.

Вот. И более того, я сейчас могу обратно поменять на двадцать второй порт и, собственно, тоже сделать `restart`. И опять же никто не пострадает. Ни моя сессия, ни вот эта параллельная сессия. Всё работает, всё здорово.

Так, `ListenAddress` – это на каких интерфейсах слушать? Причём тут маска? А так у нас нет такого понятия, на каких интерфейсах мы здесь слушаем на адресах. На одном интерфейсе может быть огромное количество адресов, но мы указываем не интерфейс, а именно адрес. Ну, если вам интересно, давайте посмотрим.

А `man sshd_config`, есть там описание этого параметра. А вот, собственно, все наши варианты, что мы можем указать. Можем `hostname` указать, можем адрес, можем `host:port` или `IP-адрес:порт`. Вот, собственно, и всё. То есть это наши локальные адреса, на которых мы будем слушать. И, соответственно, вот в такой форме мы можем это указать.

Вот можно указать несколько директив `ListenAddress`. То есть можем указать списком все сочетания `IP`-адресов с портами или просто адресов, а, которые нам нужны. Ну, получается, что, смотрите, если мы здесь будем указывать `IP+порт`, то мы можем сделать вот, как было в вопросе: «Могу ли я открыть несколько портов?» Получается, что можем. То есть для каждого адреса, допустим, порт. И я так подразумеваю, что отсюда мы можем получить набор вот этих сокетов. Ну, это надо попробовать. Э, на практике это особо не требуется, но вот можете с этим поиграться. То есть вот документация говорит, что можно.

Вот. Но насчёт интерфейсов, там нет такой формы, чтобы показать интерфейс.

Так, а в `sshd_config` вы указываете, на каком адресе будете слушать подключение. Если вы зададите адрес, который не соответствует реальному адресу, просто получите ошибку. Ну, обычно, да, вы не сможете стартануть сервис, потому что он скажет, что тот адрес, который задан, отсутствует у нас, и он к нему привязаться не сможет к этому сокету. То есть, да, он просто не стартанёт, выдаст ошибку. Ну, там есть нюансы, но, скорее всего, именно с ошибкой закончится.

А вот Александр говорит, что нужно сделать копирование настроек. А, да, это логично, особенно если вы первый раз это делаете. Но вообще, по-хорошему, иметь всегда бэкап всех настроек, чтобы он автоматически у вас был, чтобы не думать об этом и каждый раз не делать вот этот бэкап. Но заметка хорошая, да, лучше иметь бэкап.

Так, а что ещё нужно? Настройки мы покрутили. А дальше сейчас проверим, что у нас вернулся порт 22. Да, у нас всё нормально. Пусть он будет в таком виде. А что мы ещё хотели посмотреть? А, ну давайте `screen` и `tmux` посмотрим дополнительно.

А, например, вот у меня есть какая-то программа здесь. Она работает, ну, пусть будет это `top`, неважно, любая программа. И вот мне нужно, чтобы при разрыве соединения или я хочу выключить компьютер, потом вернуться в эту же сессию. А как мне это сделать? Проще всего это запустить `screen`.

Вот. И после запуска `screen`, здесь есть подсказки по определённым горячим клавишам. Вот мы сейчас очутились внутри вот такого вот вложенного дерева процессов. То есть у нас запустился `screen`, и мы теперь можем спокойно разорвать эту сессию. Ну, это может быть сетевое отключение. Главное, не набирайте команду `exit` стандартную. Я просто закрываю окно. То есть я говорю: «Закрыть терминал, всё уничтожить, больше мне не нужна». И дальше, а, я могу, а, допустим, пришёл утром, а, снова включил компьютер, возвращаюсь на этот сервер `192.168.100.180`.

Вот, залогинился. Естественно, у меня новая сессия открылась. И что я вижу? Вот моё дерево процессов. А вот `screen`, который висит вообще где-то отдельно на первом уровне процессов. Вот он. И у него есть оболочка. Соответственно, команда `screen -r` меня должна вернуть вот в этот терминал. Меня не возвращают, потому что там сессия была привязана к пользователю `root`. То есть я ожидаю, что мне надо, скорее всего, стать рутом, и отсюда `screen -r` уже сработал. То есть я только что вернулся, видите, у меня здесь вот где я нахожусь. То есть у меня здесь всё в порядке.

Кстати, старая сессия тоже осталась, видите? То есть она есть, но я сейчас `ps` запустил уже вот в рамках этой сессии. То есть любой софт, который вы здесь запускали, он будет продолжать работать. Для чего это нужно? Ну, как минимум, если вы делаете, например, какие-то обновления, то есть длительная операция, которую не надо прерывать, запустите всегда `screen` и из-под `screen` уже запускаете процесс. Тогда они не будут прерываться гарантированно. То есть у вас там отключился интернет, вы случайно закрыли терминал, неважно, всё продолжает работать, вы в любой момент сюда вернётесь.

Или у вас длительная операция, допустим, копируете там 100 Гб файлов отсюда-сюда, и вы не хотите сидеть и ждать, пока они скопируются, или не хотите, чтобы у вас в это время что-то порвалось. А, собственно, здесь всё это можно делать.

А так Иван спрашивает про знак амперсанда. Ну, в фоне, да, можно увести процесс в фоне, но это будет конкретно для одного нового процесса. Здесь прямо вся сессия. То есть вы запустили `screen` и не думаете. То есть любые команды, вообще всё, что вы делаете, всё сохранится. То есть сессия у вас постоянна.

Так, можно ещё раз показать? А `fg`? Нет, `fg` здесь ни при чём. Э `fg` – это `foreground` – это вывести фоновые задачи как раз про знак амперсанда. То, что Иван спрашивал. Мы сейчас вообще про другое. У нас сессия выводится через `screen`. Это не связано с фоновыми задачами.

А как ещё раз это работает? Ну давайте покажу. А давайте сейчас покажу, как закрыть эту сессию. Она же у нас вечно живущая. То есть при закрытии терминала она не закончится, поэтому я должен из неё выйти, и появится вот такое сообщение: `Screen is terminated`. Вот. И теперь у меня процесс `screen` закончился. То есть у меня есть обычная процедура `SSH`, вот обычная сессия. Вот я в ней нахожусь без всяких `screen`.

А как мне снова сделать `screen`? Просто командой `screen`. Всё, я теперь нахожусь в сессии через `screen`. Вот они. Вот просто разница в том, что вот этот процесс, видите, он не привязан ни к какому псевдотерминалу. У него здесь пустота, поэтому он автоматически переедет на первый уровень, как только я сломаю вот эту сессию `SSH`. То есть он не пропадёт.

Вот обратно. `screen -r`, собственно, как мы делали. То есть, так как это из-под `root`, я захожу в `root`. Ну, сейчас он ничего не скажет, потому что у меня есть сессия `screen`, но она сейчас у нас работает на другой, а, реальной сессии, поэтому я не могу в неё перейти. Вот. Но если я сейчас разорву здесь подключение, опять закрою терминал, то мне предложат в неё вернуться. Вот я снова в неё вернулся.

Так, Кирилл пишет про маску. А, ну да, в документации нам говорили про адрес. Там ничего про маски не было, поэтому да, ставим адрес.

Так, я не понимаю, при чём тут маска, если речь про конкретный адрес, на котором слушать? А, да. про конкретный адрес, но адрес `0.0.0.0` – это не конкретный адрес, это указание любых `IPv4`-адресов. То есть вам в этом смысле, скорее всего, в чате писали, что это маска, но это не маска в смысле маски подсети `/24`, это, условно говоря, такой `Wildcard` для `IPv4`, да, звёздочка. А то же самое вот эти два двоеточия – это любой `IPv6`-адрес. То есть в этом смысле мы указываем универсально, ну, специальные, скажем, адреса.

Так вот, а, про `screen`, понятно, точно так же работает `tmux`, только он, а, более навороченный, а, то есть он умеет не просто вам открывать сессию. Здесь можно делать такие виртуальные окна, между ними ходить, можно делить экран на части. Ну, если видели фильмы про кулхацкеров, вот там они всегда так делают. У вас там куча маленьких подтерминалов и так далее, но он тоже может выполнять эту функцию. То есть вы, соответственно, там можете подключаться, отключаться, в общем, а по `tmux` тоже можете почитать. Ну, сейчас не будем затягивать, у нас сейчас время подходит к концу, но, а, `screen` – простенький вариант. Э, там всё очень легко и доступно. `tmux`, там много горячих клавиш. Ну, просто посмотрите базовую статью по введению в `tmux`, и всё будет понятно.

А так, что мы ещё не посмотрели? Команды вот, которые мы использовали. Из этого, что мы не использовали, `rsync` не делали. Позволяет нам синхронизировать две файловые системы. Первый параметр – это источник, второй параметр – назначение, то есть `source destination`. А при этом, чтобы использовать `SSH`, есть параметр `-e`, это исполняемая команда. И после этого параметра обязательно должен идти `ssh`. То есть вот эта штука неразрывна.

В данном случае мы синхронизируем файлы с вот этого удалённого сервера на нашу локальную файловую систему. Поэтому здесь, если, допустим, у нас нестандартный порт, мы можем ввести кавычки и в кавычках указать `-p`. Понятно, да? То есть любые параметры `SSH`-подключения мы вводим вот сюда, оборачиваем всё в одинарные кавычки и спокойно пишем параметры. Так что с этим проблем тоже не будет.

А вот про `rsync` тоже, если кто не слышал, обязательно почитайте, посмотрите примеры. Это очень удобная штука. В сочетании с `SSH` позволяет вам без каких-либо там дополнительных телодвижений, без всяких `FTP`, без каких-то там настроек удалённого доступа, есть `SSH`, всё, файлы вы можете гонять в любую сторону с правами вот этого пользователя.

А `-C`, вот это заглавное, тоже не говорили, это компрессия. Если вы подключаетесь к удалённому хосту, крайне полезно использовать сжатие, потому что вы передаёте текст, текст прекрасно сжимается, используйте сжатие. Просто быстрее будет работать, меньше трафика и нетребовательно к каналу.

Кстати говоря, `SSH` работает в текстовом режиме даже по очень плохим каналам, прямо совсем плохим мобильным там `dial-up` тоже `SSH` будет работать. Поэтому это очень удобная штука. То есть из любого места вы сможете подключиться в любых условиях. Это очень экономно по трафику и доступно.

А вот этот вариант, что он делает? Мы здесь подключаемся по `SSH`, всё как обычно. И оттуда запускаем команду. То есть мы можем после строки подключения сразу указать команду. Тогда мы не проваливаемся просто в оболочку, а сразу запускаем команду. То есть мы по сути получаем удалённый интерфейс удалённого запуска любой команды по `SSH`. То есть вроде бы всё известное, но совершенно другая функциональность. То есть тоже можно этим пользоваться. Допустим, хотите дёрнуть какой-то удалённый скрипт, пожалуйста, прямо сюда прописали, запустили и всё получили. А результат будет выведен вам, собственно, на экран. Всё как при обычном выводе команды.

Если у вас есть ещё аутентификация по ключам, то это вообще можно записать, как я говорил, в автоматическое расписание, в какие-то регулярные задачи без участия человека.

А если вы хотите использовать другой ключ, который не является дефолтным, да, то есть у него нестандартное название, то можно указать ключ `-i`, указать путь к ключу, и с этим ключом будете подключаться. Вот поэтому, соответственно, здесь никаких тоже проблем нет. Можете использовать любой ключ, который у вас где-то лежит.

А дальше для отладки это параметр `-v`, мы про это говорили. Нестандартный порт – это `-p`. Ну и для, э, как раз более сложных элементов, но это скорее уже мы сейчас не успеем рассмотреть, это на домашнюю проработку. Это вот команда, которая пробрасывает порты через `SSH`.

Ну, это уже не бейсиковая тема, скорее, но, я смотрю, у нас есть много интересующихся. Это способ подключения к тем сервисам, которым по умолчанию этой возможности нет. То есть вы создаёте туннель, если это разрешено в настройках, для этого нужен определённый конфиг. Во, вот здесь, кстати, написаны как раз примеры с конфигами и со всем остальным. Там и картинки есть хорошие. То есть вы говорите, что у вас будет какой-то определённый порт соответствовать `localhost:80`. То есть у вас на локальном хосте работает какой-то сервис, и он вообще недоступен даже ни по одному из айпишников извне. А вы открываете порт вот такой и, соответственно, пробрасываете его на там на какую-то машину. То есть вы временно открываете туннель для подключения извне к локальным сервисам какого-то хоста.

Естественно, это опасно, потому что если вы делаете это неосторожно, это значит, что там вдруг кто-то так тоже сможет сделать, да, и к вам подключиться. Но в целом это как временная мера подключения там для отладки и так далее используется.

Ну, например, базы данных практически никогда не слушают публичные `IP`-адреса. Соответственно, чтобы к ним подключиться, обычно вам нужен вот этот какой-то внутренний порт, а вы сидите в интернете, соответственно, делаете туннель и через туннель подключаетесь.

То есть `SSH`, я просто зачем сюда это показал? Чтобы вы понимали, что `SSH` – это не просто оболочка. Это оболочка, конечно, это ещё передача файлов в любых вариантах: или чисто `SFTP`, или `SCP` – команда, которая просто копирует файлы. А и плюс ещё туннели, то есть возможностей на самом деле много. То есть это прямо такой действительно транспорт для `Linux`.

А что ещё можно сделать для клиента? То есть мы говорили про настройки сервера. Для клиента вы можете сделать настройки, чтобы не вбивать каждый раз одни и те же самые параметры. Вы можете сделать, например, определить хост `VM` и для него прописать айпишник, логин, порт, какие-то параметры. И потом вы скажете `ssh VM`, и у вас все вот эти параметры автоматом подставятся.

А `Host *` – это настройки для всех. То есть вы можете по дефолту, например, включить компрессию, протокол версии 2, конкретный ключ для подключения конкретного пользователя, который у вас всегда будет подключаться и так далее. Это кладётся в вашу домашнюю директорию `~/.ssh/config`. Вот это `config` клиента для того, чтобы это проще делать.

Так, альтернатива `VPN`? Ну да, это туннель. Это один из туннелей. `VPN` – это тоже туннели. А так `SSH` как прокси можно использовать, да? Ну, в общем, туннели, да, тоже вариант.

Так, ну что, мы всё рассмотрели. А давайте я сейчас вам отправлю ссылку на презентацию, кто не планирует оставаться до конца. Да, там можно скачать. Э, и сейчас ещё раз повторяю вам ссылку на опросник тоже. Кто планирует завершать, просьба пройти опрос, написать там: понравилось, не понравилось, что улучшить, что ухудшить и так далее. Чтобы пройти опрос, вы должны авторизоваться на сайте `Otus`. Просто так анонимно не работает. Поэтому у вас будет 403, это нормально. Вы должны залогиниться, у вас там должна быть какая-то учётная запись при регистрации, и потом сможете пройти опрос. Вот.

А те, кто остался, я расскажу про наш курс «Администратор `Linux Basic`». Это вот в рамках которого мы с вами встречаемся и по сути сегодня общались.

А есть лендинг. Ну давайте я вам тоже скину в чат. Кто хочет, можете посмотреть. Это базовый курс из линейки «Администратор `Linux`», а который, в принципе, включает три курса. Это `Basic`, `Professional` и «Инфраструктура высоконагруженных систем», то, что называлось раньше `Advanced`.

А, ну вот `Basic` он, а сейчас первый, а он всегда, собственно, решал задачи для новичков. То есть, если вы раньше с `Linux` не работали или работали, но только как-то фрагментарно, неуверенно в своих знаниях, то вот, пожалуйста, приходите на курс. Он длится 3 месяца, онлайн-формат, э, два раза в неделю занятия: в 19:00 вечера по будням в среду и 10:00 утра в субботу.

А уровень его `Basic`, то есть можно приходить без особых каких-то начальных знаний. Старт его 28 марта. Здесь можно посмотреть структуру его по модулям. Я это могу всё рассказать. Если есть вопросы по составу, то говорите.

Так вот, а, собственно, всё начинается с вводной части. Там вам предлагается записанный курс с Андреем Бурановым для вводной части. И потом начинаются уже очные занятия. Вот как мы сейчас с вами занимаемся в виде вебинаров. То есть сначала мы, э, занимаемся по курсу «Онлайн `Linux` вопрос-ответ», э, есть ли какие-то там сложности, запускаем виртуалки, решаем технические задачи и потом поехали.

Изучаем `bash`, модуль по дисковой подсистеме. Дальше модуль веб-сервисов, `Docker`, `Git`, сетевая подсистема, мониторинг, логирование, модуль `Astra Linux` для совместимости с разными дистрибутивами. Мы там изучаем, чем дистрибутивы `Linux` отличаются. И в конце вы делаете итоговый проект, который состоит, в принципе, из всех домашних заданий по всем модулям.

Иван пишет: «2 часа мало для `SSH`». Ну да, естественно, можно довольно долго всё это разбирать, но главное начать, а дальше уже там пойдёт.

Так вот, а есть преподаватели, я преподаю большую часть курса, наверное, обычно Андрей Буранов – это наш руководитель, у него тоже есть свои занятия. Ну, во-первых, это начало и конец курса, как правило, и занятия по дисковой подсистеме. Вот остальные я веду, там есть ещё другие преподаватели, тоже можете посмотреть.

А, кстати, вот рекомендую открытые уроки тоже посмотреть на соцсетях `Otus`. Вот Андрей проводил несколько, а вот этот, который мы сейчас с вами проводим, тоже будет там. Так что подписывайтесь. Я тоже от Андрея люблю смотреть. Он интересные вещи постоянно рассказывает.

А, ну дальше там понятно: отзывы, заявки и так далее. В общем, все коммерческие вопросы – это вы уже можете с менеджерами там решить. Кто хочет записаться на курс, то добро пожаловать.

Так, можно ли после двадцать восьмого влиться в курс? А, можно, я думаю. Ну, лучше, наверное, заранее согласовать с менеджерами. Там могут быть какие-нибудь временные скидки, то есть, чтобы в них попасть, может, вам как-то надо себе застолбить. Э, и начать вы можете, наверное, и попозже. В принципе, там первая часть, она такая довольно расслабленная, такой плавный старт, потому что вам даётся время на изучение записанного курса. То есть там где-то неделя, там первые 2 недели они довольно свободны, а вот дальше идёт уже плотная работа. Каждая неделя – это два занятия.

Поэтому, в принципе, можете, вам придётся немножко там нагнать, но вполне можете и чуть позже начать.

Так вот, э, живые вебинары – это наша основа в `Otus`. То есть вы приходите, общаетесь вот по вопросам, которые вас волнуют. Э, если что-то обновляется, мы, естественно, всё вживую проводим. У нас нет проблем устаревшего какого-то материала или каких-то неотвеченных вопросов. Не то что вы там включили видеозапись и вам некого спросить. В этом основная ценность этих курсов.

Все записи, материалы, там команды, презентации и так далее у вас сохраняются навсегда в личном кабинете. Домашние задания, там вы можете пообщаться, что как вы сделали, там спросить, решить вопросы. Но к этому есть ещё занятия «вопрос-ответ», то есть специальные занятия, куда вы приходите задавать вопросы. И мы там рассматриваем иногда темы, которые выходят за пределы курса. Ну, раз появился вопрос, нам нужно его разобрать. И там, на самом деле, ну, где-то вторая половина полезности помимо стандартных занятий есть – это вопрос-ответ. Обычно я их веду, и к ним мы готовимся. То есть мы составляем список вопросов и там очень плотно и серьёзно работаем.

Ну, опять же, вы можете пообщаться с преподавателями, с вашими коллегами. Многие делают какие-то общие там проекты, обмениваются знаниями. Это тоже полезно. Ну, естественно, получаете проект, всё здесь в порядке.

Ну вот ещё раз ссылка на лендинг. 3 месяца курс, 28 марта, первое занятие будет.

Так. Угу. Так, вот пишут: «Я с `Karmic Koala`». Ну, это у `Ubuntu`, да? У нас какая-то древняя была. Помню такое.

Так, групповые консультации. Групповые консультации, да, это занятие, по сути, вопрос-ответ. Ну, они по-разному называются. Есть, допустим, просто называется вопрос-ответ по какому-то конкретному направлению, есть групповые консультации, но по факту они все строятся по принципу вопрос-ответ. То есть вы задаёте свои вопросы, которые накопились, и я или другой преподаватель дают на них обстоятельный ответ в специально выделенное время.

Ну, потому что на основном занятии не всегда есть достаточно времени, чтобы сильно отклоняться от темы. Ну вот вы на этом занятии тоже видели, что не на всё мы можем распыляться, просто время заканчивается. Вот мы сейчас уже перерасходовали, у нас всего полтора часа на вебинар. Мы уже вышли за пределы.

А, да, просьба заполнить опросник. Сейчас я ещё раз его закину.

А так, всё, если есть какие-то финальные вопросы, задавайте. Э, так, я вас мотивирую подключиться к каналу `Otus`, ну, в `Telegram`. Я надеюсь, вы знаете, как сделать, чтобы `Telegram` работал. Ну, и в целом в другие соцсети, то есть там `ВК Видео`, например, можете подписаться, у вас будет поток, э, записанных вебинаров.

Так. Э, если какой-то срочный вопрос, то пишите, если нет, э, да, тогда будем завершать.

Так, ну вроде вопросов нет. Тогда всем большое спасибо, кто пришёл, досидел до конца. А всем тогда хорошего вечера. Увидимся на курсе или на других открытых уроках где-нибудь ещё, да. Всё, всем до свидания, успехов.