Усиление защиты openssh в ubuntu 18.04

Настройка server SSH в Ubuntu

Теперь самое главное – вам нужно правильно настроить server OpenSSH перед тем, как включить его и пускать клиент по защищенному протоколу на хост. Неправильная настройка может привести к понижению уровня безопасности и ваш сервер могут взломать.

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

Вам нужно переустановить на сервер другой аккаунт пользователя, чтобы вы могли безопасно пользоваться другим компьютером через SSH. Для этого вам нужно будет вместо root добавить другого юзера при помощи командной строки: adduser имя_пользователя. Но и этого недостаточно – все-таки иногда вам нужен будет пользователь root. Тогда сделайте добавленного юзера наполовину суперадминистратором, чтобы он мог временно получать root права. Для этого зайдите в root и пропишите следующую строку: gpasswd -a имя_пользователя sudo. Таким образом вы добавите нового юзера в группу пользователей sudo, у которых наибольший уровень доступа.

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

Чтобы устранить access denied, вам стоит хорошенько просмотреть все ли в порядке в настройках. Самая частая причина, почему появляется access denied – это активация опции авторизации по паролю и для обычных пользователей, и для root. Чтобы убрать access denied, поменяйте PermitRootLogin вместо yes на without-password. А затем пропишите PermitRootLogin yes. Далее перезапустите сервер (service ssh restart) и сообщение access denied окончательно пропадет.

Следующий важный шаг – это активация усиленной аутентификации пользователей. Авторизация путем ввода пароля – это уже устарелый и неэффективный способ защиты аккаунтов. Сейчас есть множество программ, при помощи которых можно путем подбора взломать пароли. Потому вам лучше использовать аутентификацию при помощи публичного ключа. То есть вам лучше использовать Public Key Authentication и поставить yes возле этого пункта в файле config.

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

Следующим шагом вам нужно добавить сгенерированный публичный ключ в список доверенных на сервере. Для начала вам нужно будет скопировать публичный ключ. Он находится в файле формата .pub в папке .ssh. Скопируйте его и зайдите на сервер. На сервере так же должна быть папка .ssh. Если ее нет, то придется создать самостоятельно. А после этого, используя стандартный текстовый редактор, создайте файл authorized_keys. Именно в него вам нужно будет поместить публичный ключ. После этого вы сможете заходить на сервер без какого-либо подтверждения. Аутентификация будет проходить в автоматическом, фоновом режиме, что весьма удобно и при этом безопасно.

В целом, на этом настройка протокола SSH заканчивается! Разве что еще можете изменить порт 22 на другой.

Basic Syntax

To connect to a remote system using SSH, we’ll use the command. The most basic form of the command is:

The in this example is the IP address or domain name that you are trying to connect to.

This command assumes that your username on the remote system is the same as your username on your local system.

If your username is different on the remote system, you can specify it by using this syntax:

Once you have connected to the server, you may be asked to verify your identity by providing a password. Later, we will cover how to generate keys to use instead of passwords.

To exit the ssh session and return back into your local shell session, type:

Шаг 3 — Аутентификация на сервере Ubuntu с помощью ключей SSH

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

Базовый процесс выглядит аналогично:

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

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

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

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

Other Packages Related to openssh-server

• dep:
  adduser
  (>= 3.9)

  add and remove users and groups

• dep:
  debconf
  (>= 0.5)

  Debian configuration management system

  or
  debconf-2.0

  virtual package provided by

  cdebconf, cdebconf-udeb, debconf

• dep:
  dpkg
  (>= 1.9.0)

  Debian package management system

• dep:
  libaudit1
  (>= 1:2.2.1)

  Dynamic library for security auditing

• dep:
  libc6
  (>= 2.26)

  GNU C Library: Shared libraries also a virtual package provided by

  libc6-udeb

  dep:
  libc6
  (>= 2.28)

• dep:
  libcom-err2
  (>= 1.43.9)

  common error description library

• dep:
  libcrypt1
  (>= 1:4.1.0)

  libcrypt shared library

• dep:
  libgssapi-krb5-2
  (>= 1.17)

  MIT Kerberos runtime libraries — krb5 GSS-API Mechanism

• dep:
  libkrb5-3
  (>= 1.13~alpha1+dfsg)

  MIT Kerberos runtime libraries

