Как настроить ssh-ключи и кодовую фразу для сервера

Подключение к серверу

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

В терминале на клиентской машине запускаем следующую команду:

Вывод должен быть примерно такой:

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

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

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

Возможно, на время эксперимента вы захотите удалить все ключи загруженные в ssh-agent. Это можно сделать командой .

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

Другой вариант: использовать опцию «IdentitiesOnly true» при запуске SSH-клиента вместе с .

Все детали о командах и ключах которые описаны в этом разделе можно найти в man для ssh и ssh_config.

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

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

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

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

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

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

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

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

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

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

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

• Закрытый ключ SSH (защищенная паролем часть) никогда не доступен через сеть. Парольная фраза используется только для расшифровки ключа на локальном компьютере. Это означает, что парольную фразу нельзя взломать через сеть методом прямого подбора.
• Закрытый ключ хранится в каталоге с ограниченным доступом. Клиент SSH не принимает закрытые ключи, хранящиеся в каталогах, доступ к которым не ограничен. У самого ключа могут быть ограниченные разрешения (чтение и запись доступны только владельцу). Это означает, что другие пользователи системы не смогут создать уязвимость.
• Для попытки взлома защищенного парольной фразой закрытого ключа SSH злоумышленнику уже необходим доступ к системе. Это означает, что у него уже должен быть доступ к учетной записи пользователя или учетной записи root. Если вы окажетесь в такой ситуации, парольная фраза может помешать злоумышленнику сразу же попасть на ваши другие серверы. Это может дать вам достаточно времени, чтобы создать и внедрить новую пару ключей SSH и запретить доступ с взломанным ключом.

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

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

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

Почему это важно?

Аппаратные ключи заметно повышают уровень безопасности любого решения. Вообще говоря, и до релиза OpenSSH 8.2 существовали методы использования аппаратных ключей совместно с SSH. Например, можно использовать сервер PrivacyIdea, хранить приватные SSH-ключи на аппаратном токене, используя PIV или же OpenPGP. Неплохая сводка таких решений доступна на сайте Yubico.

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

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

Использование секретного ключа для подключения по SSH

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

SecureCRT

В окне настроек SSH есть список Authentication. В нём необходимо увеличить приоритет PublicKey до самого высокого — сделать верхним в списке.

Затем перейдите в параметры PublicKey и выберите файл приватного ключа. Самый верхний переключатель позволяет использовать глобальные настройки секретного ключа или сеансовые настройки — другой секретный ключ (ключ не по умолчанию) — только для этого подключения.

Настраиваем глобальный публичный ключ: в меню Options → Global options → Категория SSH2.

PuTTY

В настройках SSH (Connection → SSH → Auth) в поле “Private key file for authentication” укажите файл Putty Private Key (*.ppk):

MAC OS X

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

• Подключение с нестандартным ключом (non-default key), указанным вручную: artemiy-2:~ ArtemiySP$ ssh -i ~/Documents/python/r4 The authenticity of host ‘10.31.73.29 (10.31.73.29)’ can’t be established. RSA key fingerprint is SHA256:fxOLFKU6YGyIqisrIh2P0O52Rr6Wx/wsSAcHsTz8fo0. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added ‘10.31.73.29’ (RSA) to the list of known hosts. CSR-4#
• Подключение с нестандартным ключом (non-default key), указанным вручную: artemiy-2:~ ArtemiySP$ ssh -i ~/Documents/python/r5 The authenticity of host ‘10.31.73.30 (10.31.73.30)’ can’t be established. RSA key fingerprint is SHA256:4l67C4Il4pTaqYT4vrtWr0aY7rPmNWKsjRv2zlYtQIU. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added ‘10.31.73.30’ (RSA) to the list of known hosts. MGTU#exit Connection to 10.31.73.30 closed.Ошибка примера

  Я не смог сделать снимок с запросом пароля — пароль записался в открытую сессию пользователя. Для запроса пароля в MAC OS X — необходимо разлогиниться и залогиниться снова.

• Подключение с ключом по умолчанию (default key – система сама найдет и использует Default public key): artemiy-2:~ ArtemiySP$ ssh The authenticity of host ‘10.31.73.31 (10.31.73.31)’ can’t be established. RSA key fingerprint is SHA256:2/ysACJQw48Q8S45ody4wna+6nJspcsEU558HiUN43Q. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added ‘10.31.73.31’ (RSA) to the list of known hosts. PR#exit Connection to 10.31.73.31 closed. artemiy-2:~ ArtemiySP$

Как упростить работу с SSH на MAC OS X:

• Создаём SSH Aliases.
• В SSH Aliases сразу задаём пользователей.
• Сразу прописываем местонахождение ключей.

