Т.е. это даёт возможность получать доступ через SSH к арендуемым пользователями VDS тем личностям, которые установили этот ключ. Комментарий в файле гласит, что этот ключ — для доступа техподдержки. При этом никакого оповещения пользователю не выдаётся. В базе знаний ответа тоже не нашлось. На сайте в разделе службы поддержки указаны телефоны. А также сообщается, что техническая поддержка клиентов осуществляется через личный кабинет. Решил зарегистрироваться и написать в техподдержку через личный кабинет для разъяснения этой ситуации. Получил вот такой ответ:
После последнего сообщения переписка была переведена в архив. Т.е., как я понял, была заблокирована для ответа. Вот такие у них отзывчивые менеджеры отдела Заботы о клиентах.
Т.е. мне предлагают стать клиентом (т.е. заплатить за продукт с лазейкой), а потом ответят, зачем его ставят мне и другим клиентам.
Насколько я могу видеть, файл ключа содержат сами образы виртуалок. И переустановка ОС из предоставляемого хостером образа ситуацию не исправляет. Замечено как минимум на образах с Ubuntu.
Один из вариантов решения — удаление файла /root/.ssh/authorized_keys
UPD
Привожу справедливые слова SilverFire из комментария относительно того чем плохи такие ключи:
Само наличие ключа — не проблема. Проблема в том, что он один на всех суппортов и не ограничен по IP. Что в этом плохого:
- раз нет ограничения по IP, нет и единого access-сервера, откуда суппорты имеют право ходить на клиентские сервера, причем желательно по локальным management IP адресам;
- невозможно быстро лишить сотрудника прав доступа. Придется обходить все сервера и менять публичный ключ, плюс раздавать всем действующим сорудникам новый приватный ключ;
- все сотрудники ходят под одним ключом и логинятся рутом. Если кто-то налажал и не признается — почти нереально выяснить, кто именно это был;
- сотрудники имеют на руках приватный ключ и могут случайно (или неслучайно) его скомпрометировать. Так как нет ограничения по IP, кто угодно может им воспользоваться и, снова таки, будет непонятно кто из сотрудников стал виновником.
Вот, кстати, решение от другого хостера, которое отвечает этим требованиям. Файл ключа у них выглядит так:
from=«1.2.3.4,3.4.5.6» ssh-rsa AAAAB3Nza.....bAN== support_andrey
from=«1.1.1.1,2.2.2.2» ssh-rsa AAAAB3Nza.....vbz== support_ivan
Т.е. тут хотя бы ограничение по IP, с которых можно подключаться к виртуалке. И разные ключи для разных сотрудников. Правда, и этот хостер не сообщает ничего клиентам.
Оставлять на всех виртуалках один и тот же ключ доступа тем страннее, что есть и другие более безопасные варианты экстренного доступа. Некоторые панели управления VDS (например, SolusVM) позволяют в случае утери пароля рута, задать новый пароль. Если же проблема не в забытом пароле, а в неверных настройках iptables или настройках сетевого адаптера — подключение по VNC к специальной машине резервного доступа. При этом доступ к виртуалке такой же как если бы был физический доступ к ней. Т.е. сработает даже если произошли проблемы у сетевого адаптера (неправильно настроен или ещё что-то).
Комментарии (46)
Nikon_NLG
19.01.2016 21:24+11Не хочу вас расстраивать, но если есть доступ к хост-системе, к гостевой виртуалке можно достучаться и без ключа.
Если бы они вам патченый ssh ставили, тогда другое дело.
kekekeks
19.01.2016 21:27В случае с KVM/Xen немного сложнее, т. к. виртуализация не контейнерная, а фс виртуалке обычно предоставляют блочное устройство, а не кусок файловой системы хоста.
Nikon_NLG
19.01.2016 21:38+1Понятно что есть нюансы, но в целом задачу решить можно.
Хотя, насколько я помню, они и dedicated с того же образа разворачивают, по крайней мере я ключи эти сразу вычищал, и добавлял только по мере необходимости.
shanker
19.01.2016 21:32-6Технически да. Но, насколько я знаю от людей исследовавших этот вопрос, в зависимости от типа виртуализации это может быть как не очень сложно так и не очень легко. Например, с OpenVZ — легко. KVM или XEN — существенно легче.
Да и одно дело — сам хостер при оказании техподдержки имеет доступ к внутренностям виртуалок. Другое дело — если этот ключ попадёт в нехорошие руки. Уволенный сотрудник утащит с собой и кому-нибудь передаст или ещё чтоNikon_NLG
19.01.2016 21:39+2Ключи — дело тонкое. Может они их каждый месяц меняют. В любом случае я их сразу удалял.
hyperwolf
19.01.2016 22:20+1Зайти с хоста в контейнер OVZ очень просто, в Xen — сложнее, но не более того.
shanker
20.01.2016 00:18-1Ошибка в моём комментарии выше. Имелось ввиду, что с OpenVZ — легко. KVM или XEN — существенно сложнее.
shanker
20.01.2016 00:55+2Nikon_NLG
а какая разница в каком виде оставили доступ техподдержке (или кому-то ещё): в виде ключа или как патченные бинари? И о том, и о другом пользователю не сообщалось. И то, и другое позволяет получать не согласованный с конечным пользователем доступ. Вас устроит секретный ключ от двери Вашей квартиры от производителя? Ну, якобы для саппорта или «ой, после дебага забыли убрать»
wholeman
20.01.2016 09:03Очень большая. Чтобы найти и убрать ключ достаточно пары простых команд, если знать, где искать, а чтобы найти патченый бинарник придётся сравнивать с оригинальным, что сложнее на порядки.
merlin-vrn
20.01.2016 09:15А как же sudo debsums -c, rpm -V и аналоги?
wholeman
20.01.2016 09:29Честно говоря, не разбирался с этим вопросом. Их сложно пропатчить/перенастроить, чтобы не ругались на изменённые бинарники? (Установка своих версий уже намного сложнее обнаружения и удаления /root/.ssh/autorized_keys.)
merlin-vrn
20.01.2016 09:40Ну, можно впендюрить свои репозитории, но в целом — это гораздо больше работы, чем просто вставить ключ.
vsb
20.01.2016 09:45+4Вы арендуете номер в гостинице. От вашего номера ключи есть и у администратора, и у уборщицы. Это правильная аналогия.
merlin-vrn
20.01.2016 09:51… и при этом все полагаются на эти ключи, а не на специально спроектированную уязвимость замка номера. Замок хороший.
zabbius
20.01.2016 11:19+1Только надо учесть, что двери гостиницы выходят на улицу и попробовать открыть дверь ключом может любой посторонний человек, при этом у всех номеров одинаковые ключи.
При правильной аналогии с гостиницей должно быть ограничение на доступ только из сети саппорта. И обязательное логирование. Ну и, конечно же, ключи должны отличаться.
shanker
20.01.2016 11:36Сотрудники гостиницы это скрывают? И на уточняющие вопросы реагируют отговорками?
botaniQQQ
19.01.2016 21:25+1VM Manager -> SSH Keys
Наверняка там этот ключ есть. И при каждой переустановке он будет автоматически добавляться.
Попробуйте сгенерировать свой ключ, вставить туда и переустановить сервер. Если он не изменится, то вероятно у них какие-то неполадки и он не подхватывается.
gtbear
19.01.2016 21:42+18Если человек не меняет сразу ключи авторизации то процентов на 90 ему в дальнейшем понадобится помощь технической поддержки. А раздавать направо и налево пароли это плохой вариант. Вобщем нехорошо конечно что не уведомляют пользователей, но заголовок слишком желтый.
SilverFire
19.01.2016 23:53+14Само наличие ключа — не проблема. Проблема в том, что он один на всех суппортов и не ограничен по IP. Что в этом плохого:
- раз нет ограничения по IP, нет и единого access-сервера, откуда суппорты имеют право ходить на клиентские сервера, при чем желательно по локальным management IP адресам;
- невозможно быстро лишить сотрудника прав доступа. Придется обходить все сервера и менять публичный ключ, плюс раздавать всем действующим сорудникам новый приватный ключ;
- все сотрудники ходят под одним ключом и логинятся рутом. Если кто-то налажал и не признается — почти нереально выяснить, кто именно это был;
- сотрудники имеют на руках приватный ключ и могут случайно (или неслучайно) его скомпрометировать. Так как нет ограничения по IP, кто угодно может им воспользоваться и, снова таки, будет непонятно кто из сотрудников стал виновником.
achekalin
20.01.2016 00:28+3А кто мешает, вообще говоря, свежеполученную машину проверять на подобные вещи просто на автомате? Не надо весь файл удалять, просто убираем из него ненужные ключи, и нет проблемы.
В свежесданном сервере, если подумать, ключ неплохо иметь: умный юзер удалит его, а глупый и не заметит, но именно глупый, с боле высокой вероятностью, придет однажды за помощью, рода «я пароль рута сменил, и теперь с ним не могу зайти в систему».
Другой вопрос, что а) предупреждать надо все же, и б) немного топорный метод оставить один и тот же ключ во всех VPS-ках. Как справедливо подметили, сотрудник ТП, унесший с собой ключ, может много что натворить на сотнях машин. Не то чтобы ТП любит подобное делать, но люди разные, а если еще это уволенный, обиженный на начальство — мало ли что? Приделали бы авторизацию по LDAP какому-нибудь, чем не вариант?khim
20.01.2016 02:22Почему не сделать как у людей? У Linode проблема решается просто: в случае необходимости грузится другой Linux, куда основаня файловая система монтрируется в chroot и, если нужно, меняется пароль и делаются любые другие манипуляции.
Да, для этого виртуалку придётся «погасить» и перезагрузить. Что, если вы немного подумаете — является скорее плюсом, чем минусом.merlin-vrn
20.01.2016 08:42Одна контора меня так удивила. В арендованном сервере меняли сдохший винт. Ну, вырубили машину, поменяли, врубили (хотя вообще AHCI можно было и в горячую поменять), она поднялась, стала запускаться основная система, запустила свои виртуалки. Казалось бы, молодцы, отчитайтесь клиенту, и свободны.
Нет, они снова перезагрузили машину в rescue-систему только для того, чтобы включить новый диск в soft-raid и запустить процесс синхронизации. На вопрос «зачем, это можно ведь было сделать из работающей системы, и даунтайм был бы 15 минут вместо 2 часов» не смогли ответить (ответ был в духе «ну да, это мы зря»). У них даже доступ был чтобы это сделать, не говоря уже о том, что мне было нужно только чтобы физически поменяли винт, уж раид-то починил бы сам.
Нет уж, лучше без rescue-систем, если они будут использоваться так.symbix
20.01.2016 09:44+4Да ладно, это мелочи. Бывают поразительные случаи заботы о клиентах. Припоминаю два.
Первый (было года три назад). У меня есть привычка перевешивать ssh на нестандартный порт — просто чтобы в логах любители сканирования и перебора по словарю не мешались (про fail2ban знаю, одно другому не мешает). У одних молодцов сработал мониторинг, они не поняли, что произошло, решили, что все накрылось (!), сняли бэкап виртуалки и переустановили (!!), после чего написали письмо о своем отважном подвиге. Попросил больше никогда ничего не трогать и убрать свои кривые руки подальше. :) Унес бы от них подальше, да клиент не захотел, у него там скидки были.
Другой случай был с выделенным сервером, в давние времена еще, когда про nginx в основном было известно только в ex-USSR. У других молодцов был мониторинг, который зачем-то проверял наличие заголовка Server: Apache* в ответе. Эти молодцы зашли на сервер с консоли, обнаружили отсутствие апача, после чего его поставили обратно, обнаружили, что он запуститься не может (80-й порт немножко занят), после чего догадались написать мне на емейл и спросить. От них сразу унес. :)
achekalin
20.01.2016 10:21+1Ответ один — «квалификация». И тех, кто систему управления ВМ-ками делает, и арендаторов самих ВМ-ок.
Ведь не секрет, что многие берут VPS из-за цены и возможности делать на машине то, что хочешь, да еще из-за выделенного IP, что позволяет по цене аренды shared-хостинга (который часто настроен во времена оные, и особо не поддерживается) получить и места побольше, и https нормально настроенный, и прочие плюшки.
При этом многие арендаторы таких VPS не особо сведущи, и многое выясняют методом тыка, заодно дергая ТП. И ответ «перезагрузитесь в rescue-систему, чтобы мы могли зайти и вам помочь» вроде бы и логичен, только и для этого от клиента нужна квалификация. Кроме того, мало ли какие у юзера проблемы, иногда они связаны именно с той ОС, которая на машине установлена, тут уже не ответишь в стиле «подцепил диск клиента — и ответил, что я ваши данные вижу, так что настройте ОС как надо».
В общем, возможность иметь кнопку «пустить на сервер специалистов ТП», которая бы видимым и понятным образом разрешала конкретным учеткам зайти на машину и что-то сделать — она не лишняя. При этом таким учеткам надо иметь возможность сменить пароль/ключ, и надо иметь возможность их включать.
Как вариант — ключ ТП в файлике, но приведенный в негодность. Если совсем задница, и надо звать ТП — приводим ключ в рабочее состояние (rescue как раз выручит), и тогда уже ТП подключаются. Остается решить проблему массовой замены этих ключей, если ключ скомпрометирован — и уже хоть какое-то решение у нас есть.
silention
20.01.2016 01:13+2тоже не вижу проблем. Мне кажется вы драматизируете. Ключ в руте это не ахти какой бэкдор — тот кому он мешает(профессиональный админ), заметит это сразу и уберет, а для остальных такие ключи и подкладываются, потом пользователи которые взяли впс и не знают что с ним делать мучают ТП, с ключем удобно.
Поменять ключ на всех системах 2 минуты хоть for хоть puppet/ansible/chef.shanker
20.01.2016 01:41Если саппорт хочет облегчить себе жизнь и не желает переходить на более адекватные меры экстренного доступа (типа SolusVM ли аналоги), то пусть будет любезен:
1. Настроить доступ по ключу исходя из советов этого комментария
2. Оповестить пользователей о том, что такая штука внедрена. И уж тем более не закрывать тикет, если заводятся разговоры о вещах, которые пользователю не сообщили заранее. Не понимает о чём речь — пусть уточнит что конктерно пользователь имеет в виду. Не хватает компетенции — пусть переправляет более компетентным людям.merlin-vrn
20.01.2016 08:36+1Ключ — это, пожалуй, наиболее адекватная мера экстренного достпа. Вот что вы там назвали — это как раз костыль и извращение. И к тому же, подобные извращения обычно всё равно используют ключи для выполнения функций… ну а потому что как ты ещё заберёшься в виртуалку, когда такая потребность возникла у клиента?
shanker
20.01.2016 11:49Можете уточнить чем Вам не нравятся варианты типа SolusVM?
Я встречал такой вариант (не буду утверждать, что конкретно у SolusVM): через панель управления и тебе бекапы вируталки, и создание нового ключа рута (если вдруг забыл или взломали). И VNC — если виртуалка по сети недоступна. Забыл пасс на панель управления — ссылка на восстановление доступа приходит на почту. Почтовый акккаунт был на бесплатном почтовом сервисе и уже удалён — восстановление по коду СМС, на привязанный при регистрации телефон. Тем самым взаимодействие с поддержкой сведено к минимуму. Ну, а если забыл пароль и на панель управления, и на почту и телефон украли… Тогда это очень невезучий клиент, и вопросы с ним нужно решать в отдельном порядке. Правда, такому клиенту придётся ещё подтвердить, что он — это он. Если он ещё и паспорт потерял — то вряд ли любая техподдержка ему чем поможет.
pyrk2142
20.01.2016 01:58Некоторое время назад я столкнулся с куда более серьезной проблемой у хостинг-провайдеров: значительный процент (более 50%) хостеров используют панели управления, системы биллинга, которые либо сами содержат серьезные уязвимости (CSRF, XSS и т. д.), либо настроены неправильно. Еще больше хостеров подвержены менее серьезным уязвимостям. Получилось собрать достаточно много интересного материала, возможно напишу об этом статью, если это кому-то интересно.
amarao
20.01.2016 03:57+11Ох, как человек, работающий в хостинге — всё сложно.
Это одно из технических решений (куда более валидное, чем известный рутовый пароль, хранимый в БД панели управления). И это одно из решений проблемы, решения которой не существует — как предоставить сервис и свободу пользователю одновременно. В принципе, ключ никуда не спрятан и будет виден любому пользователю, настраивающему машину.
Рассчитывать же на приватность VDS'ки в объёме большем, чем добрые намерения поставщика не стоит. В большинстве сред виртуализации существует техническая возможность получить полный доступ к файловой системе клиента даже без остановки клиента (да, можно через loop/ro смонтировать уже смонтированный внутри виртуалки диск — не очень надёжно, зато незаметно).
Более того, по понятным причинам, даже локальные шифрованные тома — это фикция — ибо ключ из дампа памяти выковырять не так уж и сложно, а запретить делать дамп памяти или хотя бы обнаружить это, гость, очевидно, тоже не может.
Что касается «дурной практики» — зависит от того, как этот ключ используется. Если делать по совести — ssh-агент на access-сервере с pam-авторизацией. На практике никто заморачиваться не будет.
Для сравнения — kimisufi, например, вообще оставляет на виртуалках запущенный сервер статистики, который в т.ч. позволяет remote code execution с серверов самого kimisufi.
grossws
20.01.2016 10:42Иногда такие ключи ещё используются для массовых обновлений уязвимых пакетов. Видел такое при shellshock и heartbleed: зашел робот, обновил, перезапустил nginx/apache.
Xelonic
20.01.2016 04:23+6На самом деле это только внешне выглядит что ключ один на всех, однако это совсем не так и в компании работают не дураки.
Приватный ключ находится в одном единственном месте, на так называемом сервере досупа, ни один сотрудник компании (кроме самых ответственных лиц), не имеет к нему прямого доступа. сотрудники попадают на сервер доступа по своему ключу, соответсвенно увольнение сотрудника влечет за собой просто удаление его ключа с сервера доступа. Доступ к этому серверу ограничен только из офиса компании. Далее с помощью специальной команды сотрудник может залогинится на сервер клиента.
Кроме того на сервер доступа ведется учет кто и куда логинился, а так же сколько провел времени на сервере клиента.
Более подробно о том как все устроено можно почитать в документации от ISPsystem — http://doc.ispsystem.ru/index.php/Установка_сервера_для_доступа_поддержки
PS
Если кого-то не устраивает сам факт наличия ключа, просто удалите его, тем более если не планируете пользоваться услугами поддержки, никаких проблем это не вызовет.
artemirk
20.01.2016 04:42Выводы в корне все не верные. На сколько я видел эту систему. Ни один сотрудник не имеет на руках приватного ключа. Сотрудник имеет доступ к сервису. Далее передается имя или ip сервера. И сервис пробрасывает ssh соединение до VDS.
При этом сам ключ защищен будь здоров. И получить его даже будучи сотрудником не возможно.
Права на доступ к этому сервису рулятся уже по честному кому и что дать. Кого и в какой vds пускать. Где то в ispsystem.
upd: пока отвлекся Xelonic все уже написал.
medved6216
20.01.2016 07:44Один из вариантов решения — удаление файла /root/.ssh/authorized_keys
Только не делайте так, если вы используете свой ключ для входа. Можно просто удалить или закомментить ключ тех.поддержки — "#" перед ключом.
nano /root/.ssh/authorized_keys
На всякий случай отключил их ключ ;) При обращении в ТП, при надобности включу.
artemirk
20.01.2016 08:27+3Отключить это можно прямо в панели ISPmanager у вас на VDS.
WST
20.01.2016 09:27Не все её ставят, многие предпочитают содержать сервер в чистоте от таких штук.
Тогда проще убрать бэкдор, удалив нужную строку руками.
Но всё равно не очень хорошо, что хостер оставляет такой бэкдор, нигде об этом открыто не заявляя.
wholeman
20.01.2016 11:26А если эту галочку снять, повторно включить уже не получится — доступа-то к /root/.ssh не будет?
dmiceman
20.01.2016 11:20-1У OVH точно такая же ерунда. Причем, там ключ у рута появляется при установке из их образа на дедике. Качественный обход проблемы прост — ставить дедик из своего образа, подключившись по IPMI.
barker
Одно непонятно: почему юзер сам не написал, зачем он пожелал не раскрываться?
DVORYAN
Некоторые беспричинно скрываются, у кого-то жизненный опыт был негативный.
В любом случаи, тех.поддержка поступила неправильно. Если он знает о подобной лазейки, то доступ у него есть. Таким образом тех.поддержка просто посчитала, что на вопрос отвечать не надо.
Да и даже если доступа нет и инфа пришла от третьих лиц или бывших клиентов, разве не надо объективно объяснить человеку данную причину?
creker
Менеджер по работе с клиентами справедливо послал непонятно откуда взявшегося человека, который даже этим клиентом и не является. Поступили правильно. Хорошо хоть после такого тона не послали прямо конкретно по-русски. Скорее всего есть четкие правила, что и кому можно сообщать. Не клиент — до свидания, мало ли чего ты там выдумал. Если найдена реальная уязвимость, а статья явно на это не походит, по крайней мере в текущем желтеньком виде, то я уверен, что есть куда более уместные каналы связи, через которые об этом можно сообщить.
igordata
Нет, не правильно. Пишет человек узнать об услуге. Никакой конкретной информации о конкретном клиенте он не спросил. Его должны были переключить с саппорта на продажников, а там он бы уже пробивался к кому-то уполномоченному или должен был бы указать клиентский аккаунт, от лица которого он говорит.
В любом случае разговаривать в чатике это бессмысленная затея. Максимум на что можно рассчитывать, это что вопрос передадут кому-то. Проще было сразу написать на несколько имейлов и подождать объяснений.
shanker
Из общедоступных каналов связи на сайте — почта отдела продаж и телефон в Москве. Можно, конечно, было звонить по межгороду. Но вот тогда не сделать скрина переписки. Саппорт как раз в личном кабинете после регистрации. Из-за чего я и зарегистрировался. Но от чего-то решили меня свести с отделом Заботы о клиентах
wholeman
Это — не инфа, а наезд. Ответ вполне соответствует вопросу.