SSH-ключі в WSL: безпечне налаштування (і як їх не допустити витоку)

WSL + SSH-ключі: ментальна модель, що запобігає витокам

Уявіть WSL як Linux-машину з дуже ліберальною спільною папкою, змонтованою в ній (зазвичай /mnt/c та інші). Ваш домашній каталог у WSL — це не Windows, але й не окремий фізичний комп’ютер, про який можна забути. Це файлова система всередині образу дистрибутива плюс багато інтеграційної клеїть.

SSH-ключі — це просто файли. Ось у чому вся проблема. Якщо вони існують як байти на диску, їх можна скопіювати, індексувати, зробити резервну копію, просканувати антивірусом, «дбайливо» синхронізувати або випадково закомітити. Тому ваше завдання — не «налаштувати SSH». Ваше завдання — контролювати, яка файлова система містить ключі, хто може їх читати, як їх розблоковують і що ви логируєте під час усунення несправностей.

Правила руху (суб’єктивно, бо ви просили про продакшн)

• Генеруйте ключі в файловій системі Linux у WSL (в /home вашого дистрибутива), а не в /mnt/c. За замовчуванням тримайте приватний ключ подалі від інструментів синхронізації Windows.
• Використовуйте фрази-паролі (passphrases). Якщо ви на них алергічні, використовуйте апаратні ключі або агента з коротким TTL — але не «без фрази-пароля».
• Не використовуйте один ключ скрізь. Один ключ для кожної межі ідентичності: особистий, корпоративний, CI, аварійний доступ до продакшну тощо.
• Фіксуйте ключі хостів і ставтеся до known_hosts як до частини безпеки, а не мотлоху. Ваше майбутнє «я» скаже дякую при першому випадку підміни DNS.
• Робіть агента явним. Сесії WSL часто перезапускаються; ви хочете передбачувану поведінку, а не випадкові підказки та мовчанку.
• Аудит виконуйте командами, а не відчуттями. «Має працювати» — це те, як народжуються інциденти.

Цікаві факти та історичний контекст (коротко, корисно)

1. SSH замінив rsh/rlogin у 1990-х, бо текстові віддалені шелли були майже подарунковим кошиком для сніфінгу пакетів.
2. RSA довго був стандартним алгоритмом публічного ключа для SSH, але сучасні налаштування схиляються до Ed25519 через швидкість і безпечніші параметри.
3. OpenSSH додав підтримку FIDO/U2F (наприклад sk-ssh-ed25519@openssh.com) щоб зменшити ризик ексфільтрації ключів.
4. ssh-agent існує через те, що фрази-паролі хороші, але набір їх 40 разів на день — це шлях до «вирішення» проблеми відключенням безпеки.
5. Файл known_hosts — це шар проти фішингу SSH: він дозволяє SSH виявляти зміни MITM без глобальної PKI для хостів.
6. WSL1 і WSL2 різко відрізняються в мережевому плані: WSL2 запускає легкий VM з NAT, що впливає на форвардинг агента та «чому localhost поводиться дивно» під час налагодження.
7. Права доступу Windows не мапляться чисто в POSIX на /mnt/c; це невідповідність — причина, чому SSH скаржиться на «погані дозволи».
8. GitHub відмовлявся від слабких SHA-1 у деяких робочих процесах; аналогічно екосистема SSH повільно штовхає користувачів від старих алгоритмів.

Модель загроз: як ключі витікають у реальному світі

Більшість витоків SSH-ключів — це операційні помилки, а не кінематографічні історії. Ось знайомі підозрювані в середовищах WSL:

1) Файл опиняється в Windows, коли ви цього не помітили

Можливо, ви скопіювали ~/.ssh у папку Windows, щоб «користуватися у VS Code». Може, репозиторій dotfiles містить симлінк, що резольвиться в /mnt/c. Може, ви редагували файли під /mnt/c, бо було зручно. Індексатори пошуку Windows, клієнти хмарної синхронізації, корпоративний DLP і інструменти безпеки кінцевих точок тепер бачать ваші секрети.

2) Резервні копії та експорти

Експорт дистрибутива WSL (wsl --export) створює tarball файлової системи дистрибутива. Цей tarball містить ваші приватні ключі, якщо ви їх не виключили. Це зручна «резервна копія», і одночасно дуже портативний шлях витоку.

3) Логи налагодження і pastebin (тиха катастрофа)

