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

Довольно часто, администрирование сервера на базе Linux происходит посредством удалённого доступа. А основным способом удалённого администрирования является администрирование с помощью SSH. Об этом и пойдёт речь в этой статье. Данная статья входит в цикл статей о настройке коммуникационного сервера класса SOHO под управлением Debian/GNU Linux и подразумевается, что дальнейшая настройка сервера будет производиться с помощью SSH. Цикл статей ещё в процессе написания

Но вернёмся к SSH. Что такое SSH и чем же он так хорош? SSH – это сетевой протокол для TCP-соединений, который позволяет удалённо управлять операционной системой. SSH – это аббревиатура от Secure SHell, что переводится как безопасная оболочка. Вся передаваемая по этому протоколу информация сжимается и надёжно шифруется, а так же производится проверка модификации пакетов. Злоумышленники могут прослушивать сеть, перехватывать и изменять пакеты, но они этим ничего не добьются. Кроме администрирования, через SSH можно передавать другие сетевые протоколы, создавая защищённые туннели.

Раньше для удалённого администрирования компьютеров на базе Linux использовали протоколы RLOGIN, TELNET и RSH. Но пароли и данные в этих протоколах не шифровались, пакеты могли быть перехвачены и модифицированы, а злоумышленник мог подменить IP клиента и, использовав перехваченные данные пройти аутентификацию. Естественно, что в незащищённых сетях работать по этим протоколам небезопасно и в 1995 году была разработана первая версия протокола SSH (SSH-1). Уже в следующем году была разработана вторая, более защищённая версия протокола SSH (SSH-2). Первая и вторая версии протоколов несовместимы между собой. В своей работе мы будем использовать протокол SSH только второй версии и всё, что будет описано ниже, подразумевает использование SSH-2.

Существует несколько реализаций программного обеспечения для SSH. Мы установим одну из его разновидностей — OpenSSH. OpenSSH расшифровывается как Open BSD Secure SHell и изначально был разработан для BSD систем.

В пакет OpenSSH входит несколько программ: scp (Secure CoPy), ssh (Secure SHell) и sftp (Secure File Transfer Protocol). Первая из них нужна для защищённого копирования файлов с одного компьютера на другой, вторая предоставляет защищённый доступ к оболочке. В основном именно она используется для удалённого администрирования, позволяя работать с другим компьютером так, как будто вы физически работаете за этим компьютером. Третья программа из пакета OpenSSH нужна для защищённой передачи файлов по протоколу FTP.

Программа ssh использует технологию клиент/сервер. Проверим, установлены ли в системе какие либо пакеты openssh:

$ aptitude search ^openssh

На выходе получаем:

iA openssh-blacklist

iA openssh-blacklist-extra

i openssh-client

p openssh-server

Как видим, клиентская часть программы установлена и в дополнение к ней для удовлетворения зависимостей автоматически установлены пакеты openssh-blacklist и openssh-blacklist-extra. Устанавливаем серверную часть, естественно с правами суперпользователя:

# aptitude install openssh-server

Во время установки будут сгенерированы ключи и перезапущен соответствующий демон - sshd. Можно было бы установить openssh в интерактивном режиме одной задачей (см. Aptitude интерактивный режим), но в этом нет большого смысла, так как метапакет и так содержит только один пакет openssh-server.

Проверяем, запущен ли sshd:

# ps ax | grep sshd

Если видим примерно такие строки, то всё в порядке:

910 ? Ss 0:00 /usr/sbin/sshd

1190 tty1 S+ 0:00 grep sshd

Состояние сервера ssh можно проверить следующим способом:

# /etc/init.d/ssh status

Если сервер работает и запущен, то видим следующее сообщение:

sshd is running

Управление сервером осуществляется так же в командной строке:

# /etc/init.d/ssh {start|stop|reload|force-reload|restart|try-restart|status}

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

Прежде чем подключиться к нашему серверу, поговорим об аутентификации (проверке подлинности) в SSH. При подключении по SSH используются три вида аутентификации: аутентификация по паролю, аутентификация по ключу хоста и аутентификация по открытому ключу. Мы не будем рассматривать аутентификацию по паролю в чистом виде, как небезопасную. Рассмотрим разницу между аутентификацией по ключу хоста и аутентификацией по открытому ключу. При первом подключении с использованием аутентификации по ключу хоста открытый ключ хоста (сервера) копируется на компьютер-клиент в профиль пользователя, инициировавшего удалённое подключение, в файл /.ssh/known_hosts. При последующих подключениях копия открытого ключа на клиенте сравнивается с открытым ключом на сервере и далее следует запрос пароля для пользователя. При использовании аутентификации по открытому ключу, пара ключей генерируется не на хосте (сервере), а на клиенте и полностью его идентифицирует. Открытый ключ шифруется и копируется на сервер. При подключении происходит сравнение копии открытого ключа и оригинала и если ключи совпали, происходит вход на удалённый компьютер.

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

Автор: Золкин А. Н.

Подключение с использованием ключа хоста

