Как настроить и использовать порт SSH? Пошаговая инструкция. Что такое SSH

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

Когда стали широко использоваться алгоритмы шифрования при передаче данных в сети, одной из первых задач стала организация безопасной оболочки. До этого существовала система rsh, которая позволяла определенным пользователям с определенных машин (между ними должны были быть доверительные отношения) работать на сервере с его оболочкой. Это практически то же самое, что и telnet-доступ. Но с развитием сетей стали видны вопиющие дыры rsh:
— Данные, передаваемые через сеть, никак не шифруются, включая пароли.
— Данные, передаваемые через сеть, могут быть без проблем получены либо модифицированы третьей стороной.
— Злоумышленник мог спокойно подменить ip клиента и, использовав полученный ранее хеш пароля, пройти аутентификацию на сервере со всеми вытекающими последствиями.

Поэтому сейчас rsh применяется в чрезвычайно редких случаях, например, при переносе данных между двумя попарно соединенными машинами (мне так пришлось работать с двумя машинами в разных комнатах). В основном стандартом де-факто стал ssh. Первая буква "s" означает безопасный (secure), что означает, что все данные, предаваемые через ssh шифруются, а значит, защищены от просмотра. Существует несколько версий протокола ssh, различающиеся используемыми алгоритмами шифрования и общими схемами работы. В настоящее время повсеместно используется протокол ssh версии два. Протокол младших версий является по современным меркам небезопасным (там есть несколько очень опасных дыр). Вообще-то сейчас ssh является коммерческим продуктом (что само по себе противоречит требованиям безопасности — всем должен быть известен исходный код системы защиты информации, чтобы убедиться в отсутствии всяких backdoors), но тем не менее доступна свободная реализация ssh — OpenSSH, которая может быть найдена на www.openssh.com. Наилучшим документом по ssh является, по-моему, банальный man ssh , поэтому в некоторых местах я не постесняюсь его просто переводить.

Итак, начнем, как обычно, с теории. SSH предоставляет 3 способа аутентификации клиента: по ip адресу клиента (небезопасно), по публичному ключу клиента и стандартный парольный метод. Вот как работает ssh версии 2: при запросе клиента сервер сообщает ему, какие методы аутентификации он поддерживает (это определяется в опции PreferredAuthentications sshd.conf) и клиент по очереди пытается проверить их. По умолчанию клиент вначале пытается аутентифицироваться своим адресом, затем публичным ключом и, если ничего не сработало, передает пароль, введенный с клавиатуры (при этом пароль шифруется асимметрическим шифрованием). После прохождения аутентификации одним из методов из имеющихся у клиента и сервера пар ключей генерируется ключ симметрического шифрования, который, как я описывал во введении, генерируется на основании своего секретного и удаленного публичного ключей. После чего все последующие данные, передаваемые через ssh, шифруются данным ключом (обычно используется алгоритм aes с длиной ключа 128 бит). Отмечу, что протокол ssh версии 1 имел некоторые баги в шифрации передаваемого трафика и являлся по сути методом безопасной аутентификации, поэтому по современным меркам данный протокол считается небезопасным. Протокол версии 2 поддерживает более современные методы шифрования тарфика, также вместе с данными посылаются контрольные суммы формата sha или md5, что исключает подмену или иную модификацию передаваемого трафика (чего не было у ssh версии 1).

Теперь пару слов о способах аутентификации пользователей через ssh:

1) По адресу клиента.

При данном способе аутентификации происходит следующее: каждый клиент и сервер имеют свои пары ключей RSA, которые называются ключи хоста. При этом существует несколько методов проверки адреса клиента. Сервер смотрит файлы $HOME/.rhosts, $HOME/.shosts, /etc/hosts.equiv или /etc/ssh/shosts.equiv, если же сервер настроен на проверку ключей клиентов (а это нужно в соображениях безопасности, т.к. иначе злоумышленник может подменить ip клиента на свой), то он дополнительно проверяет /etc/ssh/ssh_known_hosts и $HOME/.ssh/known_hosts. Естественно, что файлы, расположенные в домашних каталогах сервера, действуют на пользователя, в чьем каталоге они размещены, а файлы, расположенные в /etc имеют глобальный эффект. Для начала расскажу о синтаксисе вышеперечисленных файлов:
— .rhosts — определяет адрес машины и имя пользователя, с которой данному пользователю открыт доступ (файл расположен в домашнем каталоге пользователя).
— .shosts — аналогичен.rhosts, но предназначен исключительно для ssh, поэтому использовать лучше именно данный файл. Пример.shhosts:
user1.test.ru user1
userstend.test.ru user1
null.test.ru user1
— /etc/hosts.equiv — также содержит пары имя машины/имя пользователя, но имеет эффект на всех пользователей.
— /etc/shosts.equiv — аналог hosts.equiv, но применяется только ssh, что также более предпочтительно. Пример файла /etc/shhosts.equiv:
+ user1.test.ru user1
- server.test.ru xakep
Знак "+" означает разрешение пользователю работать с сервером с данного адреса, знак "-" запрещает подобное действие.
— /etc/ssh/ssh_known_hosts и $HOME/.ssh/known_hosts — данные файлы содержат список адресов и соответствующих им публичных ключей. При запросе клиента сервер генерирует рандомную строку и шифрует ее публичным ключом удаленного хоста. Клиент, получив данную строку, расшифровывает ее своим секретным ключом (который имеется только у него) и зашифровывает полученную строку ключом сервера. Сервер получает зашифрованное сообщение, расшифровывает своим секретным ключом и сравнивает с исходной. Если строки совпали, то клиент имеет валидный секретный ключ, что дает ему право захода на данный сервер. Но для начала клиент должен иметь правильный адрес, которому соответствует публичный ключ на сервере в файле ssh_known_hosts. Файл состоит из 3-х полей: адрес (или адреса, разделенные запятой), публичный ключ для него одной (!) строкой и дополнительное поле комментариев(необязательно). Пример файла known_hosts:
user1.test.ru {SOME_VERY_LONG_PUBLIC_KEY}

