Le problème :

• Accéder à un gestionnaire de fichier « graphique » sur un serveur headless
• Le tout depuis un Mac (déport d’affichage, X-forwarding)

Le serveur étant headless, il faut installer un gestionnaire de fichier ayant  le moins de dépendance possible (il ne doit pas installer tout Xorg/Gnome/KDE).
En voici quelques un :

• PCManFM : 51 dépendances, 39 Mo
• XFE : 75 dépendance, 67 Mo
• QtFM : 1 seul paquet (pas de dépendance), < 1 Mo, pas dans les dépôts
• emelFM2 : 1 seul paquet (pas de dépendance), < 2 Mo

(Cet article étant commencé depuis au moins 3 ans, le nombre de paquet et la taille de ces programmes à peut être changé)

Personnellement j’ai installé emelfm2.

Sur le serveur Linux toujours, s’assurer d’avoir xauth install et l’option X11Forwarding à yes dans /etc/ssh/sshd_config.

Sur le Mac, il faut installer XQuartz : https://www.xquartz.org/

Lancer XQuartz et dans le terminal qui s’ouvre lancer la commande :

ssh -X -Y -C -f  [utilisateur linux]@[serveur linux] emelfm2

Et voila…

Ouvrir le fichier ppk dans puttygen (saisir la passphrase le cas échéant), menu conversion, export opensshkey

Sauvegarder le fichier openSSH

Transférer le fichier openSSH (ou faire un copier-coller du contenu) sur la machine Linux

Modifier les permission du fichier openSSH avec un chmod 700 (important sinon SSH refuse d’utiliser la clé)

Utiliser la clé SSH :

ssh user@ip -i key.shh

Source : How To Convert Your Putty .ppk Private Key To A Normal SSH Key You Can Use On An Apple Mac

Je connaissais la technique depuis longtemps, mais je n’avais jamais eu l’occasion de la mettre en œuvre.

Il s’agit de la technique visant à déporter l’affichage graphique d’une machine vers une autre : X-Forwarding

L’usage le plus courant (le mien) étant de pouvoir interagir sur une machine n’ayant pas d’écran (un serveur) via des outils graphique (par exemple via un gestionnaire de fichier)

Le seul pré-requis est que la machine cible (le serveur sans écran) ait un serveur SSH d’installé de démarré et de configuré avec la directive suivante dans le fichier /etc/ssh/sshd_config :

X11Forwarding        yes

En contrepartie, ce mode de déport est nettement moins performant que ceux faisant intervenir des logiciels spécialisés (par exemple VNC ou encore mieux NX)

Donc pour démarrer la session de déport il suffit sur le client de saisir :

ssh -c blowfish -X -C -f user_distant@machine_distante ligne_de_commande

(-c pour indiquer le cryptage, -X pour indiquer que l’on active le déport d’affichage, -C pour activer la compression du flux et -f pour passer en arrière plan)

Après authentification de l’utilisateur distant sur la machine distante, le programme lancé par la ligne_de_commande démarre et s’affiche.

Dans l’exemple de la copie d’écran, je suis sous Gnome donc ayant Nautilus comme gestionnaire de fichier et j’éxécute le gestionnaire de fichier Thunar d’une machine distante ayant XFCE d’installé.

Tout simplement avec la commande :

ssh -c blowfish -X -C -f user_distant@machine_distante thunar

Sources :

Forwarding X over SSH in 3 simple steps

X11Forwarding : lancer une application sur un serveur et l’afficher ailleurs avec SSH

• Sauvegarde avec rSnapshot
• Sauvegarde avec rSnapshot via SSH et sudo
• Permission denied sur gvfs avec rSnapshot / rsync
• rSnapshot utilisation d’un fichier d’exclusion

Il contient tous les scripts et configuration mis en oeuvre pour la sauvegarde du home de ma machine sweetHome par sweetBox.

Configuration du serveur de sauvegarde

Tout d’abord je ne planifie pas chacun des intervals rSnapshot individuellement dans Cron, j’ai une seul tache appellant un script qui lui va « calculer » quel interval rSnapshot exécuter.

