<===

ProNotes

2025-11-15 22:22:13
~ $ ./autossh_script.sh 
** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html
Welcome to Alpine - S5 proxy!

Это предупреждение появляется при использовании современной версии OpenSSH (начиная примерно с 9.6/9.7 и новее, а также в autossh, который его вызывает) и означает следующее:

### Что происходит
Когда ты подключаешься по SSH к удалённому серверу, клиент и сервер договариваются о алгоритме обмена ключами (key exchange algorithm, KEX).  
Современные OpenSSH-клиенты теперь считают «недостаточно безопасными» все классические (не пост-квантовые) алгоритмы обмена ключами и выдают это предупреждение, если используется один из них.

### Почему это проблема
В ближайшие 5–15 лет (точные сроки неизвестны) могут появиться достаточно мощные квантовые компьютеры.  
Алгоритмы вроде RSA, ECDH, Diffie-Hellman на эллиптических кривых уязвимы к атаке алгоритмом Шора на квантовом компьютере.  
Злоумышленник может сегодня перехватить и сохранить зашифрованный SSH-трафик (или VPN, HTTPS и т.д.), а через годы расшифровать его с помощью квантового компьютера. Это и называется **«store now, decrypt later»** (собери сейчас — расшифруй потом).

Текущие классические KEX (ecdsa-sha2-nistp256, curve25519-sha256, diffie-hellman-group-exchange-sha256 и даже sntrup761x25519-sha512@openssh.com в некоторых случаях) считаются уязвимыми к такой атаке в будущем.

### Какие алгоритмы считаются пост-квантовыми (и снимают предупреждение)
OpenSSH начиная с версии 9.0 поддерживает гибридные пост-квантовые KEX:

- **kyber-512** + X25519 (рекомендуется сейчас)
- **sntrup761x25519-sha512@openssh.com** (старый гибрид, всё ещё считается приемлемым, но уже не самый лучший)

В новых версиях предпочтение отдаётся:

```
kex-algorithms sshkyber512k384-sha384@kyber.net,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,...
```

Но если сервер их не поддерживает — будет использован старый алгоритм и предупреждение.

### Что делать в твоём случае

У тебя скрипт autossh_script.sh запускает autossh, который использует современный OpenSSH-клиент (вероятно, на твоей локальной машине в Германии — свежий Debian/Ubuntu/Fedora и т.д.), а сервер, к которому ты туннелируешься, старый и не поддерживает пост-квантовые KEX.

Варианты решения (по убыванию предпочтительности):

1. **Обнови серверный OpenSSH до версии ≥ 9.6** (лучше последней 9.8+ на момент ноября 2025)  
   На большинстве новых дистрибутивов (Ubuntu 24.04+, Debian 13, Fedora 40+, RHEL 10+, OpenSSH 9.8p3+) пост-квантовые алгоритмы включены по умолчанию и предупреждение исчезнет.

2. **Если сервер обновить нельзя** (например, это старый роутер, NAS, облачный инстанс с древним образом и т.п.) — можно подавить предупреждение на клиенте.  
   Добавь в свой ~/.ssh/config или в команду autossh одну из опций:

   ```bash
   # Вариант A — полностью отключить проверку (не рекомендуется)
   Host *
     KexAlgorithms +diffie-hellman-group14-sha256,curve25519-sha256
     PubkeyAcceptedAlgorithms +ssh-rsa
     HostkeyAlgorithms +ssh-rsa
     IgnoreUnknown AddKeysToAgent,UpdateHostKeys
     # Или просто подавить конкретное сообщение
     LogLevel ERROR
   ```

   ```bash
   # Вариант B — более аккуратный: отключить только это предупреждение
   export AUTOSSH_LOGFILE=/dev/null
   autossh -o "KexAlgorithms=curve25519-sha256" -o "LogLevel=ERROR" ...
   ```

   ```bash
   # Вариант C — самый чистый способ (рекомендую)
   autossh -o "RequiredRSASize none" -o "PostQuantumKex no" ...
   ```

   Или в ~/.ssh/config:

   ```
   Host твой-сервер
       PostQuantumKex no
       LogLevel ERROR
   ```

3. **Временный костыль** — добавить в скрипт или в переменную окружения:

   ```bash
   export SSHCONFIG=~/.ssh/config_with_no_pq_check
   ```

   и в этом конфиге прописать `PostQuantumKex no` для нужного хоста.

### Кратко подытожим
- Предупреждение абсолютно正当ное — твой трафик теоретически может быть расшифрован в будущем.
- Лучшее решение — обновить OpenSSH на сервере.
- Если обновить нельзя — отключи проверку на клиенте (это просто предупреждение, соединение остаётся защищённым от атак сегодня).
← Previous Next →
Back to list