Tag: SSH | Page 2 | SkyMinds.Net

Linux : résoudre l’erreur SSH “the RSA host key differs from the key for the IP address”

30 March 202219 novembre 2014 by Matt Biscay · Lecture: 2 minutes

Au cours de mes errements avec le mode rescue, j’ai été obligé de m’identifier sur le serveur avec des identifiants temporaires différents de ceux que j’utilise habituellement.

J’ai retiré la clé habituelle, ajouté la nouvelle (celle du mode rescue), et maintenant, de retour sur ma session habituelle, SSH se plaint – à juste titre – que l’empreinte de la clé RSA du serveur a changé.

Problème : la clé RSA du serveur a changé

Dans ma précipitation à vouloir tout réparer, j’ai ajouté les identifiants temporaires de manière permanente au fichier /home/matt/.ssh/known_hosts.

Et, bien sûr, dès que j’ai voulu me connecter, j’ai obtenu ce message d’erreur :

Warning: the RSA host key for 'hostname' differs from the key for the IP address 'xxx.xxx.xxx.xxx'
Offending key for IP in /home/matt/.ssh/known_hosts:16
Matching host key in /home/matt/.ssh/known_hosts:11
Are you sure you want to continue connecting (yes/no)? Code language: JavaScript (javascript)

Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH

5 September 202113 novembre 2014 by Matt Biscay · Lecture: 7 minutes

J’ai lamentablement fait planter le serveur en voulant mettre le kernel à jour…

Heureusement, il existe le mode rescue chez OVH qui permet d’installer un linux provisoire sur le serveur et d’initier une connexion SSH pour que l’on puisse réparer le système.

Si jamais cela vous arrive, voici la marche à suivre.

Passage en mode rescue depuis le manager OVH

1. Aller sur le manager OVH > Dedicated > Infrastructure > clic sur votre serveur > clic sur l’onglet Server Status.

Serveur dédié : activer X11 forwarding pour SSH

19 August 202003 juin 2013 by Matt Biscay · Lecture: 2 minutes

Si jamais vous avez besoin que votre serveur dédié vous renvoie une image ou quoi que ce soit de graphique via SSH, vous aurez très certainement besoin d’avoir l’X11 Forwarding activé.

Il ne l’est pas par défaut donc si vous obtenez l’erreur suivante:

X11 forwarding request failed on channel 0

alors il vous faut paramétrer l’option dans la configuration SSH du serveur.

Etape 1 : installer xauth

Sur le serveur et sur le client, xauth doit être installé. Il ne l’est pas sur notre serveur Debian, donc on l’installe :

apt-get install xauthCode language: JavaScript (javascript)

Etape 2 : vérifier que X11 forwarding est activé dans SSH

Sur le serveur, on édite la configuration du daemon SSH :

nano /etc/ssh/sshd_config

Et on vérifie qu’on a bien ForwardX11 est bien à yes :

AllowTcpForwarding yes
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
AddressFamily inet

et sur le client, on édite aussi la configuration SSH :

nano /etc/ssh/ssh_config

avec :

ForwardAgent yes
ForwardX11 yes
ForwardX11Trusted yes

Bash : réparer les tables MySQL en cas de crash

16 November 201520 janvier 2013 by Matt Biscay · Lecture: 1 minute

Bash Il arrive que parfois une table SQL soit complètement plantée, ce qui peut bloquer l’accès à la base de données et donc l’accès au site.

Pour éviter cela, j’ai écrit un petit script bash qui me permet de stopper le serveur MySQL, procéder à la réparation de toutes les tables de toutes les bases de données puis relancer le serveur MySQL, Apache et Varnish.

#!/bin/sh
# MySQL Auto-Repair
# Written by Matt - skyminds.net

# stop the MySQL server
/etc/init.d/mysql stop

# check for errors
myisamchk /var/lib/mysql/*/*.MYI

# ask permission to repair
read -p "Repair tables ? (y/n)" -n 1 -r
if [[ $REPLY =~ ^[Yy]$ ]]
then
	# repair everything
	myisamchk -r /var/lib/mysql/*/*.MYI

	# restart servers
	/etc/init.d/mysql restart
	/etc/init.d/apache2 restart
	/etc/init.d/varnish restart
else
	/etc/init.d/mysql restart
fi

C’est le genre de petit fichier bash à garder au frais sur le serveur, facile à lancer en SSH depuis n’importe quel terminal en cas de besoin.

Rsync: rapatrier les fichiers du serveur à la maison