Адрес клиента должен быть в полном формате(name.domain), иначе могут быть проблемы. Кроме этого, в адресе можно использовать шаблоны * и?. Публичные ключи вставляются в данный файл самим администратором из генерированных клиентом ssh(identity.pub) публичных ключей. Вообще создание ssh_known_hosts — это прерогатива администратора (aka root).

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

2) Аутентификация пользователя по его публичному ключу.

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

Для генерации пары ключей используйте программу ssh-keygen. Для указания типа ключа укажите ssh-keygen -t {RSA DSA} , например, ssh-keygen -t rsa создаст пару ключей RSA длиной 1024 бита. Для указания файла, в котором следует сохранить ключи, можно использовать опцию -f (традиционно используются файлы $HOME/.ssh/id_rsa и $HOME/.ssh/id_dsa для ключей rsa и dsa соответственно), для указания длины ключа в битах используйте опцию -b:
ssh-keygen -t rsa -b 2048 -f $HOME/.ssh/id_rsa

В результате работы программа запросит ввод пароля для шифрования секретного ключа, чтобы исключить использование его при попадании к посторонним лицам, не знающим пароля (пароль желательно выбирать не короче 10-и символов). После этого вам будет необходимо вводить данный пароль каждый раз при использовании секретного ключа (далее я расскажу, как избежать этого при помощи программы ssh-agent). После работы ssh-keygen создается пара ключей: один секретный (зашифрованный введенным паролем), а другой публичный с расширением.pub (id_rsa.pub). Публичный ключ вам необходимо будет скопировать в домашнюю директорию сервера $HOME/.ssh/authorized_keys . После этого сервер будет знать ключ данного пользователя и сможет аутентифицировать вас без пароля. Файл authorized_keys может содержать несколько публичных ключей, допустимых для данного пользователя: просто поместите их в данный файл по порядку. После этих операций вы сможете входить, имея секретный ключ, на сервер, где размещен ваш публичный ключ, причем под тем пользователем, в чьем домашнем каталоге данный ключ находится. Пароля удаленного пользователя не требуется, необходимо только знать пароль расшифровки секретного ключа. Для переноса своего публичного ключа на сервер надо использовать только безопасные источники, иначе ваш ключ могут подменить. Для переноса публичного ключа клиента служит программа ssh-copy-id . Для начала необходимо сделать следующее:
# ssh-copy-id -i public_key_file user@machine

После соединения с севером machine и передачей имени пользователя user (необходимо указывать, если удаленное имя отличается от локального) происходит парольная аутентификация заданного пользователя(или текущего) на удаленной машине, затем происходит копирование ключа public_key_file (или $HOME/.ssh/identity.pub , если имя файла не указано) на сервер в $HOME/.ssh/authorized_keys . После этого можно входить на сервер, не используя пароль пользователя. При выполнении данной операции учтите, что вы должны скопировать на удаленную машину ПУБЛИЧНЫЙ ключ, иначе все будет очень печально (думаю, ясно почему).

3) Обычная парольная аутентификация.

Тут можно отметить только одно: в любом случае вначале идет обмен асимметрическими ключами, и хеш пароля передается в зашифрованном виде. Парольная аутентификация используется наиболее часто, но, честно говоря, ssh предлагает более удобные методы аутентификации, и пользоваться ими IMHO можно, если к ssh есть все заплатки. И, конечно же, протокол версии 1 необходимо вырубить вообще. Итак, начинаем настройку…

Я заметил, что большинство администраторов просто оставляет конфиги клиента и сервера по умолчанию, чтобы руки не марать. Но это неправильно: в разных системах эти конфиги различаются очень существенно, и это приводит к неразберихе и непониманию работы сервера, что создает дополнительную угрозу безопасности (свой сервак — потемки). Для этого я решил описать файлы конфигурации ssh на примерах ssh_config и sshd.conf для клиента и сервера соответственно. Для конфигурации клиента используется файл $HOME/.ssh/config или /etc/ssh/ssh_config (для всей системы). Файл имеет следующий формат: определение адреса хоста и параметры для него. В адресе можно использовать обычные шаблоны * и?, все имена параметров и их значения должны быть набраны в том же регистре, что и в примере (иначе параметр воспринят не будет). Вот пример ssh_config , который содержит наиболее полезные опции (на самом деле описывать некоторые параметры конфигурации ssh не имеет смысла, т.к. употребляются они очень редко):

