ssh secure shell laptop

SSH : Host key verification failed

Voici la solution pour le problème “authenticity of host ‘example.com can’t be established” ou “Host key verification failed” lors d’une session SSH sous Linux, MacOS ou Windows.

J’ai récemment travaillé sur un site WordPress multisite hébergé sur WPEngine. Lorsque j’ai voulu me connecter au site en SSH, j’ai reçu une drôle d’erreur:

The authenticity of host 'example.ssh.wpengine.net (xxx.xxx.xxx.xxx)' can't be established.
RSA key fingerprint is SHA256:T8IoIg6/q7i3pVfZipYtxow4.
This host key is known by the following other names/addresses:
    ~/.ssh/known_hosts:38: 1.ssh.wpengine.net
    ~/.ssh/known_hosts:42: 2.ssh.wpengine.net
    ~/.ssh/known_hosts:47: 3.ssh.wpengine.net
    ~/.ssh/known_hosts:52: 4.ssh.wpengine.net
    ~/.ssh/known_hosts:54: 5.ssh.wpengine.net
    ~/.ssh/known_hosts:56: 6.ssh.wpengine.net
    ~/.ssh/known_hosts:76: 7.ssh.wpengine.net
    (2 additional names omitted)
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Host key verification failed.

Comme vous pouvez le voir, il y a déjà pas mal de domaines connus dans mon trousseau SSH, qui appartiennent à ssh.wpengine.net.

Pour une raison obscure toutefois, le nouveau sous-domaine n’est pas admis, contrairement aux sous-domaines précédents qui n’avaient posé aucun problème.

Solution: ajouter la clé au trousseau manuellement

Si la clé ne peut être ajoutée automatiquement, ajoutons-la manuellement et tentons de nous connecter.

Concrétement, il faut donc insérer la clé RSA du serveur dans le fichier /home/user/.ssh/known_hosts de la machine qui se connecte en SSH au serveur distant.

Nous pouvons faire cela en une seule commande:

ssh-keyscan -t rsa example.ssh.wpengine.net >>  ~/.ssh/known_hosts
# example.ssh.wpengine.net:22 SSH-2.0-Go

Voici ce que fait la commande:

  • ssh-keyscan -t rsa SSH.EXAMPLE.COM : cela récupère la clé RSA de l’hôte SSH.EXAMPLE.COM
  • >> ~/.ssh/known_hosts : cela copie la clé et l’insère dans le répertoire .ssh du dossier personnel de notre utilisateur, à la fin du fichier known_hosts qui contient tous les hôtes et clés RSA pour SSH.

Lire la suite

WHM logo

WHM : obtenir l’accès root pour SSH

Je suis intervenu récemment sur un site qui tourne sur un serveur avec WHM (Cpanel) et j’ai eu besoin d’avoir un accès root en SSH.

Mais problème: l’hébergeur n’autorise pas l’accès root. Il faut signer une décharge de manière manuscrite qui exempte l’hébergeur de toute faute en cas de souci et met fin au support technique… ce qui n’est certainement pas ce que l’on souhaite, ni ce que notre client désire!

En cherchant un peu, j’ai trouvé un moyen très simple de circonvenir à ce problème.

Vérification de l’accès SSH de notre utilisateur

Connectez-vous à WHM.

Ensuite, allez dans Account Functions → Manage Shell Access pour vérifier que la connexion SSH est bien activée pour notre utilisateur.

Choisissez l’option Normal Shell :

WHM: configurer l'accès ssh de l'utilisateur
WHM: configurer l’accès ssh de l’utilisateur

Ajouter l’utilisateur au Wheel Group

Nous allons maintenant ajouter notre utilisateur au Wheel Group. C’est cette étape qui nous permettra d’obtenir l’accès root en SSH.

Lire la suite

Activer SSH sous CPanel photo 4

SSH : solution pour l’erreur “Permissions 0644 for ‘id_rsa.pub’ are too open”

