Как пользоваться протоколом SSH в Ubuntu: установка и настройка. Установка и настройка OpenSSH-сервера на Linux Чтобы подключиться к ubuntu по 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, поэтому использовать лучше именно данный файл; - /etc/hosts.equiv - также содержит пары имя машины/имя пользователя, но имеет эффект на всех пользователей; - /etc/shosts.equiv** - аналог hosts.equiv, но применяется только ssh, что также более предпочтительно. - /etc/ssh/ssh_known_hosts и $HOME/.ssh/known_hosts*** - данные файлы содержат список адресов и соответствующих им публичных ключей. При запросе клиента сервер генерирует рандомную строку и шифрует ее публичным ключом удаленного хоста. Клиент, получив данную строку, расшифровывает ее своим секретным ключом (который имеется только у него) и зашифровывает полученную строку ключом сервера. Сервер получает зашифрованное сообщение, расшифровывает своим секретным ключом и сравнивает с исходной. Если строки совпали, то клиент имеет валидный секретный ключ, что дает ему право захода на данный сервер. Но для начала клиент должен иметь правильный адрес, которому соответствует публичный ключ на сервере в файле ssh_known_hosts. Файл состоит из 3-х полей: адрес (или адреса, разделенные запятой), публичный ключ для него одной (!) строкой и дополнительное поле комментариев(необязательно);

    * Пример.shhosts:

    User1.test.ru user1 userstend.test.ru user1 null.test.ru user1

    ** Пример файла /etc/shhosts.equiv:

    User1.test.ru user1 - server.test.ru xakep Знак «+» означает разрешение пользователю работать с сервером с данного адреса, знак «-» запрещает подобное действие.

    *** Пример файла 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

    После этого запретил бы парольную и всякую host-based аутентификацию в 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 выделю


Для установки ssh-сервера выполните в терминале:

Ubuntu/Debian/Linux Mint

Затем отредактируйте настройки ssh-сервера в файле /etc/ssh/sshd_config
Для этого в терминале выполните:


Также для того чтобы OpenSSH слушал только определенные ip адресса, допустим 192.168.0.50, 192.168.0.51 на порту 777, то просто добавьте следующие строчки:

Ограничить доступ через SSH для пользователей: test test2 test3

OpenSSH сервер может использовать протокол Rlogin для авторизации и может имитировать поведение устаревшей комманды rsh, по этому отключите чтение пользовательских файлов ~/.rhosts и ~/.shosts:

Включите предупреждающий баннер отредактировав следующую строку и создания соотв. файла:

Сохраняйте логи, удостоверьтесь что директива LogLevel имеет значение INFO или DEBUG

Чтобы перезапустить OpenSSH на CentOS, Fedora или RHEL:

В некоторых случаях, запустить сервер можно только таким способом:


Для проверки статуса сервера используем следующую команду


Теперь на компьютер с установленным OpenSSH-server можно зайти так:

Ssh [-p port]

Например:

CentOS / RHEL / Fedora Linux - отключить или удалить OpenSSH можно так:

$ chkconfig sshd off
$ yum erase openssh-server

Основные файлы и папки SSH:
~/.ssh/ - пользовательские конфигурационные директории
~/.ssh/authorized_keys и ~/.ssh/authorized_keys2 - списки публичных ключей (RSA или DSA), которые могут быть использованы для авторизации в пользовательский аккаунт
~/.ssh/known_hosts - ключи серверов
/etc/ssh/sshd_config - конфигурационный файл сервера OpenSSH
/etc/ssh/ssh_config - конфигурационный файл клиента OpenSSH
/etc/nologin - если этот файл существует, то система будет отказываться пускать кого-либо кроме root-пользователя. Лучше удалить и не использовать.
/etc/hosts.allow и /etc/hosts.deny - списки контроля доступа (ACL)

Мы разобрались, что такое SSH и в чем ее преимущества, также мы реализовали самый простой пример SSH- сервера и клиента.

Сегодня я расскажу про более детальную настройку SSH- сервера.

Как гласит известная фраза, «в Linux все есть файл», поэтому для настройки SSH- сервера необходимо и достаточно отредактировать один конфигурационный файл. Его полный путь — /etc/ssh/sshd_config . Для редактирования откроем этот файл с правами суперпользователя любым текстовым редактором.

Перед редактированием сделаем на всякий случай backup файла:

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

Теперь посмотрим его содержимое:

Sudo nano /etc/ssh/sshd_config

После каждого изменения этого файла необходимо перезапустить ssh- сервер для применения наших изменений.

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

Port

Здесь прописывается, какой порт будет слушать наш сервер. По умолчанию он слушает 22 порт TCP/IP . Интересный факт, что можно указать несколько портов. Например:

ListenAddress

Общий вид настройки можно записать так:

ListenAddress host | IPv4_addr | IPv6_addr ListenAddress :port