# Определение хоста, в данном случае включает все хосты домена test.ru, можно
# использовать одиночный символ * чтобы указать параметры доступа к любому хосту
Host *.test.ru
# Эта опция определяет, будет ли ssh использовать передачу данных от удаленного
# X сервера через свой безопасный канал. Далее будет описано, каким образом
# организуются безопасные туннели через ssh. Данная возможность позволяет
# защищать по идее небезопасные протоколы(X, pop, smtp, ftp) шифрованием ssh. По
# умолчанию данная опция no
ForwardX11 yes
# Список предпочтительных методов аутентификации через ssh версии 2. Первым
# стоит самый предпочтительный протокол, думаю, значения данного параметра ясны
PreferredAuthentications hostbased,publickey,keyboard-interactive
# Этот параметр определяет, будет ли производится стандартная парольная проверка
# По умолчанию yes
PasswordAuthentication yes
# Число попыток ввода пароля перед тем, как клиент отсоединяется от сервера. По
# умолчанию пароль можно вводить трижды
NumberOfPasswordPrompts 3
# Список допустимых пользователей для данного сервера. Можно применять два
# формата: список пользователей, разделенных пробелом, и список пользователей и
# хостов, разделенных пробелом(USER@HOST - разрешает данному пользователю доступ
# только с данного адреса). Можно использовать выражения * и?. Подобное же
# назначение имеют опции AllowGroups, DenyUsers и DenyGroups(для групп нельзя
# указывать адрес клиента)
AllowUsers *@*.test.ru
DenyUsers xakep lamer
DenyGroups x*
# Использование ssh(2 версия) аутентификации через rhosts и RSA ключи. По
# умолчанию no.
HostbasedAuthentication yes
# Будет ли клиент пытаться работать по rsh, если ssh недоступен или по каким-то
# причинам работает неправильно. По умолчанию no
FallBackToRsh no
# Используем ли rsh. По умолчанию no
UseRsh no
# Режим скрипта, когда не спрашиваются пароли с терминала. По умолчанию no
BatchMode no
# Дополнительно проверяется ключ хоста удаленной машины в
# known_hosts, что исключает подмену ip. По умолчанию yes.
CheckHostIP yes
# Данный параметр означает, будет ли клиент доверять полученным от серверов
# ключам. Параметр может принимать следующие значения: yes - ключи никогда
# автоматически не помещаются в known_hosts, ask - ключ может быть помещен в
# known_hosts только после подтверждения пользователя, no - все ключи
# автоматически размещаются в known_hosts(небезопасно). По умолчанию ask.
StrictHostKeyChecking ask
# Следующие параметры определяют секретные ключи ssh различных форматов:
# rsa и dsa
IdentityFile $HOME/.ssh/id_rsa
IdentityFile $HOME/.ssh/id_dsa
# Порт, на удаленной машине используемый ssh. По умолчанию 22
Port 22
# Версии протоколов, используемые клиентом в порядке убывания приоритета.
Protocol 2
# Протокол шифрования для версии 1 протокола ssh
Cipher 3des
# Возможные протоколы шифрования в порядке убывания приоритета для протокола
# версии 2
Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
# Значение escape-символа, сигнализирующего, что идущие за ним символы
# необходимо воспринимать специальным образом(например ~. вызовет немедленное
# отключение клиента от сервера) при передаче двоичных данных необходимо
# установить этот параметр в none, что выключает escape последовательности. По
# умолчанию ~
EscapeChar ~
# Управление работой компрессии зашифрованнного трафика. Полезный параметр для
# медленных сетей, т.к. зашифрованные данные обычно увеличиваются в размере за
# счет фиксированной длины ключа. Компрессия позволяет уменьшить количество
# данных, передаваемых через сеть, но увеличит время работы самого протокола.
# Так что включать этот параметр желательно на медленных соединениях. По
# умолчанию no.
Compression yes
# Управляет посылкой сообщений о доступности клиента серверу, что позволяет
# нормально разорвать соединение, если произошла неполадка в сети или иная,
# приведшая к разрыва соединения. Если связь плохая, то лучше эту опцию
# отключить, чтобы дисконнект не происходил после каждой ошибки сети. По
# умолчанию yes.
KeepAlive yes

Я думаю, что в данном примере все объяснено достаточно подробно и скажу только вот что: в большинстве случаев опции по умолчанию работают неплохо, необходимо только отключить поддержку ssh версии 1 и настроить необходимые методы аутентификации (кроме парольной) и указать пути доступа к ключам. На этом закончим с настройкой клиента и настроим сервер. Файл конфигурации сервера sshd находится в /etc/ssh/sshd_config , и многие его параметры совпадают с аналогичными в ssh_config , но здесь нет определений хостов, как это было в ssh_config . Я все же приведу пример sshd_config, чтобы далее не возникало вопросов:

# Номер порта и версия протокола
Port 22
Protocol 2

# Адреса, на которых слушает сервер, можно также указывать
# порт (server.test.ru:2022), но назначение ssh нестандартного порта
# нецелесообразно, т.к. заинтересует потенциальных взломщиков("А чего это там
# они прячут?")
ListenAddress server.test.ru

# Ключ сервера для протокола версии 1
HostKey /etc/ssh/ssh_host_key
# Ключи rsa и dsa для ssh версии 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

# Данные значения определяют длину ключа сервера и его время жизни для
# использования ssh версии 1(данный ключ будет заново генерироваться через
# заданное время)
#KeyRegenerationInterval 3600
#ServerKeyBits 768

# Сервер отсоединяется по происшествии данного времени в секундах, если клиент
# не проходит аутентификацию
LoginGraceTime 600
# Разрешаем заходить по ssh руту. Долгое время эта тема обсуждалась на форуме,
# но я думаю все же, что со внутренней сети рут может заходить и по ssh (для
# этого надо настроить должным образом iptables). Также можно запретить руту
# входить по паролю: without-password, разрешая вход только по публичному ключу
PermitRootLogin yes
# Проверка sshd прав доступа и владельцев домашних каталогов. Полезно для тех
# пользователей, что дают права всему 0777. Хотя таких болванов лучше держать на
# расстоянии от сервера(лучше всего это делать бревном, подвешенным в серверной
# к потолку, чтобы придать нежеланному гостю должное ускорение, и не забудьте
# оббить конец бревна какой-нибудь железкой, иначе бревна придется менять
# слишком часто;)
StrictModes yes

# Аутентификация через RSA (версия 1)
RSAAuthentication yes
# Аутентификация пользователя по ключу (версия 2)
PubkeyAuthentication yes
# Определяет публичный ключ пользователя для аутентификации по ключу. Можно
# применять шаблоны: %u - имя пользователя, %h - домашний каталог пользователя.
AuthorizedKeysFile .ssh/authorized_keys