• dep:
  libpam-modules
  (>= 0.72-9)

  Pluggable Authentication Modules for PAM

• dep:
  libpam-runtime
  (>= 0.76-14)

  Runtime support for the PAM library

• dep:
  libpam0g
  (>= 0.99.7.1)

  Pluggable Authentication Modules library

• dep:
  libselinux1
  (>= 1.32)

  SELinux runtime shared libraries

• dep:
  libssl1.1
  (>= 1.1.1)

  Secure Sockets Layer toolkit — shared libraries

• dep:
  libsystemd0

  systemd utility library

• dep:
  libwrap0
  (>= 7.6-4~)

  Wietse Venema’s TCP wrappers library

• dep:
  lsb-base
  (>= 4.1+Debian3)

  Linux Standard Base init script functionality

• dep:
  openssh-client
  (= 1:8.2p1-4)

  secure shell (SSH) client, for secure access to remote machines

  dep:
  openssh-client
  (= 1:8.2p1-4ubuntu0.2)

• dep:
  openssh-sftp-server

  secure shell (SSH) sftp server module, for SFTP access from remote machines

• dep:
  procps

  /proc file system utilities

• dep:
  ucf
  (>= 0.28)

  Update Configuration File(s): preserve user changes to config files

• dep:
  zlib1g
  (>= 1:1.1.4)

  compression library — runtime

• rec:
  default-logind

  Package not available

  or
  logind

  Package not available

  or
  libpam-systemd

  system and service manager — PAM module

• rec:
  ncurses-term

  additional terminal type definitions

• rec:
  ssh-import-id

  securely retrieve an SSH public key and install it locally

• rec:
  xauth

  X authentication utility

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

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

ssh user@192.168.1.2

ERROR: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ERROR: @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
ERROR: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ERROR: IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
ERROR: Someone could be eavesdropping on you right now (man-in-the-middle attack)!
ERROR: It is also possible that a host key has just been changed.
ERROR: The fingerprint for the ECDSA key sent by the remote host is
ERROR: SHA256:abcde/accdefghijkld9UNaDBnnUHanJ9Svca9vFx7c.
ERROR: Please contact your system administrator.
ERROR: Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
ERROR: Offending ECDSA key in /home/user/.ssh/known_hosts:3
ERROR: remove with:
ERROR: ssh-keygen -f «/home/user/.ssh/known_hosts» -R «192.168.1.2»
ERROR: ECDSA host key for 192.168.1.2 has changed and you have requested strict checking.
ERROR: Host key verification failed.

Из строки

ERROR: Offending ECDSA key in /home/user/.ssh/known_hosts:3

Можно понять, что проблема вызвана третьей строкой файла

/home/user/.ssh/known_hosts

Если вы уверены в надёжности хоста к которому подключаетесь, то
можете просто удалить эту строку и подключиться снова

sed -i 3d /home/$(whoami)/.ssh/known_hosts

ssh-keygen -R 192.168.1.2

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

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE 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 a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:nN5D5mBv00vkinsOmKbaKN1o2dEVZj5BidWaKBY1LpA.
Please contact your system administrator.
Add correct host key in /home/username/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/username/.ssh/known_hosts:14
remove with:
ssh-keygen -f «/home/username/.ssh/known_hosts» -R «:1234»
ED25519 host key for :1234 has changed and you have requested strict checking.
Host key verification failed.

В этом случае подсказка по-прежнему содержится в предупреждении (выделил её зелёным).

Выполните

ssh-keygen -f «/home/username/.ssh/known_hosts» -R «:1234»

# Host :1234 found: line 14
/home/username/.ssh/known_hosts updated.
Original contents retained as /home/username/.ssh/known_hosts.old

Конфигурация ssh-сервера

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

$ sudo nano /etc/ssh/sshd_config

# Это только для пользователй группы sftp-group
Match Group sftp-group
    # использовать встроенный sftp-сервер
    ForceCommand internal-sftp
    # разрешить аутентификацию по паролю
    PasswordAuthentication yes
    # разрешить доступ только к /srv/sftp
    ChrootDirectory /srv/sftp
    # запретить все, что не нужно для работы
    PermitTunnel no
    AllowAgentForwarding no
    AllowTcpForwarding no
    X11Forwarding no

