Как установить защищенное подключение ssh

When you hit enter, you will be prompted to enter the password for the requested account. When you type it in, nothing will appear on the screen, but your password is, in fact being transmitted. Once you’re done typing, hit enter once again. If your password is correct, you will be greeted with a remote terminal window.

If you want to learn about some more SSH commands, find them out here.

Understanding Different Encryption Techniques

The significant advantage offered by SSH over its predecessors is the use of encryption to ensure a secure transfer of information between the host and the client. Host refers to the remote server you are trying to access, while the client is the computer you are using to access the host. There are three different encryption technologies used by SSH:

1. Symmetrical encryption
2. Asymmetrical encryption
3. Hashing

Symmetric Encryption

Symmetric encryption is a form of encryption where a secret key is used for both encryption and decryption of a message by both the client and the host. Effectively, anyone possessing the key can decrypt the message being transferred.

Symmetrical encryption is often called shared key or shared secret encryption. There is usually only one key that is used, or sometimes a pair of keys, where one key can easily be calculated using the other key.

Symmetric keys are used to encrypt the entire communication during an SSH session. Both the client and the server derive the secret key using an agreed method, and the resultant key is never disclosed to any third party.

The process of creating a symmetric key is carried out by a key exchange algorithm. What makes this algorithm particularly secure is the fact that the key is never transmitted between the client and the host.

Instead, the two computers share public pieces of data and then manipulate it to independently calculate the secret key. Even if another machine captures the publically shared data, it won’t be able to calculate the key because the key exchange algorithm is not known.

It must be noted, however, that the secret token is specific to each SSH session, and is generated prior to client authentication. Once the key has been generated, all packets moving between the two machines must be encrypted by the private key. This includes the password typed into the console by the user, so credentials are always protected from network packet sniffers.

A variety of symmetrical encryption ciphers exist, including, but not limited to, AES (Advanced Encryption Standard), CAST128, Blowfish, etc. Before establishing a secured connection, the client and a host decide upon which cipher to use, by publishing a list of supported ciphers in order of preference. The most preferred cipher – from the clients supported ciphers – that is present on the host’s list is used as the bidirectional cipher.

For example, if two Ubuntu 14.04 LTS machines are communicating with each other over SSH, they will use aes128-ctr as their default cipher.

Asymmetric Encryption

Unlike symmetrical encryption, asymmetrical encryption uses two separate keys for encryption and decryption. These two keys are known as the public key and the private key. Together, both these keys form a public-private key pair.

A public key can be used by any individual to encrypt a message and can only be decrypted by the recipient who possesses their particular private key, and vice versa. These consist of extensive and seemingly random combinations of numbers and symbols, however, both public and private keys are paired using complex mathematical algorithms.

For example, in order to authenticate the sender, a message is encrypted using their own private key. Therefore, the message can only be decrypted using that specific sender’s public key. Note that both encryption and decryption mechanisms are automatic processes – you don’t need to do anything manually.

Unlike the general perception, asymmetrical encryption is not used to encrypt an entire SSH session. Instead, it is used during the key exchange algorithm of symmetric encryption. Before initiating a secured connection, both parties generate temporary public-private key pairs and share their respective private keys to produce the shared secret key.

Once a secured symmetric communication has been established, the server uses the client’s public key to generate and challenge and transmit it to the client for authentication. If the client can successfully decrypt the message, it means that it holds the private key required for the connection – the SSH session then begins.

Hashing

One-way hashing is another form of cryptography used in Secure Shell Connections. One-way-hash functions differ from the above two forms of encryption in the sense that they are never meant to be decrypted. They generate a unique value of a fixed length for each input that shows no clear trend which can be exploited. This makes them practically impossible to reverse.

It is easy to generate a cryptographic hash from a given input, but impossible to generate the input from the hash. This means that if a client holds the correct input, they can generate the cryptographic hash and compare its value to verify whether they possess the correct input.

SSH uses hashes to verify the authenticity of messages. This is done using HMACs, or Hash-based Message Authentication Codes. This ensures that the command received is not tampered with in any way.

While the symmetrical encryption algorithm is being selected, a suitable message authentication algorithm is also selected. This works in a similar way to how the cipher is selected, as explained in the symmetric encryption section.

Each message that is transmitted must contain a MAC, which is calculated using the symmetric key, packet sequence number, and the message contents. It is sent outside the symmetrically encrypted data as the concluding section of the communication packet.

How Does SSH Work With These Encryption Techniques

The way SSH works is by making use of a client-server model to allow for authentication of two remote systems and encryption of the data that passes between them.

SSH operates on TCP port 22 by default (though SSH port can be changed if needed). The host (server) listens on port 22 (or any other SSH assigned port) for incoming connections. It organizes the secure connection by authenticating the client and opening the correct shell environment if the verification is successful.

The client must begin the SSH connection by initiating the TCP handshake with the server, ensuring a secured symmetric connection, verifying whether the identity displayed by the server match previous records (typically recorded in an RSA key store file), and presenting the required user credentials to authenticate the connection.

There are two stages to establishing a connection – first, both the systems must agree upon encryption standards to protect future communications, and second, the user must authenticate themselves. If the credentials match, then the user is granted SSH access.

Session Encryption Negotiation

When a client tries to connect to the server via TCP, the server presents the encryption protocols and respective versions that it supports. If the client has a similar matching pair of a protocol and version, an agreement is reached and the connection is started with the accepted protocol. The server also uses an asymmetric public key which the client can use to verify the authenticity of the host.

Once this is established, the two parties use what is known as a Diffie-Hellman Key Exchange Algorithm to create a symmetrical key. This algorithm allows both the client and the server to arrive at a shared encryption key which will be used henceforth to encrypt the entire communication session.

Here is how the algorithm works at a very basic level:

1. Both the client and the server agree on a very large prime number, which of course does not have any factor in common. This prime number value is also known as the seed value.
2. Next, the two parties agree on a common encryption mechanism to generate another set of values by manipulating the seed values in a specific algorithmic manner. These mechanisms, also known as encryption generators, perform large operations on the seed. An example of such a generator is AES (Advanced Encryption Standard).
3. Both the parties independently generate another prime number. This is used as a secret private key for the interaction.
4. This newly generated private key, with the shared number and encryption algorithm (e.g. AES), is used to compute a public key which is distributed to the other computer.
5. The parties then use their personal private key, the other machine’s shared public key and the original prime number to create a final shared key. This key is independently computed by both computers but will create the same encryption key on both sides.
6. Now that both sides have a shared key, they can symmetrically encrypt the entire SSH session. The same key can be used to encrypt and decrypt messages (read: section on symmetrical encryption).

Now that the secured symmetrically encrypted session has been established, the user must be authenticated.

Authenticating the User

The final stage before the user is granted SSH access to the server is authenticating his/her credentials. For this, most SSH users use a password. The user is asked to enter the username, followed by the password. These credentials securely pass through the symmetrically encrypted tunnel, so there is no chance of them being captured by a third party.

Although passwords are encrypted, it is still not recommended to use passwords for secure connections. This is because many bots can simply brute force easy or default passwords and gain shell access to your account. Instead, the recommended alternative is SSH Key Pairs.

These are a set of asymmetric keys used to authenticate the user without the need of inputting any password.

Conclusion

Gaining an in-depth understanding of the underlying how SSH works can help users understand the security aspects of this technology. Most people consider this process to be extremely complex and un-understandable, but it is much simpler than most people think.

If you’re wondering how long it takes for a computer to calculate a hash and authenticate a user, well, it happens in less than a second. In fact, the maximum amount of time is spent in transferring data across the Internet.

Hopefully, this SSH tutorial has helped you see the way different technologies can be clubbed together to create a robust system in which each mechanism has a very important role to play. Also, now you know why Telnet became a thing of the past as soon as SSH came up.

If you want more Linux tutorials, be sure to check out our VPS tutorials section.

What Is SSH FAQ

Why Is SSH Used?

Secure Shell (SSH for short) is a network communication protocol that makes it possible for two computers to communicate with one another. SSH also makes data transfers possible between two computers.

What Does SSH Stand For?

SSH is an abbreviation for the network protocol Secure Shell or Secure Socket Shell.

What Is SSH vs SSL?

SSH creates a secured network between computers that makes data transfer possible. SSL, on the other hand, encrypts the data that’s being transferred, reducing malicious and phishing attempts.

Domantas leads the content and SEO teams forward with fresh ideas and out of the box approaches. Armed with extensive SEO and marketing knowledge, he aims to spread the word of Hostinger to every corner of the world. During his free time, Domantas likes to hone his web development skills and travel to exotic places.

Алгоритм установления соединения в протоколе SSH

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

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

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

1. Установка TCP-соединения

Не буду подробно останавливаться на принципе работы стека TCP/IP, так как эта тема достаточно хорошо задокументирована в Рунете. При необходимости вы легко найдёте информацию.

На этом этапе происходит сетевое подключение клиента к серверу на TCP-порт, указанный в опции Port (по умолчанию: 22) в файле конфигурации сервера /etc/ssh/sshd_config.

2. Открытие защищенного канала

2.1 Обмен идентификационными данными

После установки TCP-соединения, клиент и сервер (далее по тексту – стороны) обмениваются версиями SSH-протокола и другими вспомогательными данными, необходимыми для выяснения совместимости протоколов и для выбора алгоритмов работы.

2.2 Выбор алгоритмов: обмена ключами, шифрования, сжатия и т.п.

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

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

Список доступных в системе симметричных алгоритмов (используются для шифрования канала):

Список типов ключей для авторизации у клиента:

Дополнено по замечанию onix74:
Все используемые в публикации команды актуальны для версии OpenSSH 7.6 из Ubuntu 18.04 LTS.

2.3 Получение сессионного ключа шифрования

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

• Сервер отсылает клиенту свой ключ (DSA, RSA или т.п. согласно договорённости между сторонами, произведёнными в п.2.2).
• Если клиент производит соединение с данным сервером впервые (о чем говорит отсутствие записи в файле /home/username/.ssh/known_hosts у клиента), то пользователю будет задан вопрос о доверии ключу сервера. Если же соединение с данным сервером уже устанавливалось ранее, то клиент сравнивает присланный ключ с ключом, записанным в /home/username/.ssh/known_hosts. Если ключи не совпадают, то пользователь получит предупреждение о возможной попытке взлома. Впрочем, эту проверку можно пропустить, если вызвать ssh с опцией StrictHostKeyChecking:
  Также, если пользователю нужно удалить старый ключ сервера (например, когда есть точная уверенность, что ключ был изменён на сервере), то используется команда:

3. Аутентификация клиента

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

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

• Клиент отсылает серверу имя пользователя (username) и свой публичный ключ.
• Сервер проверяет в файле /home/username/.ssh/authorized_keys наличие присланного клиентом открытого ключа. Если открытый ключ найден, то сервер генерирует случайное число и шифрует его открытым ключом клиента, после чего результат отправляется клиенту.
• Клиент расшифровывает сообщение своим приватным ключом и отправляет результат серверу.
• Сервер проверяет полученный результат на совпадение с тем числом, которое он изначально зашифровал открытым ключом клиента, и в случае совпадения считает аутентификацию успешной.

4. Уровень подключения

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

На этом уровне обеспечивается: мультиплицирование каналов (возможность работы множества каналов к одному серверу за счет объединения их в один канал), туннелирование и т.п.

От теории к практике

Ну а теперь, думаю, у читателей назрел вполне закономерный вопрос: а зачем нужно знать все эти тонкости работы SSH-протокола, если для повседневной работы достаточно знаний команд создания ключей (ssh-keygen), открытия терминальной сессии (ssh), передачи файлов (scp)?

В качестве ответа, можно вспомнить тему о смене стандартного порта SSH на какой-то другой, которая постоянно становится причиной холивара на Хабре…

В собственной практике я не припомню ни одного смотрящего во внешнюю сеть сервера, который бы ежедневно не подвергался долбёжке на 22-й порт. В ситуации, если SSH у вас работает на стандартном порту (и ничем дополнительно не защищён), даже если аутентификация исключительно по ключам и никакие подборы паролей не пугают, то по причине постоянно валящихся запросов от недобросовестных клиентов сервер всё равно вынужден совершать массу бесполезной работы: устанавливать TCP-соединение, выбирать алгоритмы, генерировать сессионный ключ, отправлять запросы аутентификации, писать лог-файл.

В ситуации же, когда на 22-м порту ничего нет, или порт защищён с помощью iptables (либо надстройками над ним типа fail2ban), то злоумышленник будет дропнут ещё на этапе установки TCP-соединения.

8 способов защиты ssh-сервера. Информация к размышлению

Aug 15 05:02:54 omega sshd[26789]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=112.85.42.230 user=root
Aug 15 05:02:57 omega sshd[26786]: error: PAM: Authentication failure for root from 112.85.42.230
Aug 15 05:02:58 omega sshd[26792]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=112.85.42.230 user=root
Aug 15 05:03:00 omega sshd[26786]: error: PAM: Authentication failure for root from 112.85.42.230
Aug 15 05:05:29 omega sshd[26797]: Received disconnect from 22.226.181.166 port 37420:11: [preauth]

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

• Защита средствами фаервол
• Авторизация по паролю
• Установка ssh-сервера на другой порт
• Доступ по ключам
• Доступ через программы-нокеры (port knockres)
• Использование fail2ban
• Использование vpn

Теперь подробнее о каждом

Защита средствами фаервол

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

Этот вариант защиты «только для своих». Не подходит тем, у кого провайдер использует динамическую раздачу адресов

Авторизация по паролю

Самый стандартный способ. После установки ssh-сервер висит на 22 порту. Это стандартный порт для sshd. Доступ пользователю root запрещен. При соединении запрашивается пара логин/пароль. Если все прошло удачно, то в распоряжении пользователя появляется командная строка. Тут все просто. Порт доступен для сканирования и брутфорса

В этом случае пароль должен быть достадочно сложным

Установка sshd на другой порт

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

Количество атак на такие порты стремится к нулю

Этот способ может рассматриваться администратором как дополнительный фактор защиты. Всегда нужно помнить номер порта

Доступ по ключам

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

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

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

Доступ через программы-нокеры

Суть технологии port knocking — открыть доступ к определенным портам если удаленный пользователь предварительно передал корректную последовательность соединений на целевой сервер

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

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

Более сложный метод защиты от прослушивания port knocking состоит в использовании одноразовых секретных последовательностей. Например в настройках сервера knockd можно использовать параметр one_time_sequences, значением которого должен быть путь к файлу с определением последовательностей, по одной на строку. После использования каждой последовательности knockd комментирует строку с такой последовательностью и переключается на следующую

Двухфакторная аутентификация (2FA)

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

В результате, потенциальному злоумышленнику мало знать Ваш логин и пароль, ему еще нужно завладеть Вашим мобильным устройством, где установлена программа аутентификатор ( Microsoft Authenticator )

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

Использование fail2ban

Принцип работы этой программы в следующем: если за определенное количество попыток не был выполнен удачный вход, то ip-адрес с которого пользователь соединяется будет заблокирован на время определенное в настройках fail2ban. Решения о блокировке принимается на основании онлайн анализа sshd.log и выполняется посредством корректировки правил фаервол

Этот способ эффективен на практике. После блокировки на долгое время нескольких ip-адресов бот уходил на долго

Использование vpn

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

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

Были рассмотрены различные способы защиты ssh. Комбинируя их между собой можно значительно повысить уровень защиты сервера. Но это определяется уровнем паранойи администратора

Усиление защиты OpenSSH в Ubuntu 18.04

Серверы Linux часто управляются удаленно с использованием протокола SSH путем подключения к серверу OpenSSH, который является программным обеспечением сервера SSH по умолчанию, используемым в Ubuntu, Debian, CentOS, FreeBSD и большинстве других систем на базе Linux/BSD.

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

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

Предварительные требования

Для данного обучающего руководства вам потребуется следующее:

• Сервер Ubuntu 18.04, настроенный согласно руководству по первоначальной настройке сервера с Ubuntu 18.04, включая пользователя sudo без прав root.

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

Шаг 1 — Общее усиление защиты

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

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

Многие из конфигураций усиления защиты для OpenSSH внедряются с использованием стандартного файла конфигурации сервера OpenSSH, который находится в каталоге /etc/ssh/sshd_config . Прежде чем продолжить, рекомендуем сделать резервную копию вашего существующего файла конфигурации, чтобы вы могли его восстановить, если что-то пойдет не так, хоть это и маловероятно.

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

Резервная копия файла будет сохранена в /etc/ssh/sshd_config.bak .

Перед редактированием файла конфигурации вы можете просмотреть текущие настроенные опции. Сделать это можно с помощью следующей команды:

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

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

Примечание. Файл конфигурации сервера OpenSSH включает многие опции и конфигурации по умолчанию. В зависимости от существующей конфигурации сервера некоторые из рекомендованных опций по усилению защиты могут уже быть установлены.

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

Сначала отключите возможность входа через SSH в качестве пользователя с правами root, установив следующую опцию:

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

Далее вы можете ограничить максимальное количество попыток аутентификации для конкретного сеанса входа, настроив следующее:

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

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

Файл конфигурации определяет это значение в секундах.

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

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

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

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

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

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

Сервер OpenSSH позволяет подключать клиентов для прохождения переменных настраиваемой среды, т. е. устанавливать $PATH или конфигурировать настройки терминала. Однако, как и перенаправление X11, эти опции не имеют широкого распространения, поэтому могут быть отключены в большинстве случаев:

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

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

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

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

Теперь проверьте синтаксис новой конфигурации, запустив sshd в тестовом режиме:

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

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

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

Шаг 2 — Внедрение списка разрешенных IP-адресов

Вы можете использовать списки разрешенных IP-адресов для ограничения числа пользователей, имеющих разрешение входить на ваш сервер с помощью IP-адреса. На этом шаге вы настроите список разрешенных IP-адресов для вашего сервера OpenSSH.

Зачастую вы будете входить на сервер с ограниченного числа известных доверенных IP-адресов. Например, это может быть ваше домашнее интернет-подключение, корпоративное оборудование VPN, статический инсталляционный сервер или узел-бастион в ЦОД.

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

Примечание. Обязательно проверьте корректность IP-адресов, которые вы добавляете в список. Убедитесь, что эти адреса не являются плавающими или динамическими, которые могут регулярно меняться. Данная функция, например, часто встречается у поставщиков интернет-услуг.

Вы можете определить текущий IP-адрес, с которого вы подключаетесь к вашему серверу, с помощью команды w :

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

Найдите в списке вашу учетную запись пользователя и отметьте связующий IP-адрес. В данном случае мы используем в качестве примера IP-адрес 203.0.113.1 .

Чтобы внести ваш IP-адрес в список разрешенных адресов, откройте файл конфигурации сервера OpenSSH в предпочитаемом текстовом редакторе:

Вы можете создавать списки разрешенных IP-адресов с помощью директивы конфигурации AllowUsers , которая ограничивает аутентификацию пользователя на основе имени пользователя и/или IP-адреса.

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

• Ограничить всех пользователей конкретным IP-адресом:

• Ограничить всех пользователей конкретным диапазоном IP-адресов с помощью записи бесклассовой междоменной маршрутизации (CIDR):

• Ограничить всех пользователей конкретным диапазоном IP-адресов (с помощью подстановочных знаков):

• Ограничить всех пользователей несколькими конкретными IP-адресами и диапазонами:

• Запретить вход всем пользователям, кроме указанных пользователей с конкретных IP-адресов:

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

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

После завершения установки конфигурации добавьте ее внизу файла конфигурации сервера OpenSSH:

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

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

На этом шаге вы внедрили список разрешенных IP-адресов на вашем сервере OpenSSH. На следующем шаге мы ограничим оболочку пользователя, чтобы сократить количество команд, разрешенных к использованию.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаг 4 — Расширенное усиление защиты

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

Менее известная особенность сервера OpenSSH — это возможность вводить ограничения на основе ключа, т. е. ограничения, применимые только к отдельным публичным ключам, представленным в файле .ssh/authorized_keys . Это особенно полезно для контроля доступа к межкомпьютерным сеансам, а также предоставления пользователям без привилегий sudo контроля ограничений их собственных учетных записей.

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

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

Для начала откройте файл .ssh/authorized_keys в предпочитаемом текстовом редакторе:

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

После открытия файла authorized_keys вы увидите, что каждая строка содержит публичный ключ SSH, который, скорее всего, будет начинаться с ssh-rsa AAAB. . Дополнительные опции конфигурации можно добавить в начало строки, и они будут применяться только к успешным случаям аутентификации с помощью конкретного публичного ключа.

Доступны следующие опции ограничения:

• no-agent-forwarding : отключение перенаправления агента SSH.
• no-port-forwarding : отключение перенаправления порта SSH.
• no-pty : отключение возможности выделения tty (т. е. запуск оболочки).
• no-user-rc : предотвращение выполнения файла

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

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

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

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

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

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

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

Наконец, для максимально продуктивного использования ограничения по ключу для пользователя только SFTP, которое вы настроили на шаге 3, используйте следующую конфигурацию:

Опция restrict отключает любой интерактивный доступ, а опция command="false" действует как вторая линия защиты в случае отказа опции ForceCommand или оболочки nologin .

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

На этом заключительном шаге вы внедрили некоторые дополнительные усовершенствованные меры по усилению защиты для сервера OpenSSH, используя настраиваемые опции внутри файла (файлов) .ssh/authorized_keys .

Заключение

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

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

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

Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.