Теперь попробуем подключиться к нашему серверу, который выполняет и функцию ssh сервера, с настройками по умолчанию. Позже мы изменим настройки согласно нашим нуждам и требованиям безопасности. Для подключения по SSH нам нужны учётные данные пользователя сервера ssh и имя или ip адрес самого сервера. Сейчас можно подключиться к нашей машине, используя учётные данные любого простого пользователя нашего сервера. На этапе установки Debian («Установка Debian на сервер») я добавлял пользователя andrey. Подключиться к нашему серверу можно как через внешний, так и через внутренний интерфейс. В этом примере подключимся через внешний интерфейс сервера. В нашем случае его ip адрес – 192.168.123.254, а имя – sunup. На другом компьютере под управлением Unix-подобной операционной системы, выполним одну из следующих команд:

$ ssh –l andrey 192.168.123.254

или

$ ssh andrey@sunup.aitishnik.local

Вообще можно выполнить команду так: ssh имя_сервера, но это при условии, что сервер работает через порт по умолчанию и логины локального и удалённого пользователей совпадают. Наш сервер пока работает через порт по умолчанию (22), но логин моего локального пользователя не совпадает с логином удалённого. Поэтому в первом варианте я добавил ключ –l(от login) со значением andrey, а во втором варианте сразу передал логин, как часть строки подключения.

Следует помнить, что для того чтобы подключиться к удалённому компьютеру по имени надо чтобы это имя «знал» DNS сервер или на локальном компьютере в файле /etc/hosts должна присутствовать соответствующая запись, иначе придётся подключаться по ip адресу. В нашем примере запись в файле /etc/hosts может быть следующей:

192.168.123.254 sunup.aitishnik.local sunup

Где aitishnik.local – имя рабочей группы или домена. Для подключения используем полное (FQDN) имя удалённого компьютера, хотя при подключении в локальной сети или при наличии определённых записей в файле /etc/hosts можно подключаться и по короткому имени.

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

The authenticity of host 'sunup (192.168.123.254)' can't be established.

RSA key fingerprint is ee:ba:b8:48:ef:96:93:a8:3d:7b:3f:fa:85:8c:a7:ad.

Are you sure you want to continue connecting (yes/no)?

Этим нам предлагается принять открытый ключ удалённого сервера ssh и продолжить подключение. Дело в том, что для обеспечения безопасности ssh генерирует пару ключей: открытый и закрытый. Закрытый ключ никому не показывается – на то он и закрытый, а открытыми ключами компьютеры обмениваются между собой. И так, соглашаемся – набираем yes и нажимаем Enter. Получаем сообщение о добавлении сервера sunup с ip адресом 192.168.123.254 в список известных хостов и приглашение для ввода пароля пользователя andrey:

Warning: Permanently added 'sunup,192.168.123.254' (RSA) to the list of known hosts.

$ andrey@sunup's password:

Вводим пароль для пользователя и получаем доступ к удалённому компьютеру. В результате этих действий открытый ключ удалённого сервера sunup был скопирован на локальный компьютер в файл known_hosts, в директорию ~/.ssh (в домашнюю директорию пользователя, инициировавшего подключение к удалённому хосту). Теперь при последующих подключениях к серверу sunup не будут выдаваться предупреждения, будет выводиться только запрос пароля.

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

Теперь мы можем работать на сервере sunup так же, как если бы сидели за ним. Для того чтобы закрыть подключение к удалённому компьютеру, следует выполнить команду exit или нажать комбинацию клавиш Ctrl+D.

Автор: Золкин А. Н.

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

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

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

Port 2203

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

$ ssh –l andrey –p 2203 192.168.123.254

или так

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

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

#ListenAddress ::

#ListenAddress 0.0.0.0

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

ListenAddress 192.168.123.0

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

ListenAddress 192.168.123.0:2203

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

Protocol 2

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

HostKey /etc/ssh/ssh_host_rsa_key

#HostKey /etc/ssh/ssh_sunup_dsa_key

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

UsePrivilegeSeparation yes

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

# KeyRegenerationInterval 3600

# ServerKeyBits 768

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

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

SyslogFacility AUTH

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

LogLevel INFO

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

LoginGraceTime 60

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

PermitRootLogin no

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

StrictModes yes

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

AllowUsers andrey

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

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

RSAAuthentication yes

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

PubkeyAuthentication yes

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

AuthorizedKeysFile .ssh/authorized_keys

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

IgnoreRhosts yes

RhostsRSAAuthentication no

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

HostbasedAuthentication no

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

#IgnoreUserKnownHosts yes

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

PermitEmptyPasswords no

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

ChallengeResponseAuthentication no

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

PasswordAuthentication yes

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

#KerberosAuthentication no

#KerberosGetAFSToken no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes

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

#GSSAPIAuthentication no

#GSSAPICleanupCredentials yes

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

# X11Forwarding yes

# X11DisplayOffset 10

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

PrintMotd no

PrintLastLog yes

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

TCPKeepAlive no

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

ClientAliveCountMax 3

ClientAliveInterval 20

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

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