Местонахождение Aliases и преднастроенная конфигурация SSH указаны в файле ~/.ssh/config (/Users//.ssh/config). Заполняется таким образом:

host r4 Hostname 10.31.73.29 Port 22 User r4 IdentityFile ~/Documents/python/r4 host r5 Hostname 10.31.73.30 Port 22 User r5 IdentityFile ~/Documents/python/r5 host r6 Hostname 10.31.73.31 Port 22 User r6 Примечание: у меня некорректно настроено подключение по умолчанию (как правильно, я не знаю), потому что подключение к хосту R6 (10.31.73.31) выполняется очень долго. Рекомендуется указать сразу указать путь к ключу по умолчанию.

Пример подключения по ssh используя публичные ключи и файл config:

artemiy-2:Documents ArtemiySP$ ssh r5 MGTU#exit Connection to 10.31.73.30 closed by remote host. Connection to 10.31.73.30 closed. artemiy-2:Documents ArtemiySP$ ssh r4 CSR-4#exit Connection to 10.31.73.29 closed by remote host. Connection to 10.31.73.29 closed. artemiy-2:Documents ArtemiySP$ ssh r6 PR#exit Connection to 10.31.73.31 closed. artemiy-2:Documents ArtemiySP$ ssh r6 PR#

SSH Keys and Public Key Authentication

The SSH protocol uses public key cryptography for authenticating hosts and users. The authentication keys, called SSH keys, are created using the program.

SSH introduced public key authentication as a more secure alternative to the older authentication. It improved security by avoiding the need to have password stored in files, and eliminated the possibility of a compromised server stealing the user’s password.

However, SSH keys are authentication credentials just like passwords. Thus, they must be managed somewhat analogously to user names and passwords. They should have a proper termination process so that keys are removed when no longer needed.

Как можно сохранить свой SSH-ключ на аппаратном токене FIDO2

Процитируем официальную документацию OpenSSH (в нашем переводе):

Итак, если у вас есть FIDO2-совместимый токен (в нашем случае это Yubikey 5), вы можете использовать ssh-keygen с параметром при генерации пары ключей SSH. В дальнейшем вы сможете извлечь ваши SSH-ключи из токена и записать на диск в виде файлов. Для этого нужно подключить ваш Yubikey (или тот токен, который вы используете) и запустить команду .

Команда целиком может выглядеть примерно так:

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

Итак, если вам нужно начать работу в новом окружении (на новой машине), достаточно подключить ваш Yubikey и запустить команду

Эта команда извлечет все записанные SSH-ключи (как приватные, так и публичные!) и сохранит в виде файлов на диске.

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

Для ключей Yubikey можно использовать официальное приложение Yubikey Manager.

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

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

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

Ответ 5

Единый вход SSH обычно достигается с помощью аутентификации с открытым ключом и агента аутентификации. Вы можете легко добавить свой тестовый ключ виртуальной машины к существующему агенту аутентификации (см. Пример ниже). Существуют и другие методы, такие как gssapi / kerberos, но они более сложные.

sshpass

В ситуациях, когда password доступен единственный метод аутентификации, который можно использовать sshpass для автоматического ввода пароля.  Во всех трех вариантах пароль виден или хранится в виде открытого текста:

Анонимный канал (рекомендуется sshpass)

# Create a pipe

PIPE=$(mktemp -u)

mkfifo -m 600 $PIPE

# Attach it to file descriptior 3

exec 3<>$PIPE

# Delete the directory entry

rm $PIPE

# Write your password in the pipe

 echo ‘my_secret_password’ >&3

# Connect with sshpass -d

sshpass -d3 ssh user@host

# Close the pipe when done

exec 3>&-

Это довольно громоздко в bash, возможно, проще с языками программирования. Другой процесс может подключиться к вашему pipe / fd до того, как будет записан пароль. Окно возможностей довольно короткое и ограничивается вашими процессами или root.

Переменная окружения

# Устновка вашего пароля в переменные среды

 export SSHPASS=’my_secret_password’

# Коннект с sshpass -e

sshpass -e ssh user@host

Вы и пользователь root можете читать переменные среды вашего процесса (например, ваш пароль) во время работы sshpass ( cat /proc/<pid>/environ | tr ‘\0’ ‘\n’ | grep ^SSHPASS=). Окно возможностей намного длиннее, но по-прежнему ограничено вашими собственными процессами или root, а не другими пользователями.

Аргумент командной строки (наименее безопасный)

 sshpass -p my_secret_password ssh user@host

Это удобно, но менее безопасно, как описано на странице руководства. Аргументы командной строки видны всем пользователям (например ps -ef | grep sshpass). sshpass пытается скрыть аргумент, но по-прежнему есть окно, в течение которого все пользователи могут видеть ваш пароль, переданный по аргументу.

Аутентификация с открытым ключом SSH

# Generate a key pair

# Do NOT leave the passphrase empty

ssh-keygen

# Copy it to the remote host (added to .ssh/authorized_keys)

ssh-copy-id user@host

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

Настройте агент аутентификации SSH

# Start the agent

eval `ssh-agent`

# Add the identity (private key) to the agent

ssh-add /path/to/private-key

# Enter key passphrase (one time only, while the agent is running)

Подключайтесь как обычно

ssh user@host

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

Отключение аутентификации с помощью пароля на сервере

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

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

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

Найдите в файле директиву . Она может быть помечена как комментарий. Удалите символ комментария в начале строки и установите значение «no». После этого вы потеряете возможность входа в систему через SSH с использованием паролей учетной записи:

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

На компьютерах под управлением Ubuntu или Debian можно использовать следующую команду:

На компьютерах под управлением CentOS/Fedora этот демон носит имя :

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

Создание ключей пользователя

Чтобы использовать аутентификацию на основе ключей, необходимо заранее создать для клиента одну или несколько пар открытого и закрытого ключей. Программа ssh-keygen.exe используется для создания файлов ключей, при этом вы можете задать алгоритмы DSA, RSA, ECDSA или Ed25519. Если алгоритм не указан, используется RSA. Необходимо использовать надежный алгоритм и соответствующую длину ключа, например Ed25519 в этом примере.

Чтобы создать файлы ключей с помощью алгоритма Ed25519, выполните следующую команду в командной строке PowerShell или в командной строке на клиенте:

Эта команда возвращает такие выходные данные (username заменяется вашим именем пользователя):

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

Теперь у вас есть пара открытого и закрытого ключей Ed25519 в указанном расположении. Файлы PUB являются открытыми ключами, а файлы без расширения — закрытыми.

Помните, что файлы закрытых ключей выполняют функцию пароля и должны защищаться так же тщательно.
Для этого, чтобы безопасно хранить закрытые ключи в контексте безопасности Windows, связанным с определенным именем входа Windows, используйте ssh-agent. Запустите службу ssh-agent от имени администратора и выполните ssh-add, чтобы сохранить закрытый ключ.

После этого при каждом выполнении аутентификации с этого клиента с использованием закрытого ключа, ssh-agent будет автоматически извлекать его и передавать клиенту SSH.

Важно!

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

Key Management Requires Attention

It is easy to create and configure new SSH keys. In the default configuration, OpenSSH allows any user to configure new keys. The keys are permanent access credentials that remain valid even after the user’s account has been deleted.

In organizations with more than a few dozen users, SSH keys easily accumulate on servers and service accounts over the years. We have seen enterprises with several million keys granting access to their production servers. It only takes one leaked, stolen, or misconfigured key to gain access.

In any larger organization, use of SSH key management solutions is almost necessary. SSH keys should also be moved to root-owned locations with proper provisioning and termination processes. For more information, see how to manage SSH keys. A widely used SSH key management tool for OpenSSH is Universal SSH Key Manager.

Practically all cybersecurity regulatory frameworks require managing who can access what. SSH keys grant access, and fall under this requirement. This, organizations under compliance mandates are required to implement proper management processes for the keys. NIST IR 7966 is a good starting point.

Make sure you have a key that is being used

1. Open .

2. Verify that you have a private key generated and loaded into SSH.

If you have GitHub Desktop installed, you can use it to clone repositories and not deal with SSH keys.

1. If you are using Git Bash, turn on ssh-agent:

   If you are using another terminal prompt, such as Git for Windows, turn on ssh-agent:

2. Verify that you have a private key generated and loaded into SSH.

1. Open .

2. Verify that you have a private key generated and loaded into SSH.

The command should print out a long string of numbers and letters. If it does not print anything, you will need to generate a new SSH key and associate it with GitHub.

Tip: On most systems the default private keys ( and ) are automatically added to the SSH authentication agent. You shouldn’t need to run unless you override the file name when you generate a key.

Getting more details

You can also check that the key is being used by trying to connect to :

In that example, we did not have any keys for SSH to use. The «-1» at the end of the «identity file» lines means SSH couldn’t find a file to use. Later on, the «Trying private key» lines also indicate that no file was found. If a file existed, those lines would be «1» and «Offering public key», respectively:

Пример. ssh-keygen. Ключи для Azure

Создание ssh ключей для виртуальной Linux в Microsoft Azure. Для создания и использования ключей SSH с Azure выполните описанные ниже действия.

cd .ssh
ssh-keygen -t rsa -b 2048 -N "" -C 'your-email@example' -f azuressh -q

Будут созданы два ключа azuressh и публичный azuressh.pub. Чтобы без ошибок скопировать содержимое azuressh.pub и вставить его в поле при создании VE, используйте ssh-keygen. Весь вывод, без исключений нужно копировать.

ssh-keygen -e -f azuressh.pub
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "2048-bit RSA
...
---- END SSH2 PUBLIC KEY ----

Не забудьте настроить файл config, для большего удобства.

Шаг 1 — Создание пары ключей RSA

Сперва создадим пару ключей на клиентской машине (обычно, это ваш компьютер):

По умолчанию создаёт 2048-битную пару ключей RSA, которая достаточно безопасна для большинства сценариев использования (вы можете также добавить к этой команде флаг для получения 4096-битный ключей).

После ввода этой команды вы должны увидеть следующий вывод:

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

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

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

Вы должны увидеть следующий вывод:

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

Вы должны увидеть следующий вывод:

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