Install linux from ssh

Install Arch Linux via SSH

This article is intended to show users how to install Arch remotely via an SSH connection. Consider this approach when the host is located remotely or you wish to use the copy/paste ability of an SSH client to do the Arch install.

Contents

On the remote (target) machine

Boot the target machine into a live Arch environment via the Live CD/USB image: this will log the user in as root.

At this point, setup the network on the target machine as for example suggested in Installation guide#Connect to the internet.

Secondly, setup a root password which is needed for an SSH connection, since the default Arch password for root is empty:

Now check that PermitRootLogin yes is present (and uncommented) in /etc/ssh/sshd_config . This setting allows root login with password authentication on the SSH server.

Finally, start the openssh daemon with sshd.service , which is included by default on the live CD.

On the local machine

On the local machine, connect to the target machine via SSH with the following command:

From here one is presented with the live environment’s welcome message and is able to administer the target machine as if sitting at the physical keyboard. At this point, if the intent is to simply install Arch from the live media, follow the guide at Installation guide. If the intent is to edit an existing Linux install that got broken, follow the Install from existing Linux wiki article.

Installation on a headless server

This section describes installation of Arch Linux on a headless server without a keyboard, mouse or display. It uses an additional drive with cloud-init NoCloud configuration to automatically configure OpenSSH authorized keys and optionally iwd connection(s).

Prepare cloud-init configuration files

There are two required cloud-init configuration files: meta-data and user-data .

The meta-data file can be empty:

user-data will contain the relevant configuration:

Replace ssh-ed25519 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX with your public SSH key. To add multiple keys, simply repeat the statement as shown above.

To automatically connect to a Wi-Fi network, use the write_files: statement to create iwd network configuration files in the correct directory. For example:

Once both files are created they need to be placed on a drive with an ISO 9660 or FAT volume labeled CIDATA .

Using an additional FAT formatted drive

Use a FAT formatted drive. Copy meta-data and user-data to the drive and change the file system’s LABEL to CIDATA .

You will need to attach this drive to the headless machine in addition to the one with the official ISO.

Using an additional ISO

Create a cloud-init.iso file using xorriso from libisoburn :

Prepare the cloud-init data medium by burning cloud-init.iso to an optical disc or, if deployment options permit, use the ISO as is.

Using a single USB flash drive

If the installation image is written to e.g. a USB flash drive, provided there is enough space on the drive, and additional partition to house cloud-init data can be created.

First follow USB flash installation medium#Using the ISO as is (BIOS and UEFI) to prepare the USB flash drive installation medium.

Use fdisk to edit drive’s MBR partition table without touching the ISO 9660 or invalid GPT structures:

Create a new (third) partition and set its partition type to 0c . When done, write the partition table to disk.

Format the newly created partition with a FAT file system and set its LABEL to CIDATA :

Mount the file system and copy the meta-data and user-data to the root of it.

Using a single custom-built ISO

Alternatively, create a custom ISO using Archiso. This allows using only one drive regardless of type.

Use the releng profile as basis. Place the cloud-init configuration files in airootfs/var/lib/cloud/seed/nocloud/ and build the ISO.

Boot from the installation medium

Once finished, deploy the installation medium and the cloud-init data medium (if it is separate) to the headless machine using the appropriate method.

Power up the headless machine and boot into a live Arch environment from the installation medium. Wait for a minute or so to allow the headless machine time to boot up and connect to the network.

From your existing machine (with keyboard and display) SSH into the live Arch environment on the headless server and complete the installation as described in the Installation guide.

Источник

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 из другого дистрибутива.

Источник

Ubuntu Documentation

This is a work in progress, it is not mature yet and it may break your system!

Caveat

As you may already have guessed following this instruction may break your system and you are on your own to fix it again. apt-get install linux-image-686

Scenario

This instruction describes how to install Ubuntu on a dedicated server over ssh. I assume that your provider provides you with a rescue system from which you can boot and prepare your system. An Online replacement is possible, but it is some more work and a lot more risky if things go bad (the basic idea is to temporarily disable your swap and install a transitional system on it).

Preparing the Hard Disk

Partitioning

Use fdisk to partition your hard disk.

Remember to set the root partition bootable!

For the rest of this instruction we assume the following partition layout.

Creating File Systems

Below is how we get our / populated with ext3.

And the same for our swap partition.

The Base System

Mounting Root

Getting Debootstrap

Debootstrap is a collection of scripts that we will use in the next step to set up a base system. We need an appropriate version of debootstrap from http://archive.ubuntu.com/ubuntu/pool/main/d/debootstrap/ to make this work.

Make sure that binutils is installed on your system.

On an apt based system we can use dpkg to install it.

If your current system is rpm based, use alien to install it or find a rpm on the web (http://azhrarn.underhanded.org/debootstrap-0.2.23-1.i386.rpm).

If your system is neither, this might work.

Installing the Base System

(arch may be different for you, e.g. amd64, hppa, ia64, powerpc, or sparc)

Basic Configuration

Set the Hostname

Change HOSTNAME to whatever suits your environment.

fstab

Put the following in fstab:

Networking

Make sure to use your network details instead.

Make sure to use your hostname and domain.

You need a valid resolv.conf with at least one valid nameserver, e.g.:

Enter the new environment

Before we chroot into the new environment we need to mount /proc and /dev

Change the root password

It is just bad if you forget this, so just .

Create a user and switch shadow password on

Installing Packages

Installing OpenSSH Server

Install a Kernel

Choose the right kernel for your architecture. I go with:

Reboot

Finishing

After the reboot ssh in again.

Generate locales

Install some more packages

References

An other instruction from the Ubuntu Installation Guide is somewhat outdated and has shortcomings related to the bootloader installation.

Installation/OverSSH (последним исправлял пользователь andrew-woodhead666 2011-05-31 16:43:31)

The material on this wiki is available under a free license, see Copyright / License for details
You can contribute to this wiki, see Wiki Guide for details

Источник

Удаленная переустановка 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 окружения:

Источник