Sshd key wrapper что это

Обновлено: 07.07.2024

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

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

Как работают ключи SSH?

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

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


Как создать ключи SSH?

Сначала необходимо создать ключи ssh для аутентификации на локальном сервере. Для этого существует специальная утилита ssh-keygen, которая входит в набор утилит OpenSSH. По умолчанию она создает пару 2048 битных RSA ключей, которая подойдет не только для SSH, но и для большинства других ситуаций.

И так, генерация ключей ssh выполняется командой:


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

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

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

  • Пароль никогда не попадет в сеть, он используется только на локальной машине для расшифровки ключа. Это значит что перебор по паролю больше невозможен.
  • Секретный ключ хранится в закрытом каталоге и у клиента ssh нет к нему доступа пока вы не введете пароль;
  • Если злоумышленник хочет взломать аутентификацию по ключу SSH, ему понадобится доступ к вашей системе. И даже тогда ключевая фраза может стать серьезной помехой на его пути.

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

Теперь у вас есть открытый и закрытый ключи SSH и вы можете использовать их для проверки подлинности. Дальше нам осталось разместить открытый ключ на удаленном сервере.

Загрузка ключа на сервер

Когда генерация ключей завершена, нам осталось только загрузить ключ на сервер. Для загрузки ключа можно использовать несколько способов. В некоторых случаях вы можете указать ключ в панели управления сервером, например, сPanel или любой другой. Но мы такой способ рассматривать не будем. Мы рассмотрим ручные способы.

Самый простой способ скопировать ключ на удаленный сервер - это использовать утилиту ssh-copy-id. Она тоже входит в пакет программ OpenSSH. Но для работы этого метода вам нужно иметь пароль доступа к серверу по SSH. Синтаксис команды:

При первом подключении к серверу система может его не распознать, поэтому вам нужно ввести yes. Затем введите ваш пароль пользователя на удаленном сервере. Утилита подключится к удаленному серверу, а затем использует содержимое ключа id.rsa.pub для загрузки его на сервер в файл

/.ssh/authorized_keys. Дальше вы можете выполнять аутентификацию с помощью этого ключа.

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

/.ssh, а затем поместим наш ключ в файл authorized_keys с помощью символа >>, это позволит не перезаписывать существующие ключи:

/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p

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

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

Отключение проверки пароля

sudo vi /etc/ssh/sshd_config

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

sudo service ssh restart

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

Выводы

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

Это первая из серии статей, рассказывающих об особенностях использования SSH. Мы начнем с рассмотрения стандартных SSH ключей, изучив процесс верификации, чтобы гарантировать, что вы не стали объектом атаки. Обратите внимание, что эта статья применима к широко используемому приложению OpenSSH, которое присутствует в большинстве Unix-подобных операционных систем, а не к коммерческой версии SSH.

Это первая из серии статей, рассказывающих об особенностях использования SSH. Мы начнем с рассмотрения стандартных SSH ключей, изучив процесс верификации, чтобы гарантировать, что вы не стали объектом атаки. Обратите внимание, что эта статья применима к широко используемому приложению OpenSSH, которое присутствует в большинстве Unix-подобных операционных систем, а не к коммерческой версии SSH.

SSH ключи как защита от атак "человек посередине"

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

SSH предоставляет важную возможность подтверждения подлинности хоста, с которым вы соединяетесь. Если вы правильно верифицировали хост, не существует способов чтения или манипуляции вашими пакетами промежуточным устройством [сноска 1]. Успешная верификация хоста показывает, что соединение зашифровано от начала до конца - ваш SSH клиент установил безопасное соединение непосредственно с SSH сервером, и никакие промежуточные машины не имеют доступа к этому соединению.

SSH ключи в действии

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

Так как мы подключаемся к этой машине впервые, и SSH не работает по принципу третьего доверенного лица, такого как Certificate Authorities в мире SSL/TLS, вся работа, связанная с управлением ключами, лежит на вас. Ваш клиент показывает отпечаток ключа (key fingerprint), простую для чтения строку чисел, которую вы можете использовать для проверки ключа вручную, что мы и сделаем позже. Если вы отвечаете "Да, отпечаток правильный", ваш SSH клиент продолжит аутентификацию, дав вам возможность ввести ваш пароль и приступить к работе.