Вивід налагодження SSH переважно безпечний, але ваша історія шелу, скопійовані команди та «швидкі» скрипти для усунення несправностей можуть виводити чутливі шляхи, розташування сокетів агента і іноді матеріал ключа, якщо не бути обережним. Люди вставляють цілий ~/.ssh/config у тикети. Потім система тикетів стає вашим сховищем секретів. Блискуче.

4) Неправильний ключ у неправильному місці

Легко випадково застосувати «універсальний» ключ до невідповідного хоста, особливо якщо покладаєтеся на ідентичності в агенті та не контролюєте IdentitiesOnly. Так ключі опиняються у списках authorized на системах, для яких не призначались.

5) Обхід перевірки ключів хоста «бо це дратує»

Вимкнення суворої перевірки ключів хоста, щоб «полагодити CI» або «спростити bootstrap» — класична самоподія. Ви можете й не зливати приватні ключі, але сильно спрощуєте перехоплення облікових даних і MITM.

Безпечне налаштування: створення, зберігання та використання ключів у WSL

Визначте, де живе приватний ключ (виберіть одне)

• Кращий варіант за замовчуванням: приватні ключі живуть у файловій системі Linux WSL під /home/<user>/.ssh. Windows може дістатися до них лише якщо ви свідомо скопіюєте їх назовні.
• Кращий для високої гарантії: апаратно-захищені ключі (FIDO2/YubiKey), щоб приватний ключ не був експортованим на диск.
• Іноді прийнятно: ключі зберігаються у Windows з Windows-агентом, а потім використовуються з WSL через міст. Це може бути добре в корпоративному середовищі, де Windows суворо керується, а Linux — ні. Але це додає складності на межі.

Якщо сумніваєтеся: тримайте їх у WSL спочатку, додайте фразу-пароль і використовуйте агента з часовим кешуванням. Не ускладнюйте в перший день.

Генеруйте ключі (Ed25519, якщо немає причин інакше)

Ключі Ed25519 швидкі, компактні і широко підтримуються в сучасному OpenSSH. Використовуйте сильну фразу-пароль. Ваша фраза-пароль — це не пароль; це запобіжник від крадіжки файлу ключа.

Встановіть правильні права доступу (інакше SSH відмовиться допомагати)

OpenSSH суворо ставиться до прав приватних ключів. Це добре. У WSL це також часта пастка, коли ви поміщаєте ключі на /mnt/c, де права дивні.

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

Більшість «проблем з SSH» — це фактично «занадто багато неявної поведінки». Помістіть явні блоки хостів у ~/.ssh/config і контролюйте IdentityFile, IdentitiesOnly, User та алгоритми ключів. Мета — зробити правильний шлях найпростішим.

Цитата (переказ)

Переказана ідея: надія — це не стратегія — приписують Gordon R. Dickson; часто використовується в інженерній культурі як нагадування про операційну дисципліну.

Безпека SSH-ключів у WSL — те саме правило: не сподівайтеся, що ваші ключі «не опиняться у Windows». Зробіть це складним для них.

SSH-агент у WSL: не вводити фрази щоразу, але не підставлятися

Агент — це компроміс: зручність заради обмеженого вікна експозиції. Без агента люди обирають слабкі фрази-паролі або взагалі без них. З необережним агентом люди тримають розшифровані ключі в доступі вічно. Оберіть середину: агент + TTL + явні ідентичності.

Що ви хочете від налаштування агента

• Сокет агента існує й стабільний для кожної сесії входу.
• Ключі завантажуються свідомо, а не неявно з випадкових шляхів.
• Ключі зникають з агента після закінчення часу (обмежено за часом), якщо ви не додали їх знову навмисно.
• SSH вибирає лише потрібну ідентичність для кожного хоста.

Невеликий жарт, бо ми говоримо про агентів: SSH-агент — це як залишити ключ від дому швейцару. Чудово, поки швейцар не працює подвійний змін і ніколи не йде додому.

Форвардинг агента: не робіть цього скрізь

Форвардинг вашого агента (-A) може бути корисним для стрибків через бастіони, але підвищує ризик. Якщо віддалений хост має доступ до вашого форварденого сокета агента, він може потенційно використовувати ваші ключі (не викрасти їх, але використовувати) поки форвардинг активний. Використовуйте тільки для хостів, яким довіряєте так само, як довіряєте свому ноутбуку. Тобто обережно.

Межа з Windows: де зручність їсть ваші секрети

