Протокол безопасных соединений SSH (История протокола SSH)

Содержание:

Введение

В данной курсовой работе будет рассмотрена тема протокол безопасных соединений SSH. Протокол SSH расшифровывается как Secure Shell или безопасная оболочка. Основное предназначение при удалённом управлении защитить все конфиденциальные данные с помощью зашифровки передаваемой информации. Целью курсовой работы будет ознакомиться с историей создания, устройством SSH и его возможным использованием на практике.

Понимание истории создания протоколов SSH покажет развитие данного направления технологий и даст понимание необходимости их использования.

Понимание возможностей SSH позволит находить им применение при разработке системы, а знание архитектуры необходимость применить именно их в конкретной системе.

На практике рассмотрим, как создать и сконфигурировать сервер с протоколом SSH.

В качестве источников будут применяться различные книги по ОС Linux поскольку большинстве случаев протокол SSH применяется в этой ОС, а также материалы с официального сайта www.ssh.com.

Глава 1. История протокола SSH

Для организации удаленного доступа к консоли сервера ранее использовался протокол telnet, и в каждую сетевую операционную систему, будь то FreeBSD или Windows 95 (которую, впрочем, сложно впрямую назвать сетевой), включался telnet-клиент. Эта программа так и называется — telnet (в Windows — telnet.exe). Подключившись с помощью telnet к удаленному компьютеру, вы можете работать с ним как обычно. В окне telnet-клиента представлена как бы консоль удаленного компьютера: вы будете вводить команды и получать результат их выполнения — все так, как если бы вы работали непосредственно за удаленным компьютером.

Но технологии не стоят на месте, и протокол telnet устарел. Сейчас им практически никто не пользуется. На смену ему пришел протокол SSH (Secure Shell), который, как видно из названия, представляет собой безопасную оболочку. Главное отличие SSH от telnet состоит в том, что в соответствии с этим протоколом все данные (включая пароли доступа к удаленному компьютеру, отдельные файлы и пр.) передаются в зашифрованном виде. Причиной создания SSH стало то, что во времена telnet участились случаи перехвата паролей и другой важной информации.

Протокол Secure Shell был первоначально разработан Тату Илоненом в 1995 году в ответ на случай взлома в финской сети университетов. Анализатор паролей был установлен на сервере, подключенном непосредственно к магистрали, и когда он был обнаружен, в его базе данных были тысячи имен пользователей и паролей, в том числе несколько от компании Илонена.^[1]

Этот инцидент побудил Илонена изучать криптографию и разработать решение, которое он мог бы использовать сам для безопасного входа в систему через Интернет. Его друзья предложили дополнительные функции, и три месяца спустя, в июле 1995 года, Илонен опубликовал первую версию как открытый исходный код. Это стало OpenSSH. Позже он взял протокол для стандартизации в IETF и разработал протокол передачи файлов SSH (SFTP). В декабре 1995 года он основал SSH Communications Security Corp., чтобы обеспечить коммерческую поддержку протокола.

Илонен по-прежнему работает над темами, относящимися к Secure Shell, особенно по управлению ключами, а также по более широким темам кибербезопасности.

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

^[2]

Новый протокол заменил несколько устаревших инструментов и протоколов, включая telnet , ftp , FTP / S , rlogin , rsh и rcp .

У протокола SSH по умолчанию используется 22 порт и это не случайность так было задумано разработчиком. Первоначальная версия SSH (Secure Shell) была написана весной 1995 года. В это время telnet и FTP широко использовались.

Во время разработки SSH планировалось заменить оба протокола telnet(порт 23) и ftp(порт 21). Порт 22 был свободен и это по мнению разработчика давало доверие пользователя к новому протоколу.

Основной процесс распределения портов был довольно простым в то время. Интернета было меньше, и человечество было на самых ранних стадиях интернет-бума. Номера портов были выделены IANA (Управление по присвоению номеров в Интернете). Разработчик написал в эту структуру и протокол SSH получил 22 порт. По умолчанию сервер SSH по-прежнему работает на порту 22. Однако бывают случаи, когда он работает на другом порту. Подробнее об этом в следующей главе.

^[3]

Глава 2. Устройство и возможное использование протокола SSH

Протокол SSH использует шифрование для защиты соединения между клиентом и сервером. Все аутентификация пользователя, команды, выходные данные и передача файлов зашифрованы для защиты от атак в сети.

Протокол работает в модели клиент-сервер, что означает, что соединение устанавливается клиентом SSH, подключающимся к серверу SSH. Клиент SSH управляет процессом установки соединения и использует криптографию с открытым ключом для проверки подлинности сервера SSH. После фазы установки протокол SSH использует строгие симметричные алгоритмы шифрования и хеширования, чтобы обеспечить конфиденциальность и целостность данных, которыми обмениваются клиент и сервер.

На рисунке ниже представлен упрощенный процесс настройки безопасного подключения оболочки.^[4]

Рисунок1

Протокол используется в корпоративных сетях для:

• обеспечение безопасного доступа для пользователей и автоматизированных процессов
• интерактивная и автоматическая передача файлов
• выдача удаленных команд
• управление сетевой инфраструктурой и другими критически важными компонентами системы.

