Rsync via ssh sans mot de passe

Au premier abord, Rsync ne semble pas très pratique car il est nécéssaire de saisir un mot de passe au clavier pour se connecter en ssh sur le serveur distant, ce qui empeche de créer une routine ou bash file et automotiser la sauvegarde journalière ou hebdomadaire. Mais voila, il existe bien une solution pour se connecter sans mot de passe de façon sécurisée.

Il suffit pour cela de partager une clef publique d’authentification entre le client et le serveur.

Voici comment faire (j’ai trouvé ces informations ici mais surtout sur de cette video du Urban pinguoin très précise). Le site ssh.com peut aussi être intéréssant.

Enfin on pourra aussi consulter l’aide en ligne de Linux comme par exemple ici pour la description du fichier ssh/config (on trouve parfois de mauvaises interprétations sur la toile, surtout quand il s’agit des options de commande de type -a -v …).

Enfin, il faudra penser à créer une routine pour m’envoyer un email tous les 6 mois et me dire de changer les ssh key par mesure de sécurité.

Prérequis

J’utilise ici 2 Rpi en wifi sur mon réseau local.

Obtenir l’addresse ip de votre Rpi:

• Adresse locale

ifconfig

résultat:

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 192.168.0.121  netmask 255.255.255.0  broadcast 192.168.0.255

• Adresse IP globale:

curl ifconfig.me

Résultat:

116.8x.xx.xx

A noter que mes 2 RPi ont la même addresse globale, qui doit correspondre à l’adresse IP de mon router.

Pour info, Re/Démarrer le ssh au besoin (ce n’était pas mon cas):

sudo /etc/init.d/ssh start 

sudo /etc/init.d/ssh restart 

Voilà, c’est tout.

Coté Client (root)

Création de la paire de clefs rsa privée/publique

! Se connecter en Root du coté client. Je n’ai pas réussi à me connecteur avec l’usager du client et comme cela ne me gêne pas, je passe mon tour sur ce problème mais si quelqu’un de bien intentioné pouvait m’expliquer si ca marche avec un usager, ce serait super !

Solution 1

ssh-keygen

Le fichier d’authentification (clef privée) se trouve alors :

home/user/.ssh/id_rsa

le fichier clef publique crée est :

home/user/.ssh/key_rsa.pub

Solution 2

Pour ne pas écraser une clef existante, il est préférable d’écrire la clef dans un nouveau fichier.

On peut aussi encrypter les clefs à l’aide de l’algorithme ed25519 et cela 25 fois (débat des coqs ou de celui qui a la plus grosse pour savoir quel algo est le plus puissant)

ssh-keygen -t ed25519 -o -a 25 -C « CloudPi » -f .ssh/edkey

-a signifie encrypté 25 fois.

-C commentaire

-f fichier clef

Pour voir les fichiers d’authentification et la clef publique:

ls .ssh/

home/user/.ssh/edkey

home/user/.ssh/edkey.pub

home/user/.ssh/know_hosts

et pour voir la clef elle-même:

cat ~/.ssh/edkey.pub

-> ssh-rsa <long string code> CloudPi

Il faudra ajouter ces clefs au serveur à chaque fois qu’on se connectera par ssh.

pour éviter cela, on peut enregistrer la clef private dans un cache.

Mac OSX permet de cacher clefs ..Pour linux, on peut lancer le bash suivant qui va écouter l’ajouter de clefs privés.

ssh-agent bash

Vérifier en utilisant ssh-add -L la liste des usagers définis dans le sshagent

on peut alors ajouter la clef privée:

ssh-add .ssh/edkey25519

et Entrer passphrase (vide).

La communication est désormais débloquée, mais,dans le cas ou le client est un Mac,  uniquement tant que le bash ssh-agent est actif . Alors que la clef est bien enregistrée lorsque le client est un  RPi.

par exemple (Mac) , si on fait:

exit

on perd les informations dans le cache

on préfére alors ajouter la clef dans la chaine de clefs keychain (option -K dans OS X, non disponible dans Raspbian)

ssh-add -K .ssh/edkey

la clef sera alors enregistrée.

Ajout de la clef publique du client sur le Serveur

Before that,

nano /etc/ssh/sshd_config

PermitRootLogin yes

! ca ne marche pas si PermitRootLogin without-password du côté client pour copier les clefs.