Файлова система WSL проти /mnt/c

У WSL2 файлова система дистрибутива зберігається у віртуальному диску. Вона поводиться так, як очікує Linux. Під /mnt/c ви на файловій системі Windows з шарами трансляції. Така трансляція відмінно підходить для редагування файлів; вона — ризик для семантики прав Linux і гігієни секретів.

Чому /mnt/c — погане місце для приватних ключів

• Права Windows не є POSIX-права; SSH може відмовити використовувати ключі через «занадто відкриті» дозволи.
• Клієнти хмарної синхронізації можуть споживати й реплікувати їх.
• Індексатори та антивірус можуть сканувати їх. Не завжди зловмисно, але це розширює поверхню атаки.
• Корпоративний DLP може позначити або поставити їх під карантин, ламаючи ваш робочий процес у найзаплутаніший спосіб.

Коли зберігання у Windows виправдане

Якщо корпоративна політика вимагає зберігання ключів у Windows-агенті (або апаратно-керованих облікових даних) і WSL є «найкращими зусиллями», то так: тримайте ключі у Windows і зробіть WSL споживачем. Але ставтеся до цього як до інтеграційного проєкту. Документуйте. Тестуйте після оновлень. Не «імпровізуйте» з симлінками.

Практичні завдання (команди + виводи + рішення)

Нижче наведені практичні завдання, які ви можете виконати сьогодні. Кожне містить: команду, типовий вивід, що означає вивід, і рішення, яке потрібно прийняти.

Завдання 1: Підтвердити, що ви справді в WSL і яка версія важлива

cr0x@server:~$ uname -a
Linux devbox 5.15.133.1-microsoft-standard-WSL2 #1 SMP Wed Oct 11 00:00:00 UTC 2023 x86_64 GNU/Linux

Значення: «microsoft-standard-WSL2» каже, що це поведінка ядра WSL2 (VM/NAT). Це впливає на мережеві припущення та деякі інтеграції.

Рішення: Якщо ви налагоджуєте форвардинг агента або «чому Windows не бачить цей сокет», врахуйте межі WSL2 і плануйте відповідно.

Завдання 2: Подивитися, де розташований ваш домашній каталог (файлова система Linux чи точка монтування Windows)

cr0x@server:~$ df -h ~
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc       251G   32G  207G  14% /

Значення: Дім на кореневій файловій системі Linux, не на /mnt/c.

Рішення: Добре. Тримайте ~/.ssh тут.

Завдання 3: Виявити, чи ~/.ssh знаходиться на Windows (погано) без гадань

cr0x@server:~$ readlink -f ~/.ssh
/home/cr0x/.ssh

Значення: Реальний шлях під /home. Якщо ви бачите /mnt/c/..., ваша SSH-директорія на Windows.

Рішення: Якщо вона резольвиться під /mnt/c, перемістіть ключі в WSL і виправте права.

Завдання 4: Перелічити ключі й права; помітити явні витоки

cr0x@server:~$ ls -la ~/.ssh
total 28
drwx------  2 cr0x cr0x 4096 Feb  5 10:12 .
drwxr-xr-x 19 cr0x cr0x 4096 Feb  5 09:40 ..
-rw-------  1 cr0x cr0x  464 Feb  5 10:12 config
-rw-------  1 cr0x cr0x  419 Feb  5 10:11 id_ed25519
-rw-r--r--  1 cr0x cr0x   99 Feb  5 10:11 id_ed25519.pub
-rw-------  1 cr0x cr0x 1520 Feb  5 10:12 known_hosts

Значення: Директорія — 700, приватні ключі — 600. Саме те, що хоче SSH.

Рішення: Якщо приватні ключі доступні групі/світу, виправте негайно за допомогою chmod (наступне завдання).

Завдання 5: Виправити права одночасно (безпечні значення)

cr0x@server:~$ chmod 700 ~/.ssh
cr0x@server:~$ chmod 600 ~/.ssh/id_ed25519 ~/.ssh/config ~/.ssh/known_hosts
cr0x@server:~$ chmod 644 ~/.ssh/id_ed25519.pub

Значення: Відсутній вивід означає успіх.

Рішення: Якщо це не вдається на /mnt/c, це сигнал припинити зберігати приватні ключі на точках монтування Windows.

Завдання 6: Згенерувати новий Ed25519 ключ із сильним KDF