L’avantage, on éteint les machines à sauvegarder à la fin de l’exécution des tous les intervals, on pourrait même éteindre la machine réalisant la sauvegarde.

Voici ce script :

/home/mon_user/bin/sauvegarde.sh

#!/bin/bash
 
DAY_OF_WEEKLY_BACKUP=lundi
DAY_OF_MONTHLY_BACKUP=01
 
cd $(dirname "${0}")
 
. $HOME/.profile
. wakeOnLanSweetHome.sh
sleep 120
 
echo Sauvegarde journaliere en cours...
rsnapshot -v -c rsnapshotSweetHome.conf daily > /var/log/svc/rsnapshot.log 2>&1
 
if [ $(date +%A) == $DAY_OF_WEEKLY_BACKUP ]; then
echo Sauvegarde hebdomadaire en cours...
rsnapshot -v -c rsnapshotSweetHome.conf weekly >> /var/log/svc/rsnapshot.log 2>&1
fi
if [ $(date +%d) == $DAY_OF_MONTHLY_BACKUP ]; then
echo Sauvegarde mensuelle en cours...
rsnapshot -v -c rsnapshotSweetHome.conf monthly >> /var/log/svc/rsnapshot.log 2>&1
fi
 
cat /var/log/mon_user/rsnapshot.log | rsnapreport.pl | mail -s Sauvegarde mon_email
 
ssh mon_user@sweethome "shutdown -h now"

Ce script réveil sweetHome via Wake on Lan, lance la sauvegarde journalière puis hebdmadaire si on est un lundi, la mensuelle si on est un premier du mois.

Edit 27/01/2010 : Pour que le test sur le jour de la semaine fonctionne il faut que ce script soit exécuté dans un environnement pour lequel la langue est FR, or ce n’est pas le cas par défaut dans une tache Cron.

Il conviendra donc d’ajouter LANG=fr_FR.UTF-8 dnas l’en-tête de la crontab.

Cf. cet article

Puis le rapport de sauvegarde est formatté par rsnareport et envoyé par mail, enfin on éteint le pc à distance.

Pour info le WOL est réalisé dans un script à part, ce qui me permet de réveiller sweetHome quand je veux sans avoir à me rappeler son adresse MAC, il est très succinct :

wakeOnLanSweetHome.sh

#!/bin/bash
 
echo Reveil de sweetHome
wakeonlan mon_adresse_mac

Ci-dessous mon fichier de configuration rsnapshot (purgé des commentaires) :

#################################################
# rsnapshot.conf - rsnapshot configuration file #
#################################################
# #
# PLEASE BE AWARE OF THE FOLLOWING RULES: #
# #
# This file requires tabs between elements #
# #
# Directories require a trailing slash: #
# right: /home/ #
# wrong: /home #
# #
#################################################
 
#######################
# CONFIG FILE VERSION #
#######################
 
config_version 1.2
 
###########################
# SNAPSHOT ROOT DIRECTORY #
###########################
 
snapshot_root /data/sauvegardes/sweetHome/
no_create_root 1
 
#################################
# EXTERNAL PROGRAM DEPENDENCIES #
#################################
cmd_cp /bin/cp
cmd_rm /bin/rm
cmd_rsync /usr/bin/rsync
cmd_ssh /usr/bin/ssh
cmd_logger /usr/bin/logger
cmd_du /usr/bin/du
cmd_rsnapshot_diff /usr/bin/rsnapshot-diff
#cmd_preexec /path/to/preexec/script
#cmd_postexec /path/to/postexec/script
 
#########################################
# BACKUP INTERVALS #
# Must be unique and in ascending order #
# i.e. hourly, daily, weekly, etc. #
#########################################
interval daily 7
interval weekly 4
interval monthly 2
 
############################################
# GLOBAL OPTIONS #
# All are optional, with sensible defaults #
############################################
 
# Verbose level : 1 (mini) through 5 (maxi).
verbose 2
loglevel 3
logfile /var/log/svc/rsnapshot.log
lockfile /var/lock/rsnapshot.pid
 
rsync_long_args --delete --numeric-ids --relative --delete-excluded --stats
ssh_args -o BatchMode=yes
 
