¡Esta es una revisión vieja del documento!
Tabla de Contenidos
Instale Slackware en un servidor de BareMetal Dedibox de online.net
Este tutorial explica cómo instalar y arrancar Slackware Linux en online.net Dedibox BareMetal Server Start Family. Se centra en los servidores a los que no tiene acceso físico y aquellos que no admiten la exposición remota del hardware (es decir, no hay KVM sobre IP). La configuración de este tipo de servidores es posible a través de Web interface. Afortunadamente o no, esta interfaz no admite de forma nativa la instalación de Slackware. No te preocupes, nos las arreglaremos sin embargo.
Aunque las primeras partes del tutorial son específicas del servidor Dedibox, el resto es más genérico. Esto significa que la información proporcionada aquí se aplica por igual a otras ofertas de alojamiento, que solo deben proporcionar un sistema operativo de rescate similar (más información sobre el sistema operativo de rescate más abajo). Por el contrario, las primeras partes se aplican bien a las distribuciones de Linux que no sean Slackware. Si necesita un control detallado sobre el proceso de instalación en el servidor Dedibox, está en un buen lugar.
1. Dedibox rescue OS
El sistema operativo de rescate es un sistema operativo en el que puede iniciar su servidor utilizando la interfaz web. Este sistema operativo le permite realizar tareas de mantenimiento, si su sistema operativo principal no se inicia o si necesita acceder al servidor, mientras pasa por alto su sistema operativo principal. Hay varias versiones del sistema operativo de rescate para elegir; estaremos usando uno basado en Linux.
Puede (y debe) conectarse al sistema operativo de rescate a través de SSH. Una de las características del sistema operativo de rescate es que es volátil, lo que significa que los cambios realizados en él se pierden después del reinicio. Pero lo que es más importante, las claves de host SSH se regeneran cada vez que se inicia el sistema operativo de rescate, lo que hace que la huella dactilar de la clave del host SSH también se modifique, cada vez que reinicie. Esto hace que la verificación de la autenticidad del servidor sea un poco incómoda.
Una de las formas de verificar la autenticidad del host es abrir el ticket de soporte técnico de online.net, solicitando que se le proporcione la huella digital clave del host del sistema de rescate. Y debido a que la huella digital cambia con cada reinicio, no es deseable reiniciar la máquina durante la instalación de Slackware. No es un gran drama, es posible instalar con éxito y luego arrancar Slackware en todo su esplendor con solo un reinicio al final del viaje. También puede conectarse sin asegurarse de la autenticidad del host, tener un juego e incluso una instalación de prueba. Una vez que esté familiarizado con el entorno, puede reiniciar nuevamente en el sistema operativo de rescate, solicitar asistencia técnica para la huella digital, limpiar el disco duro y realizar la instalación y configuración final. Solo ten en cuenta que sin verificar la autenticidad del host, eres susceptible a los ataques MITM. Aunque el sistema de archivos de rescate es volátil y puede limpiar el contenido del disco para asegurarse de que esté limpio y seguro, aún así, el propio hardware podría ser el objetivo del ataque. Y hoy en día, el hardware en realidad está ejecutando software (firmware) más a menudo.
Afortunadamente, existe un método alternativo que no implica el compromiso del soporte técnico. Puede leer los detalles completos en LinuxQuestions.org: Verificación de la autenticidad del host (SSH) después de iniciar sesión, por encima del terminal en serie seguro y accesible. En el tutorial en sí, solo me centraré en cómo hacer las cosas.
2. Consola serial
La interfaz web proporciona una opción de consola serie, que le permite interactuar con el hardware del servidor. Es de uso limitado con el sistema operativo de rescate (es decir, no es posible iniciar sesión), pero se puede utilizar completamente con el sistema operativo principal. Si se configura correctamente, le permitirá ver el proceso de arranque del sistema operativo principal y también tener un inicio de sesión de terminal, en caso de que la conexión SSH no esté disponible por cualquier motivo. (Pero no esperes nada lujoso, es solo una consola serie después de todo).
3. Hacer que el sistema operativo de rescate esté disponible
Si acaba de comprar un servidor nuevo, debe venir sin un sistema operativo preinstalado. Desafortunadamente, significa también que el sistema operativo de rescate no está disponible todavía.
Para habilitar el sistema operativo de rescate: mediante la interfaz web, vaya a la página de administración de su servidor: Server → Server list → (server name) Manage. Si la única opción que ve es [INSTALL]
, entonces el sistema operativo de rescate no está disponible y primero debe instalar uno de los sistemas operativos ofrecidos. (Nota de Purist: elija sabiamente el sistema operativo, ya que el ícono asociado con este sistema operativo representará su sistema Slackware a partir de entonces). Una vez que se complete la instalación del sistema operativo, se le presentarán más opciones: [REBOOT]
, [RESCUE]
, [SERIAL_CONSOLE]
y [INSTALL]
. Estás listo para irte ahora. Simplemente no arranques el sistema operativo de rescate todavía.
4. Preparando el acceso del sistema operativo de rescate a través de SSH
Ahora estamos a punto de crear dos pares de claves SSH. Se usará un par para iniciar sesión en el sistema operativo de rescate y el otro (solo parte de la clave pública) para la autenticación del sistema operativo de rescate. Escriba lo siguiente en su estación de trabajo:
$ mkdir dedibox_rescue_os_keys $ cd dedibox_rescue_os_keys $ ssh-keygen -t rsa -f login_key -N '' $ ssh-keygen -t rsa -f auth_key -N ''
Mediante la interfaz web, vaya a la página de administración de claves SSH: inicie sesión como (username) → SSH keys y agregue auth_key.pub y login_key.pub public llaves. Tenga en cuenta que después de la adición exitosa, la página no se actualiza automáticamente y para ver las claves, debe hacer clic en el enlace SSH keys en el lado izquierdo.
Cargar las claves a través de la interfaz web tiene el efecto de ponerlas a disposición del sistema operativo de rescate. Cuando se inicia el sistema operativo de rescate, las claves simplemente se agregan al archivo ~/.ssh/authorized_keys para el usuario en particular.
5. Arrancar y conectarse al sistema operativo de rescate
Usando la interfaz web, vaya a la página de administración de su servidor: Server → Server list → (server name) Manage. Habilite la consola serie haciendo clic en el botón [SERIAL_CONSOLE]
y siga la guía. La consola se abrirá en una nueva pestaña del navegador. Tenga en cuenta que la conexión de la consola tiene un tiempo de caducidad, por lo que no se quedará allí para siempre. Además, no aparecen muchos mensajes relacionados con el arranque del sistema operativo de rescate, pero sigue siendo mejor que nada. El OS Rescue tarda un tiempo en iniciarse y poder verlo puede permitirle calmarse un poco (solo tenga en cuenta que hay un tiempo entre el momento en que los mensajes dejan de aparecer y el momento en que realmente puede conectarse a través de SSH). La razón por la que necesita iniciar [SERIAL_CONSOLE]
antes de [RESCUE]
es que el botón [SERIAL_CONSOLE]
desaparece una vez que inicie el sistema operativo de rescate.
[SERIAL_CONSOLE]
no está visible. Solo tiene que ir a https://console.online.net/en/server/state/XXXXX/bmc address, reemplazando XXXXX parte con el número real de su servidor.
Ahora vuelva a la página de administración del servidor y haga clic en “[RESCUE]'”. Cuando se le solicite la selección del sistema operativo, seleccione [Ubuntu_16.04_amd64]
y luego haga clic en [CLICK_HERE_TO_LAUNCH_THE_RESCUE_SYSTEM]
. Después de un tiempo, se le presentarán los detalles necesarios para conectarse al sistema operativo de rescate a través de SSH. También puede cambiar a la ventana de
salida [SERIAL_CONSOLE]
para monitorear lo que está sucediendo.
Una vez que el sistema operativo de rescate esté completamente iniciado, conéctese desde su estación de trabajo:
$ ssh username@x.y.z.w -i ./login_key
Cuando se le pregunte Are you sure you want to continue connecting (yes/no)?, responda que sí.
Una vez que haya iniciado sesión, para autenticar el sistema operativo de rescate, en el lado del servidor escriba lo siguiente:
$ cat ~/.ssh/authorized_keys
y luego compare las claves públicas impresas en el terminal con las claves públicas auth_key.pub y login_key.pub que generó anteriormente. Si las dos claves entre el servidor y la estación de trabajo coinciden, está seguro de ir. (Una vez más, si desea comprender los detalles, consulte el LinuxQuestions.org mencionado anteriormente thread).
Ahora, en el lado del servidor, le sugiero que primero inicie el programa screen y luego inicie sesión como root (la contraseña se encuentra en la página de detalles de la conexión del sistema operativo de rescate):
$ screen $ sudo su -
(Siendo paranoico, cambio las contraseñas de usuario y root proporcionadas poronline.net).
No entraré en detalles del programa screen , pero la razón por la que queremos usarlo es su capacidad para mantener abierto el terminal remoto, incluso si la conexión SSH (o más bien la red) se interrumpe o si cierra accidentalmente la Ventana. Normalmente, tal evento rompería el proceso de instalación. Si eso le sucede a usted, y utiliza screen , puede recuperar el terminal remoto (¡con todos los comandos iniciados aún en ejecución!), Simplemente conectándose a través de SSH y luego volviendo a conectar el llamado screen sesión:
$ screen -r $ # Sometimes, detaching the session first is needed: $ screen -rd SESSION_PID
Todo lo anterior significa también que no puede detener la ejecución remota de comandos simplemente cerrando la ventana del terminal local; screen sesión se mantendrá en el extremo remoto hasta que la cierre explícitamente. Por cierto, también puede usar esta funcionalidad para reducir el tráfico de red durante la fase de instalación, es decir, una vez que los paquetes se empezaron a instalar y no necesitan atención, puede desconectarse de la sesión y volver a adjuntarla un tiempo más tarde para verificar el estado. Utiliza la combinación de teclado Ctrl+A D para separar de screen sesión. Verifique en Internet cómo usar el programa screen (la página de manual es en realidad enormemente larga).
6. Configuración del entorno del instalador de Slackware (chroot)
La principal motivación detrás de este HOWTO es el hecho de que online.net no proporciona un método directo de instalación de Slackware en sus servidores Dedibox. Y eso es genial! El punto es, si tal método existiera, sería algo desconocido para un usuario de Slackware: un instalador basado en GUI / Web. Mientras que ser colocado en el shell del instalador de Slackware le permite instalar y configurar el sistema de la manera que desee (TM). Todas las opciones avanzadas están disponibles sin mucha molestia. Y vamos a usarlos todos. : - ^
Ahora, vamos a configurar el instalador de Slackwarechroot:
$ mkdir -p ~/slackware-chroot $ cd ~/slackware-chroot $ wget https://slackware.osuosl.org/slackware64-14.2/isolinux/initrd.img $ gunzip -cd initrd.img | cpio -dvim $ mount --bind /proc proc $ mount --bind /sys sys $ mount --bind /dev dev $ mount --bind /dev/pts dev/pts $ mount --bind /run run $ touch etc/resolv.conf $ mount --bind /etc/resolv.conf etc/resolv.conf
And run the chroot:
$ chroot ~/slackware-chroot /bin/bash --login $ cd
Una vez que haya chrooted, es posible que desee jugar con la variable de entorno TERM , que influirá en la forma en que se muestran dialogs. De forma predeterminada, TERM = linux y no funciona bien si usa screen o si se conecta desde un emulador de terminal que se ejecuta bajo X.
Para obtener los mejores resultados con screen, use lo siguiente:
$ export TERM=screen
y si no usa screen , pero se está conectando desde X:
$ export TERM=xterm
Finalmente, para el terminal virtual (VT), deje el valor predeterminado:
$ export TERM=linux
Welcome to the Slackware Linux installation disk!
7. Particionamiento
Ahora puede particionar el disco a su gusto, con dos excepciones. En este tutorial, usaré una partición separada para ser montada en el directorio /boot . Este directorio contendrá los archivos de configuración del kernel, initrd y bootloader. Lo que nos lleva a la segunda excepción: como gestor de arranque, voy a usar syslinux instalado en MBR, lo que significa que el disco tiene que usar el tipo de etiqueta MBR. Si necesitas GPT, estás por tu cuenta.
El sistema de archivos de la partición / boot debe ser compatible con syslinux . ext4 hará el trabajo bien. Y cuando se trata del tamaño, 128 MiB es suficiente.
Puede usar su herramienta de partición favorita, por ejemplo, fdisk , cfdisk , etc. Voy a utilizar parted . Tenga en cuenta que el disco debe estar en estado “unmanaged”, es decir, los servicios como LVM2 o el software RAID (mdadm) deben estar desactivados. Tuve muchos dolores de cabeza al liberar el disco desde el control de LVM2, cuando estaba jugando con él (pero lo logré ).
Por cierto, el disco ya contendrá la tabla de particiones, que se creó cuando instalamos uno de los sistemas operativos de reserva para habilitar el sistema operativo de rescate. La tabla de particiones se puede limpiar con los siguientes comandos:
$ dd count=1 bs=512 conv=notrunc if=/dev/zero of=/dev/sda $ partprobe
Los siguientes comandos parted crearán la etiqueta MBR y la partición / boot:
$ parted /dev/sda mklabel msdos $ # Start at 1 MiB in the hope of a correct alignment: $ parted -a optimal /dev/sda mkpart primary 1MiB 129MiB $ # Set bootable flag: $ parted /dev/sda set 1 boot on
Con la partición / boot [/dev/sda1] en su lugar, puede particionar el espacio restante de la forma que mejor se adapte a sus necesidades. Voy a usar LVM2 para administrar el disco, así que creo una partición grande [/dev/sda2 ] que se pasará a LVM2. El procedimiento de configuración para habilitar LVM2 se describe en Apéndice A. El siguiente comando parted creará la partición requerida:
$ # Passing "-a optimal" automatically aligns at the last sectors of the disk. $ # The start and end offsets have to be given explicitly: $ parted -a optimal /dev/sda mkpart primary 129MiB 100% $ # Set the 'lvm' flag only if you plan to use LVM2 for managing the disk. $ parted /dev/sda set 2 lvm on
Informe al kernel sobre los cambios de partición:
$ partprobe
Vamos a verificar el resultado:
$ parted /dev/sda print Model: ATA SAMSUNG MZ7LN256 (scsi) Disk /dev/sda: 256GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 135MB 134MB primary ext4 boot 2 135MB 256GB 256GB primary lvm
8. Instalación de Slackware (programa de instalación)
Si prefiere descargar los paquetes requeridos por usted mismo, en lugar de dejar que el programa setup lo haga por usted (en realidad lo prefiero así), ahora es el momento.
Quiero usar rsync para descargar los paquetes de antemano. Como Slackware chroot no proporciona el comando rsync , debemos dejar Slackware chroot por un momento, usar rsync del sistema operativo de rescate de Ubuntu y luego regresar:
$ # Exit from Slackware chroot: $ exit $ mkdir -p ~/slackware-chroot/packages $ cd ~/slackware-chroot/packages $ # Download only: a, ap, d, l, n packages series (I don't need GUI apps), $ # pay !attention! to the "." at the end of command line: $ rsync -vaz rsync://rsync.osuosl.org/slackware/slackware64-14.2/slackware64/{a,ap,d,l,n} . $ wget https://slackware.osuosl.org/slackware64-14.2/slackware64/CHECKSUMS.md5 $ # Verify the checksums of the downloaded packages: $ grep -P "\./(a|ap|d|l|n)/" CHECKSUMS.md5 | md5sum -c --quiet $ mkdir -p ~/slackware-chroot/patches $ cd ~/slackware-chroot/patches $ Download patches, pay !attention! to the "." at the end of command line: $ rsync -vaz rsync://rsync.osuosl.org/slackware/slackware64-14.2/patches/packages . $ wget https://slackware.osuosl.org/slackware64-14.2/patches/CHECKSUMS.md5 $ # Verify the checksums of the downloaded patches: $ grep -P "\./packages" CHECKSUMS.md5 | md5sum -c --quiet $ # Return to Slackware chroot: $ chroot ~/slackware-chroot /bin/bash --login $ cd $ # Remember to update TERM as described earlier: $ export TERM=screen
Teniendo todas las particiones en su lugar, ahora es el momento de ejecutar el programa setup y realizar la instalación como lo sabe. Solo recuerde formatear y montar la partición / boot cuando se le solicite mediante setup . Cuando se le solicite, omita LILO instalación, ya que vamos a utilizar syslinux en su lugar. Si descargó los paquetes de antemano, dirija configuración al directorio / paquetes premontado. De lo contrario, use setup para descargar los paquetes por usted.
9. Freshly installed Slackware chroot
Yes, one more chroot to deal with. The configuration of the freshly installed system is best performed from the actual system itself. And we're going to do exactly that. When the setup program finished its job, it has left the Slackware root filesystem (and some additional ones) mounted on /mnt. And there is nothing preventing us from chrooting into this directory, meaning that we can actually “log in” into the freshly installed system without rebooting.
This system is somehow limited (i.e. there are no services running), but has all the tools needed to perform the final configuration steps before rebooting the server.
To avoid any unpleasant surprises, we mount some possibly needed filesystems, before chrooting:
$ cd /mnt $ mount --bind /run run $ mount --bind /dev/pts dev/pts $ # Only needed if you downloaded the patches and want to apply them: $ mkdir run/patches $ mount --bind /patches/packages run/patches $ # Enter Slackware Chroot (tm): $ chroot /mnt /bin/bash --login $ cd $ # Remember to update TERM as described earlier: $ export TERM=screen
10. Applying patches
The following set of commands will apply all the available patches and let you know of any .new files to deal with:
$ find /run/patches -name \*.txz -exec upgradepkg {} \; $ find /etc -name \*.new
11. Bootloader (syslinux)
The following set of commands will install the syslinux bootloader:
$ extlinux --install /boot $ dd count=1 bs=440 conv=notrunc if=/usr/share/syslinux/mbr.bin of=/dev/sda
Then, create the syslinux config file:
$ cat << EOF > /boot/syslinux.cfg PROMPT 0 TIMEOUT 0 DEFAULT vmlinuz-generic SERIAL 1 9600 LABEL vmlinuz-generic KERNEL vmlinuz-generic APPEND console=ttyS1,9600 printk.time=0 quiet ipv6.disable=1 ro INITRD initrd-generic.gz EOF
This configuration will enable the messages to appear on the serial console. I also specify some kernel parameters (printk.time=0 quiet) to considerably silence its output (error messages would still appear). As I do not want to bother with IPv6, I disable it at kernel level (ipv6.disable=1). As you can see, we will be using the generic kernel with initrd. This is the only way (that is, by means of initrd) the LVM2 can be made functional.
Note that the kernel and initrd paths specified in syslinux.cfg have to be relative to the /boot directory. This is because syslinux is unable to read from LVM2 based root partition, so something like /boot/vmlinuz-generic would not work (/ is on LVM2 partition in my case).
12. Initial RAM disk (initrd)
Create the initrd config file:
$ cat << EOF > /etc/mkinitrd.conf # mkinitrd.conf # See "man mkinitrd.conf" for details on the syntax of this file # #SOURCE_TREE="/boot/initrd-tree" #CLEAR_TREE="0" OUTPUT_IMAGE="/boot/initrd-generic.gz" KERNEL_VERSION="$( readlink /boot/vmlinuz-generic | rev | cut -f1 -d- | rev )" #KEYMAP="us" MODULE_LIST="ext4" #LUKSDEV="/dev/sda2" #LUKSKEY="LABEL=TRAVELSTICK:/keys/alienbob.luks" ROOTDEV="/dev/vg0/rootfs" ROOTFS="ext4" #RESUMEDEV="/dev/sda2" #RAID="0" LVM="1" #UDEV="1" #MODCONF="0" #MICROCODE_ARCH="/boot/intel-ucode.cpio" WAIT="0" EOF
As the comment says, refer to the mkinitrd.conf man page for details. In particular, make sure your MODULE_LIST, ROOTDEV and ROOTFS are defined correctly. If you don't need LVM2 support, you can set LVM=“0” (or comment it out).
The notable thing is how the KERNEL_VERSION is automatically derived, not for the running kernel, but rather for the installed kernel (which might be newer or older than the running one). /etc/mkinitrd.conf is sourced by the /sbin/mkinitrd script, so it is possible to use shell commands within the config file. On standard Slackware installation, you will find that /boot/vmlinuz-generic is actually a symlink:
$ ls -l /boot/vmlinuz-generic lrwxrwxrwx 1 root root 22 Dec 13 00:44 /boot/vmlinuz-generic -> vmlinuz-generic-4.4.38
So the following code:
KERNEL_VERSION="$( readlink /boot/vmlinuz-generic | rev | cut -f1 -d- | rev )"
will simply extract the version number from the installed kernel image.
And finally, to create the initrd, run the following command:
$ mkinitrd -c -F
Note that it is not necessary to run any syslinux related commands after creating or updating the initrd image. This is different from LILO, where you have to run lilo command after changing the initrd image.
13. Enabling serial console access
As of now, the serial console configuration in /boot/syslinux.cfg allows for interacting with the bootloader and also to see the kernel messages, but it does not allow for root login over serial port. If you want to enable it, then uncomment the following line in /etc/inittab:
s2:12345:respawn:/sbin/agetty -L ttyS1 9600 vt100
and the following line in /etc/securetty:
ttyS1
You might also want to comment out the follwing lines in /etc/inittab:
#c1:12345:respawn:/sbin/agetty --noclear 38400 tty1 linux #c2:12345:respawn:/sbin/agetty 38400 tty2 linux #c3:12345:respawn:/sbin/agetty 38400 tty3 linux #c4:12345:respawn:/sbin/agetty 38400 tty4 linux #c5:12345:respawn:/sbin/agetty 38400 tty5 linux #c6:12345:respawn:/sbin/agetty 38400 tty6 linux
and the following lines in /etc/securetty:
#tty1 #tty2 #tty3 #tty4 #tty5 #tty6
tty[1-6] are for the standard VT login prompts, but since we have no keyboard and no display, we cannot make any use of them.
14. Finalising the installation
We're done with the installation and initial configuration of the Slackware Linux. You can now prepare the system for reboot and, well, reboot. Before doing that, you might also consider looking at the Appendix B, where I explain how to prepare the SSH stuff, so that after rebooting, you can connect to the server with SSH right away. (Otherwise, you will have to log in over serial console to perform the other configuration tasks).
First, prepare the hard disk to safely survive the reboot phase. Note that, I only (u)mount /mnt/boot and /mnt partitions as these are the only hard disk partitions I have. If you have more mounted disk partitions, you should umount them too:
$ # Exit freshly installed Slackware chroot: $ exit $ umount -v /mnt/boot $ mount -v -o remount,ro /mnt $ # This never hurts: $ sync $ # Only needed if LVM2 is used: $ vgchange -an --ignorelockingfailure $ # This never hurts again: $ sync $ # Shouldn't be needed, but just in case: $ sleep 3
Now, go to the server management page and press [BOOT_IN_NORMAL_MODE]
button. You can observe the reboot process on the serial console.
A. Setting up LVM2 disk management
Before continuing to LVM2 partitioning, if the disk is already under LVM2 control, it has to be first deactivated. I use the following set of commands to do so:
$ lvscan $ ( cd /dev/mapper && lvchange -an $(pvs --noheadings -o vg_name) ) $ vgscan $ vgchange -an $(pvs --noheadings -o vg_name) $ pvscan $ pvremove -ffy $(pvs --noheadings -o pv_name) $ partprobe
Remember that the disk has already been partitioned using MBR in the “Partitioning” chapter and /dev/sda2 already exists. The following set of commands will activate LVM2 on /dev/sda2 and create the partitions (the LVM2 partitions are going to sit on top of /dev/sda2 partition):
$ pvcreate /dev/sda2 $ pvdisplay $ vgcreate vg0 /dev/sda2 $ vgdisplay $ # Create the partitions (logical volumes): $ lvcreate -L 12G vg0 -n rootfs $ lvdisplay $ vgchange -ay
NOTE:
- The good thing about LVM2 is that you can easily add more partitions later on.
- I have chosen partition sizes that suit my current needs, leaving significant free space. LVM2 can easily grow the sizes later on if needed.
- I haven't created the swap partition. The server has more than enough of RAM. But if needed, it can be easily added later on.
B. SSH server configuration (before rebooting)
If you enabled the sshd service during setup, it'll be automatically started the next time the Slackware system boots. Unfortunately, you won't be able to connect to it for two reasons:
- the host keys are not generated yet, so you won't be able to verify host's authenticity and of course you don't want to connect without being able to verify it,
- user's public key authentication is not set up and of course you don't want to be logging in using password authentication.
To solve the first issue, we need to manually perform the task that would normally be done by the Slackware init scripts when the system boots for the first time. Generating the host keys basically boils down to the following command:
$ ssh-keygen -A
And then to obtain the host's key fingerprint (I stick to RSA):
$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key
Setting up public key authentication is a bit more cumbersome, but still far from being rocket science. :-^ First, you need to upload your public key from your workstation to the server. Run the following command on the workstation:
$ scp -i ./login_key ~/.ssh/id_rsa.pub user@x.y.z.w:~
NOTE: The above command uploads ~/.ssh/id_rsa.pub public key, but for the transfer authentication, it uses the very same key you uploaded earlier using the Web interface.
Now, back to the server, create the required ~/.ssh directory:
$ mkdir ~/.ssh
I told you to use the screen program at the beginning, right? Now we will make use of it. The public key that you uploaded above has been placed in the user home directory of the Ubuntu rescue OS. We need to rename it to the authorized_keys file in the ~/.ssh directory of the fresh Slackware installation:
$ # Detach from screen session, you'll be dropped to Ubuntu rescue OS: (keyboard) Ctrl+a d $ # Login as root: $ sudo su - $ mv /home/user/id_rsa.pub /root/slackware-chroot/mnt/root/.ssh/authorized_keys $ # Exit root login: $ exit $ Re-attach to screen session: $ screen -r
Ensure correct ownership and permissions, otherwise sshd won't let us in:
$ chown root:root ~/.ssh $ chown root:root ~/.ssh/authorized_keys $ chmod 0700 ~/.ssh $ chmod 0600 ~/.ssh/authorized_keys
NOTE:
- If you haven't used screen, you would just open second SSH connection to perform the above task. Alternatively, you could exit all the chroots and then run them again, but who would want to do that?
- Remember that the correct server's network configuration has to be in place for you to be able to connect over SSH after reboot.
At this point, all the pieces should be in place and you should be able to successfully login to your fresh Slackware installation after the server is rebooted.
NOTE: I know I allow for root login over SSH. I have to live with that. :-^
Sources
- Originally written by Andrzej Telszewski