Мне не удалось проникнуть на сервер с .bashrc, возможно мой эксперимент не достаточно чистый.
Сделал лабораторную VDS. Предлагаю попробовать вместе найти где я не прав. Ключ в конце статьи.
Как я уже писал выше не на всех «машинах» куда я хожу я полноправный владелец. Добавить строку authorized_keys меньшее зло для владельца сервера. Наши клиенты не обрадуются если я буду менять им настройки openssh которые они с заботой сделали.
Я думаю ваш вариант тоже хорошее решение. Мы условно еще привязаны к ISPmanager у него есть возможность «пропихнуть» публичный ключ в лицензию и далее владелец сервера одной кнопкой в панели «пускает» саппорт.
Этот вариант уже был и он работал. Далее наша действительность развивалась от него.
Это мои сладкие сны когда у меня будет проект без legacy и я смогу выбрать все технологии и даже ОС на сервере :)
artem:~ artem$ssh root@149.154.64.101
Last failed login: Mon Mar 19 08:31:53 EDT 2018 from 58.242.83.24 on ssh:notty
There were 23 failed login attempts since the last successful login.
Last login: Mon Mar 19 08:31:04 2018 from 188.120.252.193
bashrc Connection DENY
Connection to 149.154.64.101 closed.
artem:~ artem$ssh root@149.154.64.101 «bash --noprofile --norc»
bashrc Connection DENY
Проблема что не все оборудование бывает «мое». Объяснить клиенту что ему сейчас надо настроить свой ssh сервер, сложнее чем дать ему команду cat >authorized_keys. После чего саппорт может помочь клиенту и вырезать ключ или договориться что ключ останется для будущих обращений.
Подход сертификатов прекрасен если все сервера в личном ведении и ты их сам раскатываешь ансибло-чефом.
Артем маленько не по теме. Но все же глядя на схемы возник вопрос у вас нигде не было статьи как вы менеджите свои железные сервера. Наверняка есть система по их учету, установке и диагностике.
Михаил Scalar, всегда очень больно обижать настоящих добрых клиентов.
Как вы поступаете в этом варианте если антиспам система блокирует добропорядочный аккаунт. Например взломанный, или возможно есть спамеры которые бодаются что их сообщение «выплаты без смс» вообще не спам и друзья хотят их видеть :)
Есть какая то выборочная ручная проверка заблокированных? Или вероятностные оценки системы никогда не ошибаются? Вопрос только в выборе правильной вероятности для блокировки.
Я с вами абсолютно согласен. Но по факту поменять надо было кусок трубы под ванной, из которого бежала вода и который не видно никому. Да это огорчительно что сантехник ко мне зашел и поменял трубу, уведомив меня по факту. Но я благодарен ему за то что все мое имущество осталось сухое и я не должен делать ремонт соседям.
Далее наш разговор упрется в разные токи зрения и как мы будем называть трубу/кран. Я принял решение не продолжать дельнейший спор. Но спасибо за то что озвучили свое мнение и ответили на мой вопрос.
Я уверен что вас есть другие решения мимо хостинг компаний.
И кстати насколько это правильно что повар в ресторане трогает продукты которые вы будете есть?
Особенность технологии. Как и в ресторане.
Если вам требуется единоличный доступ к данным то надо ставить сервер под стол в офисе или в закрытую стойку в цоде (ключи должны быть у вас). Хостер точно так же может получить доступ к данным с выделенного сервера.
Хотя есть один дешевый способ с некоторыми минусами. Шифрование раздела с данными. В этом случае после каждого ребута необходимо будет производить действия для рашифровки и мириться с некоторым оверхедом по скорости.
Хостер по факту сам не совсем хочет доступ к данным пользователя. Тогда можно будет разводить руки на запросы из МВД и в случае проблем внутри VDS всегда будет понятно что сотрудники хостера не при чем.
Я думаю в вашем случае некорректно отрабатывает модуль отображения этой страницы. На официальном сайте в этих обновлениях есть подробные описания: https://www.ispsystem.com/software/ispmanager/changelog
Недавно изучал подобные возможности «из коробки».
По факту есть возможность у saltstack указываешь md5 и путь до файла. И начинается контроль изменения при запуске (хотя он может и просто переписывать).
И у monit есть возможность следить чтобы md5 не менялось.
Так же хорошо использовать etckeeper который по умолчанию отслеживает изменения в /etc но его можно и натравить на другие папки.
Все остальные пути упираются в сриптописательство с inotify, git, md5 кому что более нравится.
Проблема в том что этим должен заняться админ сервера, которому понятно кто и что меняет. С хостера взятки гладки.
Сделал лабораторную VDS. Предлагаю попробовать вместе найти где я не прав. Ключ в конце статьи.
Все подходы которые решают задачу возможны.
Этот вариант уже был и он работал. Далее наша действительность развивалась от него.
Это мои сладкие сны когда у меня будет проект без legacy и я смогу выбрать все технологии и даже ОС на сервере :)
artem:~ artem$ssh root@149.154.64.101
Last failed login: Mon Mar 19 08:31:53 EDT 2018 from 58.242.83.24 on ssh:notty
There were 23 failed login attempts since the last successful login.
Last login: Mon Mar 19 08:31:04 2018 from 188.120.252.193
bashrc Connection DENY
Connection to 149.154.64.101 closed.
artem:~ artem$ssh root@149.154.64.101 «bash --noprofile --norc»
bashrc Connection DENY
Подход сертификатов прекрасен если все сервера в личном ведении и ты их сам раскатываешь ансибло-чефом.
Продолжение 8 числа в 18:00 как я понял, это же дожить надо
Как вы поступаете в этом варианте если антиспам система блокирует добропорядочный аккаунт. Например взломанный, или возможно есть спамеры которые бодаются что их сообщение «выплаты без смс» вообще не спам и друзья хотят их видеть :)
Есть какая то выборочная ручная проверка заблокированных? Или вероятностные оценки системы никогда не ошибаются? Вопрос только в выборе правильной вероятности для блокировки.
36066 GB used, 23074 GB / 59140 GB avail
OSD 33 штуки
Релика левел 2. Но думаем переходить на 3. Вопрос в финансировании пока.
36066 GB used, 23074 GB / 59140 GB avail
OSD 33 штуки
Релика левел 2. Но думаем переходить на 3. Вопрос в финансировании пока.
osd-1 ~]# ceph status
cluster 1d071981-9840-4f01-983b-1f423bdbf56f
health HEALTH_OK
monmap e9: 3 mons at {a=172.16.0.1:6789/0,b=172.16.0.2:6789/0,d=172.16.0.4:6789/0}, election epoch 628, quorum 0,1,2 a,b,d
osdmap e42694: 33 osds: 33 up, 33 in
pgmap v34072165: 1152 pgs, 2 pools, 17894 GB data, 4497 kobjects
36066 GB used, 23074 GB / 59140 GB avail
1152 active+clean
client io 39018 kB/s rd, 27158 kB/s wr, 1819 op/s
Синтетический тест на запить iops=6177
# fio /tmp/wr.ini
writetest: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=32
fio-2.2.8
Starting 1 process
writetest: Laying out IO file(s) (1 file(s) / 953MB)
Jobs: 1 (f=1): [w(1)] [100.0% done] [0KB/18204KB/0KB /s] [0/4551/0 iops] [eta 00m:00s]
writetest: (groupid=0, jobs=1): err= 0: pid=11188: Fri Oct 28 05:02:18 2016
write: io=976560KB, bw=24708KB/s, iops=6177, runt= 39524msec
slat (usec): min=2, max=3318, avg=11.86, stdev= 9.37
clat (msec): min=1, max=416, avg= 5.17, stdev=11.16
lat (msec): min=1, max=416, avg= 5.18, stdev=11.16
clat percentiles (usec):
| 1.00th=[ 1608], 5.00th=[ 1880], 10.00th=[ 2064], 20.00th=[ 2384],
| 30.00th=[ 2640], 40.00th=[ 2928], 50.00th=[ 3248], 60.00th=[ 3600],
| 70.00th=[ 4128], 80.00th=[ 4896], 90.00th=[ 7072], 95.00th=[11072],
| 99.00th=[48384], 99.50th=[73216], 99.90th=[166912], 99.95th=[203776],
| 99.99th=[329728]
bw (KB /s): min= 7196, max=32800, per=100.00%, avg=24718.19, stdev=5477.65
lat (msec): 2=7.96%, 4=60.20%, 10=26.05%, 20=3.39%, 50=1.45%
lat (msec): 100=0.67%, 250=0.25%, 500=0.02%
cpu: usr=2.42%, sys=8.65%, ctx=181961, majf=0, minf=30
IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued: total=r=0/w=244140/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency: target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
WRITE: io=976560KB, aggrb=24708KB/s, minb=24708KB/s, maxb=24708KB/s, mint=39524msec, maxt=39524msec
Далее наш разговор упрется в разные токи зрения и как мы будем называть трубу/кран. Я принял решение не продолжать дельнейший спор. Но спасибо за то что озвучили свое мнение и ответили на мой вопрос.
Я уверен что вас есть другие решения мимо хостинг компаний.
Особенность технологии. Как и в ресторане.
Если вам требуется единоличный доступ к данным то надо ставить сервер под стол в офисе или в закрытую стойку в цоде (ключи должны быть у вас). Хостер точно так же может получить доступ к данным с выделенного сервера.
Хотя есть один дешевый способ с некоторыми минусами. Шифрование раздела с данными. В этом случае после каждого ребута необходимо будет производить действия для рашифровки и мириться с некоторым оверхедом по скорости.
Хостер по факту сам не совсем хочет доступ к данным пользователя. Тогда можно будет разводить руки на запросы из МВД и в случае проблем внутри VDS всегда будет понятно что сотрудники хостера не при чем.
Если не секрет, а чего вы боитесь от хостера?
По факту есть возможность у saltstack указываешь md5 и путь до файла. И начинается контроль изменения при запуске (хотя он может и просто переписывать).
И у monit есть возможность следить чтобы md5 не менялось.
Так же хорошо использовать etckeeper который по умолчанию отслеживает изменения в /etc но его можно и натравить на другие папки.
Все остальные пути упираются в сриптописательство с inotify, git, md5 кому что более нравится.
Проблема в том что этим должен заняться админ сервера, которому понятно кто и что меняет. С хостера взятки гладки.
Или ipoib и подымать что угодно хоть cepth. Но тогда ~ 10Гбит.
Еще есть какие то варианты?