# Не используем аутентификацию rhosts
RhostsAuthentication no
# Можно также игнорировать rhosts и shosts при hostbased autentification,
# используя только known_hosts файл.
#IgnoreRhosts yes
# Используем ли аутентификацию через known_hosts совместно с.rhosts или
# .shosts. Опция действительна только для протокола версии 1.
RhostsRSAAuthentication no
# То же самое, что и предыдущее только для версии 2
HostbasedAuthentication yes
# Если нет доверия к known_hosts, то их можно не использовать при hostbased
# autentification. По умолчанию no
IgnoreUserKnownHosts no

# Чтобы запретить посылку хешей паролей через туннель ssh задайте значение
# данной опции no. По умолчанию аутентификация по паролю разрешена
PasswordAuthentication yes
# Можно также разрешить пустые пароли, но это полный отстой, т.к. это огромная
# дыра на сервере, через которую можно наделать много гадостей! Поэтому должно
# быть no (по умолчанию)
PermitEmptyPasswords no

# Аутентификация через механизм PAM.
PAMAuthenticationViaKbdInt no

# Передача протокола иксов через туннель ssh
X11Forwarding yes
# Используем в качестве x-сервера данный, т.е. клиент, запуская у себя x-клиента
# будет фактически использовать наш сервер, но все данные от сервера к клиенту
# будут шифроваться, что есть хорошо!
X11UseLocalhost yes
# При логине пользователя выводим /etc/motd: в некоторых системах это отменено в
# целях безопасности
PrintMotd yes
# Сообщаем пользователю время и место последнего логина, ситуация, аналогичная
# предыдущей
PrintLastLog yes
# Посылать клиенту сообщения о доступности
KeepAlive yes
# Максимальное число возможных соединений, где не произошло аутентификации. Если
# клиентов, не прошедших аутентификацию больше, то новые соединения не будут
# обрабатываться
MaxStartups 10
# Путь к файлу, который будет отображаться при входе клиента ДО аутентификации
Banner /etc/ssh_message
# Проверка соответствия ip адреса клиента и его символического имени в backzone,
# затем снова сравнение имени с ip адресом. Таким образом (извращенным)
# проверяется подлинность ip, но метод этот достаточно тормозной и по умолчанию
# он отключен
VerifyReverseMapping no

# Новые системы, работающие через ssh. В данном примере определяется
# "безопасный" ftp сервер - sftp, аналогичный доступ пользователя, но с
# возможностью передачи файлов(т.е. пользователь получает доступ ко всем своим
# файлам и нет возможности настройки разрешений и виртуальных пользователей,
# как, например в proftpd). По сути дела подсистемы ssh могут обеспечивать
# прохождение других протоколов по сети, но под "крылышком" ssh. Например, для
# sftp сервера есть одноименный sftp клиент. Его интерфейс полностью идентичен
# оригинальному ftp, но с одним отличием: происходит та же самая аутентификация
# пользователя на удаленном сервере(методами ssh), но вместо оболочки с
# пользователем взаимодействует подсистема, в данном случае sftp.
Subsystem sftp /usr/lib/ssh/sftp-server

Ну вот, вроде бы все настроено! Теперь я бы хотел поговорить о некоторых фичах, работающих в ssh. Для начала я бы хотел рассказать о туннелях. SSH имеет встроенную возможность передавать данные с локального порта на удаленный, используя сетевой туннель, причем данные, передаваемые через данный туннель будут шифроваться. То есть происходит аутентификация на удаленной системе, а затем начинается перенаправление трафика через туннель. Таким образом, можно перенаправлять любой трафик, а протокол иксов может работать в интерактивном режиме, для этого необходимо включить соответствующие опции в файлах конфигурации сервера и клиента(это было описано ранее). Для других же портов необходимо вызывать ssh с параметром -L{LOCAL_PORT}:{LOCAL_ADDRESS}:{REMOTE_PORT} :
# ssh -L10101:localhost:101 server.test.ru

Такой туннель довольно быстро умирает, т.к. сервер автоматически убивает «ленивых» клиентов. Поэтому можно применить метод, который позволяет устанавливать произвольное время удержания туннеля: выполнить sleep на удаленном сервере:
# ssh -f -L10101:loclahost:101 server.test.ru sleep 100

Данная команда держит туннель 100 секунд, чего достаточно для любого соединения. И еще одна вещь: когда по туннелю передаются данные, то он не уничтожается, что хорошо для реализации безопасного ftp-, smtp- и pop3-протоколов (впрочем, sftp-сервер имеется уже и в поставке openssh, применение его не должно вызвать затруднений sftp hostname, т.к. фактически это особая реализация ssh протокола и механизм работы sftp абсолютно идентичен механизму ssh). Чтобы отключить перенаправление портов, необходимо установить опцию sshd AllowTcpForwarding в no . Использование длительной задержки ssh-туннеля несколько уменьшает безопасность, т.к. во время ожидания злоумышленник имеет больше шансов на атаку (но механизм ssh версии 2 позволяет избежать подобной ситуации подписыванием передаваемых сообщений).

Вот что сделал бы я для безопасного ssh. Для начала создал бы rsa-ключ длиной 4096 бит:
# ssh-keygen -t rsa -b 4096

Затем скопировал бы данный ключ с помощью дискеты или ssh-copy-id на удаленный сервер(а):
# ssh-copy-id -i $HOME/.ssh/id_rsa remote_host

После этого запретил бы парольную и всякую hostbased аутентификацию в sshd_config:
IgnoreHosts yes
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes
HostbasedAutentification no
PasswordAuthentication no
PermitEmptyPasswords no
UseLogin no
PermitRootLogin without-password

И отключим потокол версии 1 (по умолчанию Protocol 2,1 и сервер падает к ssh 1, при неудаче ssh 2):
Protocol 2

