FirstVDS (у них есть блог на хабре) поставляет своим пользователям с вот таким вот содержимым файла /root/.ssh/authorized_keys:
Т.е. это даёт возможность получать доступ через SSH к арендуемым пользователями тем личностям, которые установили этот ключ. Комментарий в файле гласит, что этот ключ — для доступа техподдержки. При этом никакого оповещения пользователю не выдаётся. В базе знаний ответа тоже не нашлось. На сайте в разделе службы поддержки указаны телефоны. А также сообщается, что техническая поддержка клиентов осуществляется через личный кабинет. Решил зарегистрироваться и написать в техподдержку через личный кабинет для разъяснения этой ситуации. Получил вот такой ответ:
После последнего сообщения переписка была переведена в архив. Т.е., как я понял, была заблокирована для ответа. Вот такие у них отзывчивые менеджеры отдела Заботы о клиентах.
Т.е. мне предлагают стать клиентом (т.е. заплатить за продукт с лазейкой), а потом ответят, зачем его ставят мне и другим клиентам.
Насколько я могу видеть, файл ключа содержат сами образы виртуалок. И переустановка ОС из предоставляемого хостером образа ситуацию не исправляет. Замечено как минимум на образах с Ubuntu.
Один из вариантов решения — удаление файла /root/.ssh/authorized_keys
UPD
Привожу справедливые слова SilverFire из комментария относительно того чем плохи такие ключи:
Само наличие ключа — не проблема. Проблема в том, что он один на всех суппортов и не ограничен по IP. Что в этом плохого:
- раз нет ограничения по IP, нет и единого access-сервера, откуда суппорты имеют право ходить на клиентские сервера, причем желательно по локальным management IP адресам;
- невозможно быстро лишить сотрудника прав доступа. Придется обходить все сервера и менять публичный ключ, плюс раздавать всем действующим сорудникам новый приватный ключ;
- все сотрудники ходят под одним ключом и логинятся рутом. Если кто-то налажал и не признается — почти нереально выяснить, кто именно это был;
- сотрудники имеют на руках приватный ключ и могут случайно (или неслучайно) его скомпрометировать. Так как нет ограничения по IP, кто угодно может им воспользоваться и, снова таки, будет непонятно кто из сотрудников стал виновником.
Оставлять на всех виртуалках один и тот же ключ доступа тем страннее, что есть и другие более безопасные варианты экстренного доступа. Некоторые панели управления (например, SolusVM) позволяют в случае утери пароля рута, задать новый пароль. Если же проблема не в забытом пароле, а в неверных настройках iptables или настройках сетевого адаптера — подключение по VNC к специальной машине резервного доступа. При этом доступ к виртуалке такой же как если бы был физический доступ к ней. Т.е. сработает даже если произошли проблемы у сетевого адаптера (неправильно настроен или ещё что-то).
Автор: shanker