Lors d’une connexion SSH sur le serveur d’un client chez WPEngine, je suis tombé sur le message d’erreur suivant:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/Users/matt/.ssh/id_ed25519.pub' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/Users/matt/.ssh/id_ed25519.pub": bad permissions

Voici la commande que j’avais entré:

ssh -i ~/.ssh/id_ed25519.pub -o IdentitiesOnly=yes EXAMPLE@wEXAMPLE.ssh.wpengine.net

Au lieu d’utiliser ma clé privée, j’ai utilisé ma clé publique (id_ed25519.pub) qui – comme elle est publique – bénéficie de droits plus large que la clé privée.

Il faut donc relancer la commande en retirant l’extension .pub du chemin de la clé, pour que la clé privée soit prise en compte:

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes EXAMPLE@wEXAMPLE.ssh.wpengine.net

Dès lors, plus de problème de connexion et la connexion sur le serveur WPEngine se fait sans souci:

  ____  _____  _____
 ╱   ▕ ▕    ▕ ▕    ▕
▕    ▕ ▕    ▕ ▕    ▕
▕____▕  ╲___╱  ╲___▕                                      ▫
 ____           ____     ▃  ▃  ▃  ▃▃▃    ___   __    __      __   ___
▕    ▕    _    ╱   ▕     █  █  █ ▕█▀▀▙  ▕___) |  ▕  ╱  ▕ ▕  |  ▕ ▕___)
▕    ▕   ( )  ▕    ▕      ██ ██  ▕███▛  ▕     |  ▕ ▕   ▕ ▕  |  ▕ ▕
▕____╱    ‾    ╲___▕       █ █   ▕█      ╲__╱ |  ▕  ╲__▕ ▕  |  ▕  ╲__╱
 ____    ___   ___                                  ___╱
▕    ╲  ╱   ╲ ▕    ╲
▕    ▕ ▕    ▕ ▕    ▕
▕____╱ ▕____▕ ▕____▕

WP Engine Shell - PHP 7.3
Activer SSH sous CPanel photo 4

Résoudre l’erreur SSH: Missing privilege separation directory: /run/sshd

Sur un nouveau serveur à base d’Ubuntu Server 18.04, j’obtiens cette erreur à la suite d’un test du service ssh:

sshd -t

Could not load host key: /etc/ssh/ssh_host_ed25519_key
Missing privilege separation directory: /run/sshd

Les solutions à ces deux problèmes sont triviales, cela se règle en deux petites commandes.

L’erreur Could not load host key

L’erreur Could not load host key survient lorsque certaines clés SSH n’ont pas été générées lors de l’installation du système d’exploitation du serveur.

Dans le cas du serveur qui nous occupe, il nous manque la clé de chiffrement ED25519 qui doit se trouver à l’adresse /etc/ssh/ssh_host_ed25519_key.

Pour générer toutes les clés de chiffrement SSH manquantes, une seule commande suffit:

ssh-keygen -A

L’argument -A signifie que l’on génère toutes les clés (All keys). Voici le résultat sur le serveur:

ssh-keygen: generating new host keys: ED25519

L’erreur Missing privilege separation directory: /run/sshd

Cette erreur apparaît lorsque le répertoire mentionné – ici /run/sshd – n’a pas été correctement créé. Il suffit de le créer:

mkdir -p /run/sshd

Vérifiez la configuration SSH:

sshd -t

S’il n’y a plus d’erreur, vous pouvez alors redémarrer le service ssh:

service ssh restart

Et voilà, problèmes réglés.

Activer SSH sous CPanel photo 4

Activer SSH sous CPanel

ssh logo

Il peut être extrêmement utile d’activer la connexion SSH chez certains hébergeurs qui la proposent, comme SiteGround. Cela permet de gagner pas mal de temps, notamment lorsque l’on utilise wp-cli.

Mais avant de pouvoir se connecter, il faut d’abord l’activer dans les options de CPanel.

Activation de la connection SSH dans CPanel

Rendez-vous dans CPanel > Security > SSH Shell Access :

cpanel ssh

Ensuite, cliquez sur le bouton Manage SSH Keys:

cpanel ssh manage

Nous avons ensuite le choix entre deux solutions : soit nous créons la paire de clés privées/publiques sur le serveur et nous les copions sur notre machine locale, soit nous la créons en locale et l’envoyons sur le serveur. Je suis plutôt pour la seconde solution.

Création des clés SSH

On se rend dans le répertoire SSH de notre utilisateur et on liste le répertoire:

cd ~/.ssh
ls

Si le fichier id_rsa.pub existe déjà, il suffit d’afficher son contenu:

cat id_rsa.pub

Si le fichier n’existe pas, il suffit de le créer:

ssh-keygen

Copiez le contenu du fichier, il s’agit de la clé publique que nous allons importer dans CPanel.

Import de notre clé SSH dans CPanel

Cliquez sur Import Key:

cpanel ssh import

Renommez la clé pour id_rsa puis collez le contenu de votre clé SSH publique:

cpanel ssh import ssh key

Il ne vous reste plus qu’à vous connecter en SSH au serveur. Suivant votre hébergeur, le numéro du port SSH peut changer pour des raisons de sécurité. Chez SiteGround, SSH tourne sur le port 18765:

ssh CPANEL_USER@CPANEL_SERVER -p18765

Bon ssh !

Créer une clé SSH pour ouvrir une session distante sans mot de passe photo

Créer une clé SSH pour ouvrir une session distante sans mot de passe

Il est idéal de pouvoir s’identifier sur un serveur distant, à l’aide d’une clé SSH, sans avoir à taper son mot de passe à chaque fois.

Pas seulement pour un gain de temps mais pour, par exemple, transférer des données ou avoir un cron qui lance une sauvegarde planifiée automatiquement, sans que vous ayez à taper le mot de passe SSH.

Et puis, c’est un degré de sécurité supplémentaire puisque personne ne pourra deviner votre clé RSA, à moins d’avoir eu main mise sur votre machine.

Ce tutoriel est très rapide à mettre en œuvre, quelques minutes à peine suffisent pour créer votre clé et la placer sur le serveur distant.

Voici le principe de fonctionnement en image:

Créer une clé SSH pour ouvrir une session distante sans mot de passe photo 1

Concrètement, au lieu d’utiliser un nom d’utilisateur et un mot de passe en mode interactif (l’invite de commande vous demande d’entrer votre mot de passe), il suffit de donner le nom d’utilisateur et le serveur reconnaît votre machine grâce à votre clé SSH.

Créer un répertoire .ssh pour l’utilisateur

Normalement, votre utilisateur possède déjà un répertoire .ssh mais si ce n’est pas le cas, il faut le créer. Vous pouvez passer à l’étape suivante si vous disposez déjà de ce répertoire.

On se rend dans le répertoire de l’utilisateur:

cd ~/

On crée le répertoire .ssh:

mkdir .ssh

On s’assure que les permissions de fichiers permettent de lire, écrire et exécuter uniquement pour notre utilisateur:

chmod go-rwx .ssh

Créer une clé SSH

Nous allons maintenant créer une clé SSH, ou plutôt 2 clés : une clé privée et une clé publique.

Les guillemets à la fin de la commande indiquent que la clé privée n’a pas de mot de passe, ce qui permet de s’identifier sans mot de passe.

On se place dans le répertoire .ssh:

cd .ssh

Nous créons une clé de 4096 bits, sans mot de passe :

ssh-keygen -b 4096 -t ed25519 -f id_rsa -P ""

Nous obtenons deux fichiers :

  • id_rsa : notre clé privée
  • id_rsa.pub : notre clé publique

Lire la suite

Utiliser Rsync pour sauvegarder un serveur Debian/Ubuntu vers un NAS Synology photo

Utiliser Rsync pour sauvegarder un serveur Linux vers un NAS Synology

Dans ce tutoriel, nous allons voir comment configurer rsync pour planifier des sauvegardes d’un serveur distant et permettre l’accès SSH vers votre NAS Synology en local.

Armez-vous de votre terminal préféré et lancez une session SSH, c’est parti !

Étape 1 : créer un nouvel utilisateur Synology

Afin de bien séparer les processus et privilèges, il vaut mieux créer un nouvel utilisateur Synology : cela permet de contrôler exactement ce à quoi il a accès.

Dans ce tutoriel, notre utilisateur s’appellera saveme.

Étape 2 : activer l’accès SFTP

Activez l’accès SFTP dans Diskstation > Control Panel > FTP > SFTP > Enable SFTP service. Vérifiez aussi que le port 22 (SSH) est bien ouvert dans votre routeur et firewall; et bien redirigé vers votre NAS.

Ensuite, ouvrez une session SSH sur votre NAS :

ssh admin@IP_NAS

Entrez votre mot de passe, vous devriez être loggué. Si ce n’est pas le cas, vérifiez la configuration routeur/firewall du port 22.

Étape 3 : éditer le fichier passwd

Une fois que vous êtes identifié en SSH sur votre NAS, il vous faut éditer le fichier passwd:

nano /etc/passwd

Allez à la dernière ligne, qui gère le nouvel utilisateur créé à l’étape 1. A la fin de cette ligne, remplacez :

/sbin/nologin

par

/bin/sh

Sauvegardez le fichier.

Maintenant, on assigne un dossier de travail avec tous les droits nécessaires à notre utilisateur (qui s’appelle saveme). Au lieu de le mettre dans /homes, on va plutôt le mettre à la racine, bien au chaud, sous /volume1/backup.

On donne accès au dossier :

chown saveme:users /volume1/backup 

Étape 4 : identification avec notre nouvel utilisateur

On s’identifie avec notre utilisateur saveme :

su - saveme

Si vous obtenez des messages d’erreur comme :

su: can't chdir to home directory '/volume1/backup'
su: can't run /sbin/sh: No such file or directory

La première erreur est due à une erreur de permissions. Vérifiez que vous avez bien chowné le bon dossier. La seconde montre que vous avez oublié d’ajouter

/bin/sh

à votre utilisateur dans l’étape 3.

Étape 5 : ajouter la clé SSH du NAS sur le serveur distant

On crée la clé en utilisant le chemin par défaut et on appuie juste sur “entrée” lorsqu’on nous demande un mot de passe de clé :

ssh-keygen -t rsa

On copie la clé sur le serveur distant:

cat ~/.ssh/id_rsa.pub | ssh user@IP_SERVER "mkdir -p ~/.ssh && cat >>  ~/.ssh/authorized_keys"

Essayez maintenant d’ouvrir une session SSH sur votre serveur distant depuis la session SSH du NAS : la session devrait s’ouvrir sans que vous n’ayez à entrer le mot de passe du compte.

Si vous obtenez une erreur de permission, voici les bonnes permissions à appliquer :

  • le répertoire .ssh doit avoir un chmod 700,
  • la clé publique (fichier .pub) doit avoir un chmod 644,
  • la clé privée (id_rsa) doit avoir un chmod 600.

Voici donc les commandes à lancer pour attribuer les bonnes permissions sur le NAS:

chmod /volume1/backup/.ssh 700
chmod /volume1/backup/.ssh/id_rsa.pub 644
chmod /volume1/backup/.ssh/id_rsa 600

Lire la suite

WordPress : résoudre l'erreur

WordPress : installer des plugins et thèmes sur un site de développement local

WordPress : récupérer la liste emails des membres et commentateurs photo

Lorsque vous installez WordPress en local sur votre machine, il est assez courant que les droits des fichiers et dossiers ne permettent pas d’entrée de jeu d’installer ou de mettre à jour des plugins ou des thèmes.

Voici comment résoudre ce problème en quelques minutes.

Passage au système de fichier direct

1. On commence par éditer notre fichier wp-config.php, qui contient pas mal de constantes primordiales pour WordPress:

nano wp-config.php

2. On y rajoute, vers le haut du fichier, une constante qui passe le système de fichier en mode direct:

define('FS_METHOD', 'direct');

Sauvegardez votre fichier wp-config.php. Les fichiers de thèmes et de plugins seront désormais directement installés sans que la popup demandant des informations FTP ou SSH ne s’affiche.

Vérification des droits des fichiers et répertoires

En local, par contre, ce sera un petit peu différent : l’utilisateur www-data (Apache ou NginX) doit pouvoir gérer les fichiers mais si vous souhaitez éditer des fichiers, ce qui est quand même le but d’une installation en locale, il faut que votre utilisateur puisse aussi gérer et avoir le droit d’écriture sur les fichiers.

1. Tout d’abord, on donne les droits à Apache à tous les fichiers et dossiers de l’installation WordPress :

sudo chown www-data:www-data -R /home/matt/www/

2. J’ajoute ensuite mon utilisateur de session, matt, dans le groupe www-data (Apache):

sudo usermod -aG www-data matt

3. On vérifie que l’utilisateur matt fait bien partie du groupe www-data :

groups matt

Cela nous retourne la liste de tous les groupes auquel j’appartiens :

matt : matt adm lp dialout fax cdrom floppy tape audio dip www-data video plugdev fuse lpadmin netdev admin sambashare vboxusers usb bluetooth scanner

4. On stipule que l’utilisateur matt est propriétaire de ces fichiers :

sudo chown matt:www-data -R /home/matt/www/

5. On assigne les permissions standard de WordPress, chmod 755 pour les répertoires et chmod 664 pour les fichiers, le tout en mode récursif pour n’oublier personne :

cd /home/matt/www
sudo find . -type d -exec chmod -R 750 {} \;
sudo find . -type f -exec chmod -R 640 {} \;

Vous pouvez maintenant installer thèmes et plugins en local et être en mesure d’éditer vos fichiers avec votre utilisateur linux, sans problèmes de droits.

NAS Synology : résoudre l'erreur rsync

NAS Synology : résoudre l’erreur rsync “permission denied” lors de la connexion au NAS après mise à jour du DSM

Mon NAS Synology vient de mettre à jour son firmware DSM et je constate en lançant ma sauvegarde rsync que la connexion rsync vers le NAS ne se fait plus : après saisie du mot de passe, on obtient une erreur “permission denied”.

Voici comment remédier à ce petit désagrément en deux minutes montre en main.

Problème : connexion SSH refusée

Lors de la connexion initiale, démarrée par :

rsync --ignore-existing --progress -vr --rsh='ssh -p22222' /home/backup/* root@example.com:/volume1/video

on obtient le message d’erreur suivant, après saisie du mot de passe:

Permission denied, please try again.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.1]

Après vérification que les identifiants (user/password) sont bien corrects, il s’avère que la solution réside dans l’utilisation de l’argument --rsync-path afin d’expliciter le chemin de l’exécutable rsync présent sur le NAS.

Solution : ajouter le chemin du binaire rsync du NAS

La solution est toute simple, il suffit de renseigner le chemin du binaire rsync qui se trouve sur le NAS Synology comme argument de notre connexion.

Sous DSM5, le chemin de rsync est /usr/syno/bin/rsync.

A partir de DSM6, le chemin de rsync est /usr/bin/rsync, qui est le chemin habituel sous linux.

Nous ajoutons donc l’argument --rsync-path à notre connexion initiale, ce qui nous donne :

rsync --ignore-existing --progress -vr --rsh='ssh -p22222' --rsync-path=/usr/bin/rsync /home/backup/* root@example.com:/volume1/video
Note: n’oubliez pas de changer le chemin suivant que vous utilisez DSM5 ou DSM6.

Et hop, la sauvegarde rsync est de nouveau fonctionnelle.

Se connecter depuis un serveur vers un NAS Synology avec des clés SSH, sans mot de passe photo

Se connecter depuis un serveur vers un NAS Synology avec des clés SSH, sans mot de passe

La sauvegarde des données

Un des problèmes majeurs dans la gestion des données informatiques est la sauvegarde des données.

Idéalement, il faut pouvoir être en mesure de disposer de plusieurs copies de sauvegarde de nos données, intégres et utilisables, disponibles dans plusieurs lieux géographiquement éloignés afin de prévenir les risques.

Il est très utile d’avoir un script de sauvegarde comme backup-manager sur le serveur qui va automatiquement envoyer les fichiers de sauvegarde sur un espace de stockage distant.

Sur ce serveur par exemple, les sauvegardes sont envoyées sur le FTP de backup mis à disposition par OVH.

Connexion à un serveur distant en SSH, sans mot de passe

Se connecter depuis un serveur vers un NAS Synology avec des clés SSH, sans mot de passe photo 1

Mais il est également possible d’en envoyer une copie chez vous, directement sur votre NAS. Pour plus de sécurité (le FTP n’est pas un protocole sécurisé) il peut être très intéressant de créer un set de clés SSH pour que le script de sauvegarde (ou alors rsync) se connecte directement à votre NAS/serveur de sauvegarde en SSH.

Voyons donc comment nous pouvons créer un jeu de clés SSH sur notre serveur linux – ou n’importe quelle autre machine Unix, comme votre PC – vers un NAS Synology.

Cela nous permettra de nous identifier sur le NAS depuis le serveur, sans avoir à rentrer de mot de passe ou à le mettre en clair dans un script. C’est aussi un grain de temps de se logguer en SSH au NAS sans mot de passe !

Se connecter depuis un serveur vers un NAS Synology avec des clés SSH, sans mot de passe photo

Lire la suite

BASH : lister, bloquer et débloquer des adresses IP avec iptables photo 1

BASH : lister, bloquer et débloquer des adresses IP avec iptables

Sur un serveur dédié, il n’est pas rare d’avoir des adresses IP à bannir pour se débarrasser de visiteurs malveillants, de spammeurs ou de bots qui effectuent des requêtes farfelues visant à perturber le bon fonctionnement des services du serveur.

Heureusement, toutes ces petites contrariétés peuvent être résolues en quelques secondes grâce à un firewall comme iptables.

Ce petit tutoriel vous montre les quelques commandes à retenir pour lister, bannir ou débloquer des adresses IP avec iptables ainsi qu’un petit script bash qui vous permettra d’automatiser la gestion de ces trois fonctions très simplement.

Bannir une IP

Pour bannir une adresse IP avec iptables, il suffit de lancer cette commande:

iptables -I INPUT -s x.x.x.x -j DROP

L’argument DROP indique que l’adresse IP indiquée (x.x.x.x) n’aura plus accès à la machine.

Lister les IP bloquées

Pour voir la liste des adresses IP bloquées, il suffit de demander à iptables la liste et de ne sélectionner que celles qui sont en DROP:

iptables -L INPUT -v -n | grep DROP

Résultat :

Chain INPUT (policy DROP 23 packets, 4122 bytes)

Débloquer une IP

Pour débloquer une IP, il faut d’abord afficher la liste des IP bannies:

iptables -L INPUT -v -n | grep DROP

Toutes les IP sont classées dans un ordre numéroté, ligne par ligne. Il suffit d’indiquer le numéro de la ligne de la règle à supprimer avec la commande:

iptables -D INPUT numero-de-la-regle

L’argument -D (pour delete) permet de supprimer la règle qui correspond à l’adresse IP que nous souhaitons supprimer. Par exemple, si on veut supprimer la règle 1, il suffit d’indiquer:

iptables -D INPUT 1

Vous aurez remarqué que toutes ces commandes sont bien fastidieuses et leurs syntaxes assez complexes à retenir.

Voyons donc comment créer un script bash qui prendrait en charge toutes ces commandes.

Script Bash pour automatiser la gestion des IP bannies dans iptables

Bash

Voici un script bash qui devrait grandement vous simplifier la gestion des IP dans iptables.

Il permet de bloquer, débloquer et lister les adresses IP en toute simplicité.

Lire la suite

Linux : résoudre l'erreur SSH

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

ssh

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)? 

Lire la suite