Openssh key management

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:

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

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

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

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

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

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

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

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

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

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

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

Навигация и управление файловой системой

Команды, необходимые для перемещения и ориентирования в файловой системе сервера. А еще для перемещения, копирования и удаления файлов. В общем, все, что вы делали бы в файловом менеджере, но через терминал.

cd — отправляет вас в любую папку на выбор. Синтаксис: cd путь до нужной директории. Если хочется на рабочий стол, то пишем: cd ~/Desktop. Вернуться в предыдущую папку? cd-. Перепрыгнуть в home? Просто вводим: cd без аргументов.

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

ls ~/Desktop/papka-testovaya

pwd — укажет путь до папки тем, кто заблудился. Если вы находитесь в папке Документы, то вывод pwd будет выглядеть вот так /home/имя пользователя/Documents. И так для любого каталога, в котором вы окажетесь.

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

mv — изначально использовалась для того, чтобы перемещать файлы из одного места в другое. mv ~/Desktop/timeweb.html ~/Documents переносит HTML-документ Timeweb с рабочего стола в документы. Но пользователи приноровились использовать mv для смены имени файлов. mv ~/Desktop/timeweb.html timeweb-2.html оставляет документ на месте, но меняет его название.

cp — создает копию выбранного файла в другом каталоге. cp ~/Documents/timeweb-file.txt /home/Webmaster/Desktop копирует документ с названием timeweb-file.txt на рабочий стол того же пользователя.

dd — управляет разделами. С ее помощью можно делать копии разделов: dd if=/dev/sda of=/dev/sdb. Можно перемещать разделы. Удалять их без возможности восстановления: dd if=/dev/zero of=/dev/sdX (в качестве раздела для «уничтожения» тут указана флешка). Копирование разделов подразумевает их запись на сторонние носители. Например, запись iso-образов на внешние накопители: dd if=~/Desktop/fedora-14.6.iso of=/dev/sdX bs=4M. if здесь — это путь к образу, а of — путь к смонтированному разделу (флешке).

rm — удаляет папки и все, что сможет в них найти. «Уничтожает» все субдиректории, документы, картинки, медиа. Вообще все, без возможности восстановления. Синтаксис:

rm путь до каталога, который надо вычистить вместе со всеми «внутренностями»

mkdir — создает новую папку. Синтаксис: mkdir путь_до каталога,_где_нужно_создать_новую_директорию название_для_этой директории. Если надо сделать на рабочем столе папку Timeweb, то пишем:

mkdir ~/Desktop/Timeweb

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

wget — скачивает файл из переданной ссылки. Больше ничего не умеет. Простой текстовый менеджер загрузок. Работает так – если мы хотим загрузить скриншот панели управления Timeweb с официального сайта, то введем в терминал: wget https://timeweb.com/upload/resize_cache/iblock/b56/400_400_2/xscreen_3.jpg.pagespeed.ic.O4a5jdlo5A.jpg

zip — архивирует один или несколько файлов один файл в формате .zip. Синтаксис: zip название архива.zip путь до файла, который надо упаковать. К примеру:

zip noviy-archive.zip /home/me/soderzhimoe-archiva.txt

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

find — ищет файлы и папки по всей файловой системе. Умеет находить их по названию и по типу, но это зависит от выставленных опций. find -type d -name Timeweb будет искать только директории с именем Timeweb.

mount — монтирует образ или раздел диска. Синтаксис:

mount путь до раздела, что нужно смонтировать

unmount — «демонтирует» образ или указанный раздел. Синтаксис:

unmount путь до раздела, что нужно отмонтировать

Аутентификация по ключу

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

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

Для генерации ключей на клиенте предназначена команда:

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/c/Users/Evgeniy/.ssh/id_rsa): ~/.ssh/rsa-vm-wp
Enter passphrase (empty for no passphrase): Enter
Enter same passphrase again: Enter
Your identification has been saved in C:/Users/Evgeniy/.ssh/rsa-vm-wp.
Your public key has been saved in C:/Users/Evgeniy/.ssh/rsa-vm-wp.pub.
The key fingerprint is:
SHA256:qreJu/Sto0HZ3e9cJBcyKJl0Fb/cOBL9l6ozwtbdPAI Evgeniy@TKMCOMP
The key's randomart image is:
+-------+
|        . ..o.   |
|       . + . o   |
|        + . + +  |
|     o . o   = *.|
|    o . S . o B.+|
|   .   .   E =...|
|    o . . . +.+  |
|   . =oo + *.+ + |
|    *==+o ..= . .|
+---------+

Необходимо ввести имя файла ключа (в моем случае ), пароль для доступа к ключу (можно оставить пустым, нажав Enter).

Ключи готовы, копируем публичный ключ на сервер:

$ ssh-copy-id -p 2222 -i ~/.ssh/rsa-vm-wp.pub evgeniy@192.168.110.12
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "rsa-vm-wp.pub"
/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
evgeniy@192.168.110.12's password: пароль

Включаем на сервере аутентификацию по публичному ключу:

$ sudo nano /etc/ssh/sshd_config

PubkeyAuthentication yes

И отключаем возможность аутентификации по паролю:

PasswordAuthentication no

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

$ sudo systemctl restart ssh

$ ssh -p 2222 -i ~/.ssh/rsa-vm-wp evgeniy@192.168.110.12
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 5.0.0-37-generic x86_64)

И последний момент — добавляем новую запись в файл :

Host vm-wp
  User evgeniy
  HostName 192.168.110.12
  Port 2222
  IdentityFile ~/.ssh/rsa-vm-wp

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

$ ssh vm-wp
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 5.0.0-37-generic x86_64)

Поиск:
CLI • Linux • SSH • Ubuntu • Настройка • Установка • Служба • Сервер • Ключ

Синтаксис

Рассмотрим синтаксис команды.

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

Основные опции:

• «g» — для разрешения удаленной машине пользоваться определенным локальным портом.
• «l» — для изменения/введения имя пользователя в определенной системе.
• «f» — аргумент переводит режим работы в фоновый.
• «n» — для перенаправления классического вывода.
• «p» — для изменения/введения данных о локальном порту SSH, используемом на удаленной машине.
• «q» — для исключения вероятности показа сообщений о возникающих ошибках.
• «v» — для включения специального режима отладки.
• «x» — для отключения перенаправления X11.
• «X» — для включения перенаправления Х11.
• «C» — для включения сжатия.

Представленный выше список является неполным. На самом деле команда ssh поддерживает в разы больше опций, а описанные варианты используются чаще всего. Стоит заметить, что большинство настроек можно водить с использованием файла «ssh/config».

Настройка

Для осуществления поставленной перед пользователем задачи первоначально требуется обратиться к файлу «/etc/ssh/sshd_config». Здесь имеется множество настроек, большинство из которых применяются редко. Именно поэтому рекомендуется рассмотреть те, которые пользователи вводят чаще всего.

Строка Port

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

Строка — Protocol 2,1