8 April 202228 juillet 2012 by Matt Biscay · Lecture: 2 minutes

Je vous ai déjà parlé de rsync pour transférer des fichiers d’un serveur à un autre.

Supposons maintenant que vous vouliez récupérer les fichiers qui sont sur votre serveur chez vous, à la maison.

Cela ne prend que quelques minutes à mettre en place et cela sert très souvent.

Etape 1 : ouvrir le port 22 dans la box ou le routeur

Rendez-vous dans l’interface d’administration de votre box ou routeur :

si ce n’est déjà fait, attribuez une IP fixe à votre PC en identifiant l’adresse MAC de sa carte réseau.
ouvrez le port 22 (SSH) en TCP et redirigez-le vers l’adresse fixe de l’étape précédente.

Voilà, le port est ouvert et redirigé au niveau du routeur.

Etape 2 : ouvrir le port 22 dans le firewall de la machine

Je suis sous Linux (Debian, Ubuntu, Mint…), j’utilise donc iptables en root :

iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 22 -j ACCEPT

Le port 22 est maintenant ouvert aux connections entrantes et sortantes sur la machine.

BIND9 : supprimer le message "success resolving after reducing the advertised EDNS UDP packet size to 512 octets" des logs photo

BIND9 : résoudre l’erreur “ignoring out-of-zone data”

8 April 202210 mai 2012 by Matt Biscay · Lecture: 2 minutes

Bien configurer BIND9 pour que tout fonctionne correctement n’est pas vraiment intuitif et le parcours est semé d’embûches.

Sur mon ancien serveur OVH, j’ai connu l’erreur suivante pendant des mois :

/etc/bind/skyminds.net.hosts:15: ignoring out-of-zone data (ksXXXXXXX.kimsufi.com)

Alors bon, cela n’empêche pas du tout le serveur DNS de faire son travail mais c’est quand même un peu gênant de savoir que la configuration n’est pas optimale.

Voici comment y remédier.

Problème : BIND renvoie l’erreur “ignoring out-of-zone data”

Lors d’un checkconf BIND :

named-checkconf -z

Vous obtenez ceci :

/etc/bind/db.skyminds.net:15: ignoring out-of-zone data (ks3094174.kimsufi.com)
zone skyminds.net/IN: loaded serial 2011020911
zone localhost/IN: loaded serial 2
zone 127.in-addr.arpa/IN: loaded serial 1
zone 0.in-addr.arpa/IN: loaded serial 1
zone 255.in-addr.arpa/IN: loaded serial 1

Ce qui n’est pas vraiment optimal.

Migration de serveur : bonjour Kimsufi 750G

4 May 202228 mars 2012 by Matt Biscay · Lecture: 2 minutes

J’ai peu posté ces derniers jours et ce pour plusieurs raisons. Premièrement, il fait beau. Donc j’en profite, surtout qu’il fait aussi chaud qu’en mai-juin. Et deuxièmement, je viens de migrer le site sur un serveur plus puissant.

Migration entre deux serveurs

Il y a une grosse différence entre monter un serveur de A à Z, comme j’avais fait précédemment, et migrer données et programmes d’un serveur A à un serveur B.

L’important pour moi était de réutiliser au maximum mes configurations donc j’ai repris mes tutos un à un, tout en copiant les fichiers que j’avais précédemment créés ou édités sur le nouveau serveur.

Résultats ?

Et bien cela fonctionne très bien ! J’ai connu quelques mésaventures mais j’ai pris plein de notes donc il y a là de la matière pour quelques futurs articles. En gros le site a été indisponible pendant 1h samedi mais je pense que cela ne s’est pas trop vu.

Au niveau technique, on peut apprendre pas mal d’informations sur le processeur du serveur en lançant la commande :

less /proc/cpuinfo

L’ancien serveur était un Intel(R) Celeron(R) CPU 220 @ 1.20GHz et 2 Go de RAM.
Le nouveau serveur est un Intel(R) Core(TM)2 Quad CPU Q8300 @ 2.50GHz et 4 Go de RAM.

MySQL : résoudre l’erreur “Table is marked as crashed and last (automatic?) repair failed”

1 April 202206 février 2012 by Matt Biscay · Lecture: 3 minutes

Hier soir, gros bug sur le site : plus moyen d’accéder aux pages du site ou de sauvegarder un article. Je lance un top, le serveur n’a pas l’air d’être surchargé du tout. Je relance Apache, Varnish et MySQL et là…

Stopping MySQL database server: mysqld failed!
/etc/init.d/mysql: ERROR: The partition with /var/lib/mysql is too full! ... failed!Code language: JavaScript (javascript)

Ah cette erreur-là, je l’ai déjà eue ! Je fais un peu de ménage et je relance MySQL :

/etc/init.d/mysql restart

Stopping MySQL database server: mysqld.
Starting MySQL database server: mysqld.
Checking for corrupt, not cleanly closed and upgrade needing tables..
ERROR 144 (HY000) at line 1: Table './skyminds/wp_posts' is marked as crashed and last (automatic?) repair failedCode language: JavaScript (javascript)

Et là, c’est le drame : le terminal est dans les choux comme attendant quelque chose et en lançant le site, il n’y a plus aucune information. Rien que le design, plus d’articles. Gloups.

Je jette un coup d’oeil sur le serveur, j’ai mes sauvegardes des derniers jours mais pas de tout ce que j’ai écrit aujourd’hui. Je tente un REPAIR mais phpmyadmin refuse catégoriquement :

SQL show index from `wp_posts` failed : Table './skyminds/wp_posts' is marked as crashed and last (automatic?) repair failedCode language: JavaScript (javascript)

La solution : lancer myisamchk

La solution que j’ai utilisé consiste à lancer la commande myisamchk, qui est une commande de bas niveau qui va vérifier et réparer notre table.

On commence par arrêter le serveur MySQL :

/etc/init.d/mysql stop

et on lance myisamchk avec ces paramètres sur notre base de données qui se trouve sous /var/lib/mysql/:

myisamchk -r -v -f --sort_buffer_size=128M --key_buffer_size=128M /var/lib/mysql/skyminds/wp_posts.MYICode language: JavaScript (javascript)

Voilà ce que cela retourne :

- recovering (with sort) MyISAM-table '/var/lib/mysql/skyminds/wp_posts.MYI'
Data records: 0
- Fixing index 1
  - Searching for keys, allocating buffer for 295411 keys
  - Dumping 3420 keys
- Fixing index 2
  - Searching for keys, allocating buffer for 3421 keys
  - Dumping 3420 keys
- Fixing index 3
  - Searching for keys, allocating buffer for 3421 keys
  - Dumping 3420 keys
- Fixing index 4
  - Searching for keys, allocating buffer for 3421 keys
  - Dumping 3420 keys
- Fixing index 5
  - Searching for keys, allocating buffer for 3421 keys
  - Dumping 3420 keys
- Fixing index 6
  - Searching for keys, allocating buffer for 3421 keys
  - Dumping 3420 keys
- Fixing index 7
  - Searching for keys, allocating buffer for 3421 keys
  - Dumping 3420 keys
- Fixing index 8
  - Searching for keys, allocating buffer for 3421 keys
  - Dumping 3420 keys
- Fixing index 9
  - Searching for keys, allocating buffer for 3421 keys
  - Dumping 3420 keys
- Fixing index 10
  - Searching for keys, allocating buffer for 1177347 keys
  - Dumping 275199 keys
- Fixing index 11
  - Searching for keys, allocating buffer for 1177347 keys
  - Dumping 275199 keys
- Fixing index 12
  - Searching for keys, allocating buffer for 1177347 keys
  - Dumping 275199 keys
Data records: 3420Code language: JavaScript (javascript)

On relance MySQL :

/etc/init.d/mysql start

et cette fois, tout se passe bien :

Starting MySQL database server: mysqld.
Checking for corrupt, not cleanly closed and upgrade needing tables..

Tout est revenu mais je me dis que je devrais peut-être passer à 2 sauvegardes par jour…

Serveur dédié : configurer la limite mémoire pour PHP et Suhosin

5 April 202217 décembre 2011 by Matt Biscay · Lecture: 2 minutes

Aujourd’hui, je vous livre la solution à un problème auquel vous avez peut-être été confronté lors de la configuration de votre serveur dédié – il s’agit d’une erreur que l’on peut trouver dans les fichiers logs d’Apache :

Dec 12 16:19:26 mail suhosin[22860]: ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value (attacker '82.83.84.85', file '/home/skyminds/public_html/wp-admin/admin.php', line 96)Code language: JavaScript (javascript)

Etape 1 : paramétrage de memory_limit dans php.ini

On édite notre fichier php.ini :

nano /etc/php5/apache2/php.ini

On recherche la variable memory_limit et on l’augmente à 256MB :

; Maximum amount of memory a script may consume (128MB)
; http://php.net/manual/en/ini.core.php#ini.memory-limit
memory_limit = 256MCode language: JavaScript (javascript)

Note : vérifiez que vous éditez bien le bon fichier php.ini ! Je me suis aperçu après quelques essais que celui qui correspondait à mon installation était en fait /etc/php5/apache2filter/php.ini.

Lancez un phpinfo();pour être sûr du fichier à éditer.

Serveur dédié : mettre à jour le noyau Debian de la Kimsufi

27 September 202411 août 2011 by Matt Biscay · Lecture: 2 minutes

Aujourd’hui, on met à jour le noyau linux de notre installation Debian sur notre Kimsufi.

Un noyau à jour, c’est toujours mieux pour bénéficier des derniers patchs/améliorations/correctifs de sécurité du noyau.

OVH compile ses propres noyaux, offrant différentes options. Nous choisirons le noyau avec GRS : grsecurity est un correctif de sécurité pour le noyau incluant PaX, un système de contrôle d’accès à base de rôles et différents moyen de renforcer la sécurité générale du noyau.

Téléchargement du dernier noyau linux chez OVH

Une fois loggés en SSH, on se place dans le répertoire /boot :

cd /boot

On regarde ensuite la liste des noyaux linux modifiés par OVH pour les Kimsufi : ftp://ftp.ovh.net/made-in-ovh/bzImage/.

On récupère 2 fichiers : le fichier bzImage et le fichier System.map associé. Pour mon serveur, je prends les versions -grs-ipv6-64 : certaines mesures de sécurité sont incluses dans le noyau made in OVH (-grs), avec support de l’ipv6 sur un système 64 bits.

Nous prenons donc la dernière version du noyau ici : ftp://ftp.ovh.net/made-in-ovh/bzImage/latest-experimental/:

wget http://ftp.ovh.net/made-in-ovh/bzImage/latest-experimental/System.map-4.1.7-xxxx-grs-ipv6-64
wget http://ftp.ovh.net/made-in-ovh/bzImage/latest-experimental/bzImage-4.1.7-xxxx-grs-ipv6-64
wget http://ftp.ovh.net/made-in-ovh/bzImage/latest-experimental/config-4.1.7-xxxx-grs-ipv6-64Code language: JavaScript (javascript)

MySQL : résoudre le message "Warning: Using a password on the command line interface can be insecure." photo

Résoudre le non-redémarrage du serveur MySQL : le manque d’espace sur une partition disque

5 April 202210 juillet 2011 by Matt Biscay · Lecture: 2 minutes

Il y a quelques temps, j’ai eu la surprise de constater que le site était down au niveau de la base de données, dont le service refusait catégoriquement de redémarrer. En regardant les logs du serveur, voici ce que j’ai découvert :

/etc/init.d/mysql: ERROR: The partition with /var/lib/mysql is too full! failed!Code language: JavaScript (javascript)

La partition sur laquelle se trouvent les bases de données SQL était pleine ! Effectivement, un petit

df -h

m’a appris que la partition /dev/sda1 était pleine à 100% :

Sys. de fich.         Tail.       Occ.       Disp.       %Occ.       Monté sur
/dev/sda1            9,7G       9,3G          0        100%         /
tmpfs                  984M         0        984M          0%        /lib/init/rw
udev                   10M        2,7M       7,4M         27%       /dev
tmpfs                 984M          0        984M           0%       /dev/shm
/dev/sda2            452G       648M      429G          1%       /home

Serveur dédié : analyse des performances du serveur

9 April 202230 juin 2011 by Matt Biscay · Lecture: 2 minutes

Cela fait quelques mois que le nouveau serveur est en place et il est temps de faire un petit bilan au niveau des performances.

Charge processeur

Tout d’abord, bien que le serveur soit équipé des mêmes caractéristiques techniques (même CPU, même quantité de RAM), il s’avère qu’il est beaucoup plus réactif que l’ancien.

Le processeur n’est plus surchargé en permanence et lorsque l’on lance un top, la charge du processeur est le plus souvent entre 0.05 et 0.20, ce qui est idéal.

A titre de comparaison, l’ancien serveur avait une charge souvent supérieure à 2.

Analyse du temps de chargement des pages via Google Webmaster Tools

Il y a quelques semaines, je me suis connecté sur Google Webmaster Tools et lorsque j’ai atteint le graphique du temps de chargement des pages du site, j’ai eu l’agréable surprise de découvrir ceci :

← Précédent Suivant →