cr0x@server:~$ ssh-keygen -t ed25519 -a 64 -f ~/.ssh/id_ed25519_work -C "work-wsl"
Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/cr0x/.ssh/id_ed25519_work
Your public key has been saved in /home/cr0x/.ssh/id_ed25519_work.pub
The key fingerprint is:
SHA256:8vQZrY4eKJf1YqE6k6G4l3g6i4lqf7RkR5u9M6w8a2k work-wsl
The key's randomart image is:
+--[ED25519 256]--+
|  . . . . .      |
| . . o . o       |
|  . + . +        |
|   o . =         |
|    . . S        |
|     o o         |
|    . = +        |
|     + = .       |
|      o..        |
+----[SHA256]-----+

Значення: -a 64 збільшує кількість раундів KDF для захисту фрази-пароля. Це сповільнює brute-force, якщо файл викрадуть.

Рішення: Використовуйте фразу-пароль. Якщо не можете, використовуйте апаратні ключі замість «порожньої фрази-пароля».

Завдання 7: Перевірити, що приватний ключ зашифрований (не plain text)

cr0x@server:~$ head -n 2 ~/.ssh/id_ed25519_work
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW

Значення: Ви все одно побачите заголовок навіть коли ключ зашифрований, але за першою лише лінією неможливо підтвердити шифрування.

Рішення: Використайте ssh-keygen -y, щоб домогтися підказки для фрази-пароля (наступне завдання). Якщо не питає — ймовірно, ключ незашифрований.

Завдання 8: Підтвердити поведінку з підказкою фрази-пароля

cr0x@server:~$ ssh-keygen -y -f ~/.ssh/id_ed25519_work >/dev/null
Enter passphrase:

Значення: Підказка означає, що ключ захищено фразою-паролем (або принаймні вимагає дешифрування).

Рішення: Якщо немає підказки і команда виконується успішно, ймовірно ваш ключ незашифрований — розгляньте перевипуск із фразою-паролем.

Завдання 9: Створити строгий запис у SSH-конфігу, щоб використовувався правильний ключ

cr0x@server:~$ cat > ~/.ssh/config <<'EOF'
Host github-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_work
  IdentitiesOnly yes
  PreferredAuthentications publickey
EOF
cr0x@server:~$ chmod 600 ~/.ssh/config

Значення: IdentitiesOnly yes заважає SSH пробувати всі ключі з агента і викликати блокування або дивні потоки автентифікації.

Рішення: Використовуйте іменовані хости (github-work), щоб уникнути змішування ключів між ідентичностями.

Завдання 10: Перевірити, що SSH реально використає (без гадань)

cr0x@server:~$ ssh -G github-work | egrep '^(hostname|user|identityfile|identitiesonly|preferredauthentications) '
hostname github.com
user git
identityfile ~/.ssh/id_ed25519_work
identitiesonly yes
preferredauthentications publickey

Значення: ssh -G друкує розв’язану конфігурацію після include, match-блоків тощо.

Рішення: Якщо бачите несподіваний identityfile або user, виправте конфіг перед подальшим налагодженням.

Завдання 11: Запустити агента і завантажити ключ з TTL

cr0x@server:~$ eval "$(ssh-agent -s)"
Agent pid 1173
cr0x@server:~$ ssh-add -t 1h ~/.ssh/id_ed25519_work
Enter passphrase for /home/cr0x/.ssh/id_ed25519_work:
Identity added: /home/cr0x/.ssh/id_ed25519_work (work-wsl)

Значення: Ключ кешується в пам’яті на одну годину.

Рішення: TTL — дешева страховка. Якщо потрібно довше, робіть це свідомо, а не за замовчуванням.

Завдання 12: Підтвердити, які ключі завантажені в агент

cr0x@server:~$ ssh-add -l
256 SHA256:8vQZrY4eKJf1YqE6k6G4l3g6i4lqf7RkR5u9M6w8a2k work-wsl (ED25519)

Значення: У вашого агента наразі завантажено рівно одну ідентичність.

Рішення: Якщо бачите купу ключів, які забули, видаліть їх: ssh-add -D, потім додайте назад лише те, що потрібно.

Завдання 13: Запустити вербозний тест SSH і читати як SRE

cr0x@server:~$ ssh -vvv github-work
OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /home/cr0x/.ssh/config
debug1: /home/cr0x/.ssh/config line 1: Applying options for github-work
debug1: Connecting to github.com [140.82.112.3] port 22.
debug1: Authentication succeeded (publickey).
Authenticated to github.com ([140.82.112.3]:22).

