# Намиране и премахване на непознати SSH ключове

> Проверка на authorized_keys: къде стоят SSH ключовете на сървъра, как да разпознаете чужди записи, да ги премахнете безопасно и да втвърдите SSH достъпа след това.

Източник: https://phpsos.de/bg/blog/ssh-schluessel-pruefen/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** За да намерите непознати SSH ключове, трябва да проверите всички файлове authorized_keys на сървъра, не само този на root. Установете със `sshd -T` кои файлове чете Вашата SSH услуга, изброете пръстовите отпечатъци на всеки ключ и ги сверете с познатите ключове. Чуждите записи първо запазете, после премахнете и след това втвърдете достъпа.

## Ключът, който преживява всяка смяна на парола

След инцидент много оператори сменят първо всички пароли. Срещу една от най-незабележимите задни вратички това не помага: допълнителен публичен ключ във файл `authorized_keys`. Който притежава подходящия таен ключ, влиза без парола, докато някой не намери реда.

Непознатите SSH ключове затова спадат към признаците, които след изпълнение на код трябва да се проверяват винаги. За PHP2Shell няма публикувани, потвърдени Indicators of Compromise; разпознаването се основава на анализ на поведението. Чуждият ключ не е специфично доказателство за PHP2Shell, но е ясен знак, че някой е искал трайно достъп. Други признаци описва [Компрометиран ли съм вече?](https://phpsos.de/bg/php2shell/bin-ich-gehackt-anzeichen/).

## Къде стоят SSH ключовете на сървъра

OpenSSH чете според документацията по подразбиране два файла в домашната директория на всеки потребител: `.ssh/authorized_keys` и `.ssh/authorized_keys2`. Вторият често се забравя. Настройката може да се променя, а с `AuthorizedKeysCommand` сървърът може дори да получава ключове от външна програма. Затова проверете първо какво наистина важи на Вашия сървър:

```bash
# Извеждане на ефективната SSH конфигурация (само за четене)
sudo sshd -T | grep -iE '^(authorizedkeysfile|authorizedkeyscommand|permitrootlogin|passwordauthentication|pubkeyauthentication)'

# Допълнителни конфигурационни файлове и Match блокове
ls -la /etc/ssh/sshd_config.d/ 2>/dev/null
sudo grep -rn -iE '^\s*(Match|AuthorizedKeys)' /etc/ssh/
```

Особено място е домашната директория на потребителя на уеб сървъра. При Debian и Ubuntu това за `www-data` е често `/var/www`. Ако тази директория е достъпна за запис от PHP, вмъкнат код може да създаде там `.ssh/authorized_keys`. Дали влизането тогава успява, зависи от login shell и от SSH настройките, но самият файл вече е тревожен знак.

Не всеки непознат запис е злонамерен. Инструменти за deployment, услуги за резервни копия или бивши доставчици на услуги оставят собствени ключове. Такива записи трябва обаче да имат известен собственик и цел.

## Проверка на authorized_keys: стъпка по стъпка

Следните команди не променят нищо. Те изброяват всички файлове с ключове на потребителите и показват пръстовия отпечатък на всеки ключ:

```bash
# Всички файлове authorized_keys в домашните директории на всички потребители
getent passwd | cut -d: -f1,6 | while IFS=: read -r user home; do
  for f in "$home/.ssh/authorized_keys" "$home/.ssh/authorized_keys2"; do
    [ -f "$f" ] && echo "== $user: $f" && sudo ls -la --time-style=full-iso "$f"
  done
done

# Показване на пръстови отпечатъци и коментари на един файл
sudo ssh-keygen -lf /root/.ssh/authorized_keys

# Други файлове с ключове извън обичайните места
sudo find / -xdev -name 'authorized_keys*' 2>/dev/null
```

Преминете през резултата с този контролен списък:

1. **Принадлежи ли всеки ключ на позната личност или позната услуга?** Сверете пръстовите отпечатъци, не само коментара.
2. **Има ли потребител ключ, който изобщо не бива да има?** Например потребителят на уеб сървъра, акаунти на база данни или услуги.
3. **Стоят ли опции пред ключа?** Записи с `command=` изпълняват при всяко влизане фиксирана команда. Това е легитимно за резервни копия, но е и скривалище.
4. **Кога файлът е променен за последно?** Дата на промяна след 17.10.2026 г., първия според съобщения в медиите наблюдаван опит за нападение с PHP2Shell, заслужава особено внимание. Времевите печати обаче могат да се фалшифицират.
5. **Съвпадат ли собственикът и правата?** Файл, принадлежащ на друг потребител от този на домашната директория, прави впечатление.

## Безопасно премахване на чужди ключове

Преди да изтриете ред, запазете файла с времеви печат и контролна сума извън сървъра. Отбележете пръстовия отпечатък на чуждия ключ. Той помага по-късно при въпроса дали същият ключ се появява и на други сървъри, например при агенция с много клиентски системи.

Проверете освен това протоколите за влизане. В `/var/log/auth.log` (Debian, Ubuntu) или `/var/log/secure` (RHEL семейство) SSH услугата протоколира успешните влизания с пръстовия отпечатък на използвания ключ. Така виждате дали чуждият ключ вече е бил използван и от кой адрес.

Мислете и за обратната посока. Ако на сървъра има тайни ключове, например под `~/.ssh/id_*` за deployment или резервни копия, нападателят е могъл да ги копира. С тях той евентуално достига други сървъри, Git хранилища или цели за резервни копия. Такива ключове след проникване се считат за изразходвани: създайте нови ключове и премахнете старите на всички целеви системи.

Чуждият ключ рядко е единствената следа. Който го е оставил, е имал права за запис и вероятно е настроил други пътища, например cron задачи или допълнителни акаунти. Проверете затова и [скритите cron задачи](https://phpsos.de/bg/blog/cronjobs-als-hintertuer/) и [чуждите админ акаунти](https://phpsos.de/bg/blog/fremde-admin-konten-finden/). Ако нападателят е имал права на root, ново изграждане на сървъра често е по-надеждно от почистването.

> **Важно:**
> Премахвайте чужди ключове едва когато PHP е на отстранено състояние (8.5.12, 8.4.27, 8.3.36, 8.2.35 или потвърден backport) и всички worker-и са рестартирани. Иначе нападателят може да впише ключа веднага отново през същата уязвимост.

## Втвърдяване на SSH достъпа след това

След почистването си заслужава кратко втвърдяване. Повечето точки се реализират бързо, но винаги трябва да се тестват с втора, отворена сесия, за да не се заключите.

| Мярка | Настройка или действие |
|---|---|
| Влизане само с ключ | `PasswordAuthentication no` |
| Забрана за директно влизане като root | `PermitRootLogin no`, работа през лични акаунти със sudo |
| Изключване на втория файл с ключове | `AuthorizedKeysFile .ssh/authorized_keys` |
| Ограничаване на ключовете по произход | Опция `from=` пред ключа, например за сървър за резервни копия |
| Ограничаване на служебните ключове | Опция `restrict` и фиксиран `command=` за автоматизация |
| Потребител на уеб сървъра без влизане | Login shell `nologin`, без `.ssh` в домашната директория |

Водете освен това списък на всички оправомощени ключове със собственик и цел. Когато сътрудник или доставчик на услуги напусне, ключът му се премахва на всички сървъри. Без този списък следващата проверка отново е детективска работа. Признати насоки за втвърдяване на SSH съдържат и CIS Benchmarks.

## Как помага PHP SOS конкретно?

- Установяваме кои файлове с ключове Вашата SSH услуга наистина чете и проверяваме всеки запис спрямо познатите собственици.
- Запазваме находките и анализираме протоколите за влизане, за да изясним дали чужд ключ е бил използван.
- Почистваме ключове, акаунти и cron задачи в правилния ред и преди това затваряме уязвимостта.
- В рамките на [втвърдяването на сървъри](https://phpsos.de/bg/leistungen/server-haertung/) реализираме SSH настройките и въвеждаме управление на ключове със списък на собствениците.


## Често задавани въпроси

**Как разбирам дали един SSH ключ е чужд?**  
Всеки ключ има пръстов отпечатък и обикновено коментар в края на реда. Сверете пръстовите отпечатъци с ключовете на Вашите сътрудници и доставчици на услуги. Коментарът сам не доказва нищо, защото се избира свободно и може да се фалшифицира.

**Помага ли смяната на root паролата?**  
Срещу вмъкнат ключ - не. Влизането с ключ не изисква парола. Затова самите файлове authorized_keys трябва да се проверят и почистят.

**Защо потребителят на уеб сървъра може да има SSH ключ?**  
Потребителят на уеб сървъра има собствена домашна директория, при Debian и Ubuntu често /var/www. Ако там има .ssh/authorized_keys и акаунтът има login shell, влизане като този потребител е възможно. При директория на уеб сървъра с права за запис вмъкнат PHP код може да създаде такъв файл.

**Какво е authorized_keys2?**  
По-стар втори файл, който OpenSSH според стандартната настройка също чете. Много ръководства за проверка го пропускат. Проверете със sshd -T кои файлове Вашият сървър действително оценява.

## Източници

- [BSI: Указания за инциденти с ИТ сигурността](https://www.bsi.bund.de/)
- [php.net: Съобщения за сигурност](https://www.php.net/)
- [CIS Benchmarks](https://www.cisecurity.org/cis-benchmarks)