#exclude .gvfs
#include_file /path/to/include/file
exclude_file /home/mon_user/bin/rsnapshotExclude
 
###############################
### BACKUP POINTS / SCRIPTS ###
###############################
 
# sweetHome
backup mon_user@sweethome:/home/user_distant <br class="spacer_" />

Le fichier d’exclusion contient ceci :

Trash/
.thumbnails/
.mozilla/*/*/Cache/
.gvfs
tmp/

Afin d’avoir une connexion SSH sans mot de passe, j’ai généré un couple de clés stockés dans /home/mon_user/.ssh.

Pour simplifier la synthaxe SSH, j’ai ensuite créé un fichier config :

/home/mon_user/.ssh/config

Host sweethome
Hostname 192.168.1.100
User mon_user

Configuration de la machine sauvegardée

La clé publique généré sur le serveur de sauvegarde à été copié dans authorized_key sur la machine sauvegardée, et modifiée ainsi :

from="IP_sweetBox",command="/home/user_distant/bin/validate-rsync" ssh-rsa AAAAB3...VJpj9cjzjPTyYcXgGiQ== <a href="mailto:mon_user@sweetBox">mon_user@sweetBox</a>

On indique ainsi que cette clé utilisable que pour une connexion venant de l’IP from et que l’on exécute le script validate_rsync lors de l’établissement de cette connexion SSH.