Значення: Ви бачите точно, який конфіг застосовано, який хост/порт і чи спрацювала публічна автентифікація.

Рішення: Якщо пробує неправильний ключ, виправте конфіг (IdentityFile, IdentitiesOnly) і стан агента; не продовжуйте без кінця повторювати спроби.

Завдання 14: Перевірити пінування ключа хоста та несподівані зміни

cr0x@server:~$ ssh-keygen -F github.com -f ~/.ssh/known_hosts | head
# Host github.com found: line 3
github.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...

Значення: У вас є запис про пінування ключа хоста для цього хоста.

Рішення: Якщо ключ хоста змінився несподівано, трактуйте це як інцидент безпеки, поки не доведено інше. Не видаляйте рефлекторно known_hosts.

Завдання 15: Виявити випадковий матеріал ключа під /mnt/c (скан витоків)

cr0x@server:~$ grep -R --line-number --binary-files=without-match "BEGIN OPENSSH PRIVATE KEY" /mnt/c/Users/cr0x 2>/dev/null | head
/mnt/c/Users/cr0x/Downloads/wsl-export.tar:1:-----BEGIN OPENSSH PRIVATE KEY-----

Значення: Знайдено заголовок приватного ключа в файлі на боці Windows (тут: tar-експорт). Це реальний шлях витоку.

Рішення: Вважайте його скомпрометованим, поки не перевірите ізоляцію. Поверніть ключі, очистіть артефакт. Також виправте процес резервного копіювання/експорту.

Завдання 16: Виявити, чи ваш Git-репозиторій містить секрети перед пушем

cr0x@server:~$ git status --porcelain
?? .ssh/id_ed25519_work
?? .ssh/id_ed25519_work.pub

Значення: Ви збираєтеся закомітити свої SSH-ключі. Не «можливо». Ви це робите.

Рішення: Додайте .ssh/ до .gitignore, приберіть файли з робочого дерева і проведіть ротацію, якщо щось було запушено кудись.

Завдання 17: Підтвердити, що взаємодія з Windows не копіює конфіг SSH мовчки (саніті-чек)

cr0x@server:~$ ls -la /mnt/c/Users/cr0x/.ssh 2>/dev/null
total 12
drwxr-xr-x 1 cr0x cr0x 4096 Feb  5 09:55 .
drwxr-xr-x 1 cr0x cr0x 4096 Feb  5 09:20 ..
-rw-r--r-- 1 cr0x cr0x  412 Feb  5 09:55 config

Значення: Існує SSH-конфіг на боці Windows. Деякі інструменти (включно з Windows OpenSSH та Git-інструментами) можуть його використовувати.

Рішення: Вирішіть свідомо: або тримайте окремі конфіги для Windows і WSL, або уніфікуйте і документуйте межу. «Два конфіги, що розходяться» стає фабрикою тикетів.

Швидкий план діагностики

Це робочий процес «воно не працює і в мене є п’ять хвилин». Він пріоритетизує сигнал. Глибше можна піти пізніше.

Перше: Чи використовує SSH ту конфігурацію, яку ви вважаєте?

• Запустіть ssh -G <host-alias> і підтвердьте hostname, user і identityfile.
• Якщо identityfile неправильний, виправте ~/.ssh/config перед тим, як чіпати агенти, права або сервери.

Друге: Чи доступний ключ і чи правильно виставлені права?

• Перевірте ls -la ~/.ssh і впевніться, що приватні ключі — 600, директорія — 700.
• Якщо ключі на /mnt/c, припустіть проблему з правами і перемістіть їх у WSL.

Третє: Чи нормальний стан агента?

• Запустіть ssh-add -l. Якщо команда падає — агент не запущений або SSH_AUTH_SOCK неправильний.
• Якщо виводить десять ключів — зачистіть. Тримайте агента мінімальним і явним.

Четверте: Сервер відмовляє чи ви не пропонуєте те, що потрібно?

• Використайте ssh -vvv один раз, читайте рядки про Offering public key та Authentication succeeded/failed.
• Якщо сервер каже «too many authentication failures», ви пропонуєте забагато ключів. Закріпіть IdentitiesOnly.

П’яте: Попередження про ключ хоста — не «шум»

• Якщо бачите попередження про зміну ключа хоста — зупиніться. Підтвердіть поза каналом, якщо хост був перебудований або скомпрометований.