Ну, вот, теперь, чтобы зайти на сервак по ssh надо ввести нехилый (а он должен быть нехилый!) пароль секретного ключа. Немножко неудобно, не правда ли? Можно хранить пароль для секретного ключа в памяти на протяжении работы некоторой программы (например, bash) и при запросе его ssh клиентом доставать из памяти. Для этой цели служит программа ssh-agent (агент аутентификации ssh). Агент запускает необходимую программу и ждет добавления новых секретных ключей (ssh-agent хранит расшифрованные секретные ключи). Для этой цели есть другая программа — ssh-add , которая добавляет в агент ключи $HOME/.ssh/id_rsa , id_dsa , identity . Если необходимо добавить другие ключи, то надо запустить ssh-add с именем файла: ssh-add filename . Учтите, что при добавлении ключа в агент ssh-add вам все равно необходимо ввести пароль для его расшифровки, но пока агент находится в памяти (пока вызванная им программа не завершилась), вводить пароль секретного ключа не надо: ключ берется из ssh-agent . Причем контакт с ssh-agent может устанавливать только программа, запущенная им (и все ее дочерние процессы), т.к. устанавливаются переменные окружения. Обычный метод запуска ssh-agent:
# ssh-agent bash
# ssh-add
Enter passphrase for ".ssh/id_rsa":
Enter passphrase for ".ssh/id_dsa":
.ssh/identity: No such file or directory

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

Ну, и наконец можно разрешить доступ определенных пользователей с определенных машин. Это делается полем AllowUsers в sshd_config или правилами iptables. Думаю, этого достаточно для нормальной и безопасной работы на удаленном сервере через ssh. Особо мнительные могут запретить доступ рута по ssh (PermitRootLogin no) и делегировать часть его прав с помощью sudo. Ну, и использовать протокол версии 2 (такие плюсы, как алгоритм вычисления симметрического ключа на основании пары асимметрических, и подписывание сообщений, передаваемых по сети, а также 2 версия протокола ssh быстрее первой). Существует множество клиентов ssh, работающих на разных ОС:

Windows:
— putty (IMHO лучший виндовый клиент).

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

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

Сегодня я постараюсь описать некоторые из возможностей, не все конечно так как для этого не хватит одного материала. Ниже мы рассмотрим небольшую подборку из 20 команд или более правильно выразиться рецептов, которыми вы можешь пользоваться как шпаргалкой в будущем. Эти команды доступны для работы как в Linux, так и в большинстве других ОС, которые имеют сборку OpenSSH. Чтобы не запутать, уточню, что удaленный пользователь и хост в материале ниже мы всегда обозначаем как либо по отдельности как и .

1. Возможность быстрого запуска команд

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

Ssh df -h

А так - перезагрузить ее:

Ssh sudo reboot

2. Запуск списка команд

Если у тебя есть целый список команд, которые следует выполнить, их можно записать в файл и скормить этот файл SSH:

Ssh "`cat file.txt`"

3. Удаленные редактирование файлов локальным редактором

Чтобы отредактировать файл на удаленной машине, не обязательно заходить на нее и иcпользовать консольный редактор(vim/nano итд). Вы можете открыть на редактирование файл одним из текстовых редакторов которые установлены у вас на локальной машине (gedit заменяем на свой редактор):

Gedit scp:// //путь/к/файлу

4. Копирование содержимое удаленного файла в буфер обмена

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

Ssh cat /путь/к/файлу | xclip

Как вариант скопировать вывод команды:

Ssh uname -a | xclip

5. Сравнение удаленного и локального файлов без копирования

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

Ssh cat /путь/к/удаленному/файлу | diff /путь/к/локальному/файлу -

6. Работа с удаленными файлaми используя локальный файловый менеджер

Работая с большим количеством файлов, не удобно для этого использовать консольные команды или mc который запущен на удаленной машине. Но вы всегда можно подключить любой из каталогов удаленной машины например как сетевой диск. Это вы можете осуществить используя утилиту sshfs:

Sudo apt install sshfs

Создаем каталог для подключения «сетевого диска»:

Mkdir remote_files

8. Как быстро скопировать ключи

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

Ssh-copy-id

Не обязательно копировать основной ключ, используя флаг -i можно указать любой другой:

Ssh-copy-id -i ~/my_key.pub

9. Создаем стабильное соединение с машиной

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

Добавьте следующие строки в ~/.ssh/config:

Host host ControlPath ~/.ssh/master-% %h:%p ControlMaster no

А затем создайте соединение:

Ssh -MNf

10. Используем версию SSH для неустойчивых соeдинений

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

Решить проблему можно используя autossh . Это обертка над SSH, которая позволяет проверять жизнеспособность канала. Autossh создает дополнительное SSH-соединение с сервером и непрерывно шлет по нему heartbeat-пакеты. Если пакет не доходит до адресата, autossh считает канал мертвым и перезапускает SSH-соединение.

Пользоваться очень просто:

Sudo apt install autossh autossh -M5000

По дефолту тайм-аут между отправкой heartbeat-пакeтов составляет десять минут, что очень много. Если вы хотите уменьшить тайм-аут пропиши его в переменную AUTOSSH_POLL перед запуском autossh (значение в секундах):

Export AUTOSSH_POLL=10

Либо используем вариант еще лучше предыдущего: mosh . Оптимизированная для неустойчивых и низкоскоростных соединений версия SSH, работающая по протоколу UDP. Mosh позволяет получить быстрое и отзывчивое соединение даже на очень медленном канале, из коробки позволяет поднимать упавшее соединения, переключать клиента с одного IP на другой (при переключении с Wi-Fi-соединения на мобильное, например) без перезапуска сессии.

Mosh имеет вcего один недостаток: он требует установки не только на локальную машину, но и на удаленную. Зато после этого ничего настраивaть не нужно, достаточно использовать команду mosh вместо ssh. Более того, mosh уже встроeн в SSH-клиенты JuiceSSH для Android и Blink для iOS.

11. Открываем порт SSH лишь по необходимости

Работая с SSH порт вашего сервера в ближайшем будущем станет целью большого количества ботов, которые будут пытаться к нему подключаться или же подобрать пароль, даже если вы отключили аутентификацию по паролю. Как бороться с ботами? Для этой задачи у нас есть два способа: первым способом будет установка утилиты fail2ban которая поможет автоматически отшибать особо надоедливых ботов, второй способ, это конечно же открывать порт только тогда, когда вам это необходимо.

Если вы подключаетесь к серверу нечаcто, второй способ идеален. Идея в том, что на сервер устанавливается специальный демон, который слушает указанные порты и в случае соединения с этими портами в определенном порядке откроет 22-й порт. Другой порядок соединения будет закрывать порт.

Техника называется port knoking и реализуется с помощью демона knockd. Установка демона на сервер:

Sudo apt install knockd

Настройка демона, добавьте в файл конфиг /etc/knockd.conf следующие строки:

Logfile = /var/log/knockd.log sequence = 3000,4000,5000 seq_timeout = 5 command = /sbin/iptables -A INPUT -i eth0 -s %IP% -p tcp --dport 22 -j ACCEPT tcpflags = syn sequence = 5000,4000,3000 seq_timeout = 5 command = /sbin/iptables -D INPUT -i eth0 -s %IP% -p tcp --dport 22 -j ACCEPT tcpflags = syn

Перезапустим демон:

Sudo /etc/init.d/knockd restart

Теперь используем следующую команду для подключения к серверу:

Knock 3000 4000 5000 && ssh && knock 5000 4000 3000

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

12. Защищаемся от брутфорса

Установка fail2ban - второй метод защиты от ботов которые подбирают пароли. Демон Fail2ban, имеет основную задачу, непрерывно мониторить логи сетевых служб (Apache, vsftpd, SSH…) где он проверяет, ищет вредителей которые слишком часто пытаются аутентифицироваться и блокирует их IP (три неудачные попытки подряд и в бан на десять минут).

Преимущество fail2ban в том, что он не нуждается в настройке и начинает работать сразу же после установки. Все, что надо сделать, - это установить пакет:

Sudo apt install fail2ban

Используя SSH, вы можете легко проверить скорость вашего соeдинения с машиной. Для этой задачи можно использовать утилиту pv (pipe viewer). Смотрим пример команды ниже:

Yes | pv | ssh "cat > /dev/null"

14. Используем SSH как SOCKS-прокси

SSH очень легко изменить в SOCKS-прокси, который будет пересылать ваши данные между локальной машиной и SSH-сервером через зашифрованный канал. Для этого вам нужно сделать следующее, - запустить SSH-клиент с флагом -D, пoсле которого указать номер SOCKS-порта (флаг -C включает принудительное сжатие трафика):

Ssh -D 9999 -C

15. Обходим файрволы

В дополнение к SOCKS-прокси, SSH имеет функцию прозрачного «проброса портов». Работает примерно так: на локальной машине открывается порт. Трафик, который будет передаваться на этот порт, прозрачно проксируется через удалeнную машину и направляется на указанный хост:порт. Приведу пример: ваш твой начальник заблокировал доступ к linuxsoid.com на уровне корпоративного файрвола. Но вы можете обойти это ограничение, используя удаленный SSH-сервер:

Ssh -L8080:linuxsoid.com:80

Теперь все подключения к localhost:8080 будут перенаправляться на linuxsoid.com:80.

16. Сохраняем настройки подключения к хостам

Если вы работаете с большим количеством хостов используя имя разных юзеров и к всему этому используете разные ключи, вы можете существенно упростишь вашу жизнь, если создадите для этих хоcтов шорткаты. Например, следующие строки ~/.ssh/config описывают два хоста:

• site.com, SSH-сервер на кoтором «висит» на порту 2222, а в качестве ключа используется ~/my_key.pem ;
• 192.168.0.1, с SSH-сервером на стандартнoм порту, юзером root и принудительным отключением аутентификации с помощью ключа. Host server1 HostName site.com Port 2222 User user IdentityFile ~/my_key.pem Host server2 HostName 192.168.0.1 User root PubkeyAuthentication no

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

Ssh -i ~/my_key.pem -p 2222

Вы можете использовать шорткат:

Ssh server1

17. Подключаемся к удаленной машине через другую машину

Например, у вас есть доступ к host1, но вы не имеете доступа к host2 (он за файрволом), но доступ к host2 имеется у host1. В итоге вы можете подключиться к host2 вот так:

Ssh -t ssh

18. Копиpуем файлы с удаленной машины на другую машину через свою

Примерно такая же история как и при подключении к удаленной машине через другой компьютер. У вас есть файл который необходимо скопировать с host1 на host2, но они не могут друг с другом общаться. В данном случае, вы можете скопировать файл используя локальную машину:

Ssh "cd /копируемый/каталог/ && tar -cf - ." | ssh "cd /куда/копировать/ && tar -xf -"

19. Запуск графических приложений

Linux/BSD используют ту же клиент-серверную оконную систему X Window System, которая изначально разрабатывалась для запуска графических приложений на мейнфрейме с выводом изображения на экран клиента. Поэтому она из коробки позволяет запускать приложения на удаленной машине так, чтобы их вывoд был перенаправлен на локальную. SSH умеет форвардить протокол X, так что его можно использовать для запуска не только консольных, но графических приложений:

Ssh -X firefox

20. Прослушивание музыки с удаленной машины

Немного надуманный, но в целом довольно интересный трюк:

Ssh "cat /home/user/music/*.mp3" | mpg123 -

Своего рода интернет-радио для одного.

Выводы

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 или в Linux SSH-порт открыть не так уж и трудно. Вопрос только в том, какой именно инструментарий для этого будет использоваться.

В этом смысле нужно обратить внимание на вопрос передачи информации и аутентификации. Во-первых, сам протокол оказывается достаточно защищенным от так называемого снифинга, представляющего собой самую обычную «прослушку» траффика. 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 можно и не менять. Тут особых проблем при создании соединения и его дальнейшем использовании, в общем-то, не предвидится (если, конечно, не будет использоваться ручная настройка конфигурации на основе сервера и клиента). Самое обычное создание правила исключения на роутере позволяет исправить все проблемы или избежать их появления.

Использование ssh

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

Из man ssh мы можем узнать что: "Ssh (Secure Shell) - программа для регистрации на удаленной машине и выполнения команд на ней. Предназначена заменить rlogin и rsh, и обеспечить безопасную шифрованную связь между двумя компьютерам по незащищенной сети. Соединения X11 и произвольные TCP/IP порты могут также быть перенаправлены по защищенному каналу". Это мощная, очень удобная в работе программа, которая использует сильное шифрование для защиты всех передаваемых конфиденциальных данных, включая пароли.

В настоящее время существуют два SSH протокола, SSH2 и SSH1, первый является усовершенствованием SSH1. SSH2, помимо двойного шифрованного обмена ключами RSA, поддерживает и другие методы. Текущий дистрибутив поставляется со схемой обмена ключами Diffie-Hellman, имеет поддержку DSA и других алгоритмов открытых ключей.

SSH2 может быть совместим с SSH1, но не совместим по умолчанию; SSH2 сервер один не может управлять SSH1 соединением, требуется еще и SSH1 сервер, чтобы сделать это.

Получение и установка SSH

Вы можете получить SSH2 и SSH1 клиентов и серверы с master FTP server , или его зеркал. Последняя версия SSH1 протокола - ssh-1.2.30.tar.gz, в то время как для SSH2 ssh-2.3.0.tar.gz

Установка действительно проста. Первый шаг - распакуйте исходники:

Tar -zxf ssh-1.2.30.tar.gz

Это создаст каталог ssh-1.2.30. Теперь войдите в этот каталог, и запустите процесс конфигурации:

Сd ssh-1.2.30 ./configure.

Скрипт configure выполнит всю необходимую конфигурацию, поиск в системе требуемых библиотек и программ. Когда скрипт закончит свою работу, выполните:

После успешного завершения войдите супер-пользователем и установите бинарные, конфигурационные файлы и файл hostkey выполнив:

Make install

Это установит клиентов (scp1, ssh-add1, ssh-agent1, ssh-askpass1, ssh-keygen1, ssh1) в /usr/local/bin, и сервер (sshd1) в /usr/local/sbin. Обратите внимание, что, в /usr/local/bin имеется также символическая ссылка на реально исполняемые программы.

Следующим шагом установим SSH2. Действия те же, что и для SSH1:

Tar -zxf ssh-2.3.0.tar.gz cd ssh-2.3.0 ./configure make и как супер-пользователь: make install

Совместимость SSH1 - SSH2

В дальнейшем мы предполагаем, что SSH1 и SSH2 установлены.
Чтобы сделать SSH2 сервер способным управлять соединениями SSH1, надо отредактировать конфигурационные файлы SSH2, которые обычно помещают в каталог /etc/ssh2/.
В том каталоге редактируем sshd2_config - файл конфигурации для sshd2, который является демоном для ssh2. Добавьте строки:

Ssh1Compatibility yes Sshd1Path /usr/local/sbin/sshd1

Измените путь на реальный, куда установили sshd1. В этой конфигурации sshd2 сервер перенаправит запросы от SSH1 клиента к sshd1.

Теперь добавьте строки к файлу ssh2_config , размещенному в том же каталоге:

Ssh1Compatibility yes Ssh1Path /usr/local/bin/ssh1

Теперь ssh2 клиент вызовет ssh1 клиента при соединении с SSH1 сервером.

Запуск SSH

Существуют два основных способа запуска sshd при начальной загрузке.

Войдите в /etc/rc.d каталог, и отредактируйте файл rc.local . В его конец добавьте строки:

echo "Starting sshd ...." /usr/local/sbin/sshd

Таким способом sshd запускается в конце очередной загрузки компьютера с сообщением "Starting sshd...." на экране.
Запускать sshd можно и без перезагрузки из командной строки:

/usr/local/sbin/sshd

Альтернативно, в системах, использующих System V инициализацию, Вы можете поместить сценарий sshd2.startup , поставляемый с дистрибутивом, в /etc/rc.d/init.d, назвав его sshd2. Перейдите в каталог rc$number.d , где $number - ваше значение runlevel по умолчанию. Вы можете найти это значение в файле /etc/inittab: id:5:initdefault или id:3:initdefault В первом случае ваш runlevel - 5, во втором 3.

В каталоге rc$number.d выполните команду:

Ln -s ../init.d/sshd2 S90sshd2

Потом перейдите в директорию /etc/rc.d/rc0.d и выполните:

Ln -s ../init.d/sshd2 K90sshd2

Повторите операцию в каталоге /etc/rc.d/rc6.d.

Теперь Вы можете запускать sshd2 без перезагрузки машины, просто выполнив сценарий:

/etc/rc.d/init.d/sshd2 start

Установление SSH соединения

Запустив sshd на своей машине, проверьте правильность настроек, попробовав зайти на нее, используя ssh клиента. Давайте предположим, что ваша машина названа host1 и вы входите под именем myname. Запустите ssh соединение, используя команду:

Ssh -l myname host1

ssh2 клиент (клиент по умолчанию) попробует соединиться с host1 порт 22 (порт по умолчанию). Sshd2 демон, выполняющийся на host1, перехватывает запрос и запрашивает пароль для myname. Если пароль правилен, он позволяет вход в систему и запускает shell.

Генерирование и управление ssh ключами