Когда вы выше ответили "да", ваш SSH клиент сохранил ключ сервера в файле $HOME/.ssh/known_hosts . Это файл фактически является вашим личным Certificate Authority - списком ключей всех SSH серверов, с которыми вы работаете. Давайте посмотрим на последнею строку этого файла, которая была только что добавлена вами: (Я взял на себя смелость перенести и выровнять эту строку для удобства просмотра)

Каждая запись в known_hosts является большой строкой с тремя или больше пробелами, отделяющими поля следующим образом:

  1. Одно или несколько имен серверов или IP адресов, разделенных запятыми.
  2. Тип ключа (описан ниже).
  3. Непосредственно открытый ключ (закодированный в пределах диапазона символов ASCII).
  4. Любые дополнительные комментарии (не показаны в выводе выше)
  1. Глобальный файл, обычно /etc/ssh/ssh_known_hosts . Этот путь может быть изменен редактированием параметра GlobalKnownHostsFile в конфигурационном файле ssh (обычно это /etc/ssh/ssh_config ).
  2. Файл пользователя, обычно $HOME/.ssh/known_hosts . Этот путь может быть изменен редактированием параметра UserKnownHostsFile в конфигурационном файле ssh.

Подтверждение подлинности ключа

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

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

Если вышеописанный способ вам не доступен, проверить ключ системы, в которую вы вошли, можно следующим образом. Открытый ключ обычно доступен в директории /etc/ssh/, так что после входа в систему вы можете проверить отпечаток ключа (используя ssh-keygen), который вы приняли во время входа в систему. (ssh-keygen также используется для создания SSH ключей и Identities/PubKeys, которые мы обсудим позже.)

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

Выше мы видим, как пользователь принимает ключ, входит в систему, а затем проверяет ключ вручную с помощью ssh-keygen. Если отпечатки совпадают, вы можете с большой вероятностью быть уверены [сноска 4], что вы подключились к правильному серверу, даже при условии, что вы заранее не знали открытый ключ.

Проверка ключа

SSH имеет три способа реагирования на неопознанный или измененный ключ, основанных на значении переменной StrictHostKeyChecking: StrictHostKeyChecking=no Это самое небезопасное значение, разрешающее соединение с сервером вслепую. Если ключ сервера не присутствуют на локальном компьютере или ключ был изменен, он добавляется автоматически без каких-либо вопросов, всего лишь выдав предупреждение [сноска 5].
Ставить этот режим не очень хорошая идея.

StrictHostKeyChecking=ask Это параметр по умолчанию. Если у вас нет ключа сервера, вам будет показан отпечаток и запрошено подтверждение, как показано в примере выше. Если вы соединитесь, и ключи не совпадут, ваш вход в систему будет приостановлен и вам будет выдана информация, где в known_hosts находится конфликтующий ключ: StrictHostKeyChecking=yes Эта самая безопасная, возможно даже недружелюбная установка. Если у вас нет ключа сервера, вы вообще не сможете войти в систему: Если у вас есть ключ, но он не совпадает с ключом сервера, вы получите ошибку, такую же, как и при StrictHostKeyChecking=ask.

Почему ключ может измениться?

  • Было обновлено либо клиентское, либо серверное ПО, которое использует SSHV2, вместо прежнего SSHV1 [сноска 6].
  • Машина была переустановлена с тем же самым именем хоста, но исходные ключи не были восстановлены. После того как они будут созданы снова, они, конечно, не будут соответствовать вашему файлу known_hosts.
  • У компьютера, с которым вы хотите соединиться, было изменено DNS имя или IP адрес, или этот компьютер был заменен на новый.

Типы ключей

SSH поддерживает два основных протокола - SSHv2 и SSHv1 [сноска 7].

Старый протокол SSHv1 основан на алгоритме асимметричного шифрования RSA, тогда как более новый протокол SSHv2 поддерживает RSA и алгоритм aсимметричного шифрования DSA. SSH сервер может использовать один из трех типов ключей: SSHv1 RSA ключи, SSHv2 RSA ключи, или SSHv2 DSA ключи. Я буду называть их rsa1, rsa и dsa ключи соответственно, поскольку эта терминология используется в утилитах OpenSSH.

SSH ключ создается с помощью команды ssh-keygen [сноска 8]. Вероятнее всего, когда SSH был установлен на вашу машину, программа инсталляции или стартовый скрипт создали их для вас.

В файле sshd_config, обычно находящемся в директории /etc/ssh, перечислены ключи, загружающиеся во время старта системы.