Поширені помилки: симптом → причина → виправлення

1) Симптом: «Bad permissions» або «Unprotected private key file»

Причина: Приватний ключ лежить на /mnt/c або має надто вільні режим/власність.

Виправлення: Перемістіть ключ у файлову систему Linux WSL і встановіть суворі права.

cr0x@server:~$ mv /mnt/c/Users/cr0x/.ssh/id_ed25519 ~/.ssh/id_ed25519_windows_moved
cr0x@server:~$ chmod 700 ~/.ssh
cr0x@server:~$ chmod 600 ~/.ssh/id_ed25519_windows_moved

2) Симптом: «Permission denied (publickey)» після того, як раніше працювало

Причина: Ви ротували ключі, змінили вміст агента або ваш SSH-конфіг тепер вказує на інший IdentityFile.

Виправлення: Перевірте за допомогою ssh -G, потім переконайтеся, що правильний ключ завантажено.

cr0x@server:~$ ssh -G myhost | egrep '^(identityfile|identitiesonly|user|hostname) '
identityfile ~/.ssh/id_ed25519_work
identitiesonly yes
user deploy
hostname myhost

3) Симптом: «Too many authentication failures»

Причина: У агента багато ідентичностей і SSH пропонує їх підряд, поки сервер не роз’єднає.

Виправлення: Використовуйте IdentitiesOnly yes і вкажіть один IdentityFile на хост-аліас. Також очистіть агент.

cr0x@server:~$ ssh-add -D
All identities removed.
cr0x@server:~$ ssh-add -t 30m ~/.ssh/id_ed25519_work
Enter passphrase for /home/cr0x/.ssh/id_ed25519_work:
Identity added: /home/cr0x/.ssh/id_ed25519_work (work-wsl)

4) Симптом: Host key verification failed після перебудови

Причина: Ключ хоста змінився (легітимна перебудова або ні). Ваш запис у known_hosts застарілий.

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

cr0x@server:~$ ssh-keygen -R myhost -f ~/.ssh/known_hosts
# Host myhost found: line 12
/home/cr0x/.ssh/known_hosts updated.
Original contents retained as /home/cr0x/.ssh/known_hosts.old

5) Симптом: Ваш ключ з’являється в індексі пошуку Windows / хмарній синхронізації

Причина: Ви скопіювали ~/.ssh у Windows або експортували WSL і зберегли tarball у синхронізованому місці.

Виправлення: Припустіть експозицію. Ротуйте ключі, видаліть артефакти, налаштуйте експорт/резервне копіювання так, щоб виключати секрети.

6) Симптом: SSH працює в терміналі WSL, але падає в VS Code / Git GUI

Причина: Інструмент використовує Windows OpenSSH, а не WSL OpenSSH, отже читає інший конфіг і ключі.

Виправлення: Вирішіть, яка сторона відповідає за SSH у цьому робочому процесі. Налаштуйте інструмент явно використовувати потрібний бінар і сховище ключів. Не підтримуйте дві паралельні всесвіти, якщо вам не подобається екзистенційна мука.

7) Симптом: Агент працює в одній вкладці шелу, але не в іншій

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

Виправлення: Використовуйте узгоджену стратегію запуску агента і зберігайте SSH_AUTH_SOCK у передбачуваному місці для сесії (або покладіться на менеджер сервісів дистрибутива, якщо є).

Три корпоративні міні-історії з практики

Міні-історія 1: Інцидент через неправильне припущення

Вони ввели WSL як стандартне dev-середовище для команди, яка керувала продакшн-інфраструктурою. Це було розумно: уніфіковані інструменти, менше «працює на моїй машині» і простіший онбординг. Ключі генерувалися у WSL, усі використовували фрази-паролі, і галочка про відповідність політикам була задовільно проставлена.

Неправильне припущення було тонким: «Якщо це всередині WSL, воно не на Windows». Це здебільшого було правда — поки розробник не експортнув дистрибутив, щоб перейти на новий ноутбук. tar-експорт опинився в корпоративній синхронізованій папці, бо інструкції «Laptop Migration» казали класти великі файли туди.

Нічого не вибухнуло одразу. Це найгірший вид помилок. Через тиждень інструменти безпеки позначили підпис приватного ключа в синхронізованому сховищі. Ключ не використали явно (наскільки могли довести), але організація мусила вважати його скомпрометованим. Провели ревізію доступів. Ротували ключі. Протирали authorized_keys на бастіонах. Люди були роздратовані паперовою роботою.

