После обновления с Windows 10 до 11, почему я не могу подключиться к ПК с помощью SSH?

Я не могу настроить входящие SSH-соединения после обновления с Windows 10 до 11.

Фон:

• Я использовал Windows 10 на ПК и настроил OpenSSH и ключи, чтобы получить удаленный доступ к нему. Это работало нормально в течение многих лет. Материнская плата была несовместима с Windows 11, поэтому я никогда не обновлялся.

• Недавно я собрал новый ПК с почти всем новым оборудованием (новая материнская плата, накопители и т.д.). Клонировал существующий диск на один из новых жестких дисков. Все работало нормально. Новое оборудование совместимо с Windows 11, поэтому я обновился. После нескольких настроек и переустановок почти все работает нормально. Но входящие SSH-соединения не работают, и я не могу понять, в чем дело.

Вещи, которые могут быть полезны:

• Доступ в Интернет работает нормально, ethernet имеет статический IP.
• Не удается пинговать локальный IP-адрес изнутри сети.
  • Пробовал изменить статический IP на что-то, чем никогда не пользовался раньше, все равно не пингует.
• Исходящие SSH-соединения работают нормально.
  • Входящие не работают.
• Исходящий RDP работает нормально.
  • Входящие не работают.
• Исходящий доступ к сетевым папкам работает нормально.
  • Входящие не работают.

Вещи, которых я хочу избежать:

• Полная переустановка Windows 11. У меня много настроек, которые было бы кошмаром восстановить.

Возможно ли сделать полный сброс сетевых адаптеров без сброса всего?

Вещи, которые я пробовал:

• Удаление/переустановка клиент и сервера OpenSSH в дополнительных компонентах.
• Убедившись, что порт 22 открыт в брандмауэре.
• Перепроверка разрешений на administrators_authorized_keys.
• Временное отключение антивируса.

Я ожидаю, что SSH-соединения с ПК и на ПК будут работать корректно. Но только исходящие соединения работают. Входящие заблокированы, и попытка пинговать IP не удалась.

Содержимое sshd_config:

# Это файл конфигурации sshd сервера для всей системы. См.
# sshd_config(5) для получения дополнительной информации.

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

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey __PROGRAMDATA__/ssh/ssh_host_rsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_dsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_ecdsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_ed25519_key

# Шифры и ключи
#RekeyLimit default none

# Логирование
#SyslogFacility AUTH
#LogLevel INFO

# Аутентификация:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

PubkeyAuthentication yes

# По умолчанию проверяются как .ssh/authorized_keys, так и .ssh/authorized_keys2,
# но это переопределено, так что установки будут проверять только .ssh/authorized_keys
AuthorizedKeysFile  .ssh/authorized_keys

#AuthorizedPrincipalsFile none

# Для этого вам также понадобятся ключи хоста в %programData%/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Измените на yes, если вы не доверяете ~/.ssh/known_hosts для
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Не читайте файлы пользователя ~/.rhosts и ~/.shosts
#IgnoreRhosts yes

# Чтобы отключить туннелирование паролей в открытом текстовом виде, измените здесь на no!
PasswordAuthentication no
#PermitEmptyPasswords no

# Параметры GSSAPI
#GSSAPIAuthentication no

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

# нет пути для стандартного баннера
#Banner none

# переопределить стандартное отсутствие подсистем
Subsystem   sftp    sftp-server.exe

# Пример переопределения параметров для каждого пользователя
#Match User anoncvs
#   AllowTcpForwarding no
#   PermitTTY no
#   ForceCommand cvs server

Match Group administrators
       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

Результаты netstat -an | sls ':22':

PowerShell 7.4.1
PS C:\Users\xxxx> netstat -an | sls ':22'

  TCP    0.0.0.0:22             0.0.0.0:0              LISTENING
  TCP    127.0.0.1:2266         127.0.0.1:6850         ESTABLISHED
  TCP    127.0.0.1:2267         127.0.0.1:2268         ESTABLISHED
  TCP    127.0.0.1:2268         127.0.0.1:2267         ESTABLISHED
  TCP    127.0.0.1:6850         127.0.0.1:2266         ESTABLISHED
  TCP    127.0.0.1:22112        0.0.0.0:0              LISTENING
  TCP    192.168.0.24:2258      104.17.107.108:443     ESTABLISHED
  TCP    [::]:22                [::]:0                 LISTENING

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

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

Для меня сеть была классифицирована как “домен”. Но правило брандмауэра, которое Windows устанавливает по умолчанию для сервера OpenSSH, предназначено только для “частных” сетей.

Я изменил правило брандмауэра в “Брандмауэре Windows Defender” -> “Дополнительные параметры” -> “Правила входящего трафика” -> “OpenSSH SSH Server (sshd)” -> “Свойства” -> “Дополнительно” -> “Профили”. Это решило проблему для меня.

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