Linux посмотреть параметры ssh сервера

Установка и настройка сервера SSH в Linux

Secure Shell, т. е. SSH – протокол, обеспечивающий защищённые соединения и передачу данных между двумя удалёнными компьютерами. Изначально создавался на замену таким системам как rlogin и rcp. Как понятно из полного названия протокола, система SSH позволяет соединяться и управлять удалённым узлом (компьютером, маршрутизатором и т. д.), при этом защищая весь передаваемый трафик с помощью высоконадёжного шифрования.
SSH широко применяется администраторами серверов для их настройки и управления, да и обычные продвинутые пользователи — владельцы, например, сайтов или виртуальных серверов активно используют SSH для подключения к своей учётной записи на хостинге и использования командной оболочки сервера.
Сразу после окончания разработки система SSH стала активно трансформироваться в закрытый коммерческий продукт в виде версии SSH2. Но благодаря сообществу GNU версии протокола SSH1 и SSH2 были реализованы в виде открытого и свободно распространяемого ПО openSSH. В Linux-системах используется именно этот метапакет.
Метапакет SSH базово включает в себя сервер SSH (sshd) в качестве програмы-демона, а также несколько утилит: ssh – удаленная регистрация и выполнение команд, scp – передача файлов и ssh-keygen – для генерации пар SSH-ключей.

Установка пакетов SSH

Как уже говорилось система ssh в Linux-системах распространяется в виде составного метапакета, поэтому для установки всех требуемых утилит ssh нужно выполнить всего одну команду:
В Ubuntu

После чего начнется процесс установки

Как видно, менеджер пакетов сам распознает все зависимые и связанные пакеты и установит их. Также, по завершению установки, автоматически будет запущен SSH-сервер в режиме демона. Это можно проверить командой:
$ systemctl status sshd
или:
$ service sshd status даст тот же вывод. Теперь сервер работает с базовыми настройками по-умолчанию.

Настройка SSH

Режим работы SSH-сервера с настройками по-умолчанию хоть и является вполне работоспособным для небольших частных сетей, всё же нуждается в задании некоторых важных параметров для использования на высоконадёжных публичных серверах. Настройки демона хранятся в файле /etc/ssh/sshd_config. Посмотреть его можно командой

В первую очередь следует обратить внимание на следующие параметры: Port, AddressFamily, ListenAddress. Первый глобально задаёт номер порта, через который будет работать соединение и если оставить его стандартным, т. е. 22, то велика вероятность, что он будет слишком часто сканироваться роботами.
Примечание: для задания активации параметра необходимо раскомментировать соответствующую строку — убрать символ «#» в её начале.
Второй параметр задаёт семейство используемых IP-адресов — IPv4 и IPv6. Если, к примеру, используются только адреса IPv4, то очень рекомендуется установить для параметра

Для адресов семейства IPv6 используется значение inet6.
Параметр ListenAddress позволяет задавать порты для отдельных сетевых интерфейсов:

Поскольку реализация openSSH позволяет работать с протоколами SSH1 и SSH2, то разумно отключить использование SSH1, т. к. эта версия является устаревшей. Работа по SSH1 крайне не рекомендуется: Protocol 2
Очень полезным является параметр, позволяющий проводить авторизацию и шифрование трафика с помощью специальных SSH-ключей:

Следует заметить, что в таком случае серверу необходимо явно указывать, где хранятся открытые ключи пользователей. Это может быть как один общий файл для хранения ключей всех пользователей (обычно это файл etc/.ssh/authorized_keys), так и отдельные для каждого пользователя ключи. Второй вариант предпочтительнее в силу удобства администрирования и повышения безопасности:
AuthorizedKeysFile etc/ssh/authorized_keys # Для общего файла
AuthorizedKeysFile %h/.ssh/authorized_keys # Файл -> пользователь
Во втором варианте благодаря шаблону автоподстановки с маской «%h» будет использоваться домашний каталог пользователя.
Важно также отключать парольный доступ:

Или же, в случае, если всё-таки необходимо использовать доступ по паролю, то обязательно нужно отключать авторизацию по пустому паролю:

Для указания разрешённых или запрещённых пользователей и групп служат директивы DenyUsers, AllowUsers, DenyGroups, и AllowGroups. Значениями для них являются списки имён, разделяемых пробелами, например:

Следует также отключать root-доступ:

Иногда, когда следует задавать мультисерверную конфигурацию, очень удобно использовать алиасы (Aliases), что позволяет настроить сразу несколько режимов доступа (с разными хостами, портами и т. д.) и использовать их, указывая при этом конкретный алиас:

Настройки для алиасов хранятся либо глобально в /etc/ssh/ssh_config, либо раздельно для пользователей в

/.ssh/config. Здесь нужно не спутать с ssh_config! Пример:

Для применения сделанных настроек необходим перезапуск SSH-сервера:

Настройка и использование клиента SSH
Для подключения по к серверу используется команда:

где user_name – имя пользователя в системе, host_name – имя узла, к которому производится подключение, например:

При этом утилита ssh запросит (в зависимости от настроек сервера) логин, пароль или парольную фразу для разблокировки приватного ключа пользователя.
В случае авторизации по ключу, должна быть предварительно сгенерирована пара SSH-ключей — открытый, который хранится на стороне сервера, обычно в файле .ssh/authorized_keys в домашнем каталоге пользователя, и закрытый — используется для авторизации клиента и хранится, как правило, в каталоге .ssh/ домашней директории пользователя. Открытый ключ представляет собой «цифровой слепок» закрытого ключа благодаря которому сервер «знает», кто «свой», а кто «чужой».
Для генерации ключей используется утилита ssh-keygen:

Читайте также:  Easy tune6 amd windows 10 x64

Утилита предложит выбрать расположение ключей (лучше всё оставить по-умолчанию), обычно это каталог

/.ssh/, ввести парольную фразу для закрытого ключа. После чего будут сгенерированы открытый ключ id_rsa.pub и закрытый — id_rsa. Теперь нужно скопировать открытый ключ, т. е. «слепок» закрытого на сервер. Проще всего этого можно добиться командой:

Теперь можно выполнить подключение командой ssh и запустить защищённый сеанс удалённого управления.
Важно заметить, что использование сгенерированных openSSH-ключей несовместимо с PPK-форматом, используемым по-умолчанию в таких комплексах как PuTTY. Поэтому необходимо конвертировать имеющиеся openSSH-ключи в формат PPK. Удобнее всего это делать с помощью утилиты PuTTY – puttygen.exe.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

Насторйка OpenSSH

Настройка SSH сервера

Настройки sshd находятся в файле /etc/ssh/sshd_config. Открываем этот файл для редактирования и изменяем его содержимое для наших нужд, не забывая при этом о безопасности.

Первый параметр – Port. По умолчанию используется 22 порт. Изменим его на нестандартный порт 2203 – это избавит наш сервер от сетевых роботов, которые автоматически сканируют интернет в поиске открытых портов и пытаются через них подключиться. Это не избавит от сканирования человеком, но для защиты от человека существует фаервол, хитрые способы открытия порта, «горшочки с мёдом» и т. д.

Port 2203

Теперь, чтобы подключиться к серверу нужно будет явно указать порт. Например, так:

$ ssh –l andrey –p 2203 192.168.123.254

$ ssh andrey@sunup.aitishnik.local –p 2203

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

#ListenAddress ::

#ListenAddress 0.0.0.0

Эти строки отвечают за настройку разграничений по сетевым интерфейсам, сетевому адресу или имени компьютера. По умолчанию сервер «слушает» (принимает подключения) на всех сетевых интерфейсах. Нас это устраивает, поэтому мы оставляем значение по умолчанию. Если бы нам нужно было оставить подключение только через внешний интерфейс, то раскомментировав строку мы бы написали:

В этой же строке можно явно указать порт, предварительно закомментировав (поставив символ # в начале строки) первую строку – Port 2203:

Следующий параметр отвечает за версию протокола SSH. Значение по умолчанию 2. Его и оставляем. Не добавляем единичку ни при каких обстоятельствах. Первая версия протокола SSH не безопасна!

Protocol 2

Строки HostKey необходимы для второй версии протокола SSH и отвечают за названия файлов ключей и их расположение. Первая строка отвечает за пару ключей RSA, вторая соответственно за пару ключей DSA. К названиям открытых (публичных) ключей добавляется .pub. Эти ключи используются при аутентификации с ключом хоста. Можно поменять слово host в названии ключей на имя нашего сервера, но мы сделаем это в части, посвященной генерации ключей. Сейчас же отключим ключи DSA, так как будем пользоваться только RSA:

HostKey /etc/ssh/ssh_host_rsa_key

#HostKey /etc/ssh/ssh_sunup_dsa_key

Строка Privilege Separation указывает, должен ли демон ssh (sshd) разделять привилегии. Если да — то сначала будет создан непривилегированный дочерний процесс для входящего сетевого трафика. После успешной авторизации будет создан другой процесс с привилегиями вошедшего пользователя. Основная цель разделения привилегий — предотвращение превышения прав доступа. Оставляем yes.

UsePrivilegeSeparation yes

Следующие строки отвечают за временный ключ и его длину при работе с первой версией протокола SSH. Мы не используем SSH-1, поэтому пока закомментируем эти строки.

# KeyRegenerationInterval 3600

# ServerKeyBits 768

Далее следует группа параметров, отвечающая за журналирование. События, связанные с доступом по SSH записываются в журнал /var/log/auth

Первый параметр определяет, список каких событий администратор хочет видеть в журнале. Доступны следующие значения: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. Нас интересует авторизация, поэтому оставляем AUTH.

SyslogFacility AUTH

Второй параметр определяет уровень детализации событий. Доступны следующие события: SILENT , QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, DEBUG3. Оставляем уровень детализации по умолчанию, если возникнут ошибки, то всегда можно увеличить детализацию журнала.

LogLevel INFO

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

LoginGraceTime 60

Второй параметр разрешает или запрещает вход по SSH под суперпользователем. Запрещаем вход суперпользователю.

PermitRootLogin no

Третий параметр включает проверку демоном ssh прав и владение домашним каталогом пользователя, который пытается получить удалённый доступ к компьютеру. Оставляем yes.

StrictModes yes

Добавляем параметр AllowUsers, которого нет в конфигурационном файле по умолчанию. Этот параметр разрешает доступ к серверу по протоколу SSH только для перечисленных пользователей.

AllowUsers andrey

В нашем примере разрешение есть только у пользователя andrey. Значениями этого параметра могут выступать имена пользователей, отделённые друг от друга пробелами. Нельзя использовать в качестве значений UID (User ID). Можно использовать запись пользователя в виде user@host, например andrey@echidna. Это означает, что доступ разрешён пользователю andrey с компьютера echidna. Причём пользователь и компьютер проверяются отдельно, это позволяет разграничить доступ определенных пользователей с определенных компьютеров. Существует обратный параметр – DenyUsers, который запрещает доступ пользователям, перечисленным в значении этого параметра. Кроме параметров связанных с доступом отдельных пользователей существуют соответствующие параметры для групп: AllowGroups и DenyGroups.

Читайте также:  Как открыть текстовым редактором открой его линуксе

Оставляем включенной аутентификацию RSA, в параметре RSAAuthentication:

RSAAuthentication yes

Оставляем включенной аутентификацию по открытому ключу, в дальнейшем мы настроим аутентификацию таким способом.

PubkeyAuthentication yes

Параметр AuthorizedKeysFile определяет файл, в котором содержатся публичные ключи, используемые для аутентификации пользователей по открытому ключу. В записи могут присутствовать переменные, например %h означает домашний каталог пользователя, а %u – имя пользователя. В дальнейшем мы планируем использование аутентификации по открытому ключу — раскомментируем эту строку.

AuthorizedKeysFile .ssh/authorized_keys

Следующие два параметра отвечают за включение совместимости с программой rhosts. Нам такая совместимость только повредит, поэтому оставляем значения по умолчанию.

IgnoreRhosts yes

RhostsRSAAuthentication no

Аутентификация hostbased нам тоже не нужна и она уже отключена, поэтому оставляем существующее значение

HostbasedAuthentication no

Следующая строка нужна для совместимости с rhost – оставляем закомментированной.

#IgnoreUserKnownHosts yes

Параметр PermitEmptyPasswords разрешает или запрещает вход с пустым паролем. Естественно, запрещаем вход с пустым паролем – оставляем no.

PermitEmptyPasswords no

Параметр ChallengeResponseAuthentication включает PAM интерфейс. Если задано значение yes, то для всех типов аутентификации помимо обработки модуля сессии и аккаунта PAM, будет использоваться аутентификация на основе запроса-ответа (ChallengeResponseAuthentication и PasswordAuthentication) Т.к. аутентификация запросов-ответов в PAM обычно выполняет ту же роль, что и парольная аутентификация, следует отключить, либо PasswordAuthentication, либо ChallengeResponseAuthentication.

ChallengeResponseAuthentication no

Следующий параметр отвечает за аутентификацию по паролю. Сейчас используется аутентификация по ключу хоста — просто раскомментируем строку.

PasswordAuthentication yes

Группу из четырёх параметров, отвечающих за аутентификацию Kerberos, оставляем без изменений – не раскомментированными.

#KerberosAuthentication no

#KerberosGetAFSToken no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes

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

#GSSAPIAuthentication no

#GSSAPICleanupCredentials yes

Параметры, начинающиеся с X11, отвечают за проброс иксов через ssh туннель. Ниш сервер не имеет иксов, поэтому закомментируем эти опции

# X11Forwarding yes

# X11DisplayOffset 10

Опция PrintMotd выводит при подключении к sshd так называемое сообщение дня, что на самом деле является содержимым файла /etc/motd. Опция PrintLastLog очень полезна, так как она включает отображение информации о том, когда вы последний раз и с какого компьютера заходили на сервер.

PrintMotd no

PrintLastLog yes

Установим параметру TCPKeepAlive значение no. Этот параметр важен для поддержания соединения со стороны сервера, но мы реализуем те же функции, но более безопасней.

TCPKeepAlive no

Для этого добавим два следующих параметра:

ClientAliveCountMax 3

ClientAliveInterval 20

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

Параметр UseLogin оставляем закомментированным. Его значение по умолчанию и так no.

#UseLogin no

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

MaxStartups 3:30:9

По умолчанию значение данного параметра 10. Это количество неавторизованных подключений к серверу ssh. Длительность такого подключения определяется параметром LoginGraceTime, описанным выше. Перенесём параметр MaxStartups под LoginGraceTime и запишем в виде start:rate:full, где start – это уже имеющееся количество неавторизованных подключений, rate – процент вероятности отклонения попытки подключения, full – максимальное количество неавторизованных соединений. В нашем примере, если уже имеется 3 неавторизованных подключения, то следующее подключение будет отклонено с вероятностью 30%, а если количество неавторизованных подключений достигнет 9, то все последующие попытки подключения будут отвергнуты.

Опция Banner определяет место положения файла-баннера, который будет выведен на экран, при попытке подключиться к серверу sshd. Предлагается файл /etc/issue.net, но можно использовать свой баннер, поместив его, например в /etc/ssh. В Debian по умолчанию выводится содержимое файла /etc/motd.tail. Оставляем как есть.

#Banner /etc/issue.net

Лучше добавим ещё один полезный параметр, который отсутствует в файле sshd_config – DebianBanner. Этот параметр добавляет в строку ответа sshd информацию об операционной системе, при обращению к серверу по протоколу TELNET или при сканировании nmap. Эта строка может выглядеть так: SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze1. Скроем информацию о нашей операционной системе.

Читайте также:  Режим ahci windows не загружается

DebianBanner no

Теперь строка ответа будет выглядеть так: SSH-2.0-OpenSSH_5.5p1

Параметр AcceptEnv указывает, какие переменные окружения, переданные клиентом, будут приняты.

AcceptEnv LANG LC_*

Следующий параметр включает внешнюю подсистему (например, FTP). В качестве параметров понимает, имя подсистемы и команду, которая будет выполнена при запросе подсистемы. Команда sftp-server, реализует протокол передачи файлов через SSH — SFTP.

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

Параметр UsePAM оставляем без изменений. Если директива UsePAM включена, то запустить sshd можно будет только от имени root.

UsePAM yes

Сохраняем изменения и перезапускаем sshd. Подключаемся, проверяем, если всё в порядке, то настройка сервера ssh с аутентификацией оп ключу хоста закончена. Для разрешения проблем и вывода отладочной информации можно подключаться с ключами: -v, -vv, -vvv.

Настройка ssh клиента

В Debian настройки клиентской части ssh делятся на глобальные и пользовательские. Глобальные клиентские настройки находятся в файле /etc/ssh/ssh_config и применяются ко всем пользователям. Пользовательские настройки могут находиться в домашнем каталоге пользователя, в

/.ssh/config и применяются к одному пользователю. Файл пользовательских настроек не создаётся автоматически в отличие от файла глобальных настроек клиентской части ssh. Для большинства выполняемых задач подойдут настройки по умолчанию, но для удобства использования, так сказать для тюнинга или для выполнения нестандартных задач клиентские настройки изменяются. Рассмотрим вкратце некоторые из этих настроек. Полезно помнить о приоритетах настроек: высший приоритет имеют ключи командной строки, затем следуют настройки пользователя, а после них используются глобальные настройки клиентской части.

Параметр Host. Ограничивает множество хостов, к которым применяются последующие (до ближайшей новой директивы Host) директивы, по указанным шаблонам (хост должен соответствовать хотя бы одному шаблону). Шаблон, состоящий из одного символа *, соответствует любому хосту. Под хостом в данном контексте понимается аргумент имя_хоста передаваемый в командной строке (т.е. никаких преобразований перед сравнением не выполняется).

Параметр HostName. Устанавливает соответствие между псевдонимами, сокращениями и настоящими именами хостов. По умолчанию используется имя, передаваемое в командной строке. Допустимо непосредственное указание IP-адресов.

Параметр Port. Порт на удалённой машине, к которому следует подключаться. Значение по умолчанию — 22

Параметр User. Имя пользователя, которое следует использовать при регистрации в удалённой системе. Полезно, когда на разных серверах используются разные имена, т.к. избавляет от надобности вспоминать каждый раз нужное имя.

В качестве примера я создам файл пользовательских настроек /home/selifan/.ssh/config следующего содержания:

Теперь при подключении к компьютерам sunup.aitishnik.local, windbag или по ip адресу 212.177.65.1 мне не нужно вспоминать, ни имя пользователя, ни ssh порт подключения, достаточно после ssh набрать имя сервера. Просто и удобно! Описания всех параметров, значений и некоторых примеров находятся в man ssh_config. Продолжаем настраивать SSH и читаем «Генерация ключей SSH».

Помните, что у нас вы можете не только купить готовый сайт или заказать его разработку, но и подобрать подходящий тариф поддержки сайта, заказать продвижение сайта в поисковых системах, а так же зарегистрировать домен в одной из двухсот доменных зон и выбрать недорогой тариф хостинга! Айтишник РУ

Об авторе:

Меня зовут Андрей Золкин. Из более, чем пятнадцати лет работы в сфере информационных технологий, десять лет работаю с системами, базирующимися на открытом исходном коде. На страницах сайта Aitishnik.Ru веду блоги по CMC Joomla и Debian GNU/Linux.

Ещё статьи о Debian

Установка Debian

Эта статья об установке операционной системы Debian GNU/Linux. Тема статьи достаточно обширна и это скорее тема для книги, нежели для статьи. Мне бы хотелось сделать статью «на вырост», т. е. со временем дополняя её ссылками на другие.

Локальный хостинг на XAMPP в Debian

Эта статья своим появлением обязана блогу о Joomla 3. В блоге о Joomla в числе прочего рассматривается возможность создания локального хостинга на домашнем компьютере под управлением операционной системы Windows. Организация домашнего хостинга производится с помощью пакета XAMPP. Этот.

Настройка беспроводной карты (Wi Fi)

Попробовать настроить беспроводную карту (Wi Fi) в Debian можно ещё на этапе установки системы. Но на этапе установки поддерживается только алгоритм защиты WEP. Если используются более стойкий алгоритм защиты, то настройкой беспроводной.

Настройка FTP сервера. Конфигурация с шифрованием SSL.

Теперь изменим нашу конфигурацию ftp сервера следующим образом: анонимные пользователи не используются. Используются только виртуальные пользователи, учётные записи которых хранятся в MySQL. Для каждого пользователя можно задать свою.

Изменяем приветствие в SSH Debian

Все, кто совершал вход в систему Debian через консоль или посредством SSH, видели следующее сообщение: The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described.

Настройка FTP сервера. Более сложная конфигурация.

Рассмотрим более сложную конфигурацию ftp сервера: анонимные пользователи всё так же имеют доступ только на чтение. Локальные пользователи не используются. Вместо них используются виртуальные пользователи, учётные записи которых хранятся.

Источник

Оцените статью