Если вы собирали SSH из исходников, вы можете создать эти три ключа с помощью ssh-keygen: Программа ssh-keygen создает по два файла для каждого ключа. Первый содержит и закрытый и открытый ключ, а второй только открытый ключ. Таким образом, впервые запустив ssh-keygen, вы создадите файлы /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key.pub . Нет никаких причин скрывать открытый ключ, но закрытый ключ должен быть надежно скрыт, так как он не защищен никаким паролем (passphrase) [сноска 9]. К счастью, ssh-keygen устанавливает параноидальные разрешения на доступ к файлу.

Если вы сомневаетесь, что первый файл, не оканчивающийся на .pub, содержит закрытый ключ, или по каким-то причинам вы потеряли открытий ключ, вы всегда можете восстановить его с помощью той же самой команды ssh-keygen:

Есть ли какие-либо причины использования одного типа ключа, а не другого? Нет. Ключ rsa обычно бывает несколько быстрее с математической точки зрения, но для больших возможностей взаимодействия лучше включать оба. Оба алгоритма не запатентованы [сноска 10], поэтому насчет этого вы можете не беспокоиться. Если вам нужна поддержка SSHv1, у вас должен быть ключ rsa1.

Советы

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

Используйте глобальный файл известных хостов ( /etc/ssh/ssh_known_hosts ), содержащий все машины, с которыми соединяются ваши пользователи. Если вы выделите время для проверки этих ключей, вам не нужно будет полагаться на пользователей. Удостоверьтесь, что вы получаете все три типа ключа, rsa, dsa, и rsa1. Также, когда вам нужно будет изменить ключ (например, машина была переустановлена, и вы забыли сохранить старые ключи), у вас будет только один файл, который нужно обновить.

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

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

Опции настройки

  • StrictHostKeyChecking: Определяет, нужно ли при игнорировании ошибки во время соединения, связанной с ключом хоста, завершить работу сразу или спросить пользователя, хочет ли он продолжить работу.
  • CheckHostIP: Определяет, нужно ли проверять IP адрес сервера в файле known_hosts.
  • NoHostAuthenticationForLocalhost: Выключает проверку ключа для локальной машины. Может быть полезно, если вы настраиваете переадресацию трафика с порта SSH на удаленные машины, например ssh -p 9999 localhost, но вам нужно работать на локальной машине. Для этого лучше использовать HostKeyAliases.
  • HostKeyAlias: Эта опция позволяет указать псевдоним, который будет использоваться в командной строке вместо реального имени хоста, при поиске соответствия в файле known_hosts. Особенно это полезно для команд, использующих ProxyCommands для соединения, или при использовании различных портов на компьютере, которые переадресуют трафик на различные SSH сервера, находящиеся, например, за межсетевым экраном.
  • HostKeyAlgorithms: Алгоритм, который вы предпочитаете, RSA или DSA для второй версии протокола. По умолчанию это RSA, и если вы хотите, можете также следовать этой установке.

Сноски

[сноска 1] Это потому, что криптография, использующаяся для защиты вашего соединения, основана на надежном асимметричном шифровании, которое используется для верификации хоста.

[сноска 3] Существуют патчи к OpenSSH, позволяющие производить аутентификацию по стандарту X509, поэтому вы можете использовать эту модель, если хотите.

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

[сноска 5] Это действительно так, однако, отключая проверку пароля, вы по крайнее мерее должны использовать SSH Identities/PubKeys, Challenge/Response или какие-нибудь другие формы аутентификации, которые не могут быть повторно использованы атакующим.

[сноска 6] Обратное возможно, но маловероятно.

[сноска 7] SSHv1 считается менее безопасным, чем SSHv2. Если вам не нужно использовать клиентское ПО, поддерживающее только старый протокол SSHv1, в целях безопасности лучше всего будет включить поддержку только SSHv2 на вашем сервере. Строчка Protocol в файле /etc/ssh/sshd_config должны выглядеть следующим образом: [сноска 8] ssh-keygen используется и для создания SSH Identities/PubKeys. Действительно нет никакой разницы между ключом пользователя и хоста.

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

Этичный хакинг и тестирование на проникновение, информационная безопасность

Оглавление

Процесс настройки аутентификации по публичному ключу очень простой:

  1. Командой создаётся пара «публичный ключ — приватный ключ».
  2. Публичный ключ копируется на компьютер с сервером SSH, то есть на компьютер, к которому будет осуществляться подключение и на котором будут выполнятся команды.
  3. Затем подключение выполняется обычным способом, но ввод пароля уже не требуется.

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

