Expert Puppet sur serveur Linux Debian

Redémarrer un VPS OVH en mode rescue pour le réparer

1. Accédez à l'espace client OVH

Accédez au manager dans la section “Server” et cliquez sur votre VPS.

2. Redémarrez le VPS en mode Rescue

Après quelques minutes, un e-mail arrive contenant le login (root) et le mot de passe du système rescue :

3. Connexion par SSH

Attention, le login en mode rescue est root !

3.1 Première tentative

				
					ssh root@vps-xxxxxxx.vps.ovh.net
				
			
				
					@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:aHD6pBYP1zHxxxxxxx7hp4KwI4yl5gr5OVmBJZ/ZBE.
Please contact your system administrator.
Add correct host key in /home/kiwiof09/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/coin/.ssh/known_hosts:75
  remove with:
  ssh-keygen -f "/home/coin/.ssh/known_hosts" -R "vps-xxxxxxx.vps.ovh.net"
ECDSA host key for vps-xxxxxxx.vps.ovh.net has changed and you have requested strict checking.
Host key verification failed.

				
			

3.2 Sur votre poste de travail, effacez les empreintes de clés du serveur

				
					ssh-keygen -f "/home/coin/.ssh/known_hosts" -R "vps-xxxxxxx.vps.ovh.net"
ssh-keygen -f "/home/coin/.ssh/known_hosts" -R "51.38.yyy.yyy" 
ssh-keygen -f "/home/coin/.ssh/known_hosts" -R "2001:xxxx:xxx:xxxx::xxxx"
				
			

3.3 Nouvelle tentative de connexion

				
					ssh root@vps-xxxxxxx.vps.ovh.net
				
			
				
					The authenticity of host 'vps-xxxxxxx.vps.ovh.net (51.38.xxx.xxx)' can't be established.
ECDSA key fingerprint is SHA256:aHD6pBYP1zxxxxxxxKwI4yl5gr5OVmBJZ/ZBE.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'vps-xxxxxxx.vps.ovh.net,51.38.xxx.xxx' (ECDSA) to the list of known hosts.
root@vps-xxxxxxx.vps.ovh.net's password:
Linux vps-xxxxxxx 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11) x86_64

GNU/Linux, to the rescue!

Server: vps-xxxxxxx
Login: root
Password: azezeazeaeazezae

root@vps-xxxxxxx:~#
				
			

3.4 Listez les disques

				
					lsblk
				
			
				
					NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 2.5G 0 disk
└─sda1 8:1 0 2.5G 0 part /
sdb 8:16 0 20G 0 disk
└─sdb1 8:17 0 20G 0 part
				
			

On peut voir que le disque rescue est le disque sda1 et il correspond à la racine (/) mais le disque du serveur est sdb1 !

3.5 Changez votre racine de connexion pour pouvoir travailler dans le serveur

				
					mkdir -p /mnt/sdb1
mount /dev/sdb1 /mnt/sdb1
mount -t proc proc /mnt/sdb1/proc/ 
mount -t sysfs sys /mnt/sdb1/sys/
mount -o bind /dev /mnt/sdb1/dev/ 
mount -t devpts devpts /mnt/sdb1/dev/pts
mkdir -p /run/chroot/lock
mount -o bind /run/chroot /mnt/sdb1/run
chroot /mnt/sdb1 /bin/bash
source /etc/default/locale
				
			

3.6 Listez de nouveau les disques

				
					lsblk
				
			
				
					NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 2.5G 0 disk
└─sda1 8:1 0 2.5G 0 part
sdb 8:16 0 20G 0 disk
└─sdb1 8:17 0 20G 0 part /
				
			

La nouvelle racine est sur sdb1 ! Très bien !

3.7 Vous pouvez maintenant réparer le serveur

….

3.8 Sortir de l'environnement et revenir à la racine du système rescue

				
					exit
umount /mnt/sdb1/run
umount /mnt/sdb1/dev/pts
umount /mnt/sdb1/dev/
umount /mnt/sdb1/sys/
umount /mnt/sdb1/proc/
umount /mnt/sdb1
				
			

4. Retournez dans le manager OVH

Et redémarrez le serveur en mode normal :

Quelle est la mystérieuse ingénierie qui me permet d'obtenir un serveur Linux fiable et performant, sans devoir monter la garde jour et nuit ?

Consulter la méthode LIBRE MASTER