Указывает сетевой адрес, на котором будет «слушать» сервер.
Если на сервере есть несколько сетевых интерфейсов, которые настроены на использования разных IP- адресов, то вы можете ограничить доступ по этому параметру.
К примеру, на сервере следующие 4 сетевых интерфейса:

Eth0 – 192.168.0.1 eth1 – 192.168.0.2 eth2 – 192.168.0.3 eth3 – 192.168.0.4

По умолчанию ssh- сервер находится в состоянии ожидания подключения на всех IP- адресах. Если хотите, чтобы пользователи могли авторизовываться только на интерфейсах 2 и 3 , то следует сделать так:

ListenAddress 192.168.0.2 ListenAddress 192.168.0.3

Здесь можно также указать порт. Например:

ListenAddress 192.168.0.2:222

Если порт не задан, ssh будет слушать на этом адресе и
на порту, указанному в опции Port. Если вы будете использовать ListenAddress не указывая порт, то опция Port должна предшествовать опции ListenAddress. Если вообще не указывать ListenAddress, то по умолчанию сервер слушает на всех локальных адресах.

Address Family

Указывает, какое семейство IP адресов должно быть использовано сервисом ssh . Возможные варианты:
“any” — любые
“inet” (только IPv4 )
“inet6” (только IPv6 )
По умолчанию — “any”.

Имеет смысл по возможности ограничить семейство обрабатываемых адресов реально используемыми, т. е. если вы используете только IPv4 - отключите IРv6 , и наоборот.

Например, для разрешения IPv4 и запрета IPv6:

AddressFamily inet

Protocol

ssh может работать с протоколами SSH1 и SSH2. При этом использование небезопасного SSH1 крайне не рекомендуется. Заставить ssh работать только с протоколом SSH2 можно так:

Protocol 2

PermitRootLogin

По умолчанию зайти на удаленный сервер под пользователем root никто не запрещает. Но это не совсем безопасно. В место этого более правильно будет авторизовываться под пользовательской учетной записью и повышать свои привилегии с помощью команды ‘su -‘, либо использовать ‘sudo’.

Если в вашей организации несколько системных администраторов и все они подключаются к серверу под суперпользователем, то не всегда можно узнать кто из администраторов находится на сервере. Поэтому после отключения возможности авторизации напрямую под пользователем root, системные администраторы сначала будут заходить под своей учетной записью и только после этого получать привилегии суперпользователя; это облегчить аудит сервера и действий, которые производят сисадмины.
Для отключения вышеописанной функции следует отключить параметр PermitRootLogin , установив значение “no”.

PermitRootLogin no

PermitEmptyPasswords

Блокируем пустые пароли

PermitEmptyPasswords no

AllowUsers, AllowGroups

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

Для этого в конфигурационный файл sshd_config следует добавить определенных пользователей, существующих на сервере. В примере ниже это пользователи john, peter и michael, которым разрешен вход на сервер. Имя пользователей разделены пробелами.

AllowUsers john peter michael

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

AllowGroups developers administrators

DenyUsers, DenyGroups

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

DenyUsers apache boris

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

DenyGroups marketing hackers

Обратите внимание на то, что можно использовать комбинации запрещающих и разрешающих параметров: DenyUsers , AllowUsers , DenyGroups , и AllowGroups .

LoginGraceTime

При попытке авторизоваться по ssh на сервер у вас есть 2 минуты, чтобы ввести логин и пароль. Если вы этого не сделаете, то соединение с сервером будет разорвано. 2 минуты ожидания авторизационных данных это довольно много. Следует ограничить до 1 минуты или даже до 30 секунд.

Для этого следует изменить параметр LoginGraceTime путем редактирования файла sshd_config, и указать там требуемое время. В примере ниже это 1 минута.

LoginGraceTime 1m

ClientAliveInterval

Рассоединение при отсутствии активности в шелле

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

Используя Bash, вы можете достичь этого, изменив переменную окружения TMOUT .

В OpenSSH же это достигается путем комбинации параметров ClientAliveCountMax и ClientAliveInterval в конфигурационном файле sshd_config.

  • ClientAliveCountMax — указывает максимальное количество checkalive сообщений, отсылаемых ssh- сервером, при которых он не получает какой-либо ответ от ssh- клиента. По умолчанию это 3.
  • ClientAliveInterval — указывает время ожидания (таймаут) в секундах. После указанного времени ssh- сервер отошлет checkalive сообщение клиенту, ожидая от него ответ (response) . По умолчанию — это 0, то есть сервер не будет отсылать сообщения для проверки.

Для того, чтобы ваш ssh- клиент автоматически отключался после 10 минут (600 секунд), следует внести изменения в конфигурационный файл sshd_config следующим образом:

ClientAliveInterval 600 ClientAliveCountMax 0

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

Всем удачи и до скорых встреч на нашем блоге!

В этой статье мы покажем вам, как установить, настроить и использовать OpenSSH на Ubuntu 16.04. SSH (Secure Shell) является протоколом, который позволяет получить надежный доступ к удаленной машине в то время как OpenSSH представляет собой набор инструментов на основе протокола SSH. Сегодня мы покажем вам, как установить и настроить OpenSSH на с помощью Ubuntu 16.04 в качестве операционной системы.

Установка OpenSSH на Ubuntu 16.04

Во-первых, давайте установим OpenSSH. Обновите индексы пакетов с помощью следующей команды:

Sudo apt-get update

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

Sudo apt-get install openssh-server

Обратите внимание, что пакет сервера OpenSSH может быть уже установлен в вашей системе, как часть процесса первоначальной установки сервера. Кроме того, вы можете установить клиентское приложение OpenSSH с помощью следующей команды:

Sudo apt-get install openssh-client

Настройка OpenSSH на Ubuntu 16.04

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

Sudo systemctl start sshd.service

Чтобы остановить службу, вы можете использовать:

Sudo systemctl stop sshd.service

Чтобы перезапустить службу, вы можете использовать:

Sudo systemctl restart sshd.service

Чтобы проверить состояние службы вы можете использовать:

Sudo systemctl status sshd.service

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

Sudo systemctl enable sshd.service

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

Sudo systemctl disable sshd.service

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

Основной конфигурационный файл для приложения сервера OpenSSH это /etc/ssh/sshd_config . Убедитесь, что вы создали резервную копию исходной конфигурации перед внесением каких – либо изменений:

Sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.orig

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

Измените ее на что-то другое. Например 2022

Port 2022

Сохраните файл и закройте его. Затем перезапустите службу, чтобы изменения вступили в силу.

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

Безопасный OpenSSH на Ubuntu 16.04

#PermitRootLogin yes

и измените его на:

PermitRootLogin no

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

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

Дополнительные опции конфигурации вы можете проверить с помощью страницы man:

Man sshd_config

или вы можете посетить страницы вручную OpenSSH на https://www.openssh.com/manual.html.

Установка будет выполнятся из стандартных репозиториев Ubuntu, поэтому потребуется настроенное подключение к сети интернет.

В Ubuntu Server 12.04 используется OpenSSH Server, который и будет установлен. Выполните следующую команду:

sudo apt-get install openssh-server

Установка не займет много времени, возможно несколько минут, в зависимости от скорости подключения к сети интернет. После того, как установка будет завершена можно сразу запустить службу sshd и начать пользоваться ssh сервером, т.к. все настройки OpenSSH, которые устанавливаются при его инсталляции имеют высокую степень безопасности. Для запуска сервера OpenSSH выполните:

Однако, возможно вы захотите добавить ограничений и повысить безопасность, а для этого необходимо внести небольшие изменения в настройки. Как практически во всем серверном программном обеспечении, настройки SSH представляют собой соответствия названий параметров и их значений в файле конфигурации (в данном случае - /etc/ssh/sshd_config).

Повышение безопасности ssh сервера

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

sudo cp /etc/ssh/sshd_config ~

Теперь можно приступить к настройке сервера ssh. Откройте файл /etc/ssh/sshd_config в текстовом редакторе, например, vi:

sudo vi /etc/ssh/sshd_config

Смена порта ssh-сервера

Стандартный TCP/IP порт, который использует ssh-сервер - 22. Зная это многие автоматические программы взлома сканируют сеть, определяя открытые 22 порты и пытаются соеденится по протоколу ssh и подобрать пароль. В том случае, если имя пользователя и пароль просты (что, конечно же, недопустимо) вы подвергаетесь риску, что они будут подобраны и злоумышленник попадет в вашу систему. Смена порта на любой другой в большинстве случаев позволит спрятать ваш ssh-сервер от автоматических систем взлома. Для смены порта найдите в файле конфигурации строчку "Port 22" и измените значение порта, например:

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

Запрещение входа пользователя root по ssh

Запрет входа пользователя root через ssh также несколько улучшит безопасность, ведь если атакующему удастся подобрать пароль и зайти в вашу систему под root"ом, то он сразу получает полный контроль над системой. Для выполнения этой настройки найдите параметр "PermitRootLogin" и смените его значение с "yes" на "no":

Разрешение входа по ssh только определенным пользователям

Другой способ повышения безопасности - ограничить количество пользователей, которым разрешен вход по ssh. Это можно сделать с помощью директивы "AllowUsers". Когда она присутствует в файле конфигурации вход разрешен только тем пользователям, которые описаны в ней. Например, вы хотите разрешить выполнение входа через ssh только пользователю "howtoit", для этого допишите в конец файла /etc/ssh/sshd_config строчку:

Если вы хотите внести в список нескольких пользователей, просто добавьте их через пробел, например так:

AllowUsers howtoitru someuser

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

Теперь вы сможете подключится к вашей системе Ubuntu Server 12.04 c другой машины, используя ssh-клиент.