Сгененировать ключи и скопировать их на удалённый хост можно буквально тремя командами. Для генерации пары ключей используется программа ssh-keygen, она включена в пакет ssh и если SSH у вас уже настроен, то дополнительно устанавливать ничего не нужно.

У программы ssh-keygen много функций и возможностей, начнём с рассмотрения процедуры генерации ключей, которая выполняется элементарно.

Если вы успели залогиниться на удалённой системе, разлогинтесь. После этого наберите:

У нас спрашивают имя файла, не нужно ничего вводить, будет использовано имя по умолчанию. Также спрашивается пароль. Этот пароль позволяет установить дополнительную защиту — при подключении с помощью ключей не будет спрашиваться пароль пользователя, но будет спрашиваться пароль самого ключа. Устанавливать пароль необязательно.


В результате будет создано два файла:

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

Теперь на удалённой машине нам нужно создать каталог .ssh. В предыдущей части мы уже узнали, как выполнять команды на удалённой системе по SSH. Запустите команду вида:

Теперь нам нужно скопировать содержимое файла id_rsa.pub на удалённую машину в файл

/.ssh/authorized_keys. Сделать это очень просто (не забываем менять данные на свои):

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

Типы ключей

Программа ssh-keygen можен генерировать четыре типа ключей:

Чтобы выбрать любой из этих типов, используется опция -t. В предыдущем примере мы выбрали rsa — явно указывать тип RSA необязательно, поскольку он подразумевается по умолчанию (то есть генерацию ключей можно запустить вообще без опции -t).

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

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

Соответствующие публичные ключи будут иметь такое же название, но с дополнительным расширением .pub:

Эти файлы не являются секретными, их содержимое нужно скопировать в файл

/.ssh/authorized_keys на компьютер с сервером SSH.

Утилита ssh-keygen

Мы применили ssh-keygen для генерации ключей. Кроме этого она предназначена для управления и конвертации ключей аутентификации для ssh.

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

Как поменять количество битов в ключах ssh-keygen

Для этого используется опция: -b БИТЫ

Она определяет количество бит в создаваемом ключе. Для ключей RSA минимальный размер составляет 1024 бита, а по умолчанию — 2048 бит. Как правило, 2048 бит считается достаточным. Ключи DSA должны иметь длину 1024 бита, как указано в FIPS 186-2. Для ключей ECDSA флаг -b определяет длину ключа, выбирая один из трёх размеров эллиптической кривой: 256, 384 или 521 бит. Попытка использовать битовые длины, отличные от этих трёх значений, для ключей ECDSA потерпит неудачу. Ключи Ed25519 имеют фиксированную длину, и флаг -b будет игнорироваться.

Добавление комментариев в ключи ssh-keygen

Для работы с комментариями имеется две опции:

-C комментарий

После этой опции укажите комментарий.

-c

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

Увидеть комментарий можно с помощью опции -l. Эта опция показывает отпечаток указанного файла публичного ключа. Для RSA и DSA ключей ssh-keygen пытается найти совпадающий файл публичного ключа и вывести его отпечаток. Если совместить с -v, то визуальное художественное представление ASCII будет показано после самого отпечатка:

Файл ключа можно указать явно опцией -f:

Изменение паролей в ssh-keygen

Для работы с паролями имеется несколько опций:

-P парольная фраза

Этой опцией можно передать пароль, чтобы программа его не спрашивала. При смене пароля, этой опцией передаётся старый пароль.

-p

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

-N новый_пароль

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

Файл ключей нужно указать опцией -f:

Показ публичного ключа из приватного

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

Также с помощью опции -f нужно указать путь до приватного ключа, из которого будет извлечён соответствующий ему публичный ключ:

Например, приватный ключ помещён в файл id_rsa, тогда команда извлечения из него публичного ключа следующая:

Вы можете столкнуться с ошибкой:

Управление приватными ключами на клиенте SSH

Одну и ту же пару ключей можно использовать для доступа к множеству серверов SSH. Следовательно, на каждом из них (на клиенте и на серверах) может быть по одному ключу. Тем не менее если у вас несколько ключей или если вы хотите использовать другое, не стандартное расположение файлов ключей, то далее показано, как указать расположения в строке команды и в конфигурационных файлах клиента SSH.

В конфигурационном файле клиента SSH для указания пути до приватных ключей используется директива IdentityFile. Её значения по умолчанию:

Как можно увидеть, разрешено использовать тильду для указания на домашнюю папку пользователя.

Можно иметь несколько директив IdentityFile в конфигурационных файлах; все эти идентификаторы будут опробованы по очереди. Множественные директивы IdentityFile добавят кандидатов в очередь для попыток (это поведение отличается от других конфигурационных директив).

Также можно настроить использование определённых идентификационных файлов для определённых хостов:

Для строки команды используется опция -i, после которой нужно указать путь до приватного ключа (файла идентификации). Значение по умолчанию такие же, как и у рассмотренной выше директивы. Опцию -i можно использовать несколько раз.

Управление публичными ключами на сервере SSH

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

По умолчанию проверяются файлы:

Поле с опциями является необязательным.

Тип ключа это “ecdsa-sha2-nistp256”, “ecdsa-sha2-nistp384”, “ecdsa-sha2-nistp521”, “ssh-ed25519”, “ssh-dss” или “ssh-rsa”.

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

Как конвертировать .ppk ключ в OpenSSH ключ

Ключ .ppk генерируется при экспорте ключей из PuTTY.

Пример файла .ppk:


Конвертация ключей из файла .ppk в формат OpenSSH в Linux

Для конвертации формата .ppk в формат OpenSSH можно использовать утилиту puttygen, которая включена в пакет Putty. Следовательно, нам нужно установить PuTTY

Linux: с вашим менеджером пакетов установите PuTTY (или более минимальный пакет PuTTY-tools):

Debian, Kali Linux, Linux Mint, Ubuntu и их производные:

Дистрибутивы на основе RPM:

Arch Linux, BlackArch и их производные:

OS X: Установите Homebrew, затем запустите

Поместите ваши ключи в какую-нибудь директорию, например, в домашнюю папку. Теперь конвертируем PPK ключи в SSH пару.

Для извлечения приватного ключа:

и для извлечения публичного ключа:

Переместите эти ключи в

/.ssh и убедитесь, что для приватного ключа ограничены права записи:

Конвертация ключей из файла .ppk в формат OpenSSH в Windows

Откройте PuTTYgen, нажмите кнопку «Load» и выберите файл .ppk с ключами.


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

Теперь в меню перейдите в «Conversions» → «Export OpenSSH key» и сохраните приватный ключ.

Ssh (Secure Shell) - это программа для подключения к компьютерам через сеть, выполнения команд на удаленных машинах и перемещения файлов из одного компьютера на другой. Она предоставляет строгую аутентификацию и безопасную передачу информации по незащищенным каналам. Ssh предназначен заменить rlogin, rsh, rcp и rdist.

В нашей конфигурации мы будем настраивать OpenSSH на поддержку tcp-wrappers (inetd superserver) для улучшения безопасности уже безопасной программы и чтобы не запускать ее как демон. В результате, когда клиент пытается соединиться с сервером, ssh будет запущен TCP-WRAPPER-ом для его аутентификации и авторизации перед тем, как разрешить подключение.

OpenSSH - это свободно-распространяемая замена SSH1, в которой были удалены все патентозависимые алгоритмы (во внешние библиотеки), все известные ошибки в безопасности и добавлены новые возможности. Мы рекомендуем вам использовать OpenSSH вместо SSH1 (свободно- распространяемый, но содержащий ошибки) или SSH2, который изначально тоже был бесплатным, но сейчас поставляется под коммерческой лицензией. Для тех, кто использует SSH2 от компании Datafellows, мы описываем в этой книге обе версии, начиная с OpenSSH.

Эти инструкции предполагают.
Unix-совместимые команды.
Путь к исходным кодам "/var/tmp" (возможны другие варианты).
Инсталляция была проверена на Red Hat Linux 6.1 и 6.2.
Все шаги инсталляции осуществляются суперпользователем "root".
OpenSSH версии 1.2.3

OpenSSH требует, чтобы был установлен пакет zlib-devel, который содержит заголовочные файлы и библиотеки нужные программам, использующим библиотеки zlib компрессии и декомпрессии. Если это не так, то установите его с вашего Red Hat Linux 6.1 или 6.2 CD-ROM.

Для инсталляции zlib-devel дайте следующие комнады: OpenSSL, необходимая для включения поддержки SSL в OpenSSH, тоже должна быть установлена на вашей системе.