ssh-copy-id -i ~/.ssh/edkey25519.pub root@192.168.0.123

Accepter la clef , et saisir le mode de passe

A noter : si on a ajouté la clef en utilisant ssh-add au préalable, ssh-agent va copier les clefs disponible par la commande ssh-add -L vers le serveur lorsque vous enverrez la commande ssh-copy-id (sans -i et le nom du fichier).

Connection ssh sans mot de passe

ssh root@192.168.0.123

Et Voila, c’est presque fini.

Coté Serveur (root)

vérifier les clefs authorisées:

tail .ssh/authorized_keys

vérifier les connections récentes (incluant la demande de clef publique)

tail /var/log/auth.log

Enfin pour éviter de saisir le mot de passe du serveur à chaque fois qu’on s’y connecte,

on édite les paramètres de configuration du serveur ssh:

vim /etc/ssh/sshd_config

et changer pour la valeur suivante:

Authentification

PermitRootLogin without-password

enfin pour redémarrer le serveur ssh, on fait :

systemctl restart sshd

maintenant, le mot de passe est désactivé pour root par ssh.

Coté Client

Côté client (ici depuis un Mac), on souhaite mieux définir l’hote distant (le serveur)!

le fichier n’existait pas sur mon Pi (root).

Coté client (sur Linux ), les hotes distants sont définis ici :

sudo nano /etc/hosts

ajouter :

192.168.0.123 pistation30

Ensuite, ajouter l’hote et la clef en dur .

nano .ssh/config

Host pistation30_cloud
Hostname pistation30
IdentitiesOnly yes
User root
IdentityFile /root/.ssh/edkey

et ensuite , on peut tout simplement faire

ssh pistation30_cloud

Et ca marche , meme si on redémarre le client et le serveur !!

Par contre, je dois encore saisir le passphrase à chaque fois. Pour enlever le passphrase que j’avais crée :

ssh-keygen -p

Entrer le nom du fichier de clef, et entrer un nouveau de mode de passe vide. le tout est joué.

Voila, je redémarre les 2 pi, et la commande ssh pistation30_cloud (en root sur le client) me permet de me connecter sur le root du serveur. Le tour est joué !

 

Voici le contenu des repertoires SSH (client en haut, serveur en bas). On voit bien que les clefs sont du coté client (en haut, seule les clefs edkey25519 nous intéréssent) et que le serveur ne contient que les authorized_keys. On peut aussi remarquer le fichier known_hosts (qui contient la définition de pistation30_cloud) ne se trouve que du côté client .

Coté serveur , on peut lire le contenu du fichier authorized_keys et remarquer que notre clef  edkey25519 déclaré :

Enfin, pour rappel, on peut revoir le contenu des fichiers de config (on voit que jèai changé le permitRootLogin côté serveur en bas, mais pas celui du client.

Enfin, je peux même me connecter depuis le compte usager en utilisant la commande sudo:

Voilà, tout fonctionne très bien.

Corrolaire – Addresse IP fixe

Configurer l’adresse IP statique au préalable de chaque Pi :

Pour voir les usagers:

sudo id

pour configurer la carte réseau:

sudo nano /etc/network/interfaces

et remplacer

iface eth0 inet dhcp 

avec:

iface eth0 inet static

address 192.168.0.123

netmask 255.255.255.0

gateway 192.168.0.1

dns-namservers 192.168.0.1 8.8.8.8

8.8.8.8 = google dns

Corrolaire 2 – ‘reverse ssh tunnel’

Il en existe probablement une plétore , mais voici ici Dataplicity.

Dataplicity lets you control, manage and repair your devices even as they roam between cellular, satellite and fixed networks beyond your control.

Similar to SSH, but without the complex set-up required to get it working behind firewall and NAT.

Wormhole provides a proper URL for your web control panel which follows your devices across cellular, satellite and fixed networks.

orthole forwards TCP ports from your remote Linux devices to your workstation. Use SSH, SCP, VNC, or even proprietary protocols to reach your remote devices.

Dataplicity fournit une solution de type SSH , version gratuite permet les points suivants en date du 1er Novembre 2018.

• Remote terminal
• Website forwarding
• Portforward SSH and VNC
• 2 minute install
• HTTPS termination
• 512.0 MB per day 10MBps+ burst
• Up to 1.5Mbps* sustained