Удаленный доступ на Ubuntu с Windows машины. Установка и настройка сервера SSH в Linux Открыть доступ по ssh ubuntu

Итак, в Интернете, понятное дело, что есть огромное количество примеров установки SSH, но вот незадача-то 🙂 не везде описаны все детали, и порой новичку в данной ситуации ой как нелегко приходится, сам на себе это испытал… Итак, вот полное и подробное до мельчайших деталей описание установки великого и могучего SSH.

Сначала установим SSH на машине на которую планируем подсоединяться. Для этого в консоли (командной строке, терминале) введём команду:

sudo apt-get install openssh-server

После этой команда автоматически найдётся и установится SSH (конечно же необходимо подсоединение к великому и могучему Интернету). Затем необходимо произвести настройку. Вся конфигурация нашего сервера производиться изменением файла /etc/ssh/sshd_config . Но для начала, я бы порекомендовал сделать резервную копию исходного конфигурационного файла. Для этого пишем:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.original

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

sudo nano /etc/ssh/sshd_config

Вы увидите следующие директивы:

Port 22 — указывает порт по которому сервер будет ожидать входящего соединения. Например, Port 1234 означает что к серверу можно будет подключиться по порту 1234. Но стандартный — 22 порт, хотя я рекомендовал бы его сменить, так как именно с него и начинают попытки взлома сервера «недоброжелательные личности Интернет просторов».
PermitRootLogin no — лучше установите в значение no . Этим самым Вы запретите логиниться под рутом.
ListenAddress — указывает какой протокол/интерфейс будет прослушиваться ssh.
Protocol — позволяет выбрать версию протокола 1 или 2. Рекомендуется протокол 2.
HostKey — ключевые файлы для второй версии протокола SSH
PermitEmptyPasswords no — запретить пустые пароли, надёжность не помешает.
UsePrivilegeSeparation — лучше оставить включенным для безопасности.
AllowUsers Goodboy — этого параметра нет в конфиге, советую дописать. Goodboy — имя вашего юзера (он у каждого конечно же свой, это просто пример). Этот параметр устанавливает разрешение логинится только и только с этим именем, ssh пробивают не только на предмет пароля, но и на предмет системных или стандартных имен. К примеру apache, www, которые по каким-то причинам могут оказаться беcпарольными, или andy, bobby, anna и тп. К имени Goodboy можно добавить ip-адрес — [email protected] — если вы уверены, что на клиентской машине всегда именно этот не меняющийся адрес. Такой параметр разрешит логинится только пользователю Goodboy и только при условии, что его хост совпадает с заданным. В принципе это конечно же не обязательно, но пять же, дополнительная защита не помешает.

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

Затем перезагружаем SSH демон:

sudo /etc/init.d/ssh restart

Затем мы можем к нему подсоединяться. Как правило, сервер — на Linux стоит, а рабочие машины как правило на Windows, то и подсоединяться к серверу будем через ОС Windows. Для этого на машине с которой планируем подключаться устанавливаем 2 програмки: Putty — для доступа к командной строке сервера, WinSCP — для более удобных стандартных операций копирования, удаления, перемещения, создания папок на сервере и так далее. Последняя программа своим интерфейсом напоминает аналог Total commander, Far manager и подобные им программы. На самом же деле можно использовать не только WinSCP, но и вышеперечисленные программы, а так же FileZilla и прочие, но легче, удобнее, и менее проблемнее в настройке и работе, на мой взгляд текущая программа. Итак, для подсоединения необходимо всего навсего указать порт к которому хотим подсоединиться, по умолчанию 22 если Вы его не изменили, а затем имя хоста или его IP адресс. Так как сервера, как правило ставятся на статические IP то в этом нет никаких проблем.

Спасибо 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

SSH – один из важнейших инструментов системного администрирования.

SSH, или Secure Shell (безопасная оболочка) – это протокол, который используется для безопасного подключения к удаленным системам. Это самый распространенный способ подключения к удаленным Linux- и Unix-подобным серверам (например, к VPS).

В данном руководстве речь пойдет об использовании SSH для подключения к удаленной системе.

Базовый синтаксис