$ sudo systemctl restart sshd.service

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

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

9: Настройка обязательной многофакторной аутентификации (опционально)

Вы также можете сделать многофакторную аутентификацию обязательной для всех пользователей и запретить им самостоятельно генерировать ключи. Для этого достаточно просто использовать один и тот же файл .google-authenticator для всех пользователей в системе (в этом файле нет индивидуальных данных).

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

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

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

Также можно сделать MFA обязательной с помощью сценария bash, который:

• Создаст TOTP-токен;
• Загрузит приложение Google Authenticator и просканирует QR-код;
• Запустит google-authenticator и проверит, существует ли файл .google-authenticator.

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

ssh-copy-id

Я предпочитаю использовать с флагом -i и задавать путь до нужного ключа

sudo ssh-copy-id -i ~/.ssh/andrei-key.pub andrei@192.168.0.2

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: «/home/andrei/.ssh/andrei-key.pub»
The authenticity of host ‘192.168.0.2 (192.168.0.2)’ can’t be established.
ECDSA key fingerprint is SHA256:abcdefgh1234567890abcdefgh1234567890abc+def.
Are you sure you want to continue connecting (yes/no/)?

Введите yes

Are you sure you want to continue connecting (yes/no/)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed — if you are prompted now it is to install the new keys
andrei@192.168.0.2’s password:

Введите пароль

Number of key(s) added: 1

Now try logging into the machine, with: «ssh ‘andrei@192.168.0.2′»
and check to make sure that only the key(s) you wanted were added.

Проверить ключ можно командой

ssh -i ~/.ssh/mykey user@host

В нашем случае

ssh -i ~/.ssh/andrei-key andrei@192.168.0.2

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

Last login: Sun Jan 10 16:48:27 2021 from 192.168.0.1

Шаг 4 — Отключение аутентификации по паролю на вашем сервере

Если вам удалось войти в ваш удалённый аккаунт на удалённом хосте по  SSH без ввода пароля, вы успешно настроили аутентификацию по ключу SSH  для вашего аккаунта. Однако возможность входить на сервер с  использованием пароля всё есть активна, что означает, что ваш сервер  уязвим для атак с перебором пароля (brute-force attacks).

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

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

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

Внутри файла найдите директиву .  Она может быть закомментирована. Раскомментируйте её при необходимости и  установите её значение в “no”. Это отключит возможность входа на сервер  по паролю.

/etc/ssh/sshd_config

Сохраните и закройте файл нажав + , затем для подтверждения сохранения файла, а далее для выхода из текстового редактора nano. Для применения внесённых изменений нам необходимо перезапустить сервис :

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

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

Теперь демон SSH на вашем сервере с Ubuntu работает только с ключами SSH. Аутентификация по паролю полностью отключена.

Управление пользователями

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

useradd — создает на сервере новую учетную запись. По сути, нового пользователя. Синтаксис: useradd имя будущей учетной записи. Имя можно указать любое на свой вкус. Потом останется лишь добавить для нового аккаунта пароль.

passwd — задает пароль для учетной записи. Работает вкупе с предыдущей командой. То есть сразу после создания аккаунта, пишем: passwd имя новой учетной записи. После этого система попросит придумать и указать пароль для новой учетной записи.

Система безопасности в Linux не показывает во время ввода пароля даже звездочки, но это не значит, что он не вводится. Продолжайте набирать вслепую, а как закончите, нажмите Enter, и все сработает. И не бойтесь запутаться, вас попросят повторить придуманный пароль.

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

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

• -с — добавляет комментарий к аккаунту (можно вписать любой текст по желанию, чтобы запомнить для чего нужен выбранный пользователь).
• -d — меняет расположение домашней директории выбранной учетной записи.
• -e — указывает время, которое будет существовать аккаунт (после этого сработает автоматический userdel).
• -g — меняет группу, к которой принадлежит аккаунт.
• -G — привязывает аккаунт к выбранной группе.
• -L — блокирует пользователя.
• -m — перемещает контент из домашней папки пользователя в другую папку.
• -p — устанавливает незашифрованный пароль (лучше так не делать).
• -s — задает конкретную оболочку для нового аккаунта на усмотрение администратора компьютера.
• -U — снимает блокировку с выбранной учетной записи.

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