#UseLogin no

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

MaxStartups 3:30:9

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

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

#Banner /etc/issue.net

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

DebianBanner no

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

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

AcceptEnv LANG LC_*

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

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

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

UsePAM yes

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

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

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

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

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

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

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

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

Host sunup

HostName sunup.aitishnik.local

Port 2203

User andrey

Host windbag

HostName windbag.nnov.ru

Port 2280

User joker

Host 212.177.65.1

HostName 212.177.65.1

Port 2222

User forester

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

Автор: Золкин А. Н.

Генерация ключей

Мы знаем, что при подключении с использованием аутентификации с ключом хоста открытый ключ сервера копируется на компьютер-клиент. А где находятся ключи на сервере? На сервере они лежат в директории /etc/ssh. В Debian при установке OpenSSH создаются две пары ключей RSA и DSA, которые представляют собой отдельные файлы: ssh_host_rsa_key, ssh_host_rsa_key.pub, ssh_host_dsa_key и ssh_host_dsa_key.pub. Файлы, которые оканчиваются на .pub являются открытыми (публичными) ключами, а те, что оканчиваются на key – закрытыми. В процессе администрирования сервера может понадобиться сгенерировать новые ключи. Рассмотрим генерацию ключей на следующем примере. В предыдущей части этой статьи мы оставили параметр HostKey без изменений. Теперь изменим его значение, например, так:

HostKey /etc/ssh/ssh_sunup_rsa_key

Удалим старые ключи:

# rm /etc/ssh/ssh_host*

И сгенерируем новую пару RSA ключей, для чего выполним следующую команду:

# ssh-keygen -t rsa -f /etc/ssh/ssh_sunup_rsa_key

В запросе о пароле оставляем поля пустыми (см. man ssh-keygen). В результате будет создана новая пара RSA ключей с длиной шифрования 2048 бит. Перезапускаем sshd:

# /etc/init.d/ssh restart

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

@@@@@@@@@@@@@@@@@@@@@@@@@

@WARNING: HOST IDENTIFICATION HAS CHANGED! @

@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Someone could be eavesdropping on you right now (man-in-the-middle attack)!

It is also possible that the RSA host key has just been changed.

The fingerprint for the RSA key sent by the remote host is

2b:f3:c6:42:29:f2:26:6c:6f:28:dc:16:39:9f:bb:e7.

Please contact your system administrator.

Add correct host key in /home/andrey/.ssh/known_hosts to get rid of this message.

Offending key in /home/andrey/.ssh/known_hosts:3

RSA host key for [sunup]:2203 has changed and you have requested strict checking.

Host key verification failed.

При попытке подключения не совпали слепки ключей (fingerprint). Решение проблемы содержится в сообщении - нужно просто удалить указанную строку, в нашем случае 3, в файле known_hosts, снова подключиться и принять новый ключ сервера.

$ sed –ie 3d ~/.ssh/known_hosts

Теперь перейдём к следующей части этой статьи и настроим сервер ssh с аутентификацией по открытому ключу.

Автор: Золкин А. Н.

Подключение с использованием открытого ключа

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

$ ssh-keygen –t rsa

В процессе генерации пары ключей сначала будет предложено ввести желаемое название файла ключа, а так же ввести и подтвердить пароль. Вместо имени файла нажимаем Enter – будут созданы файлы ключей с именами по умолчанию. Секретную фразу тоже не вводим, особенно если планируем удалённо запускать скрипты. В противном случае нужно будет каждый раз вводить секретную фразу или работать с помощью ssh-agent. Пароль для файла ключа может оказаться полезным в случае попадания ключа в чужие руки, но такие вещи как секретные ключи надо беречь, даже если они защищены хорошим паролем. Полезно знать, что файлы закрытых ключей должны быть недоступны для чтения/записи всем кроме их владельца (режим 600). Открытые ключи для чтения должны быть доступны всем, но право на запись должен иметь только владелец (режим 644). В идеале лучше хранить ключи на Tokenе. Как это организовать я расскажу в одной из следующих статей – следите за новостями на www.aitishnik.ru!

И так, были сгенерированы два RSA ключа с именами id_rsa и id_rsa.pub. Теперь нужно скопировать на сервер открытый ключ в директорию, указанную в файле /etc/ssh/sshd_config, в параметре AuthorizedKeysFile, но сначала на сервере в домашней директории нужно создать скрытую поддиректорию .ssh, если её нет:

$ mkdir ~/.ssh

Теперь с клиента копируем сгенерированные ключи на сервер, воспользовавшись утилитой scp, входящей в пакет OpenSSH:

$ scp –P 2203 ~/.ssh/id_rsa.pub andrey@sunup:.ssh/authorized_keys

Совсем отключаем аутентификацию по паролю. Для этого на сервере в файле /etc/ssh/sshd_config меняем параметр PasswordAuthentication:

PasswordAuthentication no

Подключаемся к серверу:

$ ssh andrey@sunup –p 2203

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

Автор: Золкин А. Н.

• Вперёд >