Виправлення не було героїчним. Оновили внутрішню інструкцію: експорти WSL вважаються чутливими; експорти повинні бути зашифровані у стані спокою; і ~/.ssh виключається з експорту, якщо це не явно потрібно. Також ввели апаратні ключі для доступу до продакшну, щоб експорти не містили довгоживучих секретів.

Міні-історія 2: Оптимізація, що обернулася проти

Інша команда прагнула «нульових підказок» у розробці. Фрази-паролі гальмували автоматизацію, казали вони, і операцій з репозиторієм було багато. Тому вони стандартизували незашифровані приватні ключі в WSL і сильно спільний базовий образ для прискорення нового персоналу. Виглядало круто у демо: clone, build, deploy — без перешкод.

Потім прийшло фіаско: базові образи почали копіюватися. Люди зіпаковували свої WSL-дистрибутиви для «швидкого шарінгу». Машина підрядника була скомпрометована комодитним малварем, який навіть не цілиться в SSH — просто скрінив файли, що виглядали як ключі. Раптом незашифровані ключі були саме тим, що потрібен нападник. Без брутфорсу. Без складності. Просто «знайди файл, використовуй файл».

Вони тижнями розплутували, який ключ мав доступ до чого. Найгірше було не миттєве усунення — а археологія: старі ключі, забуті хости, застарілі записи authorized_keys на довгоживучих серверах. «Оптимізація» перетворила операційний борг на множник інцидентів.

Після цього вони перейшли на фрази-паролі плюс TTL агента, і стандартизували ключі по сервісах з вузьким доступом. Продуктивність залишилась високою; підказки були керовані; поверхня ризику суттєво звузилась. Виявилось, можна бути швидким і безпечним. Просто не варто «бути швидким, бо ігноруємо проблему».

Міні-історія 3: Нудна, але правильна практика, що виручила

Команда платформи мала звичку, що виглядала прискіпливо: кожен інженер підтримував строгий ~/.ssh/config з іменованими хост-аліасами, явними файлами ідентичностей і IdentitiesOnly yes. Вони також пінували ключі хостів і відмовлялися відключати сувору перевірку ключів хоста, крім дуже контрольованих bootstrap-процедур.

Під час вікна реагування на інцидент їм довелося доступатися до фліту через бастіон. DNS частково ламався, і деяких інженерів переадресовувало на неправильні IP. Тут багато команд стають неуважними: «просто підключіться, потім полагодимо».

Але SSH відмовлявся на частину підключень через невідповідність ключів хостів. Неприємно? У момент — так. Цінно? Абсолютно. Це завадило людям вводити облікові дані і запускати команди на неправильних машинах, коли увага була розсіяна.

Команда підтвердила правильні ключі хостів через довірений канал, оновила записи де потрібно і лише потім перепідключилася. Та дисципліна врятувала їх від ускладнення інциденту. Надійність часто — це мистецтво відмовитись робити зручне, але неправильне.

Контрольні списки / покроковий план

Контрольний список A: Новий WSL-машин — безпечний SSH за 20 хвилин

1. Створіть ~/.ssh у файловій системі WSL Linux і заблокуйте права.
2. Згенеруйте Ed25519-ключ з фразою-паролем і пристойною кількістю KDF-раундів.
3. Створіть ~/.ssh/config з явними хост-аліасами і IdentitiesOnly yes.
4. Запустіть агента і завантажте ключ з TTL (ssh-add -t).
5. Підключіться один раз з ssh -vvv, щоб підтвердити вибір ключа й пінування хоста.
6. Проскануйте монтування Windows на випадкові копії приватних ключів.

Контрольний список B: Запобігання витокам через резервні копії та експорти

1. Визначте, чи дозволено експорти WSL містити секрети.
2. Якщо потрібно експортувати — зашифруйте tarball негайно й зберігайте тільки в погоджених місцях.
3. Віддавайте перевагу апаратно-захищеним ключам для продакшну, щоб експорти не містили коронних коштовностей.
4. Періодично робіть grep-сканування заголовків приватних ключів на шляхах Windows.

Контрольний список C: Ротація ключів без драм

