С помощью защищенного протокола SSH администраторы подключаются к своим серверам для безопасной работы. Рассмотрим особенности этого протокола подробнее:
Что такое SSH-протокол
SSH-протокол (от англ. Secure Shell ) - криптографический сетевой протокол, предназначенный для удаленного доступа к операционной системе и осуществления безопасного удаленного управления в рамках незащищенной сети (например, через интернет).
SSH обеспечивает защищенный канал связи между клиентом и сервером, через который можно передавать данные (почтовые, видео, файлы), работать в командной строке, удаленно запускать программы, в том числе графические. SSH-сервер должен быть установлен на удаленной операционной системе. SSH-клиент должен быть запущен на машине, с которой будет осуществляться удаленное подключение.
Основные функции, доступные при использовании SSH-протокола:
- Передача любых данных через защищенное SSH-соединение, включая сжатие данных для последующего шифрования.
- X11 Forwarding - механизм, позволяющий запускать программы UNIX/Linux-сервера в виде графической оболочки, как в Windows (использовать X Window System).
- Переадресация портов - передача шифрованного трафика между портами разных машин.
Безопасность SSH-соединения обеспечивается:
- шифрованием данных одним из существующих алгоритмов
- аутентификацией сервера и клиента одним из нескольких доступных методов
- наличием дополнительных функций протокола, направленных на предупреждение различных хакерских атак
Аутентификация сервера дает защиту от:
- взлома путем подмены IP-адресов (IP-spoofing), когда один удаленный хост посылает пакеты от имени другого удаленного хоста
- подмены DNS-записей (DNS-spoofing), когда подменяется запись на DNS-сервере, в результате чего соединение устанавливается с хостом, который указан в подмененной записи, вместо необходимого
- перехвата открытых паролей и других данных, передаваемых в открытом виде через установленное соединение
На сегодняшний день существуют две версии протокола SSH (SSH-1 и SSH-2), причем вторая версия усовершенствована и расширена по сравнению с первой. Например, вторая версия устойчива к атакам вида MITM («человек посередине», атака посредника). Также существуют две редакции данного протокола: открытая версия (бесплатная) и коммерческая (платная). Бесплатная версия - OpenSSH - встроена во все UNIX-подобные операционные системы в виде стандартных утилит SSH-клиента и SSH-сервера.
Коммерческая реализация SSH-протокола - SSH Communications Security - разработана одноименной организацией. Имеет небольшие отличия от бесплатной версии, такие как доступность коммерческой технической поддержки, наличие инструментов веб-управления и др. Основной набор команд и возможностей практически одинаковый у обоих продуктов.
Для ОС Windows выпущены различные SSH-клиенты и оболочки, самые распространенные из них - это бесплатные PuTTY и WinSCP . Для других операционных систем также существуют свои SSH-клиенты.
Что такое SFTP-протокол
SFTP-протокол (от англ. SSH File Transfer Protocol ) – сетевой протокол прикладного уровня, предназначенный для передачи файлов и других действий с ними через имеющееся надежное соединение. Протокол был разработан как расширение SSH-2, предназначенное для операций с файлами по защищенному каналу, однако может работать и с другими протоколами, обеспечивающими безопасное соединение сервера с клиентом. Иными словами, для надежной работы через SFTP-протокол необходимо иметь установленное защищенное соединение (например, SSH), которое проводит аутентификацию клиента и сервера и устанавливает факт их надежности, поскольку сам SFTP-протокол не проводит аутентификацию и не обеспечивает безопасность.
SFTP имеет ряд преимуществ перед своими предшественниками - FTP и SCP - таких, как прерывание передачи файла, удаление, возобновление передачи, связь переданных файлов с основными атрибутами, например, меткой даты/времени, а также более высокая платформонезависимость.
SFTP-протокол реализуется через SFTP-сервер и SFTP-клиент, которые являются подсистемами OpenSSH.
Для чего используются SSH и SFTP протоколы
Чаще всего протоколы SSH и SFTP используются для удаленной работы с операционной системой или переноса большого количества файлов.
Например, клиент берет в аренду сервер или какую-то часть серверного пространства. Возникает необходимость переносить туда уже имеющиеся данные клиента, например, сайт или почтовые файлы. Провайдер должен обеспечить надежность и быстроту обмена данными с его сервером, особенно если речь идет о больших объемах информации и ее высокой конфиденциальности. В этом случае на удаленной машине (в данном случае - виртуальном сервере) устанавливается SSH-сервер (со встроенным SFTP-протоколом), а на клиентском компьютере - SSH-клиент. Создается SSH-туннель, и обмен данными между клиентом и удаленным сервером осуществляется через надежное соединение со всеми преимуществами протокола, описанными выше.
Также SSH может использоваться для удаленной работы по защищенному соединению с различными сервисами провайдера, такими как программное обеспечение, операционные системы и т.д.
Как работает SSH
По протоколу SSH работает набор программ, служащих для выполнения различных действий на удаленной операционной системе. Например, программа sshd обеспечивает серверную функциональность SSH, она должна быть запущена на SSH-сервере. Программа ssh запускается на SSH-клиенте и позволяет устанавливать соединение с удаленным хостом, регистрироваться на нем, работать с удаленной машиной через SSH-соединение.
Для запуска тех или иных программ SSH-протокола существуют специальные команды с набором различных опций. Эти команды могут отличаться в зависимости от используемой клиентской операционной системы и оболочки SSH-клиента. Команды запускаются либо из командной строки, если речь идет о UNIX-подобных системах, либо посредством графического интерфейса в соответствующих SSH-оболочках.
Как подключиться по SSH
Если на вашем компьютере установлена ОС Windows, а на удаленной машине UNIX-подобная система (например, Linux), то для установки SSH-соединения можно использовать PuTTY . Это бесплатная программа под Windows состоит из одного запускаемого файла и не требует инсталляции.
Чтобы установить соединение при помощи PuTTY, необходимо проделать следующие действия.
Запустить PuTTY (putty.exe).
По умолчанию никаких дополнительных настроек проводить не нужно, можно убедиться, что указан 22-й порт и тип соединения Connection type - SSH. В поле Host Name (or IP address) нужно ввести имя удаленного компьютера или его IP-адрес и нажать кнопку Open .
Может появиться предупреждение системы безопасности PuTTY, однако если есть уверенность в том, что хост достоверен, то нужно нажать Да и продолжить соединение.
В появившейся командной строке нужно ввести имя пользователя, под которым будет выполняться вход на удаленный компьютер.
В следующей строке нужно ввести пароль для данного пользователя. При вводе пароля никакие символы в командной строке не отображаются, поэтому необходимо просто набрать пароль и нажать клавишу ввода (Enter). Если введены неправильные имя пользователя и пароль, то выведется ошибка « Access denied », в случае успешного подключения предоставляется командная строка удаленного компьютера.
SSH (Secure Shell) — это сетевой протокол, предназначенный для удалённого управления сервером и передачи данных по зашифрованным TCP соединениям. Большинство хостингов , даже виртуальных, сегодня предоставляет доступ как по FTP, так и по SSH. На мой взгляд, это здорово, SSH намного удобнее и безопаснее в использовании.
Настройка SSH
Настройка будет происходить под выделенный сервер, VDS, VPS на Debian, Ubuntu. Конфигурационный файл располагается тут: /etc/ssh/sshd_config .
Если у вас обычный хостинг, всё и так должно быть настроено как надо, переходите к разделу .
По умолчанию, демон SSHD (именно в него мы вносим изменения) не нуждается в каких-либо настройках и работает нормально. Мы внесём лишь пару небольших изменений с целью ограничить доступ нежелательных лиц к серверу.
В результате внесения неправильных изменений в конфигурационный файл вы можете потерять доступ к серверу по ssh, поэтому убедитесь, что у вас есть альтернативные варианты для доступа к нему, например, с помощью панели управления ISPManager.
Как ограничить доступ по SSH
Все изменения вносятся в /etc/ssh/sshd_config
Чтобы изменения вступили в силу, необходимо
Сменить порт
Port 9724Теперь при авторизации вам нужно вместо стандартного 22 порта указывать 9724 .
Способ очень простой и действенный против большинства простых ботов хакеров, которые стучатся в стандартные порты. Тут главное не создать конфликт с другими службами и подобрать заведомо неиспользуемое число.
Запретить связь по старому протоколу
Здесь мы определяем, что связь возможна только по протоколу v2
Если вы авторизованы не под root , перед всеми консольными командами нужно добавлять sudo — расшифровывается как Substitute User and DO — подмени юзера и делай (под ним). Например, позволяет исполнять команды от имени суперпользователя root .
Уменьшить число попыток авторизации
MaxAuthTries 2Количество попыток ввода пароля. По умолчанию 6. При неудачном переборе сеанс связи обрывается.
Уменьшить время ожидания авторизации
LoginGraceTime 30sПо умолчанию, 120 секунд может длиться сеанс авторизации. По истечению этого времени он обрывается. 2 минуты на авторизацию — это перебор, всё это время сервер держит связь открытой, что очень нерационально. Полминуты за глаза хватит.
Закрыть доступ по IP
Если доступ нужен только вам, самым простым и надёжным будет закрыть доступ отовсюду, кроме вашего IP или, если он динамический, то диапазона IP.
- Открываем /etc/hosts.allow и добавляем туда
SSHD: 192.168.1.1
где 192.168.1.1 — ваш IP. Если у вас динамический IP, определите IP с маской подсети и запишите Вашу подсеть вместо IP, например:
SSHD: 192.168.0.0/16
- Открываем /etc/hosts.deny и добавляем туда: SSHD: ALL
Ещё один способ ограничения доступа по IP
Можно воспользоваться следующей директивой:
AllowUsers = *@1.2.3.4
Здесь мы разрешаем доступ только для IP 1.2.3.4
Авторизация SSH по ключам
Намного безопаснее, удобнее и правильнее будет настроить ssh авторизацию без пароля. Для этого будет использоваться авторизация по ключу.
Итак, вот инструкция:
Подключение настроено. Если что-то сделали не так, при авторизации появится ошибка Server refused our key , то есть Сервер не принял наш ключ . В этом случае пройдитесь по всем пунктам последовательно и поищите ошибку
Спасибо MadKox
Пример конфигурационного файла# Условные обозначения: #
# Под "по умолчанию" подразумевается поведение sshd при #
# неуказанной явно директиве. Стоит заметить, что в Ubuntu #
# файл sshd_config уже содержит ряд настроек, которые #
# являются настройками по умолчанию для именно для Ubuntu. #
# Такие настройки указаны в этом файле. #
# #
################ Настройки адресов/портов и т.д. ###########
############################################################
# #
## Port ####################################################
# #
# Используемый порт. Можно указывать несколько, например: #
# Port 22 #
# Port 23 #
# Port 24 #
# Рекомендуется использовать нестандартный порт, т.к. #
# стандартный часто сканируется ботами на предмет #
# потенциальных "дырок". Может быть опущен, если задан #
# через адрес. См. также параметр ListenAddress. #
# #
Port 8022
# #
## ListenAddress ###########################################
# #
# Сетевой адрес, на котором "слушает" сервер. Адрес можно #
# записывать так: #
# ListenAddress host|IPv4_addr|IPv6_addr #
# ListenAddress host|IPv4_addr:port #
# ListenAddress :port #
# Если порт не задан, sshd будет слушать на этом адресе и #
# на порту, указанному в опции Port. Если вы будете #
# использовать ListenAddress не указывая порт, то опция #
# Port должна предшествовать опции ListenAddress. Если не #
# указывать, то по умолчанию слушает на всех локальных #
# адресах. Можно указывать несколько адресов. #
# #
## AddressFamily ###########################################
# #
# Указывает, какое семейство IP адресов должно быть #
# использовано sshd. Возможные варианты: #
# “any” любые #
# “inet” (только IPv4) #
# “inet6” (только IPv6) #
# По умолчанию “any”. #
AddressFamily inet
# #
## UseDNS ##################################################
# #
# Указывает, должен ли sshd проверять имя хоста и #
# используя это имя сверять IP адрес переданный клиентом с #
# полученным от DNS. #
# #
############################################################
############# Настройки доступа пользователей ##############
############################################################
# #
# Пустить/не пустить пользователя определяется директивами #
# 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 #
# задан равным
5 и ClientAliveCountMax оставлен по #
# умолчанию, неотвечающие клиенты будут отключены примерно #
# через 45 секунд. Эта директива работает только для #
# протокола ssh2. #
# #
## ClientAliveInterval #####################################
# #
# Задает временной интервал в секундах. Если в течении #
# этого интервала не было обмена данными с клиентом, sshd #
# посылает сообщение по зашифрованному каналу, #
# запрашивающее ответ от клиента. По умолчанию 0, т.е. #
# не посылать таких сообщений. Эта директива работает #
# только для протокола ssh2. #
# #
############################################################
################ Общие опции аутентификации ################
############################################################
# #
## AuthorizedKeysFile ######################################
# #
# Указывает файл, в котором содержатся публичные ключи, #
# используемые для аутентификации пользователей. Директива #
# может содержать маркеры вида %М, которые подставляются в #
# процессе установки соединения. #
# Определены следующие маркеры: #
# Таким образом, файл с ключами может быть задан как #
# абсолютным путем (т.е. один общий файл с ключами), так и #
# динамически в зависимости от пользователя (т.е. по #
# файлу на каждого пользователя). #
# По умолчанию “.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 #
# в процессе аутентификации, основанной на проверке хоста. #
# Файлы /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 no
# #
## 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”. #
# #
PasswordAuthentication yes
#
## HostKey #################################################
# #
# Указывает файл, содержащий закрытый хост-ключ, #
# используемый SSH. По умолчанию /etc/ssh/ssh_host_key #
# для протокола ssh
и /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. #
# По умолчанию “no”. #
# #
RhostsRSAAuthentication no
# #
## RSAAuthentication #######################################
# #
# Указывает, разрешена ли "чистая" RSA-аутентификация. #
# Актуально только для протокола ssh1. #
# По умолчанию “yes”. #
# #
RSAAuthentication no
# #
## ServerKeyBits ###########################################
# #
# Определяет число бит во временном ключе сервера для #
# протокола ssh1. Минимальное значение 512. #
# Значение по умолчанию 1024. #
ServerKeyBits 1024
# #
############################################################
########### Опции протокола 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,[email protected] ,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 доступ, т.к. они всегда смогут установить #
# свои собственные аналоги агента. #
# #
AllowAgentForwarding no
# #
## AllowTcpForwarding ######################################
# #
# Указывает, разрешить или запретить перенаправление TCP. #
# По умолчанию “yes”, т.е. разрешить. Стоит заметить, #
# что как и в случае с AllowAgentForwarding отключение #
# перенаправления не увеличит безопасности, пока у #
# пользователей будет консольный доступ, т.к. они смогут #
# установить свои аналоги. #
# #
# #
AllowTcpForwarding no
# #
## GatewayPorts ############################################
# #
# Указывает, разрешать ли удаленным хостам доступ к #
# перенаправленным портам. По умолчанию, sshd слушает #
# соединения к перенаправленным портам только на локальном #
# интерфейсе (loopback). Это не дает другим удаленным #
# хостам подсоединяться к перенаправленным портам. Можно #
# использовать GatewayPorts, чтобы разрешить sshd это #
# делать. Директива может принимать 3 значения: #
# "no" только loopback. #
# "yes"- любые адреса. #
# "clientspecified" адреса указанные клиентом. #
# #
GatewayPorts no
# #
## PermitOpen ##############################################
# #
# Указывает куда разрешено перенаправление TCP портов. #
# Указание перенаправления должно принимать одну из #
# следующих форм: #
# PermitOpen host:port #
# PermitOpen IPv4_addr:port #
# PermitOpen :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 и DEBUG
эквивалентны друг другу. #
# DEBUG2 и DEBUG3 задают самые высокие уровни отладочного #
# вывода. Запись логов с уровнем DEBUG угрожает #
# приватности пользователей и не рекомендована. #
# #
LogLevel INFO
# #
############################################################
################### Перенаправление X
####################
############################################################
# #
## X11Forwarding ###########################################
# #
# Указывает, разрешено ли перенаправление графической #
# подсистемы X11. Может принимать значения “yes” или “no”. #
# По умолчанию “no”. #
# Внимание включение простого перенаправления Х11 #
# большой риск как для сервера, так и для клиентов, т.к. в #
# случае такого перенаправления прокси-дисплей sshd #
# принимает соединения с любых адресов. Используйте #
# директиву X11UseLocalhost для ограничения доступа к #
# серверу перенаправления "иксов". Стоит отметить, что #
# отключение перенаправления не даст гарантии, что #
# пользователи не смогут перенаправлять Х11, т.к. имея #
# консольный доступ они всегда установить свой #
# перенаправлятель. Перенаправление Х11будет #
# автоматически отключено, если будет задействована #
# директива UseLogin. #
# #
X11Forwarding no
# #
## X11UseLocalhost #########################################
# #
# Указывает, должен ли sshd ограничить область #
# перенаправления Х11 локальным loopback адресом, или #
# должен разрешить любые адреса. По умолчанию sshd #
# "сажает" сервер перенаправления Х11на локальный адрес #
# и задает часть переменной окружения DISPLAY, отвечающую #
# за имя хоста как “localhost”. Стоит заметить, что #
# некоторые старые клиенты Х11могут не работать с такими #
# настройками. По умолчанию "yes", т.е. перенаправление #
# ограничено локалхостом, значение “no” отключает #
# ограничения. #
# #
## XAuthLocation ###########################################
# #
# Указывает полный путь к программе xauth. #
# По умолчанию /usr/bin/X11/xauth. #
# #
## X11DisplayOffset ########################################
# #
# Указывает номер первого дисплея, доступного sshd в #
# качестве перенаправления X11. Это сделано для того, #
# чтобы перенаправленные "иксы" не пересекались с #
# реальными. По умолчанию 10. #
# #
X11DisplayOffset10
# #
############################################################
################### Различные опции ########################
############################################################
# #
## LoginGraceTime ##########################################
# #
# Время, по прошествии которого сервер отключает #
# пользователя, если тот не смог удовлетворительно #
# залогиниться. Значение 0 разрешает пользователю #
# логиниться бесконечно. По умолчанию 120 (секунд). #
# #
LoginGraceTime 120
# #
## MaxAuthTries ############################################
# #
# Указывает максимальное число попыток аутентификации, #
# разрешенное для одного соединения. #
# Как только число неудачных попыток превысит половину #
# заданного значения, все последующие попытки будут #
# заноситься в журнал. Значение по умолчанию 6. #
# #
MaxAuthTries 4
# #
## MaxSessions #############################################
# #
# Указывает максимальное число одновременных подключений #
# для каждого сетевого соединения. По умолчанию 10. #
# #
MaxSessions1
# #
## 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 #
Сразу небольшая ремарка к конфигу в нем отключена возможность по ssh логинеться под пользователем root, поэтому если вы "любитель " поправьте настройку PermitRootLogin на yes
Для копирования выше указаного конфига на вашу unix машину
Перейдите в католог где хранится конфигурационный файл sshd_config
Sudo cd /etc/ssh
Поскольу мы сделали резервную копию файла sshd_config удалим его
Sudo rm sshd_config
Все еще находясь в директории /etc/ssh скопируем с сайта itautsors выше указаный файл конфигурации ssh,
Sudo wget http://сайт/sshd_config
Перезапустим демон
Sudo service ssh restart
Убедимся что демон SSH запущен
Ps -A | grep sshd
Увидим что то подобное
<какой то номер> ? 00:00:00 sshd
Если строки нет то SSH демон не запущен,
Проверим прослушиваются ли входящие соединения:
Sudo ss -lnp | grep sshd
В ответ получим
0 128:::22:::* users:(("sshd",16893,4)) 0 128 *:22 *:* users:(("sshd",16893,3))
Если строк более чем одна, значит демон SSH прослушивает более чем один порт, если не одной нужно указать хотя бы один порт, в обоих случаях неоходимо вернутся и отредактировать конфигурационный файл
Попробуем войти с локального компьютера (то есть заходим с того же ПК на котором настраиваем ssh server, так сказать первоначальная проверка), (помним что у нас порт не стандартный 8022):
Ssh -v localhost -p 8022
Будет выведена отладочная информация, и предложение ввести пароль.
После удачного соединения для выхода наберите:
Настроим доступ к OpenSSH Server с OpenSSH Client с авторизацией по ключу
Дано: Хост OpenSSH Server на который в будущем хотим логинется по ssh под пользователем NameUserOnOpenSSHServer с хоста OpenSSH Client Сгенерируем пару ключей на Хосте с которого мы хотим подключится (OpenSSH Client). Проверьте может пара ключей уже сгенерирована.
Согласившись с местом сохранения ключа (/home/NameUserOnOpenSSHClient/.ssh/id_rsa), пароль можно оставить пустым тогда при аутентификации по сертификату не нежно будет вводить пароль что менее надежно но намного удобнее (в нашем примере вводить пароль не будем):
Ssh-keygen -t rsa -b 4096
В домашней папке ~/.ssh пользователя под которым запускали генерецию (в нашем примере NameUserOnOpenSSHClient ) на хосте OpenSSH Client появятся файлы:
~/.ssh/id_rsa.pub
публичный
~/.ssh/id_rsa
приватный
Выставим права на папку и файлы
Без разницы под каким пользователем мы будем запускать генерацию на OpenSSH Client, единственное логинется на удаленную машину OpenSSH Server нужно будет под этим пользователем так как права будут высталены следующие (такие права необходимо выставить что бы не был скомпроментирован приватный ключ) :
$ chmod 0700 ~/.ssh/ $ chmod 0600 ~/.ssh/id*
Передадим публичный ключ с клиента на сервер для пользователя под которым находимся, командой ssh-copy-id в файл ~/.ssh/authorized_keys, если порт на котором слушает сервер не стандарный, необходимо его прописать используя ключ -p и заключить в кавычки. Ключ можно передать любым способом потому что он публичный.
Ssh-copy-id "-p 8022 NameUserONOpenSSHServer@ipAdressOpenSSHServer"
NameUserOnOpenSSHServer - это тот пользователь под которым мы будем в будущем логинется на удаленной машине.
Далее необходимо ввести пароль пользователя NameUserONOpenSSHServer, и после удачной авторизации увидим подсказку:
Now try logging into the machine, with "ssh "NameUserONOpenSSHServer@ipAdressOpenSSHServer"", and check in: ~/.ssh/authorized_keys to make sure we haven"t added extra keys that you weren"t expecting.
Логинемся на Хост через ssh и проверяем содержания файла (в этом файле могут быть прописаны и другие ключи, ищем наш.) NameUserONOpenSSHServer/.ssh/authorized_keys :
Sudo ssh "NameUserONOpenSSHServer@ipAdressOpenSSHServer" sudo cat /home/NameUserONOpenSSHServer/.ssh/authorized_keys
Он должен совподать с содержимым файла NameUserONOpenSSHClient/.ssh/id_rsa.pub
Sudo cat /home/NameUserONOpenSSHClient/.ssh/id_rsa.pub
Sudo mcedit /etc/ssh/sshd_config
Жмем F7, ищем PubkeyAuthentication, RSAAuthentication, AuthorizedKeysFile
должно быть раскоментированы строчки/выставлены параметры (проверяем):
# разрешаем использование RSA ключей RSAAuthentication yes # если используете SSH1 не желательно # разрешаем авторизацию при помощи ключей PubkeyAuthentication yes # Путь где будут находиться ключи, с которыми можно соединяться для каждого пользователя свой файл в его директории. AuthorizedKeysFile %h/.ssh/authorized_keys
Перезапустим сервер SSH
Sudo service ssh restart
Выставляем права на файл /home/NameUserOnOpenSSHServer/.ssh/authorized_keys
Chmod 0600 ~/.ssh/authorized_keys
Выходим из консоли OpenSSHServer, пробуем залогинится с клиента на сервер использую сертификат, вводим строчку и должны попасть в консоль OpenSSHServer без ввода паролья (если при генерации ключей вы не вводили пароль)
Ssh NameUser@ipAdressOpenSSHServer
Возможностей организовать удалённый доступ к вашему компьютеру через интернет-соединение существует в большом количестве. Некоторые из них являются очень сложными и используются лишь специалистами в профессиональной среде, в то время как другие - очень простые и их могут освоить даже неопытные пользователи. Мы уже писали о нескольких способах, в частности, о программе TeamViewer и протоколе VNC.
Нюансы работы с протоколом SSH в Ubuntu.
В этой статье мы поговорим о протоколе безопасного подключения SSH, в последнее время ставшего практически стандартом в среде пользователей Linux. Он является очень надёжным, поскольку поддерживает шифрование, а также его очень легко настраивать. Мы рассмотрим особенности протокола SSH, а также научимся выполнять настройки сервера и клиента. Всё, что от вас будет требоваться - наличие компьютера с установленной операционной системой Ubuntu и интернет-подключение.
Протокол Secure Shell, известный также как SSH - специальный протокол для безопасного удалённого доступа к компьютеру через сетевое подключение. Протокол имеет много возможностей, в том числе организацию защищённого подключения, запуск командной строки терминала на компьютере, к которому вы подключаетесь удалённо, запуск приложений с графическим интерфейсом, передача файлов и развёртывание приватных сетей.
Существует множество утилит, отвечающих за управлением протоколом. На операционной системе Ubuntu самым известным является Open SSH. Это полностью свободный продукт с открытой лицензией и полным набором самых необходимых функций. Клиент для управления SSH-подключением уже включён в дистрибутив Ubuntu , вам нужно будет лишь установить и настроить серверные компоненты. Управление осуществляется через команды в терминале.
Установка SSH в Ubuntu
Поскольку протокол SSH клиент для его управления является общепринятым стандартом, установить его можно при помощи короткой команды в терминале Ubuntu. для этого запустите сам терминал , нажав комбинацию кнопок на клавиатуре Ctrl + Alt + T, после чего примените команду sudo apt-get install ssh. После подготовки к скачиванию утилита запросит, хотите ли вы продолжить. переключите клавиатуру на русский язык и нажмите Д. На вашем компьютере с Ubuntu установка ssh будет завершена уже через пару секунд. Если вы желаете активировать автоматический запуск при включении системы, используйте для этого команду sudo systemctl enable sshd. соответственно, если потом вы пожелаете убрать службу из автоматического запуска, вам понадобится команда sudo systemctl disable sshd.
Теперь можно проверить, как всё работает. Этого достаточно попробовать подключиться к локальному SSH server: ssh localhost. Утилита обязательно запросит пароль суперпользователя, а также предложит добавить введённый адрес в список разрешённых. Если у вас всё работает, как положено, вы увидите небольшое сообщение, заканчивающиеся уведомление о дате последнего подключения к адресу.
Теперь можно подключаться к любому компьютеру в сети , если вы знаете его IP-адрес и имя пользователя. для этого в терминале вам нужно ввести команду следующего формата:
ssh имя_пользователя@ip_адрес
Например, если вы хотите подсоединиться к компьютеру Васи Пупкина с адресом 132.14.25.10, то команда будет выглядеть следующим образом:
Настройка SSH в Ubuntu
Для правильной и безопасной работы с SSH-сервером его нужно определённым образом настроить. Для этого нужно отредактировать файл параметров sshd_config, расположенный в каталоге /etc/ssh. Примечательно, что его нельзя изменить, просто открыв через файловый менеджер в обычном текстовом редакторе. Система оповестит вас о недостаточных правах, и вы просто не сможете сохранить изменения. Поэтому вам снова понадобится терминал и знание нескольких команд, о которых мы сейчас расскажем. Давайте рассмотрим необходимые шаги по настройке ssh сервера в операционной системе Ubuntu .
Что можно поменять в настройках SSH
Минимально необходимые команды
Или сокращенно SSH, является одной из самых передовых технологий защиты данных при передаче. Использование такого режима на том же маршрутизаторе позволяет обеспечить не только конфиденциальность передаваемой информации, но и ускорить обмен пакетами. Правда, далеко не все знают, как SSH и зачем все это нужно. В данном случае придется дать конструктивное пояснение.
Порт SSH: что это и зачем нужно?
Поскольку речь идет о безопасности, в данном случае под портом SSH следует понимать выделенный канал связи в виде туннеля, обеспечивающего шифрование данных.
Самая примитивная схема работы такого туннеля состоит в том, что открытый SSH-порт по умолчанию используется для зашифровки информации в источнике и дешифровке на конечной точке. Пояснить это можно так: хотите вы этого или нет, передаваемый траффик, в отличие от IPSec, шифруется в принудительном порядке и на выходе одного сетевого терминала, и на входе принимающей стороны. Для расшифровки информации, передаваемой по данному каналу, принимающий терминал использует специальный ключ. Иными словами, вмешаться в передачу или нарушить целостность передаваемых данных на текущий момент без ключа не может никто.
Как раз открытие SSH-порта на любом маршрутизаторе или при помощи соответствующих настроек дополнительного клиента, взаимодействующего с SSH-сервером напрямую, позволяет в полной мере использовать все возможности системы безопасности современных сетей. Речь тут о том, чтобы использовать порт, назначенный по умолчанию, или пользовательские настройки. Эти параметры в применении могут выглядеть достаточно сложно, однако без понимания организации такого подключения здесь не обойтись.
Стандартный порт SSH
Если действительно исходить из параметров любого маршрутизатора, для начала следует определиться с тем, какое именно программное обеспечение будет использоваться для задействования этого канала связи. Собственно, и порт SSH по умолчанию может иметь разные настройки. Все зависит о того, какая методика применяется в данный момент (прямое соединение с сервером, установка дополнительного клиента, проброс портов и т. д.).
Так, например, если в качестве клиента применяется Jabber, для корректного соединения, шифрования и передачи данных должен использоваться порт 443, хотя в стандартном варианте устанавливается порт 22.
Чтобы перенастроить маршрутизатор с выделением для определенной программы или процесса необходимых условий, придется выполнить проброс портов SSH. есть назначение определенного доступа для отдельно взятой программы, которая использует подключение к Интернету, вне зависимости от того, какие настройки имеет текущий протокол обмена данными (IPv4 или IPv6).
Техническое обоснование
Как уже понятно, стандартный порт SSH 22 используется не всегда. Однако тут нужно выделить некоторые характеристики и параметры, используемые при настройке.
Почему конфиденциальность передачи зашифрованных данных предполагает использование протокола SSH в виде исключительно внешнего (гостевого) пользовательского порта? Да только потому, что применяемое туннелирование позволяет использовать так называемую удаленную оболочку (SSH), получить доступ к управлению терминалом посредством удаленного входа в систему (slogin), а также применять процедуры удаленного копирования (scp).
Кроме того, SSH-порт может быть задействован и в том случае, когда у пользователя возникает необходимость выполнения удаленных сценариев X Windows, что в самом простом случае представляет собой передачу информации с одной машины на другую, как уже говорилось, с принудительным шифрованием данных. В таких ситуациях самым необходимым станет использование алгоритмов на основе AES. Это есть алгоритм симметричного шифрования, которое изначально предусмотрено в технологии SSH. И использовать его не только можно, но и нужно.
История реализации
Сама технология появилась достаточно давно. Оставим пока в стороне вопрос того, как сделать проброс портов SSH, а остановимся на том, как все это работает.
Обычно все сводится к тому, чтобы использовать прокси на основе Socks или применить туннелирование VPN. В случае если какое-то программное приложение умеет работать с VPN, лучше предпочесть именно этот вариант. Дело в том, что практически все известные на сегодня программы, использующие интернет-траффик, с VPN работать могут, а настройка маршрутизации особого труда не составляет. Это, как и в случае с прокси-серверами, позволяет оставить внешний адрес терминала, с которого в данный момент производится выход в сеть, неузнанным. То есть в случае с прокси адрес меняется постоянно, а в варианте VPN остается неизменным с фиксацией определённого региона, отличного от того, где действует запрет доступа.
Сама же технология, когда открывается порт SSH, была разработана еще в 1995 году в Технологическом университете Финляндии (SSH-1). В 1996 году было добавлено усовершенствование в виде протокола SSH-2, который получил достаточно большое распространение на постсоветском пространстве, хотя для этого, равно как и в некоторых странах Западной Европы, иногда необходимо получение разрешения на использование такого туннеля, причем от государственных органов.
Основным преимуществом открытия SSH-порта, в отличие от telnet или rlogin, считается применение цифровой подписи RSA или DSA (использование пары в виде открытого и зарытого ключа). Кроме того, в данной ситуации может использовать так называемый сеансовый ключ на основе алгоритма Диффи-Хеллмана, который подразумевает применение симметричного шифрования на выходе, хотя и не исключает использование алгоритмов асимметричного шифрования в процессе передачи данных и их приема другой машиной.
Серверы и оболочки
В Windows или в не так уж и трудно. Вопрос только в том, какой именно инструментарий для этого будет использоваться.
В этом смысле нужно обратить внимание на вопрос передачи информации и аутентификации. Во-первых, сам протокол оказывается достаточно защищенным от так называемого снифинга, представляющего собой самую обычную «прослушку» траффика. SSH-1 оказался беззащитным перед атаками. Вмешательство в процесс передачи данных в виде схемы «человек посередине» имело свои результаты. Информацию можно было просто перехватить и расшифровать совершенно элементарно. Зато вторая версия (SSH-2) была застрахована от подобного рода вмешательства, называемого session hijacking, благодаря чему и получила наибольшее распространение.
Запреты системы безопасности
Что же касается безопасности в отношении передаваемых и принимаемых данных, организация подключения, созданного с применением таких технологий, позволяет избежать появления следующих проблем:
- определение ключа к хосту на стадии передачи, когда используется «слепок» fingerprint;
- поддержка Windows и UNIX-подобных систем;
- подмена адресов IP и DNS (spoofing);
- перехват открытых паролей при физическом доступе к каналу передачи данных.
Собственно, вся организация такой системы построена по принципу «клиент-сервер», то есть в первую очередь пользовательская машина посредством специальной программы или надстройки обращается к серверу, который и производит соответствующее перенаправление.
Туннелирование
Само собой разумеется, что для осуществления подключения такого рода в системе должен быть установлен специальный драйвер.
Как правило, в Windows-системах это встроенный в программную оболочку драйвер Microsoft Teredo, представляющий собой некое виртуальное средство эмулирования протокола IPv6 в сетях с поддержкой только IPv4. по умолчанию находится в активном состоянии. В случае появления сбоев, с ним связанных, можно просто произвести перезапуск системы или выполнить команды отключения и рестарта в командной консоли. Для деактивации используются такие строки:
- netsh;
- interface teredo set state disabled;
- interface isatap set state disabled.
После ввода команд следует перезагрузка. Для повторного включения адаптера и проверки его состояния вместо disabled прописывается разрешение enabled, после чего, опять же, следует рестарт всей системы.
SSH-сервер
Теперь посмотрим, какой порт SSH используется в качестве основного, отталкиваясь от схемы «клиент-сервер». Обычно по умолчанию применяется 22-й порт, но, как уже было указано выше, может использовать и 443-й. Вопрос только в предпочтении самого сервера.
Самыми распространенными SSH-серверами принято считать следующие:
- для Windows: Tectia SSH Server, OpenSSH с Cygwin, MobaSSH, KpyM Telnet/SSH Server, WinSSHD, copssh, freeSSHd;
- для FreeBSD: OpenSSH;
- для Linux: Tectia SSH Server, ssh, openssh-server, lsh-server, dropbear.
Все приведенные серверы являются бесплатными. Однако можно найти и платные услуги, которые отличаются повышенным уровнем системы безопасности, что крайне необходимо для организации сетевого доступа и защиты информации на предприятиях. Стоимость таких услуг сейчас не обсуждается. Но в общем и целом можно сказать, что это относительно недорого, даже по сравнению с установкой специализированного программного или «железного» файрвола.
SSH-клиент
Смена порта SSH сможет производиться на основе клиентской программы или соответствующих настроек при пробросе портов на маршрутизаторе.
Однако, если касаться клиентских оболочек, для разных систем могут применяться следующие программные продукты:
- Windows - SecureCRT, PuTTY\KiTTY, Axessh, ShellGuard, SSHWindows, ZOC, XShell, ProSSHD и т. д.;
- Mac OS X: iTerm2, vSSH, NiftyTelnet SSH;
- Linux и BSD: lsh-client, kdessh, openssh-client, Vinagre, putty.
Аутентификация на основе открытых ключей и изменение порта
Теперь несколько слов о том, как происходит верификация и настройка сервера. В самом простом случае необходимо использовать файл конфигурации (sshd_config). Однако можно обойтись и без этого, например, в случае использования программ вроде PuTTY. Изменить порт SSH со стандартного значения (22) на любое другое можно совершенно элементарно.
Главное - чтобы номер открываемого порта не превышал значение 65535 (выше портов просто не бывает в природе). К тому же следует обратить внимание на некоторые открытые по умолчанию порты, которые могут использоваться клиентами вроде MySQL или базами данных FTPD. Если указать для SSH их конфигурацию, понятное дело, те просто перестанут работать.
Стоит учесть, что тот же клиент Jabber должен быть запущен в одной среде с использованием SSH-сервера, например, на виртуальной машине. А самому серверу localhost необходимо будет присвоение значения 4430 (а не 443, как было указано выше). Такая конфигурация может использоваться в том случае, когда доступ к основному файлу jabber.example.com блокируется файрволом.
С другой стороны, перебросить порты можно и на самом маршрутизаторе, используя для этого настройки его интерфейса с созданием правил исключения. На большинстве моделей вход осуществляется через ввод адресов, начинающихся с 192.168 с добавлением 0.1 или 1.1, но на роутерах, совмещающих возможности ADSL-модемов вроде Mikrotik, конечный адрес предполагает использование 88.1.
В этом случае создается новое правило, после этого устанавливаются необходимые параметры, например, для установки внешнего подключения dst-nat, а также вручную прописываются порты не в разделе общих настроек, и в разделе предпочтений активных действий (Action). Ничего особо сложного здесь нет. Главное - указать необходимые значения настроек и установить правильный порт. По умолчанию можно использовать порт 22, но, если используется специализированный клиент (какой-то из вышеуказанных для разных систем), значение можно менять произвольно, но только так, чтобы этот параметр не превышал заявленное значение, выше которого номера портов просто отсутствуют.
При настройке подключения также стоит обратить внимание на параметры клиентской программы. Очень может быть, что в ее настройках придется указать минимальную длину ключа (512), хотя по умолчанию обычно установлено 768. Также желательно установить таймаут входа в систему на уровне 600 секунд и разрешение на удаленный доступ с использованием прав root. После применения таких настроек необходимо дать еще и разрешение на использование всех прав аутентификации, кроме тех, которые основаны на использовании.rhost (но это нужно лишь системным администраторам).
Кроме всего прочего, если имя пользователя, зарегистрированного в системе, не совпадает с вводимым в данный момент, нужно будет указать его явно, используя для этого команду user ssh master с вводом дополнительных параметров (для тех, кто понимает, о чем идет речь).
Для преобразования ключа и самого метода шифрования может применяться команда ~/.ssh/id_dsa (или rsa). Для создания публичного ключа используется преобразование при помощи строки ~/.ssh/identity.pub (но это не обязательно). Но, как показывает практика, проще всего использовать команды вроде ssh-keygen. Тут суть вопроса сводится только к тому, чтобы добавить ключ к доступным инструментам авторизации (~/.ssh/authorized_keys).
Но мы зашли слишком далеко. Если возвращаться к вопросу настройки порта SSH, как уже понятно, изменить порт SSH не так уж и сложно. Правда, в некоторых ситуациях, что называется, придется попотеть, поскольку нужно будет учесть все значения основных параметров. В остальном же вопрос настройки сводится либо ко входу в серверную или клиентскую программу (если это предусмотрено изначально), либо к использованию проброса портов на маршрутизаторе. Но даже в случае изменения порта 22, установленного по умолчанию, на тот же 443-й, нужно четко понимать, что такая схема работает не всегда, а только в случае с установкой той же надстройки Jabber (другие аналоги могут задействовать и соответствующие им порты, отличающиеся от стандартных). Кроме того, особое внимание следует уделить выставлению параметров SSH-клиента, который будет непосредственно взаимодействовать с SSH-сервером, если таковое действительно предполагается в использовании текущего подключения.
В остальном же, если не предусмотрен изначально (хотя желательно выполнить такие действия), настройки и параметры для доступа по протоколу SSH можно и не менять. Тут особых проблем при создании соединения и его дальнейшем использовании, в общем-то, не предвидится (если, конечно, не будет использоваться ручная настройка конфигурации на основе сервера и клиента). Самое обычное создание правила исключения на роутере позволяет исправить все проблемы или избежать их появления.