Для подключения к удаленной системе с помощью SSH в Linux существует одноименный инструмент – ssh.

Базовый вид команды:

ssh удаленный_хост

В данном примере фраза «удаленный_хост» заменяет IP-адрес или доменное имя хоста, к которому нужно подключиться.

Эта команда предполагает, что имя пользователя на удаленной и локальной системах совпадают.

Если же на удаленной системе установлено другое имя пользователя, его нужно указать с помощью следующего синтаксиса:

ssh имя_пользователя@удаленный_хост

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

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

Чтобы вернуться в локальную сессию, просто наберите:

Как работает SSH?

SSH работает путем подключения клиентской программы к серверу ssh.

В приведенных выше командах ssh является клиентской программой. Сервер ssh уже запущен на указанном удаленном хосте.

Если сервер ssh еще не запущен на VPS, нажмите кнопку «Console Access», которая находится на странице сервера. Это выведет экран авторизации. Для входа используйте свои учетные данные.

В целом, процесс запуска сервера ssh зависит от используемого дистрибутива Linux.

В Ubuntu для запуска сервера ssh на VPS нужно ввести:

Sudo service sshd start

Настройка SSH

При изменении настроек SSH изменяются и настройки ssh-сервера.

В Ubuntu главный конфигурационный файл SSH находится в /etc/ssh/sshd_config.

Создайте резервную копию текущей версии этого файла перед его редактированием:

Sudo cp /etc/ssh/sshd_config{,.bak}

Откройте его с помощью текстового редактора:

Sudo nano /etc/ssh/sshd_config

Некоторые настройки требуют особенного внимания, например:

Данная строка определяет, какой порт ssh-сервер будет прослушивать для соединений. По умолчанию это порт 22.

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

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key

Строки HostKey указывают, где находятся ключи хоста (подробнее о ключах хоста позже).

SyslogFacility
LogLevel INFO

Данные строки содержат настройки журналирования и определяют уровень журнала.

При возникновении каких-либо проблем с SSH рекомендуется повысить уровень журнала (что увеличивает количество записываемых данных).

LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

Данные параметры содержат некоторую регистрационную информацию.

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

Примечание : в данной строке установите немного больше времени, чем обычно необходимо для регистрации.

PermitRootLogin определяет возможность входа в систему как пользователь root.

В большинстве случаев после создания пользователя, имеющего повышенные привилегии (su или sudo) и возможность подключаться через ssh, в данной строке рекомендуется установить «no»

strictModes – это защитное устройство, которое откажет во входе, если файлы аутентификации доступны для чтения всем.

Это предотвращает попытки входа, если файлы конфигурации не защищены.

X11Forwarding yes
X11DisplayOffset 10

Данные параметры настраивают функцию под названием X11 Forwarding, что позволяет просматривать графический пользовательский интерфейс (GUI) удаленной системы на локальной системе.

Этот параметр должен быть активирован и на локальной, и на удаленной машине; для использования функции необходимо передать клиента и опцию –X.

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

sudo service sshd restart

Кроме того, внесенные изменения необходимо тщательно протестировать, чтобы убедиться, что все работает должным образом.

Столкнувшись с проблемами, помните, что войти можно также с помощью кнопки «Console Access».

Вход с помощью ключей SSH

Зачастую аутентификация на основе ключей намного надежнее, чем вход в удаленную систему при помощи пароля.

Как работает аутентификация на основе ключей?

Аутентификация на основе ключей подразумевает создание пары ключей – закрытого и открытого.

Закрытый ключ находится на клиентской машине, должен быть защищен и храниться в секрете.

Открытый ключ можно давать кому угодно и разместить на любом сервере, к которому нужно получить доступ.

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

Затем клиентский компьютер посылает серверу соответствующий ответ, благодаря чему сервер понимает, что клиент является законным.

После настройки ключей весь этот процесс осуществляется автоматически в фоновом режиме.

Создание SSH-ключей

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

В командной строке наберите:

ssh-keygen -t rsa

Чтобы принять настройки по умолчанию, нажмите Enter. Ключи будут созданы в ~/.ssh/id_rsa.pub и ~/.ssh/id_rsa.

Перейдите в каталог.ssh, набрав:

Обратите внимание на права на файлы:

ls -l
-rw-r--r-- 1 demo demo 807 Sep 9 22:15 authorized_keys
-rw------- 1 demo demo 1679 Sep 9 23:13 id_rsa
-rw-r--r-- 1 demo demo 396 Sep 9 23:13 id_rsa.pub

Как можно видеть, права на чтение и изменение файла id_rsa есть только у владельца. Такие привилегии необходимы, чтобы сохранить ключ в секрете.

В то же время, файл id_rsa.pub можно использовать совместно, потому он имеет соответствующие привилегии.

Передача открытого ключа на сервер

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

ssh-copy-id удаленный_хост

Это откроет сессию SSH, для входа в которую нужно ввести пароль.

После введения пароля открытый ключ будет скопирован на сервер, что позволит в следующий раз войти в систему без пароля.

Клиентские настройки SSH

При подключении по SSH можно использовать ряд флагов.

Некоторые из них нужны для установки соответствующих параметров вфайле ssh удаленного хоста.

Например, если номер порта в конфигурациях ssh на локальном хосте был изменен, нужно установить соответствующий порт на стороне клиента, набрав:

ssh -p номер_порта удаленный_хост

Если на удаленной системе нужно выполнить какую-либо команду, ее можно указать следующим образом:

ssh удаленный_хост нужная_команда

Эта строка установит соединение с удаленной машиной и выполнит указанную команду.

Как уже было сказано, если функция X11 forwarding активирована на обоих компьютерах, ее можно использовать, набрав:

ssh -X удаленный_хост

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

Итоги

Научиться работать с SSH очень важно хотя бы потому, что это необходимо для выполнения самых базовых задач.

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

Tags: ,

Благодарим Вас за проявленный интерес к нашему сайту. Компания Айтишник существует с 2006 года и предоставляет услуги IT аутсорсинга. Аутсорсинг - это перепоручение необходимых, но непрофильных для компании работ другой организации. В нашем случае это: создание, поддержка и сопровождение сайтов, продвижение сайтов в поисковых системах, поддержка и администрирование серверов под управлением Debian GNU/Linux.

Сайты на Joomla

В нынешний век информации, сайт де факто, становится как минимум визитной карточкой организации, а зачастую одним из инструментов бизнеса. Уже сейчас сайты создаются не только для организаций и частных лиц, но и для отдельных товаров, услуг и даже событий. На сегодняшний день сайт это не только источник рекламы на гигантскую аудиторию, но и инструмент для продаж и завязывания новых контактов. Мы создаем сайты, используя CMS Joomla! Эта система управления сайтами проста и интуитивно понятна. Она очень широко распространена и, следовательно, в Интернете о ней содержится большое количество информации. Найти специалиста, работающего с Joomla тоже несложно. И вам не надо далеко ходить! Наша компания Айтишник занимается обслуживанием и сопровождением сайтов на Joomla! Мы проведём все технические работы, возьмём на себя всю переписку с хостером и регистратором домена, наполним сайт и обновим на нём информацию. И хотя Joomla проста в управлении, интуитивно понятна. Но будете ли вы сами регулярно выполнять необходимые работы на сайте? Сколько времени они отнимут у вас? Если вы хотите сконцентрироваться на своём деле, то доверьте поддержку вашего сайта нам. Мы сделаем все от нас зависящее, чтобы сайт жил и приносил пользу своему владельцу.
Если вы коммерческая организация, которая рекламирует или продаёт свои товары, услуги в Интернет, то вам просто необходимо продвижение сайта в поисковых системах. Ведь для того, чтобы продать что-нибудь надо, как минимум, чтобы это увидели, чтобы об этом узнали. И мы поможем вам в этом, мы продвинем ваш Joomla сайт в поисковых системах. В зависимости от конкуренции и выделенного для продвижения бюджета, ваш сайт будет занимать достойные позиции в поисковой выдаче. Сайт увеличит вашу прибыль!

Серверы Debian

Рано или поздно, стремясь к открытости и прозрачности своего бизнеса, многие компании сталкиваются с необходимостью обеспечения лицензионной чистоты используемого программного обеспечения. Однако, далеко не всегда затраты на лицензионные отчисления приемлемы, в особенности для малого и среднего бизнеса. Выходом из этой сложной ситуации является решение о переходе на Open Source технологии. Одним из направлений Open Source является операционная система Linux (Линукс). Сотрудники нашей компании специализируются на Debian Linux (Дебиан Линукс). Это старейший и наиболее устойчивый дистрибутив операционной системы Линукс. Мы предлагаем вам услуги по внедрению Debian Linux на Вашем предприятии, настройку, обслуживание и поддержку серверов.

Информация и реклама

Часть 2.

Перед тем как начнём, давайте создадим нового пользователя с root правами.

Укажем права пользователю test командой

usermod -a -G sudo test

Чтобы убедиться, что пользователь test был добавлен в группу sudo, можно выполнить следующую команду:

Теперь настраим удаленный доступ к серверу по ssh (командная строка), как по локальной сети, так и по интернету

Установим ssh

sudo apt-get install openssh-server

После установки нам необходимо настроить безопасность соединения и непосредственный доступ. Зайдем в файл с настройками

sudo nano /etc/ssh/sshd_config

По умолчанию, ssh использует порт 22. Заменим его на нестандартный, это повысит безопасность нашего доступа. Порт заменим например на 2200

При подключении по ssh, наш сервер потребует вместо пароля ключ RSA, а не пароль. Что бы этого не произошло, в параметре RSAAuthentication и PubkeyAuthentication, вписываем "NO". Так же запрещаем доступ пользователю ROOT, для этого нужно раскомментировать параметр Authetication: и в параметре PermitRootLogin вписать "NO"

Теперь пропишем доступ пользователям

В строке AllowUsers прописываем пользователей через пробел в виде юзер@хост, т. е. указываем какой пользователь откуда может подключаться. Можно использовать знак *

Пропишем пользователю test права доступа и разберёмся в них.

[email protected]

Так же можно запретить доступ определённым пользователям (например пользователю test2), для этого нужно вписать ниже

Запускаем

sudo /etc/init.d/ssh start

Ssh мы настроили. Теперь откроем к нему доступ. Для этого откроем доступ к порту 2200.

В прошлой части мы устанавливали firewall командой arno-iptables-firewall, теперь нужно внести туда изменения. По этому перенатроим его.

sudo dpkg-reconfigure arno-iptables-firewall

Запустилась настройка

Вписываем порт, который нужно открыть. Так же в этом окне можно вписать и другие порты, если они нуждаются в открытии.

В следующем окне, так же вписваем порт 2200.

Как только вписали порты, можно везде нажимать ENTER и перезагрузить Файрвол.

После этого порт ssh будет доступен из сети

Для повышения безопасности ssh соединения можно настраиваем утилиту denyhosts. Утилита представляет собой python-скрипт, который анализирует файл /var/log/auth.log на наличие записей о несанкционированных попытках входа на сервер по ssh и добавляет ip-адреса, с которых осуществлялись эти попытки в файл /etc/hosts.deny, с которых запрещен вход по ssh.

Установим командой

sudo aptitude install denyhosts

Сразу после установки утилита просканирует файл /var/log/auth.log и добавит ip-адреса, с которых осуществлялся подбор паролей, в /etc/hosts.deny. На сканирование потребуется время, если в файле /var/log/auth.log уже много таких записей.

После установки нужно подправить конфигурационный файл

sudo nano /etc/denyhosts.conf

Скорректируем настройку PURGE_DENY на 3 часа. А то мы можем заблокировать доступ самому себе, введя несколько раз неверный пароль.

Ещё, для контроля, нужно указать адрес электронной почты для рассылки уведомлений о неудачных попытках доступа к серверу:

ADMIN_EMAIL = [email protected] вместо [email protected] указываем свою почту

Для того чтобы новые настройки вступили в силу, нужно перезапустить службу denyhosts:

sudo service denyhosts restart

P.S. Если вам понадобиться сменить пароль на учетной записи. Введите команду

passwd user - где user это имя пользователя

P.S.S. Если возникнут проблемы с кодирвкой, то покопайтесь в настройках клиентской программы shh

Самая популярная программа для работы по ssh, программа PuttY.