На сервере команда ssh согласно стандартным установкам используются две версии протоколов. Они предназначены для совмещения. К примеру, если потребуется использование только второго протокола, потребуется раскомментировать (удалить #) строку «Protocol 2,1» и убрать цифру 1.

Запрет входа root через ssh

В команде ssh согласно стандартным установкам разрешается Root-доступ. Данное поведение также небезопасно. Именно поэтому пользователю потребуется обязательно раскомментировать строку:

Вход только одному пользователю

В файле конфигурации sshd_config можно добавить две директивы:

1. Allowusers;
2. AllowGroups.

Они позволяют разрешить пользоваться ssh только конкретным пользователям или группам.

Особенности выполнения приложений Х11

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

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

Или можно перезагрузить всю машину:

Remote Forwarding

In OpenSSH, remote SSH port forwardings are specified using the option. For example:

This allows anyone on the remote server to connect to TCP port 8080 on the remote server. The connection will then be tunneled back to the client host, and the client then makes a TCP connection to port 80 on . Any other host name or IP address could be used instead of to specify the host to connect to.

This particular example would be useful for giving someone on the outside access to an internal web server. Or exposing an internal web application to the public Internet. This could be done by an employee working from home, or by an attacker.

By default, OpenSSH only allows connecting to remote forwarded ports from the server host. However, the option in the server configuration file sshd_config can be used to control this. The following alternatives are possible:

This prevents connecting to forwarded ports from outside the server computer.

This allows anyone to connect to the forwarded ports. If the server is on the public Internet, anyone on the Internet can connect to the port.

This means that the client can specify an IP address from which connections to the port are allowed. The syntax for this is:

In this example, only connections from the IP address to port 8080 are allowed.

OpenSSH also allows the forwarded remote port to specified as 0. In this case, the server will dynamically allocate a port and report it to the client. When used with the option, the client will print the allocated port number to standard output.

Step 2 — Implementing an IP Address Allowlist

You can use IP address allowlists to limit the users who are authorized to log in to your server on a per-IP address basis. In this step, you will configure an IP allowlist for your OpenSSH server.

In many cases, you will only be logging on to your server from a small number of known, trusted IP addresses. For example, your home internet connection, a corporate VPN appliance, or a static jump box or bastion host in a data center.

By implementing an IP address allowlist, you can ensure that people will only be able to log in from one of the pre-approved IP addresses, greatly reducing the risk of a breach in the event that your private keys and/or passwords are leaked.

Note: Please take care in identifying the correct IP addresses to add to your allowlist, and ensure that these are not floating or dynamic addresses that may regularly change, for example as is often seen with consumer internet service providers.

You can identify the IP address that you’re currently connecting to your server with by using the command:

This will output something similar to the following:

Locate your user account in the list and take a note of the connecting IP address. Here we use the example IP of

In order to begin implementing your IP address allowlist, open the OpenSSH server configuration file in your favorite text editor:

You can implement IP address allowlists using the configuration directive, which restricts user authentications based on username and/or IP address.

Your own system setup and requirements will determine which specific configuration is the most appropriate. The following examples will help you to identify the most suitable one:

Restrict all users to a specific IP address:

Restrict all users to a specific IP address range using Classless Inter-Domain Routing (CIDR) notation:

Restrict all users to a specific IP address range (using wildcards):

Restrict all users to multiple specific IP addresses and ranges:

Disallow all users except for named users from specific IP addresses:

Restrict a specific user to a specific IP address, while continuing to allow all other users to log in without restrictions:

Warning: Within an OpenSSH configuration file, all configurations under a block will only apply to connections that match the criteria, regardless of indentation or line breaks. This means that you must be careful and ensure that configurations intended to apply globally are not accidentally put within a block. It is recommended to put all blocks at the bottom/end of your configuration file to help avoid this.

Once you have finalized your configuration, add it to the bottom of your OpenSSH server configuration file:

sshd_config

Save and close the file, and then proceed to test your configuration syntax:

If no errors are reported, you can reload OpenSSH server to apply your configuration:

In this step, you implemented an IP address allowlist on your OpenSSH server. Next, you will restrict the shell of a user to limit the commands that they are allowed to use.

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.

Шаг 3 — Ограничение оболочки пользователя

На этом шаге вы рассмотрите различные опции ограничения оболочки пользователя SSH.

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

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

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

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

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

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

Будет выведено сообщение следующего вида:

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

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

Начните с открытия файла конфигурации сервера OpenSSH в вашем любимом текстовом редакторе:

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

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

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

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

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

sshd_config

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

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

Если ошибок нет, вы можете внедрять конфигурацию:

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

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

Generating Your Keys

Generating SSH keys and configuring key login is a little bit more advanced than just logging in with a password, but it’s certainly doable and makes logging in much more secure. The key that’s on your device is what authenticates you, so you can disable password authentication on the remote system and just log in with keys.

To do this, you’ll need to create a new key pair on your client system, copy the public key to the remote system, and make sure the key on the remote system is trusted. Overall, it’s a very simple process.

On the system you’re using to log in to the remote system, run the following command:

You’ll be prompted to create a passphrase. I highly recommend making one that’s secure and that you’ll also remember. This is how you’ll be logging in to a computer, so make it as secure as you can. That’ll be saved in a folder that the SSH program knows to look in.

Now, still on your main system, use the command to transfer your public key to the remote system.

Change the username and the IP address to the ones you used previously. This will show you the keys that would have been transferred if you actually executed the command. If it looks like the key you want, remove the flag, and the command will run.

Now you can log into the remote system without entering a password.

Now that you have set up and used SSH, the next thing you should do is secure the SSH configuration. Alternatively, if you are using Windows, learn how you can generate an SSH key pair in Windows.

Related:

John Perkins

John is a young technical professional with a passion for educating users on the best ways to use their technology. He holds technical certifications covering topics ranging from computer hardware to cybersecurity to Linux system administration.

Local Forwarding

Local forwarding is used to forward a port from the client machine to the server machine. Basically, the SSH client listens for connections on a configured port, and when it receives a connection, it tunnels the connection to an SSH server. The server connects to a configurated destination port, possibly on a different machine than the SSH server.

Typical uses for local port forwarding include:

• Tunneling sessions and file transfers through jump servers

• Connecting to a service on an internal network from the outside

• Connecting to a remote file share over the Internet

Quite a few organizations for all incoming SSH access through a single jump server. The server may be a standard Linux/Unix box, usually with some extra hardening, intrusion detection, and/or logging, or it may be a commercial jump server solution.

Many jump servers allow incoming port forwarding, once the connection has been authenticated. Such port forwarding is convenient, because it allows tech-savvy users to use internal resources quite transparently. For example, they may forward a port on their local machine to the corporate intranet web server, to an internal mail server’s IMAP port, to a local file server’s 445 and 139 ports, to a printer, to a version control repository, or to almost any other system on the internal network. Frequently, the port is tunneled to an SSH port on an internal machine.

In OpenSSH, local port forwarding is configured using the option:

This example opens a connection to the jump server, and forwards any connection to port 80 on the local machine to port 80 on .

By default, anyone (even on different machines) can connect to the specified port on the SSH client machine. However, this can be restricted to programs on the same host by supplying a bind address:

The option in the OpenSSH client configuration file can be used to configure forwarding without having to specify it on command line.

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

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

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

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

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

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

/etc/ssh/sshd_config

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

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

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

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

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

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

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

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

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

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

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