Первый шаг — создание пары ключей на клиентской системе (обычно на вашем компьютере):

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

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

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

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

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

Затем вы должны увидеть следующую строку:

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

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

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

Step 3 — Authenticate to Ubuntu Server Using SSH Keys

If you have successfully completed one of the procedures above, you should be able to log into the remote host without the remote account’s password.

The basic process is the same:

If this is your first time connecting to this host (if you used the last method above), you may see something like this:

This means that your local computer does not recognize the remote host. Type “yes” and then press to continue.

If you did not supply a passphrase for your private key, you will be logged in immediately. If you supplied a passphrase for the private key when you created the key, you will be prompted to enter it now (note that your keystrokes will not display in the terminal session for security). After authenticating, a new shell session should open for you with the configured account on the Ubuntu server.

If key-based authentication was successful, continue on to learn how to further secure your system by disabling password authentication.

1: Установка libpam-google-authenticator

Сначала нужно установить PAM.

PAM, или Pluggable Authentication Module – это инфраструктура для аутентификации пользователей, используемая в системах Linux. Поскольку Google разработал приложение TOTP, необходимо было создать и PAM для генерации одноразовых паролей, полностью совместимый с любым TOTP-приложением.

Для начала обновите кэш репозиториев Ubuntu:

Затем установите PAM:

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

Обратите внимание: ключ генерируется индивидуально для каждого пользователя, анне общесистемно; то есть, чтобы настроить двухфакторную аутентификацию для нескольких аккаунтов, нужно на каждом из них запустить вспомогательное приложение и сгенерировать индивидуальный TOTP-ключ

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

PAM позволяет создавать токены, синхронизированные по времени, и токены на основе математического алгоритма.

Токены на основе математического алгоритма создаются сериями на основе секретного ключа; ни один из таких токенов невозможно угадать, даже если предыдущие токены известны. Синхронизированные по времени токены постоянно меняются в установленный интервал времени (например, раз в 30 секунд). В данном руководстве будут использоваться синхронизированные по времени токены, поскольку такие обычно используются в приложениях типа Google Authenticator.

После этого на экране появится большой вывод, содержащий QR-код. Сохраните секретный ключ, проверочный код и аварийные скретч-коды в надежном месте (например, в менеджере паролей).

Затем используйте приложение на смартфоне, чтобы просканировать QR-код, или введите секретный ключ вручную. Если код слишком большой для сканирования, откройте уменьшенную его версию по URL-адресу, предоставленному тут же. После этого вы получите шестизначный код, который будет обновляться каждые 30 секунд.

Остальные вопросы настраивают работу PAM. Рассмотрим их по очереди.

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

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

Эта опция будет создавать до 8 валидных кодов в течение 4 минут в скользящем окне. Если выбрать no, количество действительных кодов будет ограничено до 3 за полторы минуты. Это гораздо более безопасный вариант.

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

Ручной способ копирования

Данный способ подойдет в том случае если у вас нет ssh доступа к серверу. Придется вручную добавить содержание файла ключей на сервер. Для просмотра файла ключей используем cat:

cat ~/.ssh/id_rsa.pub

1	cat~.sshid_rsa.pub

Содержимое будет примерно таким:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test

1

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0Xvh2xPff6SQ1BLzkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosiuS66+PujOO+xt2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7UASsmY095ywPsBo1XQ9PqhnN1YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ==demo@test

Заходим на удаленную машину, любым доступным способом.

Вводим:

mkdir -p ~/.ssh

1	mkdir-p~.ssh

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

Далее переходим к созданию или редактированию файла authorized_keys.

Создание данного файла и внесение в него значения ключей:

echo «значение_публичного_ключа» >> ~/.ssh/authorized_keys

1	echo»значение_публичного_ключа»>>~.sshauthorized_keys

Подставляем значение публичного ключа и нажимаем enter. Затем изменим права:

chmod -R go= ~/.ssh

1	chmod-Rgo=~.ssh

Если файл создается от имени пользователя root, то придется изменить владельца:

chown -R user:user ~/.ssh

1	chown-Ruseruser~.ssh

Вместо user подставляем имя пользователя в домашней папке которого создали файл ключей.

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

ssh username@remote_host

1	ssh username@remote_host