Как только соединение между клиентом и сервером SSH установлено, передаваемые данные шифруются в соответствии с параметрами,^[5] согласованными в настройке. Во время согласования клиент и сервер согласовывают алгоритм симметричного шифрования, который будет использоваться, и генерируют ключ шифрования, который будет использоваться. Трафик между связывающимися сторонами защищен с помощью отраслевых стандартных алгоритмов надежного шифрования (таких как AES (Advanced Encryption Standard)), а протокол SSH также включает механизм, который обеспечивает целостность передаваемых данных с использованием стандартных хеш-алгоритмов (таких как SHA -2 (стандартный алгоритм хеширования).

Когда протокол SSH стал популярным, Тату Илонен взял его в IETF для стандартизации. Теперь это интернет-стандарт, который описан в следующих документах:

RFC 4251 - Архитектура протокола Secure Shell (SSH)

RFC 4253 - Протокол транспортного уровня Secure Shell (SSH)

RFC 4252 - Протокол аутентификации Secure Shell (SSH)

RFC 4254 - Протокол соединения Secure Shell (SSH)

Формат файла открытого ключа не является формальным стандартом (это информационный документ), но многие реализации поддерживают этот формат. RFC 4716 - формат файла открытого ключа Secure Shell (SSH)^[6]

Протокол передачи файлов SFTP (SSH File Transfer Protocol) является, вероятно, наиболее широко используемым протоколом передачи файлов безопасных сегодня. Протокол SFTP работает по протоколу SSH как подсистема. Первоначально он был разработан Tatu Ylonen для SSH 2.0 в 1997-1998 годах. Нет отдельного порта SFTP; он использует обычный порт SSH. Полную документацию по протоколу SFTP можно найти в Internet-Draft draft-ietf-secsh-filexfer-02.

SFTP (SSH File Transfer Protocol) - это безопасный протокол передачи файлов. Он работает по протоколу SSH. Он поддерживает полную функциональность безопасности и аутентификации SSH.

SFTP имеет довольно много изменений по сравнению с устаревший FTP в качестве протокола передачи файлов, и быстро заменяет FTP / S . Он обеспечивает все функциональные возможности, предлагаемые этими протоколами, но более безопасно и надежно, и с более простой настройкой. По сути, больше нет причин использовать устаревшие протоколы.

SFTP также защищает от перехвата паролей и атак «человек посередине» . Он защищает целостность данных с помощью шифрования и криптографических хеш-функций и аутентифицирует как сервер, так и пользователя.

Номер порта SFTP - это порт SSH 22. Это в основном просто сервер SSH. Протокол SFTP может быть инициирован только после того, как пользователь вошел на сервер, используя SSH. На серверах нет отдельного порта SFTP. Не нужно настраивать еще одну дыру в брандмауэрах.

Номер порта можно настроить, изменив Port 22директиву в / etc / ssh / sshd_config . Это также можно указать с помощью -p <port>опции sshd . Клиент SSH и программы sftp также поддерживают эту -p <port>опцию.

В редких случаях сервер SSH также может быть запущен без привилегий суперпользователя, и в этом случае он должен быть запущен в непривилегированном порту (т. Е. Номер порта> = 1024).

Эта -p <port>опция может использоваться для указания номера порта для подключения при использовании ssh команды в Linux. Опция -P <port>(примечание: заглавная P) может использоваться с SFTP и scp. Параметр командной строки номера порта SSH переопределяет любое значение, заданное в файлах конфигурации.

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

Настроить исходящий SSH в брандмауэре очень просто. Если вообще существуют ограничения на исходящий трафик, просто создайте правило, которое позволяет TCP-порту 22 выходить. Это все. Если вы хотите ограничить адреса назначения, вы также можете ограничить правило, разрешающее доступ только к внешним серверам вашей организации в облаке или к серверу перехода, который защищает облачный доступ.

Однако неограниченный исходящий SSH может быть рискованным. Протокол SSH поддерживает туннелирование . Основная идея заключается в том, что SSH-сервер на внешнем сервере можно прослушивать из любого места, перенаправлять их обратно в организацию и затем подключаться к какому-либо внутреннему серверу.

Это может быть очень удобно в некоторых условиях. Разработчики и системные администраторы часто используют его, чтобы открыть туннель, который они могут использовать для получения удаленного доступа из дома или со своего ноутбука, когда они путешествуют.^[7]

Однако это, как правило, нарушает политику и отнимает контроль у администраторов брандмауэра и группы безопасности. Это может, например, нарушать PCI , HIPAA или NIST SP 800-53 . Он может быть использован хакерами и иностранными спецслужбами, чтобы оставить бэкдор в организации. ^[8]

Для входящего доступа есть несколько практических альтернатив:

• Настройте брандмауэр для переадресации всех подключений к порту 22 на определенный IP-адрес во внутренней сети или DMZ
• Используйте разные порты на брандмауэре для доступа к разным серверам
• Разрешите доступ по SSH только после того, как вы вошли в систему с помощью VPN (виртуальная частная сеть), обычно с использованием протокола IPsec

Для получения доступа по SSH через iptables (Iptables - это межсетевой экран, встроенный в ядро Linux. Обычно он настроен на защиту сервера путем предотвращения доступа к любым портам, которые не были открыто открыты.)Если iptables на сервере включен, следующие команды могут использоваться для разрешения входящего доступа SSH:

iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Они должны быть запущены от имени пользователя root.

Для сохранения конфигураций, на некоторых системах это можно сделать с помощью команды:

service iptables save

Для работы SFTP нужен SFTP-клиент. Многие клиентские реализации SFTP доступны. Многие клиенты SSH поддерживают SFTP. Вот некоторые из них:

• Tectia SSH Client
• WinSCP
• FileZilla
• PuTTY
• Cyberduck

SFTP-сервер обычно входит в реализацию SSH. Большинство организаций используют Tectia SSH или OpenSSH в качестве сервера; оба идут с реализациями сервера SFTP из коробки. Существуют такие версии:

• Tectia SSH Server для Windows
• Tectia SSH Server для мейнфреймов IBM z / OS
• OpenSSH - сервер с открытым исходным кодом для Linux и Unix
• FileZilla - бесплатный sftp сервер для Windows

Команда SCP в Linux является программой передачи файлов для SFTP в Linux. Интерфейс scpкомандной строки был разработан после старой команды rcp в BSD Unix. Scp также обычно поставляется с пакетом OpenSSH.

Типичное использование:

scp [-r] file ... [user@]host:[path]

По сути, это копирует один или несколько файлов на данный хост. Если user указано, то они копируются в эту учетную запись на хосте. Если нет user, то предполагается, что используется то же имя пользователя, что и на стороне клиента. Если path задано, то файлы копируются в этот каталог (относительно домашнего каталога данного пользователя). Если нет path, файлы копируются в домашний каталог пользователя. Если –r опция указана, то файлы могут быть каталогами, а данный каталог и все его подкаталоги и файлы в них (рекурсивно) копируются.^[9]

Можно также скопировать в обратном направлении:

scp [-r] [user@]host:file path

Обычно это path будет .текущий каталог.

Команда sftp в Linux является клиентской программой для SFTP. Интерфейс sftp командной строки был разработан, чтобы быть похожим на команду ftp . Команда sftp обычно является частью пакета OpenSSH .

SFTP может также использоваться для обмена файлами, подобно файлообменнику Windows и Linux NFS . Основное отличие состоит в том, что SFTP является безопасным и может надежно использоваться по трансляции сетевых адресов (NAT) и общедоступному Интернету.

Sshfs - это сетевая файловая система для Linux, которая работает по протоколу SFTP. Он может использовать любой SSH-сервер в качестве сервера и использовать удаленные файлы по сети, как если бы они были локальными файлами. Удаленная файловая система может быть смонтирована и размонтирована по желанию. Это наиболее удобный способ монтирования удаленных файлов ad hoc без необходимости какой-либо настройки администратором сервера. Ключи SSH могут даже полностью автоматизировать установление соединения с сервером. По сути, любой, кто может войти на сервер, может смонтировать свою файловую систему с доступом к тем файлам, к которым имеет доступ пользователь.^[10]

Другие реализации совместного использования файлов, использующие SFTP:

Expandrive (Windows и Mac)

Apache Commons VFS

ChromeOS-файловая система, SFTP

Как и сам SSH, SFTP является протоколом клиент-сервер. Клиенты SFTP включены в качественные клиенты SSH, а полные реализации SSH корпоративного уровня обеспечивают функциональность как клиента SFTP, так и сервера. Некоторые клиенты SSH, такие как Tectia SSH , также предоставляют графические представления файлового менеджера для удаленных файловых систем.

В Linux SFTP часто используется как утилита командной строки, которая поддерживает как интерактивную, так и автоматическую передачу файлов. Аутентификация с открытым ключом может использоваться для полной автоматизации входа в систему для автоматической передачи файлов. Тем не менее, правильное управление жизненным циклом ключей SSH важно для контроля доступа.

Распространенные случаи использования для автоматической передачи файлов включают ночные резервные копии системы, копирование данных в системы аварийного восстановления, распространение данных конфигурации и перемещение журналов транзакций в архивные системы. Многие организации имеют тысячи ежедневных передач SSH. В некоторых случаях мы видели более 5 миллионов ежедневных автоматических входов в систему по SSH.^[11]

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

IBM MQ Управляемая передача файлов

GlobalScape Улучшенная передача файлов

GoAnywhere MFT

SFTPPlus Управляемая передача файлов

IPSwitch MOVEit Complete

Solarwinds управляемая передача файлов

JScape MFT Server

Серв-У MFT Сервер

Безопасный MFT-шлюз Axway: SecureTransport

Stonebranch Универсальный Data Mover

Coviant Diplomat Управляемая передача файлов

Акронис МассТранзит

Tibco Управляемая передача файлов

BMC Control-M Управляемая передача файлов

Signiant Безопасная передача файлов

SFTP библиотеки для разработчиков

Существует много библиотек SSH с открытым исходным кодом, доступных для различных языков программирования.^[12]

pysftp - это реализация Python

Paramiko - это еще одна реализация Python

pkg / sftp - это реализация языка Go

libssh - реализация протокола на C

libssh2 - еще одна реализация протокола C

Rebex SFTP является реализацией .NET (C #)

codeignioter-sftp - это реализация PHP

phpseclib - это еще одна реализация PHP

SmartFTP является компонентом ActiveX

JCraft JSch - это реализация Java

SSHJ - другая реализация Java

Протокол SFTP поддерживает несколько одновременных операций. Каждая операция идентифицируется уникальным номером, назначенным клиентом, и ответ сервера содержит тот же идентификационный номер. Сервер может обрабатывать запросы асинхронно и может возвращать ответы не в порядке. По соображениям производительности клиенты передачи файлов часто отправляют несколько запросов перед тем, как остановиться, ожидая ответов.

Операции или типы пакетов, поддерживаемые протоколом, включают в себя:^[13]

INIT : отправляет номера версий клиента и расширения на сервер

VERSION : возвращает номер версии сервера и расширения клиенту

OPEN : открывает или создает файл, возвращая дескриптор файла

CLOSE : закрывает дескриптор файла

READ : читает данные из файла

WRITE : записывает данные в файл

OPENDIR : открывает каталог для чтения, возвращает дескриптор каталога

READDIR : читает имена файлов и атрибуты из дескриптора каталога

MKDIR : создает каталог

RMDIR : удаляет каталог

REMOVE : удаляет файл

RENAME : переименовывает файл

STAT : возвращает атрибуты файла с указанным путем, следуя символическим ссылкам

LSTAT : возвращает атрибуты файла с указанным путем, без следующих символических ссылок

FSTAT : возвращает атрибуты файла с указанным дескриптором файла

SETSTAT : изменяет атрибуты файла с указанием пути

FSETSTAT : изменяет атрибуты файла с учетом дескриптора файла

READLINK : читает значение символической ссылки

SYMLINK : создает символическую ссылку

REALPATH : канонизирует относительный путь размера сервера к абсолютному пути

Следующие ответные пакеты возвращаются сервером:

STATUS: указывает на успех или неудачу операции

HANDLE : возвращает дескриптор файла в случае успеха

DATA: возвращает данные в случае успеха

ATTRS : возвращает атрибуты файла в случае успеха

Существует также механизм расширения для произвольных расширений, зависящих от поставщика. Поддерживаемые расширения согласовываются с использованием пакетов INIT и VERSION.

EXTENDED : отправляет специфичный для поставщика запрос от клиента к серверу

EXTENDED_REPLY : отправляет специфический для поставщика ответ с сервера на клиент.

Люди часто хотят сравнивать SFTP и FTPS. FTPS - это в основном старый протокол ftp , работающий через SSL (Secure Sockets Layer) или TLS (Transport Layer Security).^[14]

Преимущества SFTP перед SFTP включают в себя:

• SFTP работает через SSH в стандартном порту SSH. Таким образом, на сервере не нужно открывать дополнительные порты и не нужно поддерживать дополнительную аутентификацию. Это упрощает настройку и снижает вероятность ошибок конфигурации.
• FTPS требует сложной настройки брандмауэра и может не работать через NAT. Порты 989 и 990 должны быть открыты. Кроме того, FTPS поддерживает как активный, так и пассивный режимы (см. FTP ), что еще больше усложняет настройку брандмауэра и приводит к проблемам.
• FTPS требует сертификат X.509 для сервера, как правило, из общедоступного центра сертификации. SSH работает без какой-либо централизованной инфраструктуры. SFTP может использовать любой метод распространения или сертификации ключей хоста, используемый для SSH, без необходимости дополнительной работы и текущего обслуживания.
• FTPS - это, в основном, FTP, что означает, что он имеет режим ASCII, который может повредить файлы, если режим не установлен должным образом. Некоторые реализации по умолчанию используют режим ASCII.
• FTPS нельзя использовать в качестве файловой системы. (Это не улучшает безопасность, так как он может читать те же файлы.)
• FTPS требует, чтобы дополнительный серверный пакет программного обеспечения был установлен и исправлен, тогда как SFTP обычно идет с SSH с системой.^[15]

Подведя итоги данной главы можем отметить протоколы ssh и sftp является безопасным и удобным протоколами для безопасной передачи данных между компьютерами. В следующей главе рассмотрим, как настроить такой сервер.

Глава 3. Конфигурация сервера SSH

Для создания сервера будет взят обычный офисный компьютер с характеристиками:

• Процессор core 2 duo E8400
• Оперативная память 4 гигабайта
• Жесткий диск на 1 терабайт

Для целей опробования создания сервера таких характеристик на создания пробного сервера хватит. Используем операционную систему Ubuntu 18.4 LTS.

Для сервера будем использовать OpenSSH. Это самый распространённый сервер в SSH. Для его установки вводим команду:^[16]

sudo apt-get install ssh

В метапакете ssh содержится как клиент, так и сервер, но при этом, скорее всего, будет установлен только сервер, т. к. клиент уже есть в Ubuntu по умолчанию.

При установке SSH-сервер автоматически прописывается в автозагрузку. Управлять его запуском, остановкой или перезапуском можно с помощью команд:

sudo service ssh stop|start|restart

Основной файл конфигурации SSH-сервера — файл /etc/ssh/sshd_config, доступный для чтения или редактирования только суперпользователю.

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

Приступим к настройке конфигурационного файла (файл с разъяснением на русском можно увидеть в приложении работы^[17]). Для повышения безопасности сервера необходимо присвоить некоторые настройки:^[18]

• Ограничить семейство обрабатываемых адресов реально используемыми, т. е. если вы используете только IPv4 — отключите IРv6, и наоборот. Сделаем разрешение IPv4 и запретим IPv6 командой: AddressFamily inet.
• Поменяем порт нашего SSH сервера. Это связано с тем, что многочисленные сетевые сканеры постоянно пытаются соединиться с 22-м портом и как минимум получить доступ путем перебора логинов/паролей из своей базы. Присвоим порт 2002 с помощью команды: Port 2002.
• Наш будет рассчитан на узкий круг лиц, для каждого будет создан свой ключ, поэтому будет разумно убрать парольную аутентификацию с помощью команды: PasswordAuthentication no
• sshd может работать с протоколами SSH1 и SSH2. При этом использование небезопасного SSH1 крайне не рекомендуется. Заставить sshd работать только с протоколом SSH2 можно так: Protocol 2
• как уже говорилось выше для аутентификации будет использовать ключевой доступ. Для этого будут использованы RSA-ключи. При таком способе пользователь генерирует на своей стороне пару ключей, из которой один ключ является секретным, а другой публичным. Публичный ключ копируется на сервер и служит для проверки идентичности пользователя. Для включения аутентификации по публичному ключу вводим: PubkeyAuthentication yes
• Сервер должен знать, где ему следует искать публичный ключ пользователя. Для этого применяется специальный файл authorized_keys. Используем метод пользователь файл. Для каждого пользователя будет свой файл с публичным ключем. Для этого вводим параметр: AuthorizedKeysFile %h/.ssh/my_keys.
• Установим таймаут, чтобы удалять брошенные сессии ssh. Для этого ставим значения:

ClientAliveInterval 300

ClientAliveCountMax 0

Устанавливаем таймаут idle в секундах (300 секунд = 5 минутам). После того, как указанное время истечет, бездействующий пользователь будет отключен от системы.

• Добавим информационный баннер: Banner /etc/issue. Создадим файл /etc/issue напишем «Hello, User».

На этом настройка конфигурационного файла сервера заканчивается. Вводим команду sudo service ssh restart. Все сервер готов к использованию. Теперь к этому компьютеру можно подключиться удалено, но для этого из настроек видно выше, что на клиентской машине необходимо установить клиентскую версию SSH. На клиентской машине установлена операционная система windows 10. С 2019 года и начиная с версии Windows 10 1809 появилась возможность устанавливать встроенную openssh^[19].

Клиент и сервер OpenSSH устанавливаются в Windows 10 версии 1809 как отдельные компоненты.

Устанавливаем OpenSSH, открываем раздел "Параметры" и последовательно выбераем "Приложения" > "Приложения и компоненты" > "Управление дополнительными возможностями".

Смотрим этот список и выяснием, установлен ли клиент OpenSSH. Если нет, то выберите пункт "Добавить компонент" в верхней части страницы, а затем уставливаем клиент OpenSSH, находим элемент "Клиент OpenSSH" и щелкаем "Установить"^[20];

После завершения установки возвращаемся в раздел "Приложения" > "Приложения и компоненты" > "Управление дополнительными возможностями", где теперь появляются компоненты OpenSSH.

Создаем пару ключей с помощью команды в консоле:

ssh-keygen -t rsa -b 2048

Windows сгенерирует пару открытых\закрытых ключей RSA. Открытый ключ будет сохранен как "id_rsa.pub" в указанной вами директории.

Копируем его на сервер в директорию .ssh/ .

Подключаемся к нашему серверу.

Видим успешное соединение.

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

Заключение

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

Библиография

1. Колисниченко Д. Н. К60 Linux. От новичка к профессионалу. — 6-е изд., перераб. и доп. — СПб.: БХВ-Петербург, 2018. — 672 с.: ил. — (В подлиннике)
2. www.ssh.com
3. https://docs.microsoft.com
4. https://help.ubuntu.ru/wiki/ssh

Приложение

# Пример конфигурации open-ssh сервера с русскими #

# комментариями. #

# Написан для http://help.ubuntu.ru #

# by MadKox, 01.2010. #

# #

# #

# Условные обозначения: #

# Под "по умолчанию" - подразумевается поведение sshd при #

# неуказанной явно директиве. Стоит заметить, что в Ubuntu #

# файл sshd_config уже содержит ряд настроек, которые #

# являются настройками по умолчанию для именно для Ubuntu. #

# Такие настройки указаны в этом файле. #

# #

############################################################

################ Настройки адресов/портов и т.д. ###########

############################################################

# #

## Port ####################################################

# #

# Используемый порт. Можно указывать несколько, например: #

# Port 22 #

# Port 23 #

# Port 24 #

# Рекомендуется использовать нестандартный порт, т.к. #

# стандартный часто сканируется ботами на предмет #

# потенциальных "дырок". Может быть опущен, если задан #

# через адрес. См. также параметр ListenAddress. #

# #

Port 22

# #

## ListenAddress ###########################################

# #

# Сетевой адрес, на котором "слушает" сервер. Адрес можно #

# записывать так: #

# ListenAddress host|IPv4_addr|IPv6_addr #

# ListenAddress host|IPv4_addr:port #

# ListenAddress [host|IPv6_addr]:port #

# Если порт не задан, sshd будет слушать на этом адресе и #

# на порту, указанному в опции Port. Если вы будете #

# использовать ListenAddress не указывая порт, то опция #

# Port должна предшествовать опции ListenAddress. Если не #

# указывать, то по умолчанию слушает на всех локальных #

# адресах. Можно указывать несколько адресов. #

# #

## AddressFamily ###########################################

# #

# Указывает, какое семейство IP адресов должно быть #

# использовано sshd. Возможные варианты: #

# “any” - любые #

# “inet” (только IPv4) #

# “inet6” (только IPv6) #

# По умолчанию - “any”. #

AddressFamily inet

# #

## UseDNS ##################################################

# #

# Указывает, должен ли sshd проверять имя хоста и #

# используя это имя сверять IP адрес переданный клиентом с #

# полученным от DNS. #

# Значение по умолчанию - “yes”. #

# #

############################################################

############# Настройки доступа пользователей ##############

############################################################

# #

# Пустить/не пустить пользователя определяется директивами #

# DenyUsers, AllowUsers, DenyGroups, и AllowGroups. #

# при этом, проверка проходит сверху - вниз по цепочке: #

# ## DenyUsers ## #

# || #

# ## AllowUsers ## #

# || #

# ## DenyGroups ## #

# || #

# ## AllowGroups ## #

# Принимаются только имена пользователей и групп, числовые #

# идентификаторы (UserID) - не распознаются. Корректная #

# запись нескольких пользователей/групп по очереди, через #

# пробел. Если записано в виде пользователь@хост - то #

# пользователь и хост проверяются отдельно, это позволяет #

# разграничить доступ определенных пользователей с #

# определенных хостов. Стоит помнить, что директивы #

# DenyUsers и AllowUsers принимают в качестве параметра #

# имя пользователя, а DenyGroups и AllowGroups - имя #

# группы. См. PATTERNS в man ssh_config для дополнительной #

# информации о формах записи имен пользователей и групп. #

# #

## DenyUsers ###############################################

# #

# Список ПОЛЬЗОВАТЕЛЕЙ, которым НЕЛЬЗЯ пользоваться sshd. #

# По умолчанию - не указан = не запрещен никто. Т.е. если #

# тут указан пользователь, то ему будет отказано в доступе #

# к ssh серверу. #

# #

## AllowUsers ##############################################

# #

# Список ПОЛЬЗОВАТЕЛЕЙ, которым МОЖНО пользоваться sshd, #

# По умолчанию - не указан = разрешено всем. Т.е. если #

# указан хотя бы один пользователь, ssh доступ к серверу #

# доступен только для него. #

# #

## DenyGroups ##############################################

# #

# Список ГРУПП, которым НЕЛЬЗЯ пользоваться sshd. #

# По умолчанию - не указан = не запрещена ни одна группа. #

# Т.е. если указана хотя бы одна группа, то пользователям, #

# входящим в эту группу будет отказано в доступе к ssh #

# серверу. #

# #

## AllowGroups #############################################

# #

# Список ГРУПП, которым МОЖНО пользоваться sshd. #

# По умолчанию - не указан = разрешено всем. Т.е. если #

# указана хотя бы одна группа, то только тем пользователям,#

# которые в нее входят будет разрешен доступ к ssh серверу.#

# #

############################################################

######### Опции определения состояния соединения ###########

############################################################

# #

## TCPKeepAlive ############################################

# #

# Указывает, нужно системе посылать TCP сообщения клиенту #

# с целью поддержания соединения. Если посылать эти пакеты,#

# можно определить разрыв соединения. Однако это также #

# означает, что соединение может быть разорвано в случае #

# кратковременного перебоя в работе маршрутизации и #

# некоторых это сильно раздражает. С другой стороны, если #

# таких сообщений не посылать - сеансы на сервере могут #

# длиться бесконечно, порождая пользователей - "призраков",#

# и пожирая ресурсы сервера. Значение по умолчанию - “yes”,#

# т.е. посылать такие сообщения. Для отключения отправки #

# таких сообщений нужно задать значение “no”. Ранее эта #

# опция называлась KeepAlive. Стоит заметить, что #

# существуют более защищенные способы проверки состояния #

# соединения (см. ниже). #

# #

TCPKeepAlive yes

# #

## ClientAliveCountMax #####################################

# #

# Задает количество сообщений к клиентам, которые sshd #

# посылает подряд, не получая какого либо ответа от #

# клиента. Если пороговое значение будет достигнуто, а #

# клиент так и не ответил - sshd отключит клиента, прервав #

# ssh сессию. Стоит отметить, что использование таких #

# сообщений в корне отличается от директивы TCPKeepAlive. #

# Сообщения к/от клиентов посылаются по зашифрованному #

# каналу и поэтому не подвержены спуфингу. Сообщения же #

# TCPKeepAlive спуфингу подвержены. Механизм client alive #

# особо ценен в тех случаях, когда серверу и клиенту нужно #

# знать когда соединение стало неактивным. По умолчанию #

# значение равно 3. В случае, если ClientAliveInterval #

# задан равным 15 и ClientAliveCountMax оставлен по #

# умолчанию, неотвечающие клиенты будут отключены примерно #

# через 45 секунд. Эта директива работает только для #

# протокола ssh2. #

# #

## ClientAliveInterval #####################################

# #

# Задает временной интервал в секундах. Если в течении #

# этого интервала не было обмена данными с клиентом, sshd #

# посылает сообщение по зашифрованному каналу, #

# запрашивающее ответ от клиента. По умолчанию - 0, т.е. #

# не посылать таких сообщений. Эта директива работает #

# только для протокола ssh2. #

# #

############################################################

################ Общие опции аутентификации ################

############################################################

# #

## AuthorizedKeysFile ######################################

# #

# Указывает файл, в котором содержатся публичные ключи, #

# используемые для аутентификации пользователей. Директива #

# может содержать маркеры вида %М, которые подставляются в #

# процессе установки соединения. #

# Определены следующие маркеры: #

# %% - заменяется литералом '%' #

# %h - заменяется домашней директорией #

# аутентифицируещегося пользователя #

# %u - заменяется именем аутентифицируещегося пользователя #

# Таким образом, файл с ключами может быть задан как #

# абсолютным путем (т.е. один общий файл с ключами), так и #

# динамически - в зависимости от пользователя (т.е. по #

# файлу на каждого пользователя). #

# По умолчанию - “.ssh/authorized_keys”. #

# Пример для файла ключа в домашней папке пользователя: #

# AuthorizedKeysFile %h/.ssh/authorized_key #

# Пример для общего файла: #

# AuthorizedKeysFile /etc/ssh/authorized_keys #

# См. описание файла authorized_keys для большей #

# информации. #

# #

## ChallengeResponseAuthentication #########################

# #

# Указывает, разрешить ли аутентификацию вида вопрос-ответ #

# (challenge-response authentication). Поддерживаются все #

# виды аутентификации из login.conf По умолчанию - “yes”, #

# т.е. разрешить. #

# В Ubuntu - выключена по соображениям безопасности. #

# #

ChallengeResponseAuthentication no

# #

## HostbasedUsesNameFromPacketOnly #########################

# #

# Указывает, как сервер должен получать имя хоста клиента #

# при схеме аутентификации, основанной на проверке хоста. #

# Если задать "yes" - при проверке соответствия в файлах #

# ~/.shosts, ~/.rhosts или /etc/hosts.equiv sshd будет #

# использовать имя хоста, предоставленное клиентом. #

# (выполняя реверсивное DNS распознование) Если задать "no"#

# - sshd будет ресолвить имя из самого TCP соединения. #

# По умолчанию - "no". #

# #

## IgnoreRhosts ############################################

# #

# Запрещает использование файлов .rhosts и .shosts #

# в процессе аутентификации, основанной на проверке хоста. #

# (RhostsRSAAuthentication или HostbasedAuthentication). #

# Файлы /etc/hosts.equiv и /etc/ssh/shosts.equiv все еще #

# используются. #

# По умолчанию - “yes”. #

# #

IgnoreRhosts yes

# #

## IgnoreUserKnownHosts ####################################

# #

# Указывает должен ли sshd игнорировать пользовательские #

# "известные хосты" - файл ~/.ssh/known_hosts в процессе #

# аутентификации, основанной на проверке хоста #

# (RhostsRSAAuthentication или HostbasedAuthentication). #

# По умолчанию - “no”. #

# #

## PermitBlacklistedKeys ###################################

# #

# Указывает, стоит ли sshd принимать ключи, занесенные в #

# черный список как скомпрометированные (known-compromised #

# keys (см. ssh-vulnkey)). Если задано значение “yes” - #

# попытки аутентификации с такими ключами будут занесены в #

# журнал и приняты, если значение “no” - попытки #

# аутентификации будут отвергнуты. #

# По умолчанию - “no”. #

# #

## PermitEmptyPasswords ####################################

# #

# В случае разрешенной аутентификации с помощью пароля, #

# указывает, возможен ли вход с пустым паролем. #

# По умолчанию - “no”. #

# #

PermitEmptyPasswords no

# #

## PermitRootLogin #########################################

# #

# Указывает, возможен ли ssh-вход под суперпользователем #

# (root). Может принимать значения: #

# “yes” - суперпользователь может зайти. Применяется #

# текущая глобальная схема аутентификации. #

# #

# “without-password” - суперпользователь может зайти. #

# Парольная аутентификация для него будет отключена. #

# #

# “forced-commands-only” - суперпользователь сможет зайти, #

# пользуясь аутентификацией на основе публичного ключа и #

# только если передаст необходимую к исполнению комнаду. #

# Это удобно для осуществления резервного копирования, #

# даже в том случае, когда нормальный (т.е. не через ssh) #

# вход суперпользователя запрещен. Все остальные методы #

# аутентификации для суперпользователя будут заблокированы.#

# #

# “no” - суперпользователь не может использовать ssh для #

# входа в систему. #

# #

# Значение по умолчанию - “yes”. #

# #

PermitRootLogin yes

# #

## Protocol ################################################

# #

# Указывает, какой протокол должен использовать sshd. #

# Возможные значения ‘1’ и ‘2’ - ssh1 и ssh2 #

# соответственно. Возможна одновременная запись, при #

# которой значения следует разделять запятыми. #

# По умолчанию - “2,1”. #

# Стоит отметить, что порядок следования протоколов в #

# записи не задает приоритет, т.к. клиент выбирает какой #

# из нескольких предложенных сервером протоколов ему #

# использовать.Запись "2,1" абсолютно идентична #

# записи "1,2". #

# #

Protocol 2

# #

## UsePAM ##################################################

# #

# Включает интерфейс PAM (Pluggable Authentication Module #

# interface).Если задано значение "yes" - для всех типов #

# аутентификации помимо обработки модуля сессии и аккаунта #

# PAM будет использоваться аутентификация на основе #

# запроса-ответа (ChallengeResponseAuthentication и #

# PasswordAuthentication) Т.к. аутентификация #

# запросов-ответов в PAM обычно выполняет ту же роль, #

# что и парольная аутентификация, вам следует отключить #

# либо PasswordAuthentication, либо #

# ChallengeResponseAuthentication. Стоит отметить, что #

# если директива UsePAM включена - вы не сможете запустить #

# sshd от имени пользователя, отличного от root. #

# Значение по умолчанию - “no”. #

# #

UsePAM yes

# #

## PasswordAuthentication ##################################

# #

# Указывает, разрешена ли аутентификация с использованием #

# пароля. #

# По умолчанию - “yes”. #

# #

## HostKey #################################################

# #

# Указывает файл, содержащий закрытый хост-ключ, #

# используемый SSH. По умолчанию - /etc/ssh/ssh_host_key #

# для протокола ssh1 и /etc/ssh/ssh_host_rsa_key и #

# /etc/ssh/ssh_host_dsa_key для протокола ssh2. Стоит #

# отметить, что sshd не станет пользоваться файлом, #

# который доступен кому либо, кроме пользователя. Можно #

# использовать несколько файлов с ключами, ключи “rsa1” - #

# для протокола ssh1 и “dsa”/“rsa” для протокола ssh2. #

# #

HostKey /etc/ssh/ssh_host_rsa_key

HostKey /etc/ssh/ssh_host_dsa_key

# #

############################################################

########## Опции протокола SSH версии 1 (ssh1) #############

############################################################

# Настоятельно НЕ РЕКОМЕНДУЕТСЯ использовать протокол ssh1.#

# Протокол ssh2 намного более безопасен, чем ssh1 #

############################################################

# #

## KeyRegenerationInterval #################################

# #

# Для протокола ssh1 - раз в определенное время #

# автоматически генерируется новый временный ключ сервера #

# (если он был использован). Это сделано для #

# предотвращения расшифровки перехваченных сеансов,с целью #

# позже зайти с параметрами этих сеансов на машину и #

# украсть ключи. Такой ключ нигде не хранится (хранится в #

# оперативной памяти). Данная директива указывает период #

# "жизни" ключа в секундах, после которого он будет #

# сгенерирован заново. Если значение задать равным 0 - #

# ключ не будет генерироваться заново. #

# По умолчанию значение - 3600 (секунд). #

# #

KeyRegenerationInterval 3600

# #

## RhostsRSAAuthentication #################################

# #

# Указывает, нужна ли аутентификация на основе файлов #

# rhosts или /etc/hosts.equiv совместно с успешной #

# аутентификацией хоста через RSA. #

# Актуально только для протокола ssh1. #

# По умолчанию - “no”. #

# #

RhostsRSAAuthentication no

# #

## RSAAuthentication #######################################

# #

# Указывает, разрешена ли "чистая" RSA-аутентификация. #

# Актуально только для протокола ssh1. #

# По умолчанию - “yes”. #

# #

RSAAuthentication yes

# #

## ServerKeyBits ###########################################

# #

# Определяет число бит во временном ключе сервера для #

# протокола ssh1. Минимальное значение 512. #

# Значение по умолчанию - 1024. #

ServerKeyBits 768

# #

############################################################

########### Опции протокола SSH версии 2 (ssh2) ############

############################################################

# #

## Ciphers #################################################

# #

# Указывает алгоритмы шифрования, разрешенные для #

# протокола ssh2. Несколько алгоритмов должны быть #

# разделены запятыми. Поддерживаемые алгоритмы: #

# “3des-cbc”, “aes128-cbc”, “aes192-cbc”, “aes256-cbc”, #

# “aes128-ctr”, “aes192-ctr”, “aes256-ctr”, “arcfour128”, #

# “arcfour256”, “arcfour”, “blowfish-cbc”, “cast128-cbc”. #

# По умолчанию используются: #

# aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128, #

# arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr, #

# aes192-ctr,aes256-ctr #

# #

## HostbasedAuthentication #################################

# #

# Указывает, разрешена ли аутентификация, основанная на #

# проверке хоста. Проверяется rhosts или /etc/hosts.equiv, #

# и в случае успеха, совместного с успешной проверкой #

# публичного ключа, доступ разрешается. Данная директива #

# одинакова с директивой RhostsRSAAuthentication и #

# подходит только для протокола ssh2. #

# По умолчанию - "no". #

# #

HostbasedAuthentication no

# #

## MACs ####################################################

# #

# Указывает допустимый алгоритм MAC (message #

# authentication code). Алгоритм MAC используется #

# протоколом ssh2 для защиты целостности данных. Несколько #

# алгоритмов должны быть разделены запятыми. #

# По умолчанию используются: #

# hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160, #

# hmac-sha1-96,hmac-md5-96 #

# #

## PubkeyAuthentication ####################################

# #

# Указывает, разрешена ли аутентификация на основе #

# публичного ключа. Актуально только для протокола ssh2. #

# По умолчанию - “yes”. #

# #

PubkeyAuthentication yes

############################################################

#################### Опции GSSAPI ##########################

############################################################

# #

############ Применимо только для протокола ssh2 ###########

# #

## GSSAPIAuthentication ####################################

# #

# Указывает, разрешена ли аутентификация пользователя на #

# основе GSSAPI. По умолчанию - "no", т.е. запрещена. #

# #

## GSSAPIKeyExchange #######################################

# #

# Указывает, разрешен ли обмен ключами, основанный на #

# GSSAPI. Обмен ключам при помощи GSSAPI не полагается на #

# ssh ключи при верификации идентичности хоста. #

# По умолчанию - "no" - т.е. обмен запрещен. #

# #

## GSSAPICleanupCredentials ################################

# #

# Указывает, нужно ли автоматически уничтожать #

# пользовательский кеш аутентификационных полномочий при #

# завершении сеанса. #

# По умолчанию - "yes" - т.е. нужно уничтожать. #

# #

## GSSAPIStrictAcceptorCheck ###############################

# #

# Указывает, насколько строгой должна быть проверка #

# идентичности клиента при аутентификации через GSSAPI. #

# Значение "yes" заставляет клиента аутентифицироваться в #

# принимающей хост-службе на текущем хосте. Значение "no" #

# позволяет клиенту аутентифицироваться при помощи любого #

# ключа служб. #

# Значение по умолчанию - "yes". #

# Стоит заметить, что задание значения "no" может #

# сработать только с редкими библиотеками Kerberos GSSAPI. #

# #

############################################################

################### Опции Kerberos #########################

############################################################

# #

## KerberosAuthentication ##################################

# #

# Указывает, требует ли пароль, предоставленный #

# пользователем для аутентификации #

# (PasswordAuthentication) валидации в Kerberos KDC. #

# Для использования этой опции серверу нужно #

# удостовериться в истинности KDC. (Тhe server needs a #

# Kerberos servtab which allows the verification of the #

# KDC’s identity) #

# По умолчанию - “no”. #

# #

## KerberosGetAFSToken #####################################

# #

# Если активен AFS и пользователь получил Kerberos 5 TGT, #

# пытаться ли получить AFS токен до того, как пользователь #

# получит доступ к своей домашней папке. #

# По умолчанию - “no”. #

# #

## KerberosOrLocalPasswd ###################################

# #

# Указывает, как поступать в случае, если аутентификация #

# через Kerberos завершилась неудачей. Если #

# значение = "yes" - пароль будет проверен при помощи #

# любого дополнительного локального механизма авторизации, #

# например - /etc/passwd. #

# По умолчанию - “yes”. #

# #

## KerberosTicketCleanup ###################################

# #

# Указывает, нужно ли автоматически уничтожать файл с #

# кешем тикета пользователя по завершению сеанса. #

# По умолчанию - “yes”. #

# #

############################################################

################# Опции перенаправления ####################

############################################################

# #

## AllowAgentForwarding ####################################

# #

# Указывает, разрешить или запретить перенаправление #

# ssh-agent'а. По умолчанию - “yes”, т.е. разрешить. #

# Стоит заметить, что отключение перенаправления не #

# увеличит безопасности пока пользователям также не будет #

# запрещен shell доступ, т.к. они всегда смогут установить #

# свои собственные аналоги агента. #

# #

## AllowTcpForwarding ######################################

# #

# Указывает, разрешить или запретить перенаправление TCP. #

# По умолчанию - “yes”, т.е. разрешить. Стоит заметить, #

# что как и в случае с AllowAgentForwarding отключение #

# перенаправления не увеличит безопасности, пока у #

# пользователей будет консольный доступ, т.к. они смогут #

# установить свои аналоги. #

# #

# #

## GatewayPorts ############################################

# #

# Указывает, разрешать ли удаленным хостам доступ к #

# перенаправленным портам. По умолчанию, sshd слушает #

# соединения к перенаправленным портам только на локальном #

# интерфейсе (loopback). Это не дает другим удаленным #

# хостам подсоединяться к перенаправленным портам. Можно #

# использовать GatewayPorts, чтобы разрешить sshd это #

# делать. Директива может принимать 3 значения: #

# "no" - только loopback. #

# "yes"- любые адреса. #

# "clientspecified" - адреса указанные клиентом. #

# #

## PermitOpen ##############################################

# #

# Указывает куда разрешено перенаправление TCP портов. #

# Указание перенаправления должно принимать одну из #

# следующих форм: #

# PermitOpen host:port #

# PermitOpen IPv4_addr:port #

# PermitOpen [IPv6_addr]:port #

# Несколько записей можно задать, разделяя их пробелами. #

# Аргумент “any” можно использовать для снятия всех #

# запретов на перенаправление портов. По умолчанию любое #

# перенаправление разрешено. #

# #

## PermitTunnel ############################################

# #

# Указывает, разрешено ли перенаправление tun-устройств. #

# Может принимать значения: #

# “yes” #

# “point-to-point” (3-й сетевой уровень) #

# “ethernet” (2-й сетевой уровень) #

# “no” #

# Значение “yes” разрешает одновременно и “point-to-point” #

# и “ethernet”. По умолчанию - “no”. #

# #

############################################################

################## Опции журналирования ####################

############################################################

# #

## SyslogFacility ##########################################

# #

# Задает код объекта журнала для записи сообщений в #

# системный журнал от sshd. Возможные значения: #

# DAEMON #

# USER #

# AUTH #

# LOCAL0 #

# LOCAL1 #

# LOCAL2 #

# LOCAL3 #

# LOCAL4 #

# LOCAL5 #

# LOCAL6 #

# LOCAL7 #

# По умолчанию используется AUTH. #

# #

SyslogFacility AUTH

# #

## LogLevel ################################################

# #

# Задает уровень детальности журнала sshd. #

# Возможные варианты: #

# SILENT #

# QUIET #

# FATAL #

# ERROR #

# INFO #

# VERBOSE #

# DEBUG #

# DEBUG1 #

# DEBUG2 #

# DEBUG3 #

# По умолчанию - INFO. #

# DEBUG и DEBUG1 эквивалентны друг другу. #

# DEBUG2 и DEBUG3 задают самые высокие уровни отладочного #

# вывода. Запись логов с уровнем DEBUG угрожает #

# приватности пользователей и не рекомендована. #

# #

LogLevel INFO

# #

############################################################

################### Перенаправление X11 ####################

############################################################

# #

## X11Forwarding ###########################################

# #

# Указывает, разрешено ли перенаправление графической #

# подсистемы X11. Может принимать значения “yes” или “no”. #

# По умолчанию - “no”. #

# Внимание - включение простого перенаправления Х11 - #

# большой риск как для сервера, так и для клиентов, т.к. в #

# случае такого перенаправления прокси-дисплей sshd #

# принимает соединения с любых адресов. Используйте #

# директиву X11UseLocalhost для ограничения доступа к #

# серверу перенаправления "иксов". Стоит отметить, что #

# отключение перенаправления не даст гарантии, что #

# пользователи не смогут перенаправлять Х11, т.к. имея #

# консольный доступ они всегда установить свой #

# перенаправлятель. Перенаправление Х11 будет #

# автоматически отключено, если будет задействована #

# директива UseLogin. #

# #

X11Forwarding yes

# #

## X11UseLocalhost #########################################

# #

# Указывает, должен ли sshd ограничить область #

# перенаправления Х11 локальным loopback адресом, или #

# должен разрешить любые адреса. По умолчанию - sshd #

# "сажает" сервер перенаправления Х11 на локальный адрес #

# и задает часть переменной окружения DISPLAY, отвечающую #

# за имя хоста как “localhost”. Стоит заметить, что #

# некоторые старые клиенты Х11 могут не работать с такими #

# настройками. По умолчанию - "yes", т.е. перенаправление #

# ограничено локалхостом, значение - “no” - отключает #

# ограничения. #

# #

## XAuthLocation ###########################################

# #

# Указывает полный путь к программе xauth. #

# По умолчанию - /usr/bin/X11/xauth. #

# #

## X11DisplayOffset ########################################

# #

# Указывает номер первого дисплея, доступного sshd в #

# качестве перенаправления X11. Это сделано для того, #

# чтобы перенаправленные "иксы" не пересекались с #

# реальными. По умолчанию - 10. #

# #

X11DisplayOffset 10

# #

############################################################

################### Различные опции ########################

############################################################

# #

## LoginGraceTime ##########################################

# #

# Время, по прошествии которого сервер отключает #

# пользователя, если тот не смог удовлетворительно #

# залогиниться. Значение 0 - разрешает пользователю #

# логиниться бесконечно. По умолчанию - 120 (секунд). #

# #

LoginGraceTime 120

# #

## MaxAuthTries ############################################

# #

# Указывает максимальное число попыток аутентификации, #

# разрешенное для одного соединения. #

# Как только число неудачных попыток превысит половину #

# заданного значения, все последующие попытки будут #

# заноситься в журнал. Значение по умолчанию - 6. #

# #

## MaxSessions #############################################

# #

# Указывает максимальное число одновременных подключений #

# для каждого сетевого соединения. По умолчанию - 10. #

# #

## MaxStartups #############################################

# #

# Указывает максимальное число одновременных #

# неавторизованных подключений к sshd. В случае, если #

# число подключений превысит лимит - все дополнительные #

# подключения будут сброшены до тех пор, пока текущие #

# подключения не завершатся либо успешной авторизацией, #

# либо истечением периода времени указанного в директиве #

# LoginGraceTime. Значение по умолчанию - 10. #

# Дополнительно, можно задать ранний сброс соединений, #

# указав в качестве параметра три значения, разделенные #

# двоеточием “start:rate:full” (например: "10:30:60"). #

# sshd отклонит попытку соединения с вероятностью равной #

# “rate/100” (т.е. в нашем примере - 30%), если уже #

# имеется “start” (10) неавторизованных соединений. #

# Вероятность увеличивается линейно и любые попытки #

# соединения будут отклонены, если число неавторизованных #

# соединений достигнет значения “full” (60). #

# #

## Compression #############################################

# #

# Указывает, разрешено ли сжатие данных. Может быть #

# "yes" - сжатие разрешено. #

# "delayed" - сжатие отложено до тех пор, пока #

# пользователь успешно не аутентифицируется. #

# "no" - сжатие запрещено. #

# По умолчанию - "delayed". #

# #

## UseLogin ################################################

# #

# Указывает, должен ли использоваться login для #

# интерактивного сеанса. Значение по умолчанию - “no”. #

# Стоит отметить, что login никогда не использовался для #

# выполнения удаленных команд. Так же заметим, что #

# использование login сделает невозможным использование #

# директивы X11Forwarding, потому что login не знает, что #

# ему делать с xauth. Если включена директива #

# UsePrivilegeSeparation - она будет отключена после #

# авторизации. #

# #

## UsePrivilegeSeparation ##################################

# #

# Указывает, должен ли sshd разделять привилегии. Если да #

# - то сначала будет создан непривилегированный дочерний #

# процесс для входящего сетевого трафика. После успешной #

# авторизации будет создан другой процесс с привилегиями #

# вошедшего пользователя. Основная цель разделения #

# привилегий - предотвращение превышения прав доступа. #

# Значение по умолчанию - “yes”. #

# #

UsePrivilegeSeparation yes

# #

## StrictModes #############################################

# #

# Указывает должен ли sshd проверить режимы доступа и #

# владения пользовательских папок и файлов перед тем, как #

# дать пользователю войти. Обычно это объясняется тем, что #

# новички часто делают свои файлы доступными для записи #

# всем подряд.По умолчанию - “yes”. #

# #

StrictModes yes

# #

## AcceptEnv ###############################################

# #

# Указывает, какие переменные окружения, переданные #

# клиентом будут приняты. См. опцию SendEnv в клиенте. #

# Стоит заметить, что передача переменных возможна только #

# для протокола ssh2. Переменные указываются по имени, #

# можно использовать маски (‘*’ и ‘?’). Можно указывать #

# несколько переменных через пробел, или разбить на #

# несколько строк AcceptEnv. Будьте осторожны - некоторые #

# переменные окружения могут быть использованы для обхода #

# запрещенных пользовательских окружений. Пользуйтесь этой #

# директивой аккуратно. По умолчанию никакие #

# пользовательские переменные окружения не принимаются. #

# #

AcceptEnv LANG LC_*

# #

## PermitUserEnvironment ###################################

# #

# Указывает, должен ли sshd воспринимать #

# ~/.ssh/environment и опцию environment= в #

# ~/.ssh/authorized_keys. По умолчанию - “no”. Стоит #

# заметить, что разрешение обработки окружения может дать #

# пользователям возможность обойти ограничения в некоторых #

# конфигурациях, использующих такие механизмы, как #

# LD_PRELOAD. #

# #

# #

## PidFile #################################################

# #

# Указывает файл, содержащий идентификатор процесса #

# (process ID, PID) демона SSH. #

# По умолчанию - /var/run/sshd.pid #

# #

# #

## PrintLastLog ############################################

# #

# Указывает, должен ли sshd выводить на экран дату и время #

# последнего севнса при интерактивном входе пользователя. #

# По умолчанию - “yes”. #

# #

PrintLastLog yes

# #

## PrintMotd ###############################################

# #

# Указывает, должен ли sshd выводить на экран /etc/motd #

# при интерактивном входе пользователя. На некоторых #

# системах (например в Ubuntu) эта информация так же #

# выводится на экран оболочкой. #

# Значение по умолчанию - “yes”. #

# #

PrintMotd no

# #

## Banner ##################################################

# #

# Указывает какой файл содержит текстовый баннер, который #

# будет показан пользователю ПЕРЕД процедурой #

# аутентификации. Опция доступна только для протокола ssh2.#

# По умолчанию - не показывает ничего. #

# В Ubuntu файл issue.net содержит фразу Ubuntu {version}, #

# например, для karmic это "Ubuntu 9.10". Можно #

# использовать для дезориентации возможных атакующих, #

# написав туда например "My D-Link Interet Router" =) #

# #

Banner /etc/issue.net

# #

## ChrootDirectory #########################################

# #

# Если указан - предоставляет путь, по которому будет #

# выполнен chroot после аутентификации. Путь и все его #

# содержимое должны соответствовать принадлежащим #

# суперпользователю папкам и быть не доступными для #

# записи другими пользователями. #

# В пути могут быть указаны метки, подставляемые в #

# процессе аутентификации: #

# %% - заменяется литералом '%' #

# %h - заменяется домашней директорией #

# аутентифицируещегося пользователя #

# %u - заменяется именем аутентифицируещегося пользователя #

# chroot-папка должна содержать все необходимые файлы и #

# папки для пользовательского сеанса. Для интерактивного #

# сеанса нужны как минимум: #

# оболочка, обычно - sh #

# базовые устройства в /dev, такие как: #

# null, zero, stdin, stdout, stderr, arandom и tty #

# для сеанса передачи данных при помощи sftp никаких #

# дополнительных настроек не нужно, если используется #

# внутренний процесс sftp сервера. См. Subsystem для #

# большей информации. По умолчанию chroot не выполняется. #

# #

## ForceCommand ############################################

# #

# Заставляет выполняться указанную команду. Игнорирует #

# любые команды переданные клиентом или записанные в #

# ~/.ssh/rc. Команда вызывается из пользовательской #

# оболочки с опцией -с. Подходит для запуска оболочки, #

# команды или подсистемы. Наиболее полезна внутри блока #

# Match. Команда, изначально переданная клиентом, хранится #

# в переменной окружения SSH_ORIGINAL_COMMAND. Если #

# указать команду "internal-sftp", будет запущен #

# внутренний sftp сервер, которому не нужны дополнительные #

# файлы и папки, описанные в директиве ChrootDirectory. #

# #

## Subsystem ###############################################

# #

# Определяет и настраивает внешнюю подсистему (например #

# демона передачи файлов - file transfer daemon). #

# Аргументами служат имя и команда (с возможными #

# аргументами), которая будет выполнена во время запроса #

# на подсистемы. Команда sftp-server запускает “sftp” - #

# подсистему передачи файлов. Дополнительно можно указать #

# в качестве подсистемы “internal-sftp” - что запустит #

# внутренний sftp сервер. Это может значительно упростить #

# настройку в случае использования директивы #

# ChrootDirectory По умолчанию никаких подсистем #

# не вызывается. Актуально только для протокола ssh2. #

# #

Subsystem sftp /usr/lib/openssh/sftp-server

# #

############################################################

##################### Блок Match ###########################

############################################################

# #

# Специально вынес в конец файла, чтобы было удобнее #

# писать Match правила. #

# MadKox. #

# #

# Директива Match представляет собой начало условного #

# блока. Если выполнены все критерии, указанные в строке #

# Match, директивы в последующих строках блока выполняются,#

# позволяя обойти значения глобальных директив файла #

# sshd_config для случая, являющегося критерием директивы #

# Match. Блоком считаются все строки, идущие после строки #

# с критерием (Match - строки) до следующей match-строки #

# или до конца файла. Аргумент директивы Match - одна или #

# несколько пар записей критериев. Возможные виды записей: #

# User #

# Group #

# Host #

# Address #

# Записи могут содержать как одиночные значения #

# (например User=user), так и несколько значений, #

# разделенные запятыми (User=user1,user2). Так же могут #

# быть использованы регулярные выражения, описанные в #

# секции PATTERNS файла ssh_config. Записи в критерии #

# Address могут содержать адреса в нотации CIDR #

# (Адрес/Длинна маски, например “192.0.2.0/24” или #

# “3ffe:ffff::/32”). Стоит заметить, что представленная #

# длинна маски должна соответствовать адресу, и слишком #

# длинные/короткие для адреса не будут работать. #

# В качестве директив Match может использовать только #

# определенный набор директив: #

# AllowTcpForwarding #

# Banner #

# ChrootDirectory #

# ForceCommand #

# GatewayPorts #

# GSSAPIAuthentication #

# HostbasedAuthentication #

# KbdInteractiveAuthentication #

# KerberosAuthentication #

# MaxAuthTries #

# MaxSessions #

# PasswordAuthentication #

# PermitOpen #

# PermitRootLogin #

# RhostsRSAAuthentication #

# RSAAuthentication #

# X11DisplayOffset #

# X11Forwarding #

# X11UseLocalHost #

1. Колисниченко Д. Н. К60 Linux. От новичка к профессионалу. — 6-е изд., перераб. и доп. — СПб.: БХВ-Петербург, 2018. — 672 с.: ил. — (В подлиннике)

   https://www.ssh.com/ssh ↑

2. https://www.ssh.com/ssh ↑

3. https://www.ssh.com/ssh ↑

4. https://www.ssh.com/ssh ↑

5. https://www.ssh.com/ssh ↑

6. https://www.ssh.com/ssh ↑

7. https://www.ssh.com/ssh ↑

8. https://www.ssh.com/ssh ↑

9. https://www.ssh.com/ssh ↑

10. https://www.ssh.com/ssh ↑

11. https://www.ssh.com/ssh ↑

12. https://www.ssh.com/ssh ↑

13. https://www.ssh.com/ssh ↑

14. https://www.ssh.com/ssh ↑

15. https://www.ssh.com/ssh ↑

16. https://help.ubuntu.ru/wiki/ssh ↑

17. https://help.ubuntu.ru/wiki/ssh#fn__2 ↑

18. https://help.ubuntu.ru/wiki/ssh ↑

19. https://docs.microsoft.com/ru-ru/windows-server/administration/openssh/openssh_install_firstuse ↑

20. https://docs.microsoft.com/ru-ru/windows-server/administration/openssh/openssh_install_firstuse ↑