CityCat4

Восстановить прям на VPS скорее всего не получится, но слить образ себе не особо сложно (когда разберешься). Я делаю вот так:

Команда выполняется на удаленном сервере с одновременной передачей дампа на сервер, который указан в командной строке. При выполнении команды будет инициировано обычное ssh-соединение, запрошен ключ или пароль, выходные данные записываются в несжатом виде

# dump -0auL root -f - /dev/vda2 | bzip2 | ssh user@servera.net -p 22 dd of=vda2.dump

Параметры, которые нужно менять:

-L root - метка бэкапа
/dev/vda2 - имя устройства, с которого снимается бэкап
user@servera.net - пользователь и имя сервера, куда передается бэкап
vda2.dump - имя файла, куда будет записан бэкап (по умолчанию он будет в домашнем каталоге пользователя)

На сервере servera.net должен уже существовать юзер user - именно его пароль будет запрошен.

Можно через dd, как выше, но в таком случае будут передаваться все блоки в том числе и пустые и размер файла бэкапа будет равен размеру диска (до сжатия)

Нанять того, кто сможет это сделать. Ей-Богу, это будет:

- быстрее
- надежнее
(особенно если это тыщапервый Интернет-магазин, который нафиг никому не впилился его тырить)

Рута (юзера с uid = 0) ни в чем ограничить нельзя. От слова совсем.
А вот запретить логин руту удаленно можно и даже нужно. В sshd_config:
PermitRootLogin no

Кроме того, можно запретить логин вообще всем, кроме допустим логина vasya:
AllowUsers vasya
и все. Совершенно неважно, знают они пароль, не знают они пароль - их будет посылать в любом случае.

Ломать будут :) Пароли подбирать, занимать ресурсы. Логин рута запретить, заход только по ключу, ограничить диапазон IP. Можно еще порт сменить, но это отлавливается быстро, хотя в комплексе помогает.

Запустить сервер вручную с ключом -vvv и попробовать подключиться - сервер должен написать на консоли, как он выбирал порядок аутентификации и что ему не нравится. Проблем обычно две - неверные права и неверный владелец.

Видимо потому что, он на самом деле был взломан :) Микротик очень популярное устройство - а с популярностью приходит одна штука - все начинают пробовать сделать гадость :) Тут еще хакеры оказались вежливые - честно написали :)

Конечно возможно. Такое было возможно еще в 70-е :)

man write (написать кому-то конкретному)
man wall (написать всем, кто залогинен)

Запустить sshd без перехода в фон и с отладкой и посмотреть, что он напишет по поводу того, почему он denied.

Возможные причины:
- не согласовались шифронаборы (редкая, но возможная - либо очень старый клиент, либо очень старый сервер)
- пользователи разрешаются поименно, то есть если у меня в конфиге стоит :
AllowUsers rmbackup testonlytt
то хоть тресни, а никто кроме этих двоих не подключится

Если это Ваш собственный VDS - у Вас есть консоль в личном кабинете. Если нет - обратитесь к системному администратору :)

А самое очевидное решение в голову не приходило? Скопировать нужные команды (и их файлы сопровождения) в ~/bin? Или еще куда-нибудь внутри домашки юзера?

Привет чемпиону!

У openssh альтернативы нет. Был некогда финский ssh2, но давно сдох и разложился...

Консоль. Заход рутом через консоль и правка всех необходимых файлов. Если по каким-то причинам консоль недоступна - только перестановка.

ЗЫ: Древо познания произрастает из шишек на лбу.

Многабукаф...

Все так называемые "VPN", "анонимайзеры" и прочие херайзеры работают по одному принципу (и по-другому они работать не могут) - браузер устанавливает соединение с херайзером (посредством локального прокси, если он есть) и отдает херайзеру запрос "скачай мне енту страницу". Херайзер страницу скачивает и отдает браузеру, он ее отображает. И все :)

Никакой полноценной защиты, как в настоящем VPN здесь нет. Логирование идет на всех уровнях - на уровне локального прокси (если он есть - видит, что пошли на херайзер), на уровне провайдера (то же самое), на уровне самого херайзера (видит, куда пошли - и не надо говорить, что там нет логирования - это проверить невозможно, значит оно есть).

Задачей херайзера является скрыть от локального прокси/провайдера целевой урл, а от сайта назначения - адрес, с которого пришли.

Имеется ли в нем смысл? Нет. Сам факт обращения к херайзеру уже вешает на Вас черную метку, дальнейшая защита имеет смысл только если в модели нарушителя не государство, а жена/сосед - от них таким образом можно защититься. Но даже от работодателя уже - никак.

и как их в этом максимально ограничить сохранив при этом удобство входа по логину/паролю?

Написать правило, которое ограничивает вход с определенных IP

Если сервер HP, то возможно настроен iLO, если Dell - то iDRAC.

Очень сомневаюсь, что там выставили вход на iLO наружу, потому что это чревато весьма неприятными вещами

Если он на гипервизоре, тоже никаких проблем.

Каким образом наличие гипера Вам поможет

Connection refused - отказ в соединении. Например, потому что там заход по списку юзеров - юзер1, юзер2 и все.

Данный сервер не поддерживает в качестве метода аутентификации ввод пароля с клавиатуры, только ключи. Я обычно такое ставлю на учетки автоматов, чтобы мудаки умники различные не лезли.

Ну то есть некоторые системные команды? Есть несколько способов:
- Если бинарь в /sbin, /usr/sbin - просто исключить эти пути из PATH в .bashrc у юзера
- Если бинарь в /bin, /usr/bin - можно создать папку /bin в домашке юзера, накидать туда пустышек (линков с true например) и поставить ее первой в PATH
- Дать юзеру другой шелл, не bash :)