Ce script de validation s’assure que la connexion SSH n’est établie que pour les commandes rsync (pour la sauvegarde) et/ou shutdown (pour éteindre sweetHome à la fin de la sauvegarde :

bin/validate-rsync

#!/bin/sh
 
case "$SSH_ORIGINAL_COMMAND" in
*\&*)
echo "Rejected"
;;
*\(*)
echo "Rejected"
;;
*\{*)
echo "Rejected"
;;
*\;*)
echo "Rejected"
;;
*\<*)
echo "Rejected"
;;
*\`*)
echo "Rejected"
;;
*\|*)
echo "Rejected"
;;
rsync\ --server*)
sudo $SSH_ORIGINAL_COMMAND
;;
shutdown\ -h\ now*)
sudo $SSH_ORIGINAL_COMMAND
;;
 
*)
echo "Rejected"
;;
esac

On le voit ici que les commande rsync et shutdown sont précédées de sudo pour les exécuter en super-utilisateur.

Il convient donc de modifier le sudoer (sudo visudo) pour autoriser l’utilisateur de sweetHome réalisant la sauvegarde (utilisateur que j’ai décrit comme utilisateur distant vis a vis de sweetBox qui est ma référence) ait le droit de lancer sudo pour ces 2 commandes sans mot de passe.

J’ai donc ajouté cette ligne à mon sudoer :

mon_user ALL = NOPASSWD: /usr/bin/rsync, /sbin/shutdown

Et voila..

Edit :

10/11/2009 : ajout de l’option –relative aux paramètres rsync et mise à jour de la variable rsnapshot exclude_file

27/01/2010 : Ajout de la remarque concernant le langue du script de sauvegarde dans le cadre d’une exécution via Cron

• Monter un partage Samba
• Monter un partage NFS
• Passer à travers SSH

La dernière solution à bien sûr ma préférence :

• sécurisé
• j’ai déja openssh-server d’installé sur les machines à sauvegarder, je n’ai donc rien d’autre à installer.

Au niveau utilisateur j’ai créé  :

• un utilisateur sur le serveur de sauvegarde (sweetBox) qui lancera rSnapshot : on l’appelera user_rsnapshot
• un utilisateur sur la/les machines à sauvegarder (swettHome) : on l’appelera user_distant

L’utilisateur user_rsnapshot a un repertoire dont il est propriétaire sous /var/log à des fin de log.

Remarque : cet article appliqué a sudo marche tout aussi bien si vous l’appliquez à rsync directement.

Connexion SSH sans mot de passe

On se basera sur l’article Simplifier les connexions SSH dont je rappelle ici les grandes lignes

• connexion avec user_rsnapshot
• génération d’une paire de clé
• copie de la clé publique généré dans le authorized_key de user_distant
• connexion à l’ordinateur distant avec user_distant afin d’ajouter l’empreinte de l’ordinateur distant à sauvegarder dans la liste des ordinateurs connus

Configuration de rSnapshot

Création d’un fichier de configuration rsnapshot dans le home de user_rsnapshot, voir pour cela voir Sauvegarde avec rSnapshot.

Dans la section sauvegarde de ce fichier, mettre une ligne de la forme (avec des tabulations) :

backup       user_distant@machine_a_sauvegarder:/repertoire_a_sauvegarder       destination

La syntaxe de la source est la même syntaxe que lors de la copie de fichier via scp, enfin la destination est optionnelle (penser tout de même à mettre la tabulation)

Test

Faire un test en modifiant par exemple votre fichier de configuration pour ne sauvegarder qu’un petit répertoire (le Bureau par exemple), ainsi le test sera plus rapide que si lancez directement la sauvegarde de tous votre home de x Go.

Lancer rSnapshot :

rsnapshot -v -c fichier.conf daily

Normalement tout devrait bien se passer (pas de message d’erreur) et la connexion SSH devrait se faire demander de mot de passe.

Restriction SSH et sauvegarde avec sudo

On va désormais paramétrer la machine à sauvegarder pour n’autoriser la connexion SSH que lors de la sauvegarde et faire en sorte que rsync côté client (c’est à dire la machine sauvegardé) tourne en sudo permettant ainsi la sauvegarde de tous les répertoires voulus sur la machine clientes y compris ceux pour lesquelles l’utilisateur user_distant n’a pas de droits.

Se connecter (physiquement ou en SSH) sur la machine à sauvegarder avec l’utilisateur user_distant.

Script de validation de la commande SSH

Créer un script où vous le souhaitez que l’on nommera (au choix) validate-rsync, y copier ceci :

#!/bin/sh
 
case "$SSH_ORIGINAL_COMMAND" in
 *\&*)
 echo "Rejected"
 ;;
 *\(*)
 echo "Rejected"
 ;;
 *\{*)
 echo "Rejected"
 ;;
 *\;*)
 echo "Rejected"
 ;;
 *\<*)
 echo "Rejected"
 ;;
 *\`*)
 echo "Rejected"
 ;;
 *\|*)
 echo "Rejected"
 ;;
 rsync\ --server*)
 sudo $SSH_ORIGINAL_COMMAND
 ;;
 *)
 echo "Rejected"
 ;;
 esac

Ce script test la variable d’environnement $SSH_ORIGINAL_COMMAND (créée lors de la connexion SSH) et rejette toutes les connexions SSH dont la commande est différente de rsync –server.

La connexion SSH est donc impossible pour les usage autre que la sauvegarde.

Appel du script de validation

Il faut maintenant indiquer a SSH d’appeller ce script lors de la connexion, cela se fait dans authorized_keys.

Nous avons vus dans Simplifier les connexions SSH que nous pouvions grâce à authorized_keys limiter les connexions SSH à certaine adresse IP, nous allons ici rediriger notre connexion SSH vers notre script de validation :

Éditer votre fichier authorized_keys :

vim ~/.ssh/authorized_keys

Et ajouter au début le mot-clé command suivi du chemin vers votre script de validation :

from="192.168.1.222",command="/home/user_distant/bin/validate-rsync" ssh-rsa AAAAB3NzaC1yc2EAAA  ... VJpj9cjzjPTyYcXgGiQ== user_distant@machine_a_sauvegarder 

Exécution en tant que sudo

Pour que votre sauvegarde puisse accéder à tous les répertoire de votre filesystem, il faut que rsync soit lancé en sudo.

Dans le script validate-rsync ci-dessous vous pourrer remarque que lorsque que la commande SSH est accepter, on ne se contente pas de l’exécuter, mais on a précédé la variable d’environnement $SSH_ORIGINAL_COMMAND de sudo

rsync\ --server*)
 sudo $SSH_ORIGINAL_COMMAND
 ;;

Il faut ensuite paramétrer le fichier sudoer pour autoriser votre utilisateur à lancer rsync via sudo sans demander de mot de passe.

Si votre utilisateur user_distant n’est pas déjà autorisé dans sudo (ce qui est certainement le cas si vous venez juste de le créer pour la sauvegarde), il vous faudra vous connecter avec votre utilisateur principal (ou faire un su).

On entre ensuite dans le fichier sudoer via visudo :

sudo visudo

Et ajoutera une ligne du genre :

svc ALL = NOPASSWD: /usr/bin/rsync

Indiquant que l’utilisateur user_distant à le droit d’utiliser sudo sans mot de passe (NOPASSWD) pour la commande rsync et ce quel que soit la machine sur laquelle il est (ALL)

Test

Sur le serveur de sauvegarde , re-lancer rSnapshot comme lors du test précédent :

rsnapshot -v -c fichier.conf daily

Il ne devrait pas y avoir de changement par rapport au test précédent si ce n’est que vous pouvez désormais suavegarde le home ou le bureau d’un uatilisateur autre que l’utisateur user_distant.

On va en plus faire un test pour valider le bridage SSH en saisissant la commande :

ssh user_distant@machine_distante ls

Au lieu de nous donner le contenu d’un répertoire (normalement le home de user_distant), on a :

 Rejected

Nous indiquant que la connexion SSH est interdite pour autre chose de la sauvegarde avec rsync.

Sources :

Le site de référence : http://troy.jdmz.net/rsnapshot/

Modification du précédent pour appliquer le sudo : http://www.pervasive-network.org/SPIP/Backup-incremental-avec-rsnapshot

http://www.ruzee.com/blog/2008/11/using-rsnapshot-for-file-and-database-backups

http://blog.innerewut.de/2005/6/3/follow-up-on-remote-filesystem-snapshots-with-rsnapshot

http://www.maxsworld.org/index.php/how-tos/rsnapshot-backups

http://blog.mageekbox.net/?post/2008/11/07/Mise-en-place-de-sauvegardes-%C3%A0-l-aide-de-rsnapshot

http://blog.innerewut.de/2005/5/25/remote-filesystem-snapshots-with-rsnapshot

http://geekfault.org/2009/05/16/rsnapshot/

ssh mon_user_distant@adresse_machine_distante

Où adresse_machine_distante peut être une adresse IP, ou un nom de machine si vous avez un DNS ou un fichier host bien configuré.

Puis saisir son mot de passe

Je vous propose grace à cet article de n’avoir plus qu’a saisir :

ssh mot_clé

(plus de mot de passe, de user et plus besoin de connaitre l’ip de la machine si vous n’avez pas de DNS)

Supprimer la saisie du mot de passe

Pour ce faire on utilisera un connexion SSH par clé et non plus par mot de passe , il faut donc que nous générions une paire de clé.

Se loguer avec cet utilisateur qui devra faire la connexion SSH ou faire un su pour cet utilisateur :

su mon_user_local

Générer une paire de clé sans passphrase

Cela se fait avec la commande :

ssh-keygen -t rsa -b 2048

• rsa : type de la clé générée, on peut aussi choisir dsa
• 2048 : longueur de la cél

A la question demandant où doit être sauvé la pair de clé généré, laisser la valeur par défaut : /home/mon_user_local/.ssh

Ajouter la clé public à l’ordinateur distant

Certains sites conseillent de copier la clé via scp sur l’ordinateur distant puis de faire un cat redirigé vers le fichier authorized_keys, mais il ya  plus simple :

ssh-copy-id -i /home/mon_user_local/.ssh/id_rsa.pub mon_user_distant@IP_machine_distante

Se connecter et ajouter l’ordinateur distant à liste des known_host

On peut alors de connecter avec :

ssh mon_user_distant@IP_machine_distante

Aucun mot de passe ne sera demandé, par contre à la première connexion, SSH vous demandera si vous voulez ajouter l’ordinateur distant à la liste des ordinateurs connus et de confiance, repondez oui sinon cette question vous sera posée à chaque fois.

The authenticity of host '192.168.1.104 (192.168.1.104)' can't be established.
RSA key fingerprint is 4d:24:12:81:41:c0:53:84:0f:da:33:b0:78:39:80:3d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.104' (RSA) to the list of known hosts.

Restreindre la porté de la clé

On peut si on veut ajouter de la sécurité restreindre les condition d’applications de la connexion via la clé précedement générée.

Pour cela sur la machine distante se connecter et editer .ssh/authorized_keys

vim /home/mon_user_distant/.ssh/authorized_keys

Y ajouter :

from="adresse_ip"

Où adresse_ip est l’adresse IP de la machine ayant le droit d’utiliser cette clé pour fiare une connexion SSH

Exemple :

from="192.168.1.222" ssh-rsa AAAAB3 ... cXgGiQ== 

Configuration des options par défaut

On peut via le fichier  .ssh/config spécifier à SSH l’utilisateur devant réaliser le connexion SSH et le nom ou l’adresse IP de la machine distante, le tout associé à un mot clé.

Ainsi il n’ya plus qu’a se souvenir de ce mot clé et SSH fait le reste.

Créer/éditer le fichier /home/mon_user_local/.ssh/config et y ajouter :

Host mot_cle
Hostname adresse_ip_machine_distante
User mon_user_distant

Le sauvegarder et la connexion se fera alors pas un simple :

ssh mot_cle

Sources :

http://reseau.erasme.org/static/serveurs_linux/sect_03_04.html

http://troy.jdmz.net/rsnapshot/

http://theclimber.fritalk.com/post/2009/06/17/Trics-Tips-%3A-configurer-son-client-ssh

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
6a:32:8f:d2:96:d3:4f:29:ee:8e:b9:23:a0:14:c0:ef.
Please contact your system administrator.
Add correct host key in /home/mon_user/.ssh/known_hosts to get rid of this message.
Offending key in /home/mon_user/.ssh/known_hosts:1
RSA host key for 192.168.1.xxx has changed and you have requested strict checking.
Host key verification failed.

Cela indique que l’empreinte de sweetBox à changé depuis la dernière connexion, ce qui est logique puisque lors de la connexion précédente j’étais sous une autre version d’Ubuntu.

La solution de facilité que j’avais trouvé consistait à supprimer le fichier known_host sur ma machine cliente, dès lors SSH ne connaissait plus la machine et me proposais de l’ajouter à la liste des machines connus.

Au bout de quelques fois à faire cette manipulation non pérenne, je me suis décidé à chercher sur Internet comment mettre en œuvre une solution pérenne.

ssh-keyscan 192.168.1.xxx >> ~/.ssh/known_hosts

A noter le double signe supérieur pour ajouter au fichier et ne pas l’écraser, en effet dans mon cas il faut ajouter dans le fichier know_hosts les empreintes de sweetBox Jaunty et sweetBox Gutsy.

Source :

http://www.billyboylindien.com/securite/warning-remote-host-identification-has-changed.html

Configuration du réseau

La configuration du réseau se fait dans le fichier /etc/network/interfaces, on remplacera la ligne du type :

iface eth0 inet dhcp

Par

iface eth0 inet static
 address 192.168.1.222
 netmask 255.255.255.0
 gateway 192.168.1.1

Où l’on indique que l’adresse IP de la machine doit être 192.168.1.222  et la passerelle 192.168.1.1 (mon routeur Linksys)

On redemarre le réseau avec un :

sudo /etc/init.d/networking restart

Un ifconfig devrait alors indiquer la nouvelle adresse IP de la machine (192.168.1.222)

Installation d’un serveur SSH

Avec une installation minimale type ligne de commande le client SSH est installé mais pas de serveur, on fera donc un :

sudo aptitude install openssh-server

Il faudra ensuite configurer plus finement le serveur SSH (surtout si il doit être accessible du WAN), mais cela fera l’objet d’un autre post.

Accès depuis une autre machine

Avec ces 2 configuration de base on doit pouvoir être en mesure d’accéder à la machine en cours d’installation via :

ssh mon_user@192.168.1.222

Sur une autre machine Linux, ou via le client SSH Putty depuis une machine Windows.