Ssh предлагает и другой аутентификационный механизм, основанный на аутентификационных ключах: метод шифрования с открытым ключом. Каждый пользователь, желающий использовать ssh с аутентификацией с открытым ключом, должен выполнить команду ssh-keygen (без опций) чтобы создать ключи. Команда генерирует пары ключей (публичный и частный) и запрашивает passphrase для их защиты.Создаются два файла в каталоге $HOME/.ssh2/ : id_dsa_1024_a и id_dsa_1024_a.pub , пользовательские частный и публичный ключи.

Давайте предположим, что у нас есть два аккаунта, myname1 на host1 и myname2 на host2 . Мы хотим войти с host1 на host2, используя аутентификацию ssh c открытыми ключами. Чтобы сделать это, потребуются четыре шага:

1. На host1 генерируем ключевую пару, используя команду ssh-keygen, и выбираем passphrase (кодовую фразу), чтобы защитить ее.
2. Входим на host2, используя парольную идентификацию ssh, и повторяем предыдущую операцию. Переходим в каталог $HOME/.ssh2, и создаем файл identification , содержащий следующие строки: # identification IdKey id_dsa_1024_a

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

Находясь на host2, получим публичный ключ ssh host1, и переименуем его (например в host1.pub ):

Ftp host1 [...] cd .ssh2 get id_dsa_1024_a.pub host1.pub

По окончании ftp сеанса копию публичного ключа host1, названного host1.pub , перемещаем в каталог $HOME/.ssh2 на host2.

3. Создаем файл authorization , содержащий следующие строки: # authorization Key host1.pub

   Этот файл содержит все доверительные публичные ssh ключи, помещенные в каталог $HOME/.ssh2. Когда ssh инициировано пользователем, публичный ключ которого соответствует одной из записей файла authorizashion , стартует схема аутентификации с открытыми ключами.

Чтобы проверить полученную конфигурацию, пробуйте соединиться с host1 на host2, используя ssh. Sshd должен ответить запросом о passphrase, иначе, если затребован пароль, в процессе конфигурации были ошибки, и Вы должны тщательно проверить шаги с 1 до 4.
Требуемая passphrase - ваша ЛОКАЛЬНАЯ passphrase (то есть passphrase, защищающая публичный ключ host1).

В следующей статье...

Следующая статья представит другие программы и средства из комплекта ssh: ssh-agent и ssh-add (две полезных программы управления passphrase), а также sftp и scp (защищенный ftp).

Copyright © 2000, Matteo Dell"Omodarme.
Copying license

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

Secure Shell - так расшифровывается аббревиатура SSH. Благодаря использованию этой технологии достигается надежная авторизация и безопасная передача информации по открытым каналам связи. SSH успешно заменяет такие протоколы, как telnet, rlogin, rcp и rsh. Т.к. применение перечисленных технологий связано с некоторыми проблемами безопасности:

1. Передача данных по сети осуществляется в открытом виде, поэтому любой пользователь компьютера, подключенного к этой сети, может перехватить эти данные. Проблема безопасности усугубляется еще и тем, что пароли также передаются в открытом (незашифрованном) виде.
2. Также авторизация с использованием IP-адресов (rlogin) и паролей (telnet и FTP) весьма уязвима с точки зрения безопасности. SSH отлично справляется с перечисленными выше задачами. Даже учитывая то, что вход в другой компьютер осуществляется с помощью введения пароля. Этот пароль не может быть перехвачен, так как его передача осуществляется в зашифрованном виде.

Принцип работы SSH

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

Допустим Штирлицу необходимо передать в Центр важные данные, но старый шифр уже известен врагам. Что же предпринять в этой ситуации? Самым оптимальным вариантом может быть организация встречи для передачи Штирлицу нового шифра (то есть создать новый код). Однако если встреча невозможна, то остается только открытый канал связи, который могут прослушивать враги. Но и эту ситуацию можно решить.

В середине 1970-х годов учеными-математиками был разработан алгоритм RSA. Используя его, можно применять в криптографии «публичные ключи». Суть этого алгоритма состоит в том, что существует два криптоключа: один используется для зашифровки, а второй применяется для расшифровки. «Публичным ключом» называется код для зашифровки, так как он не является секретным и его можно свободно передавать. В отличии от ключей для зашифровки, ключи для расшифровки являются секретными, (ещё их называю приватными) и это значит, что расшифровать сообщение сможет только владелец этого ключа.

Действие алгоритма RSA основано на невозможности получения из публичного ключа приватного ключа, который необходим для расшифровки. Поэтому, если бы действие знаменитой киноленты «Семнадцать мгновений весны» происходило сейчас, Центру было бы достаточно отправить Штирлицу новый публичный ключ, а Мюллеру не удалось бы расшифровать их сообщения, сколько бы он не пытался.

Какой лучше выбрать SSH клиент?

Чтобы использовать Secure Shell-доступ достаточно скачать, а затем установить любой SSH-клиент. Специалисты советуют отдать предпочтение популярному и бесплатному клиенту Filezilla . Также существует WinSCP2 , так как это одна из наиболее эффективных программ, которая может работать по протоколу SSH2. Программа визуально похожа на достаточно известный FTP-клиент - CuteFTP , она имеет хороший графический интерфейс, а также предоставляет возможность сравнения контента каталогов. Третей в этом списке идет программа PuTTY (как настроить PuTTY), которая тоже имеет своих поклонников, на нашим экспертам понравилась меньше всего.

Для того чтобы осуществить настройку SSH-клиента, достаточно указать ваше доменное имя (или User ID), IP адрес, пароль и выбрать SHH-протокол. Другие настройки вы можете оставить по умолчанию. После того, как соединение будет установлено, сервер отправит запрос на введение пароля и имени пользователя. вам следует ввести данные, аналогичные тем, что вы используете для получения FTP-доступа (их обычно присылает хостинг-провайдер в первом письме, после создания аккаунта).

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