1. Згенеруйте новий ключ з новим ім’ям файлу (не перезаписуйте відразу).
2. Додайте новий публічний ключ до віддаленого сервісу або authorized_keys.
3. Оновіть ~/.ssh/config, щоб він вказував на новий ключ для хост-аліасу.
4. Протестуйте з ssh -vvv і переконайтесь, що пропонується правильний ключ.
5. Видаліть старий ключ з віддаленого сервера, потім видаліть старий приватний ключ локально.
6. Очистіть ідентичності агента і перезавантажте лише новий ключ.

Ще один короткий жарт, бо ви заслуговуєте перерву: Ротація ключів схожа на чистку міжзубних проміжків — ніхто не любить, але альтернатива коштує набагато дорожче.

Поширені питання

1) Де мені генерувати SSH-ключі — у Windows чи у WSL?

Якщо ви в основному працюєте у WSL, генеруйте й тримайте ключі у файловій системі WSL Linux (/home). Тримайте їх у Windows лише якщо у вас є свідома стратегія Windows-агента під управлінням адміністраторів.

2) Чи безпечно покласти приватний ключ під /mnt/c?

Це поганий вибір за замовчуванням. Ви наслідуєте індексацію й синхронізацію Windows та нечітку мапу прав. Краще покласти приватні ключі у нативну файлову систему WSL.

3) Який найкращий тип ключа у 2026 році?

Для загального використання: Ed25519. Для високого ступеня гарантії: апаратно-захищені (FIDO2) ключі, де приватний ключ не підлягає експорту. RSA лише якщо потрібно підтримувати застарілі системи.

4) Чи справді мені потрібна фраза-пароль, якщо я використовую ssh-agent?

Так. Агент економить введення фрази. Фраза-пароль захищає, якщо файл ключа скопіювали. Вони вирішують різні проблеми.

5) Чому SSH каже, що права мого ключа занадто відкриті?

OpenSSH відмовляється використовувати приватні ключі, доступні іншим. На монтуваннях Windows права часто виглядають занадто відкритими. Перемістіть ключ у файлову систему WSL і застосуйте chmod 600.

6) Чому в терміналі працює, а в Git-клієнті — ні?

Ваш Git-клієнт може використовувати Windows OpenSSH і Windows-сховище ключів, а не WSL. Визначте, яка сторона повинна керувати SSH, і налаштуйте інструмент відповідно.

7) Чи безпечний форвардинг агента?

Відносно безпечний при обережному використанні на довірених хостах, ризиковий при широкому використанні. Форвардинг дозволяє віддаленим хостам використовувати ваш агент під час підключення. Не форвардьте в середовища, яким не довіряєте повністю.

8) Як дізнатися, який ключ пропонує SSH?

Використайте ssh -vvv і шукайте рядки типу «Offering public key» і шлях файлу ідентичності. Також використовуйте ssh -G, щоб побачити розв’язану конфігурацію.

9) Що робити, якщо я випадково закомітив приватний ключ?

Припустіть компрометацію. Ротуйте негайно, видаліть його з авторизованих місць і очистіть історію де можливо. Потім проскануйте на копії (CI-логи, форки, дзеркала).

10) Чи можна використовувати один ключ на всіх хостах, щоб спростити?

Можна, але не варто. Один ключ скрізь перетворює один витік на повний компроміс. Використовуйте кілька ключів за ідентичністю та обсягом доступу.

Висновок: наступні кроки, які ви справді можете зробити сьогодні

SSH-ключі в WSL не є апріорно ризиковими. Ризик виникає, коли ви ставитесь до WSL як до магічної межі безпеки і поводитесь з файлами ключів як з нешкідливою конфігурацією. Це облікові дані. Поводьтеся з ними як з обліковими даними.

1. Перемістіть приватні ключі з /mnt/c у домашній каталог WSL.
2. Переконайтесь, що кожен приватний ключ захищено фразою-паролем і має правильні права (700 для ~/.ssh, 600 для приватних ключів).
3. Використовуйте хост-аліаси в ~/.ssh/config з IdentitiesOnly yes, щоб потрібний ключ використовувався завжди.
4. Запустіть агента з TTL і тримайте мінімум завантажених ідентичностей.
5. Проскануйте папки на боці Windows на випадкові копії ключів, особливо експорти та «Downloads».

Зробіть ці п’ять речей — і ви уникнете найпоширеніших шляхів витоку. Ви теж будете налагоджувати швидше, бо поведінка SSH стане детермінованою, а не як привид у домі налаштувань за замовчуванням.