ЗАМЕЧАНИЕ. Для того, чтобы получить большую информацию об OpenSSL сервере читайте соответствующую главу этой книги. Даже если вам не нужно использовать OpenSSL для создания и хранения зашифрованных файлов ключей, все равно для правильной работы OpenSSH требуются библиотеки OpenSSL.

Хорошей идеей будет создать список файлов установленных в вашей системе до инсталляции OpenSSH и после, в результате, с помощью утилиты diff вы сможете узнать какие файлы были установлены. Например,

До инсталляции:
find /* > OpenSSH1

После инсталляции:
find /* > OpenSSH2

Для получения списка установленных файлов:
diff OpenSSH1 OpenSSH22 > OpenSSH-Installed

Компиляция и оптимизация.
Шаг 1.

Переместитесь в новый каталог OpenSSH и выполните следующие команды:
CC="egcs" \
CFLAGS \
./configure \
--prefix=/usr \
--sysconfdir=/etc/ssh \
--with-tcp-wrappers \
--with-ipv4-default \
--with-ssl-dir=/usr/include/openssl

Вышеприведенные опции говорят OpenSSH следующее:

Вкомпилировать libwrap и включить поддержку TCP Wrappers (/etc/hosts.allow|deny)
Заблокировать длительные задержки при разрешении имен под Linux/glibc-2.1.2 для улучшения времени соединения
Определить месторасположение OpenSSL
Шаг 2.

Команда "rm", использованная выше, будет удалять все исходные коды, которые мы использовали при компиляции и инсталляции OpenSSH. Она также удалит .tar.gz архив.

Конфигурации.

Для запуска OpenSSH клиента/сервера следующие файлы должны быть созданы или скопированы в нужный каталог:

Копируйте ssh_config в каталог "/etc/ssh/".
Копируйте sshd_config в каталог "/etc/ssh/".
Копируйте sshd в каталог "/etc/pam.d/".

Вы можете взять эти файлы из нашего архива floppy.tgz.
Настройка файла "/etc/ssh/ssh_config".

Файл "/etc/ssh/ssh_config" это конфигурационный файл для OpenSSH, действующий в масштабах системы, который определяет опции изменяющие действия клиентских программ. Он содержит пары ключ-значение, одну на строку, не зависящие от регистра. Здесь описаны наиболее важные ключи влияющие на безопасность; полный список вы можете найти на стрнице руководства (man) для ssh (1).

Редактируйте файл ssh_config (vi /etc/ssh/ssh_config) и добавьте/или измените следующие параметры: Host *
Опция "Host" ограничивает влияние всех нижестоящих объявлений и опций только на компьютеры соответствующих шаблону приведенному после ключевого слова. "*" подразумевает все компьютеры. При помощи этой опции вы сможете в одном файле определить параметры для разных удаленных машин.

ForwardAgent no
Опция "ForwardAgent" определяет какой агент установления подлинности соединения должен быть направлен на удаленную машину.

ForwardX11 no
Опция "ForwardX11" для людей, которые используют Xwindow GUI и хотят автоматически перенаправлять сессии X11 на удаленную машину. Так как мы устанавливали сервер и не инсталлировали GUI, мы можем спокойно выключить эту опцию.

RhostsAuthentication no
Опция "RhostsAuthentication" определяет можем ли мы использовать аутентификацию, базирующуюся на rhosts. Так как она не безопасна, то мы отключаем ее.

RhostsRSAAuthentication no
Опция "RhostsRSAAuthentication" определяет использовать ли rhosts аутентификацию совместно с RSA host аутентификацией или нет.

RSAAuthentication yes
Опция "RSAAuthentication" определяет использовать RSA аутентфикацию или нет. Эта опция должна быть установлена в "yes" для лучшей безопасности ваших сессий. RSA использует пару из общедоступного и личного ключей, созданную при помощи утилиты ssh-keygen1.

PasswordAuthentication yes
Опция "PasswordAuthentication" определяет можем ли мы использовать аутентификацию, базирующуюся на паролях, или нет. Для большей безопасности эта опция должна быть установлена в "yes".

FallBackToRsh no
Опция "FallBackToRsh" определяет, что если соединение с демоном ssh завершилось ошибкой, должен ли автоматически использоваться rsh. Запомните, что сервис rsh небезопасен, поэтому эту опцию устанавливаем в no.

UseRsh no
Опция "UseRsh" определяет, что сервис rlogin/rsh должен использоваться на этом компьютере. Как и с опцией "FallBackToRsh", эта опция должна быть установлена в "no" из соображений безопасности.

BatchMode no
Опция "BatchMode" определяет можем ли мы отключить запрос имени и пароля при соединении. Эта опция полезна когда вы создаете скрипты и не хотите вводить пароль. (например, скрипт, который использует команду scp для создания резервных копий через сеть).

CheckHostIP yes
Опция "CheckHostIP" определяет будет или нет ssh дополнительно проверять IP адрес компьютера, который подключается к серверу, для определения DNS spoofing. Рекомендую установить эту опцию в "yes".

StrictHostKeyChecking no
Опция "StrictHostKeyChecking" определяет будет или нет ssh автоматически добавлять новые ключи компьютера в файл $HOME/.ssh/known_host. Эта опция, когда установлена в "yes", предоставляет максимальную защиту от атак Trojan horse. С этой опцией должна быть проведена одна процедура. Вначале она устанавливается в "no", чтобы ключи с обычно используемых компьютеров были собраны в файле, а затем нужно установить ее в "yes", чтобы воспользоваться ее дополнительными возможностями.

/.ssh/identity
Опция "IdentityFile" определяет альтернативный идентичный файл RSA идентификации для чтения. Много идентичных файлов может быть определено с помощью этой опции.

Port 22
Опция "Port" опередляет какой порт используется для ssh соединений на удаленном компьютере. По умолчанию он равен 22.

Cipher blowfish
Опция "Cipher" определяет какой шифр должен быть использован для шифрования сессии. blowfish использует 64-битные блоки и ключи до 448 бит.

Опция "EscapeChar" определяет сессионный знак перехода в приостановленное состояние.

Настройка файла "/etc/ssh/sshd_config".

Файл "/etc/ssh/sshd_config" - это конфигурационный файл для OpenSSH, действующий в масштабах системы, который определяет опции изменяющие действия демона. Он содержит пары ключ-значение, одну на строку, не зависящие от регистра. Здесь описаны наиболее важные ключи влияющие на безопасность sshd; полный список вы можете найти на странице руководства к sshd (8).
Редактируйте файл sshd_config (vi /etc/ssh/sshd_config) и добавьте/или измените следующие параметры: Port 22
Опция "Port" определяет какой порт слушает ssh демон для входящих соединений. По умолчанию - 22.

ListenAddress 192.168.1.1
Опция "ListenAddress" определяет IP адрес интерфейса к которому подключен сокет ssh демона. По умолчанию это "0.0.0.0"; для улучшения безопасности вы можете ограничиться только одним адресом.

HostKey /etc/ssh/ssh_host_key
Опция "HostKey" определяет место содержащее приватный ключ сервера.

ServerKeyBits 1024
Опция "ServerKeyBits" определяет как много бит используется в ключе сервера. Эти биты используются когда демон стартует для генерации RSA ключа.

LoginGraceTime 600
Опция "LoginGraceTime" определяет как долго в секундах после соединения сервер ждет правильной регистрации до его разрыва.

KeyRegenerationInterval 3600
Опция "KeyRegenerationInterval" определяет как долго в секундах сервер должен ждать перед автоматической регенерацией своего ключа. Эта опция защиты предназначена для предотвращения расшифровки захваченного сеанса связи.

PermitRootLogin no
Опция "PermitRootLogin" определяет может ли root подключаться, используя ssh. Никогда не говорите "yes" в этой опции.

IgnoreRhosts yes
Опция "IgnoreRhosts" определяет должны ли файлы rhosts или shosts использоваться при аутентификации. Из соображений безопасности рекомендуется не использовать эти файлы.

IgnoreUserKnownHosts yes
Опция "IgnoreUserKnownHosts" определяет должен ли ssh демон игнорировать пользователей "$HOME/.ssh/known_hosts" во время RhostsRSAAuthentication.

StrictModes yes
Опция "StrictModes" определяет должен ли ssh проверять права пользователей в их домашних каталогах и файлы rhosts перед тем, как пустить на сервер. Эта опция должна всегда быть установлена в "yes", потому что иногда пользователи могут случайно оставить свои каталоги и файлы открытыми всем для записи.

X11Forwarding no
Опция "X11Forwarding" определяет должен ли сервер перенаправлять X11 пакеты или нет. Так как мы установили сервер без GUI, то эту опцию устанавливаем в no.

RhostsAuthentication no
Опция "RhostsAuthentication" определяет может ли sshd использовать rhosts аутентификацию. Так как rhosts аутентификация небезопасна, то мы не используем эту опцию.

RhostsRSAAuthentication no
Опция "RhostsRSAAuthentication" определяет можно ли использовать rhosts аутентификацию вместе с RSA аутентификацией.

RSAAuthentication yes
Опция "RSAAuthentication" определяет можно ли использовать RSA аутентификацию. Эта опция должна быть установлена в "yes" для лучшей безопасности. RSA использует пару из общедоступного и личного ключей, созданных с помощью утилиты ssh-keygen1.

PasswordAuthentication yes
Опция "PasswordAuthentication" определяет можно ли использовать аутентификацию по паролю. Для лучшей защищенности эта опция должна быть установлена в "yes".

PermitEmptyPasswords no
Опция "PermitEmptyPasswords" определяет позволяет ли сервер входить на сервер с бюджетов с пустыми паролями. Если вы используете утилиту "scp" для автоматического создания резервных копий через сеть, то нужно установить эту опцию в "yes".

AllowUsers admin
Опция "AllowUsers" определяет и контролирует какие пользователи могут использовать ssh сервис. Для разделения нескольких имен используйте пробелы.

Настройка OpenSSH для использования с TCP-Wrappers inetd супер сервером.

Tcp-Wrappers может быть использован для запуска и остановки вашего ssh сервиса. Перед выполнением inetd читает информацию из конфигурационного файла /etc/inetd.conf.
Шаг 1.

Редактируйте файл inetd.conf (vi /etc/inetd.conf) и добавьте в него следующую строку:
ssh stream tcp nowait root /usr/sbin/tcpd sshd -i

Которая значит, что клиенту с IP адресом "192.168.1.4" и именем компьютера "win.openna.com" разрешен ssh доступ к серверу.

Эти строки "демона" (для tcp-wrappers) используются sshd:

sshdfwd-X11 (если вы хотите разрешить/запретить X11-forwarding).
sshdfwd-<port-number> (для tcp-forwarding).
sshdfwd-<port-name> (номер порта определен в /etc/services. Ипсользуемый в tcp-forwarding).

ЗАМЕЧАНИЕ. Если вы решили переключиться на использование ssh, сделайте так, чтобы вы инсталлировали и использовали его на всех ваших серверах. Наличие десяти защищенных серверов и одного незащищенного бесполезно.

Дополнительная документация.

Для получения большей информации, вот несколько man-страниц, которые можно прочитать.

$ man ssh (1) - OpenSSH secure shell клиент (программа удаленного подключения)
$ man ssh [slogin] (1) - OpenSSH secure shell клиент (клиент (программа удаленного подключения)
$ man ssh-add (1) - добавление identities для агента аутентификации
$ man ssh-agent (1) - аутентификационный агент
$ man ssh-keygen (1) - генерация аутентификационного ключа
$ man sshd (8) - ssh демон

Конфигурирование OpenSSH для каждого пользователя

Результат должен выглядеть примерно так: ЗАМЕЧАНИЕ. Если вы имеете несколько бюджетов, то вы можете хотеть создать независимые ключи для них.

  1. Ваш почтовый сервер
  2. Ваш Веб сервер
  3. Ваш шлюз

Копируйте ваш общедоступный ключ (identity.pub) на удаленный компьютер в каталог "/home/admin/.ssh" под именем "authorized_keys".

ЗАМЧЕАНИЕ. Одним из способов копирования файла является использование ftp команд или вам нужно послать по электронной почте ваш общедоступный ключ администратору системы. Только включите содержимое файла

Изменение вашей pass-phrase.

Утилиты пользователя OpenSSH

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

"ssh" (Secure Shell) команда предоставляющая безопасную шифрованную связь между двумя недоверенными компьютерами через небезопасную сеть. Эта программа для безопасного подключения к удаленной машине и выполнения команд на ней. Она заменяет такие небезопасные программы, как telnet, rlogin, rcp, rdist и rsh.

Например: Где <login_name> это имя, которое вы используете для соединения с ssh сервером и <hostname> это имя удаленного ssh сервера.
scp

Например:
[admin@deep /]$ scp1 -p /usr/bin/test2 admin@mail:/var/tmp
admin@mail's password:
test2 | 7 KB | 7.9 kB/s | ETA: 00:00:00 | 100%

ЗАМЕЧАНИЕ. Опция "-p" говорит, что время модификации и доступа, также как и режимы исходных файлов, должны быть сохранены и на копии. Это обычно желательно.

Читайте также: