← Cloudflare One / cloudflare-one / networks / connectors / cloudflare-tunnel / use-cases / ssh

SSH с Access for Infrastructure

Access for Infrastructure обеспечивает детальный контроль над тем, как пользователи подключаются к вашим SSH-серверам. Как и собственные ключи SSH метод использует Cloudflare One Client на устройствах пользователей и Cloudflare Tunnel на сервере для создания безопасного приватного соединения через сеть Cloudflare. Access for Infrastructure добавляет политики на уровне приложений с элементами управления по целевому объекту и по имени пользователя, а также ведение логов SSH-команд.

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

1. В панели управления Cloudflare перейдите в Сеть > Tunnels.

   Перейдите в Tunnels ↗

2. Создать новый туннель или отредактировать существующий cloudflared туннель.

3. В панели управления Cloudflare перейдите в Сеть > Маршруты.

   Перейдите в Маршруты ↗

4. Выберите Создать маршрут > Tunnel CIDR. Выберите только что созданный туннель, введите IP-адрес или CIDR-адрес вашего сервера (обычно приватный IP-адрес, но допускаются и публичные) и выберите Создать маршрут.

Чтобы подключить свои устройства к Cloudflare:

1. Разверните Cloudflare One Client на ваших устройствах в режиме Traffic and DNS.
2. Включите Gateway proxy для TCP.
3. Создать правила регистрации устройств чтобы определить, какие устройства могут регистрироваться в вашей организации Zero Trust.

По умолчанию WARP исключает трафик, направленный на Пространство адресов RFC 1918 ↗, то есть IP-адреса, обычно используемые в частных сетях и недоступные из интернета. Чтобы Cloudflare One Client мог отправлять трафик на ваш SSH-сервер, необходимо настроить Split Tunnels чтобы трафик к IP-адресу/CIDR вашего SSH-сервера направлялся через Cloudflare One Client.

1. Сначала проверьте, ваш Режим Split Tunnels имеет значение Exclude или Включить режим.

2. Измените маршруты Split Tunnel в зависимости от режима:

   Если вы используете Exclude режим:

   a. Удалите маршрут содержащий диапазон IP/CIDR вашего SSH-сервера. Например, если в вашей сети используется диапазон AWS по умолчанию 172.31.0.0/16, удалите 172.16.0.0/12.

   b. Повторно добавить диапазоны IP/CIDR которые явно не используются вашим SSH-сервером. Для приведенного выше примера AWS вы бы добавили новые записи для 172.16.0.0/13, 172.24.0.0/14, 172.28.0.0/15, а также 172.30.0.0/16. Это гарантирует, что только трафик к 172.31.0.0/16 маршруты через Cloudflare One Client.

   Чтобы определить, какие IP-адреса нужно добавить повторно, можно воспользоваться следующим калькулятором:

   Базовый CIDRВычтенные CIDR

   Рассчитать

   Инструкции для калькулятора

   1. В Базовый CIDR, введите диапазон RFC 1918, который вы удалили из Split Tunnels.
   2. В Вычтенные CIDR, введите диапазон IP/CIDR, используемый вашим SSH-сервером.
   3. Повторно добавьте результаты калькулятора в список режима Exclude для Split Tunnel.

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

   Если вы используете Включить режим:

   1. Добавьте необходимые Домены Zero Trust или IP-адреса в список включений Split Tunnel.
   2. Добавьте маршрут чтобы включить диапазон IP/CIDR вашего SSH-сервера.

Цель представляет собой отдельный ресурс вашей инфраструктуры (например, сервер, кластер Kubernetes, базу данных или контейнер), к которому пользователи будут подключаться через Cloudflare.

Цели не зависят от протокола: не нужно определять отдельную цель для каждого протокола, работающего на сервере. Чтобы создать новую цель:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/infrastructure/targets" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"hostname": "infra-access-target",
		"ip": {
				"ipv4": {
						"ip_addr": "187.26.29.249",
						"virtual_network_id": "c77b744e-acc8-428f-9257-6878c046ed55"
				},
				"ipv6": {
						"ip_addr": "64c0:64e8:f0b4:8dbf:7104:72b0:ec8f:f5e0",
						"virtual_network_id": "c77b744e-acc8-428f-9257-6878c046ed55"
				}
		}
	}'

Далее создайте приложение Access, чтобы защитить целевой ресурс.

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Example infrastructure app",
		"type": "infrastructure",
		"target_criteria": [
				{
						"target_attributes": {
								"hostname": [
										"infra-access-target"
								]
						},
						"port": 22,
						"protocol": "SSH"
				}
		],
		"policies": [
				{
						"name": "Allow a specific email",
						"decision": "allow",
						"include": [
								{
										"email": {
												"email": "[email protected]"
										}
								}
						],
						"connection_rules": {
								"ssh": {
										"usernames": [
												"root",
												"ec2-user"
										]
								}
						}
				}
		]
	}'

Теперь цели в этом приложении защищены вашими политиками инфраструктуры.

Трафик от Cloudflare One Client к целевым объектам вашей инфраструктуры фильтруется одновременно с помощью Политики Network Gateway и специфичными для приложения политиками Access.

Чтобы запретить пользователям Cloudflare One Client доступ ко всей вашей частной сети, рекомендуем создать catch-all-политика блокировки Gateway для вашего частного IP-пространства. После этого вы можете добавить политики Allow с более высоким приоритетом (в Access или Gateway), которые предоставляют пользователям доступ к конкретным приложениям или IP-адресам.

По умолчанию Cloudflare оценивает политики приложений Access только после оценки всех Политики Network Gateway. Чтобы оценивать приложения Access до или после определенных политик Gateway:

1. В Панель управления Cloudflare ↗, перейдите в Zero Trust > Политики трафика > Политики Firewall. В Сеть, создать политику Network со следующей конфигурацией:

   Селектор	Оператор	Значение	Действие
   Access Infrastructure Target	является	Present	Allow

2. Обновите в политике порядок приоритета с помощью панели управления или API.

Эта политика Gateway будет применяться ко всем целям Access for Infrastructure, включая RDP и SSH.

Далее настройте свой SSH-сервер так, чтобы он доверял Cloudflare SSH CA. Это позволяет Access выполнять аутентификацию с помощью краткосрочных сертификатов вместо традиционных SSH-ключей.

Чтобы создать SSH CA Cloudflare и получить его открытый ключ:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/gateway_ca" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/gateway_ca" \
	--request GET \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

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

   cd /etc/ssh

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

   vim ca.pub

3. В ca.pub файл, вставьте открытый ключ без каких-либо изменений.

   ca.pub

   ecdsa-sha2-nistp256 <redacted> [email protected]

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

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

   :w !sudo tee %
   :q!

Настройте свой сервер SSH, чтобы он доверял Cloudflare SSH CA, обновив sshd_config файл на удалённой целевой машине.

1. Находясь в /etc/ssh каталоге на удаленной машине откройте sshd_config файл.

    sudo vim /etc/ssh/sshd_config

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

   PubkeyAuthentication yes
   TrustedUserCAKeys /etc/ssh/ca.pub

3. Нажмите esc а затем введите :x и нажмите Enter и сохраните и выйдите.

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

sudo systemctl reload ssh

sudo systemctl reload sshd

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

Чтобы настроить независимую MFA для SSH, см. Принудительно применять MFA для инфраструктурных приложений.

Прежде чем пользователи смогут подключаться с включенной MFA, они должны зарегистрировать свой ключ и настроить SSH-клиент.

• Для ключей PIV зарегистрируйте ключ и настроить SSH-клиент.
• Для ключей FIDO2 зарегистрируйте ключ и настроить SSH-клиент.

Когда пользователь выполняет ssh <username>@<target IP>, прокси-сервер SSH проверяет, требуется ли MFA для соответствующей политики. Если требуется, пользователь проходит аутентификацию с помощью аппаратного ключа. Будет ли ключ запрашивать прикосновение, PIN-код или и то, и другое, зависит от настроенных вами политик PIV key либо от собственной конфигурации ключа FIDO2. После этого прокси-сервер завершает подключение.

Пользователи могут использовать любой SSH-клиент, будучи авторизованными в Cloudflare One Client. Если целевой узел использует виртуальную сеть, подключиться к этой виртуальной сети сначала.

ssh <username>@<target IP>

Access for Infrastructure также поддерживает scp, sftp, а также rsync команды. См. Известные ограничения для списка неподдерживаемых команд и функций SSH.

Чтобы узнать больше о подключениях пользователей, см. Документация Access for Infrastructure.

Логи SSH-команд содержат непосредственно команды SSH, которые пользователь выполнил на целевом узле. Клиенты на любом тарифном плане могут хранить логи SSH в Cloudflare и загружать их из панели управления. Загружаемые журналы шифруются открытым ключом, который предоставляет заказчик, и не видны Cloudflare. Загружаемые журналы SSH доставляются по принципу best effort; для гарантированной доставки клиенты с планом Enterprise могут настроить задание Logpush чтобы отправлять журналы SSH в места хранения. Полезные данные Logpush не шифруются с помощью открытого ключа, предоставленного клиентом.

Следуйте этим инструкциям, чтобы зашифровать и загрузить журналы команд SSH из Zero Trust.

Чтобы вести логи SSH-команд, необходимо сгенерировать пару ключей HPKE и загрузить открытый ключ в Cloudflare.

1. Скачать ↗ Cloudflare ssh-log-cli утилиты.

2. С помощью ssh-log-cli утилиты сгенерируйте пару открытого и закрытого ключей.

   ./ssh-log-cli generate-key-pair -o sshkey
   ls

   README.md    ssh-log-cli    sshkey    sshkey.pub

   Эта команда выводит два файла: sshkey.pub открытый ключ и соответствующий sshkey закрытый ключ.

3. В Панель управления Cloudflare ↗, перейдите в Zero Trust > Политики трафика > Настройки трафика.

4. В Открытый ключ шифрования журналов SSH, вставьте содержимое sshkey.pub и выберите Save.

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

Чтобы отключить логирование SSH-команд, удалите загруженный открытый ключ:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/gateway/audit_ssh_settings" \
	--request PUT \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"public_key": ""
	}'

Логи SSH-команд недоступны непосредственно в панели управления: их необходимо экспортировать и расшифровать.

Чтобы вручную получить журналы:

1. В Панель управления Cloudflare ↗, перейдите в Zero Trust > Insights > Журналы.
2. Выберите логи SSH-команд.
3. Фильтруйте журналы по имени вашего приложение SSH.
4. Выберите SSH-сессию, для которой нужно экспортировать журналы команд.
5. На боковой панели прокрутите вниз до Журналы SSH и выберите Скачать.

6. Чтобы расшифровать журнал, следуйте инструкциям в репозиторий SSH Logging CLI ↗. В следующем примере sshkey является закрытым ключом, соответствующим открытому ключу, загруженному в Cloudflare.

   ./ssh-log-cli decrypt -i sshlog -k sshkey

   Эта команда выводит sshlog-decrypted.zip файл с расшифрованными журналами.

Cloudflare позволяет отправлять журналы команд SSH в места хранения, настроенные в Logpush, включая сторонние ресурсы назначения. Список доступных полей данных приведён в Набор данных журналов SSH.

Чтобы настроить задание Logpush, см. в интеграция Logpush.

Следующие функции SSH не поддерживаются:

• Локальное и удалённое перенаправление портов
• ProxyJump
• проброс SSH-агента
• Переадресация X11

Максимальная ожидаемая продолжительность сеанса SSH составляет 10 часов. Дополнительную информацию см. в Устранение неполадок Access.

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

1. Убедитесь, что ваши политики Access позволяют пользователю получить доступ к цели.
2. Проверить Cloudflare Tunnel работоспособность.
3. Подтвердите наличие пользователя на сервере.
4. Проверьте sshd_config файл на наличие ошибок конфигурации.

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

Как конечный пользователь выполните команду warp-cli target list чтобы убедиться, что у вас есть доступ к цели.

warp-cli target list

╭──────────────────────────────────────┬──────────┬───────┬───────────────────────┬──────────────────────┬────────────╮
│ Target ID                            │ Protocol │ Port  │ Attributes            │ IP (Virtual Network) │ Usernames  │
├──────────────────────────────────────┼──────────┼───────┼───────────────────────┼──────────────────────┼────────────┤
│ 0193f22a-9df3-78e3-b5bb-7ab631903306 │ SSH      │ 22    │ hostname: do-target   │ 10.116.0.3 (a1net)   │ alice      │
├──────────────────────────────────────┼──────────┼───────┼───────────────────────┼──────────────────────┼────────────┤
│ 0193f22a-9df3-78e3-b5bb-7ab631903306 │ SSH      │ 23    │ hostname: do-target   │ 10.116.0.3 (a1net)   │ root       │
├──────────────────────────────────────┼──────────┼───────┼───────────────────────┼──────────────────────┼────────────┤
│ 01943cff-6130-7989-8bff-cbc02b59a2b1 │ SSH      │ 80    │ hostname: az-target   │ 172.16.0.0 (b1net)   │ alice, bob │
╰──────────────────────────────────────┴──────────┴───────┴───────────────────────┴──────────────────────┴────────────╯

• Если цель отображается в списке, убедитесь, что имя пользователя, с которым выполняется подключение, присутствует в выводе. Если это имя пользователя отсутствует, администратор должен найти политику Access, связанную с этой целью, и добавить это имя пользователя в политику. Администратор должен был создать политику Access в Подшаг 9 шага 5: Добавьте инфраструктурное приложение. Если имя пользователя отображается, это означает, что политика Access должна предоставлять доступ, и вам следует убедиться, что туннель работает исправно в шаг 2.

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

Как администратор, вместо выполнения команды warp-cli target list на устройстве конечного пользователя, вы можете использовать логи Access, чтобы проверить, не вызывает ли проблемы с подключением политика Access. Просмотр логов полезен при устранении проблем с подключением от имени конечного пользователя.

1. В Панель управления Cloudflare ↗, перейдите в Zero Trust > Insights > Журналы.

2. Выберите Журналы аутентификации Access.

3. Выберите приложение, которое вы тестируете, или отфильтруйте Infrastructure как App Type.

4. Просмотрите Решение. Если Решение это Access denied, выберите приложение и скопируйте имя в поле App.

   Если решение имеет значение Access granted, политики Access не мешают вашим попыткам подключения, а проблема с подключением связана с Cloudflare Tunnel (шаг 2), SSH-сервер (шаг 3), или sshd_config файл (Шаг 4).

5. Перейдите в Контроль доступа > Приложения.

6. Введите название приложения в строке поиска и выберите приложение.

7. Выберите Настройте.

8. Перейдите в Политики и проверьте, какие критерии могут блокировать пользователя.

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

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

Если конечный пользователь не может подключиться к цели, туннель, настроенный в Шаг 1: Подключите сервер к Cloudflare может быть недоступен или неактивен.

Чтобы проверить статус туннеля:

1. В панели управления Cloudflare перейдите в Сеть > Маршруты.

   Перейдите в Маршруты ↗

2. Найдите свой IP-адрес, чтобы увидеть маршрут и связанный с ним туннель.

   Этот IP-адрес будет виден в warp-cli target list вывод в предыдущий шаг. Если вы администратор, вы также можете перейти в Сети > Цели и найдите IP-адрес рядом со своим Hostname.

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

4. Проверьте, что Статус туннеля указывает Active, а не Down, Degraded, или Inactive.

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

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

Чтобы проверить наличие пользователя на сервере UNIX, выполните id <USERNAME> команду на сервере, чтобы проверить существование имени пользователя. Если имя пользователя не существует, необходимо добавить пользователя на сервер.

Если пользователь существует на сервере, выполните отладку sshd_config файл на следующем шаге.

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

sshd логи могут подтвердить, доходит ли пользователь до сервера. Расположение вашего sshd логов определяется в вашем sshd_config. Расположение журналов, скорее всего, находится по адресу journalctl -u ssh в Ubuntu и tail /var/log/auth.log для Red Hat.

Использование вашего sshd логи, чтобы убедиться, что попытки подключения по SSH доходят до сервера.

Чтобы исключить проблемы в вашей sshd_config файл, сравните свой существующий sshd_config файл с примером ниже, чтобы проверить, не вызывают ли какие-либо директивы проблемы с аутентификацией. В следующем примере sshd_config файл приведёт к успешной аутентификации:

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

PubkeyAuthentication yes
TrustedUserCAKeys /etc/ssh/ca.pub

Include /etc/ssh/sshd_config.d/*.conf

# When systemd socket activation is used (the default), the socket
# configuration must be re-generated after changing Port, AddressFamily, or
# ListenAddress.
#
# For changes to take effect, run:
#
#   systemctl daemon-reload
#   systemctl restart ssh.socket
#
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
LogLevel DEBUG3

# Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10



# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile    .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
KbdInteractiveAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the KbdInteractiveAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via KbdInteractiveAuthentication may bypass
# the setting of "PermitRootLogin yes
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and KbdInteractiveAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem    sftp    /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#    X11Forwarding no
#    AllowTcpForwarding no
#    PermitTTY no
#    ForceCommand cvs server

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

Certificate invalid: name is not a listed principal

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

sudo sshd -T -C user=<USERNAME> | grep -i principals

Если authorizedprincipalsfile или authorizedprincipalscommand установлено в любое значение, отличное от none, убедитесь, что имя пользователя SSH указано в этом файле или в выводе команды. Если его нет, добавьте его и проверьте свою конфигурацию с помощью sudo sshd -t, затем Обновить вашего SSH-сервера.

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

1. Создайте резервную копию существующего sshd_config файл.

   mv /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

2. Создайте новый sshd_config файл.

   vi /etc/ssh/sshd_config

3. Перейдите в режим вставки, нажав i клавишу на клавиатуре.

4. Вставьте в пример файла.

5. Выйдите из режима вставки, нажав клавишу escape (esc) ключ.

6. Введите :x и сохраните и выйдите.

7. Перезагрузить вашего SSH-сервера.

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

   Для Debian/Ubuntu:

   sudo systemctl reload ssh

   Для CentOS/RHEL 7 и новее:

   sudo systemctl reload sshd

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

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

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

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

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

• Временные метки: указывайте точное время и часовой пояс возникновения проблемы.

• Попытки устранения неполадок: опишите действия или изменения, которые уже предпринимались для решения проблемы.

• sshd журналы уровня debug: приложите sshd логи, которые вы собрали в Шаг 4: Отладьте sshd_config неправильная настройка файла.

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

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