Install Arch Linux via SSH (Русский)
Эта статья предназначена для того, чтобы показать пользователям удалённую установку Arch по SSH-соединению. Данный подход полезен, когда хост находится на удалённом расстоянии или вы хотите использовать функции SSH-клиента для копирования и вставки текста в процессе установки Arch.
На удалённой (целевой) машине
Загрузите целевую машину в Live-среду Arch с помощью образа Live CD/USB, что запустит сессию от имени root-пользователя.
На данном этапе настройте сеть на целевом компьютере, как показано, например, в разделе Руководство по установке#Соединение с интернетом.
Во-вторых, настройте пароль root, который необходим для подключения SSH, так как он по умолчанию пуст:
Теперь проверьте, что параметр PermitRootLogin yes присутствует (и раскомментирован) в файле /etc/ssh/sshd_config . Этот параметр позволяет авторизироваться пользователя root на SSH-сервере.
Наконец, запустите службу openssh — sshd.service — которая входит в live CD по умолчанию.
На локальной машине
На локальной машине подключитесь к целевому хосту по SSH с помощью следующей команды:
Теперь отобразится сообщение-приветствие live-среды и можно будет управлять целевой системой так же, как и сидя за её физической клавиатурой. Если необходимо просто установить Arch, следуйте статье Руководство по установке. Если вы хотите изменить существующую установку Linux (например, из-за каких-либо неполадок), см. статью Установка Arch из другого дистрибутива.
Источник
Установка и настройка сервера SSH в Linux
Secure Shell, т. е. SSH – протокол, обеспечивающий защищённые соединения и передачу данных между двумя удалёнными компьютерами. Изначально создавался на замену таким системам как rlogin и rcp. Как понятно из полного названия протокола, система SSH позволяет соединяться и управлять удалённым узлом (компьютером, маршрутизатором и т. д.), при этом защищая весь передаваемый трафик с помощью высоконадёжного шифрования.
SSH широко применяется администраторами серверов для их настройки и управления, да и обычные продвинутые пользователи — владельцы, например, сайтов или виртуальных серверов активно используют SSH для подключения к своей учётной записи на хостинге и использования командной оболочки сервера.
Сразу после окончания разработки система SSH стала активно трансформироваться в закрытый коммерческий продукт в виде версии SSH2. Но благодаря сообществу GNU версии протокола SSH1 и SSH2 были реализованы в виде открытого и свободно распространяемого ПО openSSH. В Linux-системах используется именно этот метапакет.
Метапакет SSH базово включает в себя сервер SSH (sshd) в качестве програмы-демона, а также несколько утилит: ssh – удаленная регистрация и выполнение команд, scp – передача файлов и ssh-keygen – для генерации пар SSH-ключей.
Установка пакетов SSH
Как уже говорилось система ssh в Linux-системах распространяется в виде составного метапакета, поэтому для установки всех требуемых утилит ssh нужно выполнить всего одну команду:
В Ubuntu
После чего начнется процесс установки
Как видно, менеджер пакетов сам распознает все зависимые и связанные пакеты и установит их. Также, по завершению установки, автоматически будет запущен SSH-сервер в режиме демона. Это можно проверить командой:
$ systemctl status sshd
или:
$ service sshd status даст тот же вывод. Теперь сервер работает с базовыми настройками по-умолчанию.
Настройка SSH
Режим работы SSH-сервера с настройками по-умолчанию хоть и является вполне работоспособным для небольших частных сетей, всё же нуждается в задании некоторых важных параметров для использования на высоконадёжных публичных серверах. Настройки демона хранятся в файле /etc/ssh/sshd_config. Посмотреть его можно командой
В первую очередь следует обратить внимание на следующие параметры: Port, AddressFamily, ListenAddress. Первый глобально задаёт номер порта, через который будет работать соединение и если оставить его стандартным, т. е. 22, то велика вероятность, что он будет слишком часто сканироваться роботами.
Примечание: для задания активации параметра необходимо раскомментировать соответствующую строку — убрать символ «#» в её начале.
Второй параметр задаёт семейство используемых IP-адресов — IPv4 и IPv6. Если, к примеру, используются только адреса IPv4, то очень рекомендуется установить для параметра
Для адресов семейства IPv6 используется значение inet6.
Параметр ListenAddress позволяет задавать порты для отдельных сетевых интерфейсов:
Поскольку реализация openSSH позволяет работать с протоколами SSH1 и SSH2, то разумно отключить использование SSH1, т. к. эта версия является устаревшей. Работа по SSH1 крайне не рекомендуется: Protocol 2
Очень полезным является параметр, позволяющий проводить авторизацию и шифрование трафика с помощью специальных SSH-ключей:
Следует заметить, что в таком случае серверу необходимо явно указывать, где хранятся открытые ключи пользователей. Это может быть как один общий файл для хранения ключей всех пользователей (обычно это файл etc/.ssh/authorized_keys), так и отдельные для каждого пользователя ключи. Второй вариант предпочтительнее в силу удобства администрирования и повышения безопасности:
AuthorizedKeysFile etc/ssh/authorized_keys # Для общего файла
AuthorizedKeysFile %h/.ssh/authorized_keys # Файл -> пользователь
Во втором варианте благодаря шаблону автоподстановки с маской «%h» будет использоваться домашний каталог пользователя.
Важно также отключать парольный доступ:
Или же, в случае, если всё-таки необходимо использовать доступ по паролю, то обязательно нужно отключать авторизацию по пустому паролю:
Для указания разрешённых или запрещённых пользователей и групп служат директивы DenyUsers, AllowUsers, DenyGroups, и AllowGroups. Значениями для них являются списки имён, разделяемых пробелами, например:
Следует также отключать root-доступ:
Иногда, когда следует задавать мультисерверную конфигурацию, очень удобно использовать алиасы (Aliases), что позволяет настроить сразу несколько режимов доступа (с разными хостами, портами и т. д.) и использовать их, указывая при этом конкретный алиас:
Настройки для алиасов хранятся либо глобально в /etc/ssh/ssh_config, либо раздельно для пользователей в
/.ssh/config. Здесь нужно не спутать с ssh_config! Пример:
Для применения сделанных настроек необходим перезапуск SSH-сервера:
Настройка и использование клиента SSH
Для подключения по к серверу используется команда:
где user_name – имя пользователя в системе, host_name – имя узла, к которому производится подключение, например:
При этом утилита ssh запросит (в зависимости от настроек сервера) логин, пароль или парольную фразу для разблокировки приватного ключа пользователя.
В случае авторизации по ключу, должна быть предварительно сгенерирована пара SSH-ключей — открытый, который хранится на стороне сервера, обычно в файле .ssh/authorized_keys в домашнем каталоге пользователя, и закрытый — используется для авторизации клиента и хранится, как правило, в каталоге .ssh/ домашней директории пользователя. Открытый ключ представляет собой «цифровой слепок» закрытого ключа благодаря которому сервер «знает», кто «свой», а кто «чужой».
Для генерации ключей используется утилита ssh-keygen:
Утилита предложит выбрать расположение ключей (лучше всё оставить по-умолчанию), обычно это каталог
/.ssh/, ввести парольную фразу для закрытого ключа. После чего будут сгенерированы открытый ключ id_rsa.pub и закрытый — id_rsa. Теперь нужно скопировать открытый ключ, т. е. «слепок» закрытого на сервер. Проще всего этого можно добиться командой:
Теперь можно выполнить подключение командой ssh и запустить защищённый сеанс удалённого управления.
Важно заметить, что использование сгенерированных openSSH-ключей несовместимо с PPK-форматом, используемым по-умолчанию в таких комплексах как PuTTY. Поэтому необходимо конвертировать имеющиеся openSSH-ключи в формат PPK. Удобнее всего это делать с помощью утилиты PuTTY – puttygen.exe.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Источник
Установка Linux по ssh
Всем доброго дня. Есть доступ по ssh к серверу с CentOS. Нужно установить другой дистрибутив Linux имея только доступ ssh. Физически нет доступа к серверу. Каким образом это сделать?
Скажи честно, ты писал, для начала, даже на русском «Установка Linux по ssh» в гугле?
Честно писал. И по ссылкам ходил которые гугл выдал.
И что не устроило в ответа, что там были?
на первой же странице в гугле по запросу «установка linux по ssh»
Еще один способ: копируешь туда куда-нибудь ядро и initrd для netinstall. Если загрузчик — груб, то в меню нажимаешь кнопку «C» и вводишь
bootparam — это параметры, отвечающий за расположение установочного носителя и за включение режима установки по ssh. Для примера, в opensuse 11.4 это должно выглядеть как
В других дистрибутивах будут другие параметры, надо гуглить. И кстати, если сеть настраивается вручную, нужно еще передавать параметры ядру для настройки сетевого интерфейса.
1. Найти сервер с физическим доступом для тренировок.
2. Написать пошаговую инструкцию по мотивам интернетов.
3. Попробовать на удаленном сервере.
4. Изыскать возможность физического доступа к удаленнному серверу.
зы. 4 пункт как бы шутка, но .
+1, проверить на виртуалке со схожими сетевыми настройками, а то мало ли какой нюанс всплывет. Вдруг в настройках по умолчанию после перезагрузки ссш не поднимется на установленной системе?
Источник
Удаленная переустановка Linux по ssh без доступа к консоли
Понадобилось мне переустановить сервер, который как бы хостился у знакомых знакомых. Там был сильно устаревший Debian, а, самое главное, система стояла на обычных разделах без lvm и пространство было распределено очень не оптимально. Физический доступ получить к нему было практически нереально, местного админа попросить что-то сделать было можно, но занять это могло неделю. Виртуальный KVM у сервера был, но извне на него попасть было нельзя; у как бы хостера не было лишних IP-адресов, а внутрь его сети попасть было невозможно. Надо было переустановить сервер из-под работающей системы по ssh. Ага, давайте поменяем ротор у турбины не выключая, потом её перезапустим и будет она с новым ротором работать!
Первой идеей было создать chroot окружение на ram-диске и с него создать lvm и залить систему. Но не тут-то было, не дает система изменить таблицу разделов.
Второй идеей было взять исходники дистрибутива Debian, зашить в них IP-адрес сервера, пересобрать initrd с установщиком Debian, ssh сервером и моими IP, подставить этот initrd в конфиг grub блоком по умолчанию и перегрузиться. После этого я должен был получить ssh консоль с сетевым установщиком. На стенде у меня получилось! Но на бою все окончилось неудачей, сервер не поднялся. Хозяевам сервер оказался не очень нужен, и дело так и заглохло, но у меня осталось ощущение нерешенной задачи.
Как-то с коллегами обсуждали всякие деструктивные действия с системой (типа rm -rf /) и один из коллег сказал, что можно отключить scsi диск, на котором находится корневой раздел и система не пикнет. Это дало мне идею номер три, взять идею один, оторвать диск, вернуть диск и возвращенный диск будет уже другим, не тем который система не отдавала. Именно так и оказалось. А теперь по пунктам, как же все-таки переустановить систему без доступа к физической консоли.
Предупреждение! Надо понимать, что все, что мы будем делать — дорога в один конец, при ошибке мы теряем доступ к системе! Вполне возможно, что придется ехать 1500 километров и лезть в шахту, чтобы реанимировать сервер.
Будем считать, что IP нашей системы 192.168.56.102. Именно так было у меня на стенде. Плюс доступ к интернету через прокси:
Начинаем работу на исходной системе.
# System #0
Заходим по ssh на сервер:
Создаем каталог и файловую систему для «Системы убийцы», монтируем её:
Ставим отличную утилиту debootstrap, которая разворачивает минимальную установку Debian, при помощи неё мы создадим chroot окружение:
Существуют аналогичные утилиты для Федоры и Centos, соответственно febootstrap и yumbootstrap, но я с ними не работал.
Первый аргумент — версия, второй — каталог установки, третий — репозиторий.
Бекапим самое необходимое:
Самое важное — настройки сетевых интерфейсов, без них не получится попасть в переустановленную систему.
Даем имя chroot-окружению:
Слово «Killer_system» будет показываться в приглашении bash. Это важная штука, без неё будет не понятно, где мы в данный момент находимся.
Переходим в новое окружение.
# System #1
Монтируем полезные fs:
Еще раз ставим debootstrap:
Дальше мои заморочки: у дебиановского пакета openssh-server в рекомендованных пакетах есть пакет xauth, а у него в зависимостях всякие иксовые библиотеки. Я, как сторонник минимализма, не хочу, чтобы на сервере, где не было и не будет графики, ставились огрызки иксов. Поэтому ставим с ключиком —no-install-recommends:
Правим конфиги. Ставим альтернативный порт для ssh демона, чтобы мы могли зайти на chroot систему по ssh:
И разрешаем доступ для root:
Можно не давать доступ root, а создать пользователя и дать ему sudo права, но тут я сознательно упрощаю.
Дальше надо задать пароль root, так как по умолчанию debootstrap не устанавливает никакие пароли:
Заходим в chroot окружение по ssh:
Это мы делаем для того, чтобы полностью отвязаться от старой системы, у которой мы оторвем диски. А так у нас будет полностью автономная система в оперативной памяти, никак не связанная со старой.
Такой трюк очень хорошо подходит, если мы уходим от хостера, а оставлять ему наши файлы очень не хочется (я знаю, паранойя). На этом этапе просто забиваем диски нулями, если хотим быстро:
Или случайными данными в несколько проходов, если хотим хорошо. Достоинство метода в том, что мы можем дождаться окончания работы dd и, при необходимости, повторить. Если же затирать диски непосредственно из боевой системы, то посмотреть на результаты работы dd мы уже не сможем.
Попробуем простой путь, удалим тома и разделы:
Но неудача. При этом раздел удалится, и система сломается, но воспользоваться простым путем без перезагрузки не получится. А перегружаться будет некуда.
Мы пойдем другим путем. Проверяем, где у нас что находится:
Будем считать, что корневой раздел у нас на диске sda.
Затираем диск, чтобы ни в коем случае его не подцепил lvm.
Предупреждение! После этого момента возврата нет, даже следующий шаг не такой вредоносный. Задумаемся на минуту, проверим консоль, за которой сидим и оправдаем имя нашего chroot’а:
Проверяем, диск оторвался:
Подключаем диск обратно:
Проверяем, что вернулось:
Был sda, стал sdb, отлично.
Важный момент: на згрузочном диске необходимо создать один первичный раздел размером на весь диск и этот раздел отдать lvm’у для того чтобы на него смог встать grub. Все остальные диски можно отдавать lvm’у целиком не создавая систему разделов (pvcreate /dev/sdc). Создаем таблицу разделов и один первичный раздел типа 8e, Linux LVM:
В первоначальной версии скрипта было создание одного логического тома под всю систему, но когда мой коллега переустанавливал Linux по этому скрипту, оказалось, что создание нескольких разделов представляет некоторую трудность, особенно отдельный раздел под логи. Внимание надо обратить на порядок создания точек монтирования и собственно монтирования разделов.
Разворачиваем уже боевую систему на новое место на жестком диске:
Возвращаем на место резервные копии конфигов:
Теперь нас ждет новая система:
# System #2
Обратите внимание, в приглашении командной строки теперь имя нового chroot окружения.
Монтируем файловые системы:
Ещё можно примонтровать эти файловые системы из родительского chroot’а:
Устанавливаем и конфигурируем openssh:
Устанавливаем пакеты, без которых не обойтись:
Да, я не могу жить без vim и ненавижу nano:
В принципе grub прописывается куда надо ещё при установке, но, всё же, для поддержки штанов и морального духа повторим:
Теперь правим конфиги, вначале самый важный, без которого система не поднимется:
В файле interfaces все должно быть в порядке, ведь как-то сеть у нас работала?
В конфиг apt’а добавляем информацию о прокси:
Добавляем строчку в /etc/hosts:
Размонтируем файловые системы:
И выходим из chroot’а:
Размонтируем файловые системы:
Если размонтировать /dev не удалось, то не удастся размонтировать и /target, но это не страшно.
Если удалось, то делаем так:
Если нет, то так:
Эти команды сбросят дисковые кеши и перемонтируют корневую файловую систему в read only. После этого можно перегружаться.
Тут-то нас ждет сюрприз от всеми любимого systemd! Он знает, что мы в chroot и не дает перегрузиться! Google дает советы выйти из chroot, но нам-то выходить некуда. Но на помощь приходит Magic SysRq!
Активируем SysRq (он, скорее всего, активирован, но нам же надо убедиться?).
Барабанная дробь, тревожное ожидание, неужели мы что-то забыли, и сервер не поднялся?
Ура! Мы в новой системе!
Пересоздадим initrd. Это не обязательно, но в дальнейшем избавит от некоторых ошибок при перезагрузке:
Удаляем файлик с именем chroot окружения:
Источник
