Yubikey : sécurisez vos accès SSH (sous Debian) avec une double authentification [HowTo]

Yubikey

C'est désormais une certitude, les simples mots de passe ne sont plus suffisants pour assurer l'accès à des services critiques. En ce qui me concerne j'utilise, dès que cette option existe, le système de double authentification ("authentification à facteurs multiples"). Le principe est d'associer un mot de passe classique avec un deuxième identifiant à usage unique. Beaucoup utilisent Google Authenticator, ou bien la réception d'un SMS pour obtenir cette information.

Il existe une solution un peu moins connue mais particulièrement intéressante :  Yubikey. Il s'agit d'une petite clé usb (cf. la photo d'illustration de ce billet) particulièrement robuste, légère et ne nécessitant pas de pile. Il suffit de l’insérer dans un port USB et d'appuyer sur le bouton central. La Yubikey se comporte alors comme un clavier (pas besoin de driver spécifique) et génère automatiquement le code à usage unique. Cette clé est vendue sur le net à un tarif abordable (environ 23€ sur Amazon). Certaines sociétés (comme OVH,  par exemple) ont adopté massivement ce dispositif afin de sécuriser l'accès à leur système d'information.

J'utilise une Yubikey depuis quelques mois et je dois reconnaître que cette dernière est particulièrement pratique (pour sécuriser l'accès à mon compte LastPass par exemple). J'ai également commencé à sécuriser l'accès SSH de certains de mes serveurs avec ce dispositif et j'ai décidé de créer ce how-to pour aider ceux qui souhaiteraient faire de même.

Comme d'habitude, ce tuto est basé sur Debian 7, mais il devrait être assez facilement utilisable avec d'autres distributions.

Avertissement important : durant toutes ces opérations ne redémarrez pas le service SSH (ni votre serveur), vous risqueriez de ne plus pouvoir vous connecter ! Une fois la configuration achevée (et le service SSH relancé) conservez votre session SSH ouverte et testez en lançant une nouvelle connexion en parallèle : si les choses tournent mal (connexion impossible) vous conserverez ainsi un accès 🙂

La première opération à réaliser est d'installer la librairie PAM pour Yubico/Ybikey

apt-get install libpam-yubico

Il faut ensuite créer le fichier qui va contenir la liste des Yubikey habilitées à se connecter avec un compte utilisateur donné

mkdir ~/.yubico
vim ~/.yubico/authorized_yubikeys

Pour mémoire le "~" représente le home directory de l'utilisateur actuellement connecté. Si vous êtes connecté en root, le fichier sera donc créé dans "/root/.yubic/authorized_yubikeys"

et d'y placer la liste des Yubikey autorisées à se connecter de la façon suivante

username:token_ID

Le username correspond à votre login Unix (root par exemple) et le token_ID peut être récupéré à cette adresse.

Rendez-vous sur cette page, insérez votre Yubikey sur un port USB, sélectionnez "OTP" (1) dans "source format" et générez une clé en appuyant sur le bouton de votre clé (2).

yubi_screen1

Vous obtiendrez en retour une "input string" composé de 12 caractères et commençant par 6 fois la lettre "c". De la forme "ccccccabcdef". Cette chaine est votre "token_ID". Ajuster le fichier "authorized_yubikeys" avec cette valeur. On obtient donc quelque chose comme "root:ccccccabcdef".

yubi_screen2

Si vous devez donner l'accès à plusieurs Yubikey pour le même login vous pouvez accumuler les Token_ID avec quelque chose du type "root:token_yubikey1:token_yubikey2..."

On édite ensuite le fichier

/etc/pam.d/sshd

Ajoutez la ligne suivante après "@include common-auth"

auth required pam_yubico.so id=16

Si vous préférez devoir générer votre code à usage unique avant d'avoir à mentionner votre mot de passe placez cette ligne avant "@include common-auth" (à vous de décider ce que vous souhaitez faire).

Éditez ensuite le fichier

/etc/ssh/sshd_config

Afin de modifier la directive suivante

ChallengeResponseAuthentication yes

Redémarrez SSH

/etc/init.d/ssh restart

Essayez d'ouvrir une nouvelle session (conservez la session en cours active - on ne sait jamais ...). Vous devriez obtenir ça

yubi_screen3

 

  • Commander une Yubikey sur Amazon : ICI
  • Plus d'information sur Yubikey : ICI

 

 

Monit : la supervision en toute simplicité

monitoringSi vous gérez des serveurs, vous avez déjà certainement été confronté à la mise en place d'un système de supervision. Les solutions techniques ne manquent pas (Nagios, Zabbix ...) mais la plupart restent assez lourdes à mettre en œuvre et on tombe vite dans l'usine à gaz !

Si vos besoins sont simples (monitoring de l'espace disque, de la charge mémoire/processeur, requêtes simples sur un serveur distant, surveillance d'un processus local ...) je vous conseille de jeter un coup d’œil du côté de Monit. Cette solution m'a séduit par sa simplicité et sa rapidité de mise en œuvre : un petit "apt-get install" (sous Debian ou Ubuntu / le paquet est disponible dans les dépôts officiels) et un seul et unique fichier de conf. On peut difficilement faire plus simple !

Un bémol toutefois : cette solution n'est pas capable d'aller interroger un agent localisé sur un serveur distant (comme on peut le faire avec Nagios par exemple). Il est toutefois possible de superviser le fonctionnement d'une machine distante au travers de requêtes standards (ping, http, smtp ...)

Concernant l'installation et le paramétrage c'est assez simple (pour Debian / Ubuntu) :

apt-get install monit

Editez ensuite le fichier de configuration : /etc/monit/monitrc (au passage je vous conseille de faire une copie du fichier original : cp /etc/monit/monitrc /etc/monit/monitrc.original )

* vers la ligne 19 : la directive "set daemon" permet de définir l'intervalle entre deux tests (en secondes). On peut aussi retarder l'exécution du premier test avec "start delay" pour être sûr que le serveur ait bien fini de booter

* vers la ligne 52 : on définie "set mailserver" le serveur smtp à utiliser pour transmettre les alertes (il est possible d'en spécifier plusieurs en les séparant par une virgule)

* vers la ligne 84 : la directive "set mail-format" vous permet de modifier la structure et le contenu des emails d'alerte

* vers la ligne 109 : on mentionne l'adresse du contact qui recevra les alertes ( "set alert" ). De nombreuses options sont disponibles dans cette rubrique pour limiter l'envoi de certaines alertes à des contacts spécifiques par exemple. Consultez la doc pour en savoir plus

Vous trouverez ensuite quelques configurations types de tests pouvant être réalisés par Monit.

A titre trois exemples (très simples) que j'utilise personnellement :

* Pour tester l'espace disque disponible (envoi d'une alerte si l'espace disque occupé dépasse 90%)

check filesystem rootfs with path /dev/sda1
    if space usage > 90% then alert

* Pour tester un hôte distant et envoyer une alerte si ce dernier ne répond plus au ping et/ou ne répond plus à une requête smtp sur le port 25

check host mail.votre_serveur.com with address mail.votre_serveur.com
    if failed icmp type echo count 3 with timeout 2 seconds then alert
    if failed port 25 protocol smtp with timeout 10 seconds then alert

* Pour tester la présence du process "Apache", lancer une requête http sur le port 80 du serveur et alerter en cas d'échec

check process apache with pidfile /var/run/apache2.pid
    if failed
    host www.votre_serveur.com port 80 protocol http
    then alert

Les possibilités offertes par Monit sont très vastes (il est possible par exemple de relancer automatiquement un service en cas de dysfonctionnement ...). Je vous invite à consulter la doc qui est particulièrement bien détaillée (ICI).

A noter que Monit propose également un serveur web embarqué vous permettant de visualiser les équipements supervisés (et de gérer les services) à partir d'un simple navigateur. Vous pouvez activer et paramétrer cette fonctionnalité au sein du fichier de configuration "monitrc" (vers la ligne 118). Là encore le nombre d'options est important (authentification, gestion des droits ...) il est donc impératif de consulter la documentation pour en savoir plus.

  • Site officiel de Monit : http://mmonit.com/monit/

  • Lien direct vers la documentation : ICI

  • Si le sujet de la supervision vous intéresse voici un site assez complet présentant les différentes solutions disponibles : ICI

 

Debian 6 support étendu (LTS) : quelques opérations s’imposent pour en bénéficier


Logo Debian

Comme vous le savez peut être, le support (mises à jours de sécurité) de Debian 6 (Sqeeze) va prendre fin d'ici quelques jours (le 31/5/2014). Toutefois les équipes de Debian, conscientes que de très nombreux serveurs fonctionnent encore avec cette release ont décidés de mettre en place une organisation spécifique (LTS) afin d'offrir les mises à jours de sécurité pour cette version jusqu'au 6 février 2016.

Si vous gérez encore quelques machines équipées de Debian 6 et que vous souhaitez bénéficier du support étendu, quelques modifications et contrôles vont être nécessaires :

Il faut ajouter les lignes suivantes au fichier "/etc/apt/sources.list" :

deb http://http.debian.net/debian squeeze-lts main contrib non-free
deb-src http://http.debian.net/debian squeeze-lts main contrib non-free

Puis lancer :

apt-get update
apt-get upgrade

Quelques packages ne sont pas concernés par le support LTS. Pour connaître les éventuels paquets non pris en charge , il suffit d'installer "debian-security-support" ( apt-get install debian-security-support ) puis de lancer " check-support-status ".

A signaler également que ce support étendu n'est proposé que pour les architectures i386 et amd64. Pour les autres il faudra migrer vers Debian 7 !

Enfin, si vous souhaitez recevoir les avis de mise à disposition des correctifs par email n'oubliez pas de vous inscrire à la liste de diffusion spécifique : https://lists.debian.org/debian-lts-announce/ .

Plus d'infos :

Linux // Effectuer un reboot d’urgence à distance

stopVote serveur est hébergé dans un datacenter à plusieurs centaines de kilomètres. Vous disposez toujours d'un accès SSH mais la machine refuse de rebooter (Init 6, reboot, halt ... rien ne fonctionne...). Bien entendu vous ne disposez pas de module de contrôle de l'alimentation à distance ... C'est une situation que j'ai rencontré il y a peu de temps suite à un problème NFS sur l'un de mes serveurs.

Si vous rencontrez ce type de problème vous pouvez tenter les commandes "de la dernière chance" ;-).

Attention : en appliquant ces commandes vous allez engendrer un reboot direct (un peu comme si vous appuyez sur le bouton "reset" du serveur ...). Autant vous dire tout de suite que ce n'est pas vraiment ce qu'il y a de plus clean : rien ne va être fermé proprement, pas de sync sur les disques bref un vrai reboot à l'arrache (avec toutes les conséquences possibles ...) !

Voici donc les commandes à utiliser :

echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger

Si vous préférez arrêter complétement le serveur (attention quand même si vous êtes à plusieurs centaines de kilomètres c'est peut être pas une très bonne idée  😉 ) :

echo 1 > /proc/sys/kernel/sysrq
echo o > /proc/sysrq-trigger

Ces commandes ont pour effet de simuler l'usage de la combinaison de touche apellée "magic SysRq key". Cette combinaison de touche reconnue par le Kernel permet d’effectuer des opérations d'assez bas niveau sur votre système. Si vous souhaitez en savoir plus vous pouvez consulter cet article Wikipedia .

[HowTo] Installation et configuration d’OpenVPN sous Debian 7


Photo Post OpenVPN

En bons Geeks nous avons tous besoin, à un moment ou un autre, d'un VPN (pour se connecter en sécurité depuis un hot-spot public, pour accéder à des contenus disponibles qu'à partir de certaines zones géographiques ...). Il existe bien entendu une offre commerciale assez fournie mais partant du principe qu'on est jamais aussi bien servi que par soi même il n'est en fait pas très compliqué de mettre en œuvre sa propre solution (en s'appuyant par exemple sur des offres de VPS low cost ...).


Logo OpenVPN

Il existe aujourd’hui différentes technologies permettant la mise en place d'un tunnel VPN (IPSec, PPTP, L2TP ...). Toutefois ces protocoles nécessitent tous l'ouverture de certains ports et/ou protocoles au niveau des routeurs utilisés pour la connexion à l'Internet. Malheureusement lors de vos déplacements vous ne maîtrisez pas toujours ces aspects ... OpenVPN permet de s’affranchir de ce type de problème. En effet il est capable d'utiliser un port standard (par exemple le TCP:443) qui est habituellement utilisé pour les connexions HTTPS. S'agissant là d'un port largement utilisé il est fort probable que tous les accès Internet que vous rencontrerez laisseront passer ce type de flux !

Ce how-to est destiné à vous fournir les éléments nécessaires à la mise en œuvre de ce type de VPN en toute autonomie (côtés serveur et client).

OpenVPN en quelques concepts :

  • Open VPN nécessite un client spécifique en fonction de votre matériel (téléchargements disponibles ICI )
  • L'authentification est basée sur un système de certificats. Vous devrez générer ces certificats (et les clés associées) sur votre serveur pour chaque client. Ainsi qu'un certificat propre à votre serveur (qui jouera le rôle d'Autorité de Certification). Ces fichiers seront ensuite utilisés sur le client pour s'authentifier
  • La configuration du client est réalisée au travers d'un fichier de conf spécifique

Pré-requis : vous devez disposer d'un serveur Linux fonctionnant sous Linux Debian 7 qui n'utilise pas actuellement le port TCP:443(EDIT : voir le commentaire de Denis pour les possibilités de partage de ce port). Si vous utilisez déjà des règles IPtables vous serez amené à adapter la configuration de votre Firewall ...

Vous verrez c'est un peu long 😉 mais j'ai essayé de détailler chaque opération le plus précisément possible.

C'est parti!

  • Nous allons commencer à installer le serveur OpenVPN
apt-get install openvpn
  • On place au bon endroit les fichiers nécessaires à la génération des clés et certificats (OpenVPN est fourni avec un ensemble d'outils permettant la gestion de ces éléments : Easy RSA)
cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0/ /etc/openvpn/easy-rsa/
cd /etc/openvpn/easy-rsa/
  • On édite ensuite le fichier "vars" qui intègre les paramètres par défaut pour la génération des clés et certificats (les informations à modifier se situent à la fin de ce fichier)
vim vars

et adaptez les informations en fonction de vos besoins ...

# These are the default values for fields
# which will be placed in the certificate.
# Don't leave any of these fields blank.
export KEY_COUNTRY="FR"
export KEY_PROVINCE="Auvergne"
export KEY_CITY="ClermontFerrand"
export KEY_ORG="BdX"
export KEY_EMAIL="votre@email.com"
...
  • On lance ensuite ces commandes nécessaires à l'initialisation de différents paramètres de crypto et de l'Autorité de Certification
source ./vars
./clean-all
./build-dh
./pkitool --initca
./pkitool --server server
  • Après ces différentes opérations on crée le fichier de configuration du serveur OpenVPN (openvpn.conf)
cd /etc/openvpn/
vim openvpn.conf

Votre fichier devrait ressembler à ça :

8<----------------------------
port 443
proto tcp
dev tun
comp-lzo
persist-key
persist-tun
keepalive 10 20
server 10.8.0.0 255.255.255.0

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem

status openvpn-status.log

verb 3
8<----------------------------

  • On lance ensuite le serveur OpenVPN pour tester la conf ...
openvpn openvpn.conf

Vous devriez obtenir quelque chose de ce style :

root@debian:/etc/openvpn# openvpn openvpn.conf
Sun Feb 16 16:33:46 2014 OpenVPN 2.2.1 i486-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Jun 19 2013
Sun Feb 16 16:33:46 2014 NOTE: OpenVPN 2.1 requires &#039;--script-security 2&#039; or higher to call user-defined scripts or executables
Sun Feb 16 16:33:46 2014 Diffie-Hellman initialized with 1024 bit key
Sun Feb 16 16:33:46 2014 TLS-Auth MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
Sun Feb 16 16:33:46 2014 Socket Buffers: R=[87380-&gt;131072] S=[16384-&gt;131072]
Sun Feb 16 16:33:46 2014 ROUTE default_gateway=xxx.xxx.xxx.xxx
Sun Feb 16 16:33:46 2014 TUN/TAP device tun0 opened
Sun Feb 16 16:33:46 2014 TUN/TAP TX queue length set to 100
Sun Feb 16 16:33:46 2014 do_ifconfig, tt-&gt;ipv6=0, tt-&gt;did_ifconfig_ipv6_setup=0
Sun Feb 16 16:33:46 2014 /sbin/ifconfig tun0 10.8.0.1 pointopoint 10.8.0.2 mtu 1500
Sun Feb 16 16:33:46 2014 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2
Sun Feb 16 16:33:46 2014 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
Sun Feb 16 16:33:46 2014 Listening for incoming TCP connection on [undef]
Sun Feb 16 16:33:46 2014 TCPv4_SERVER link local (bound): [undef]
Sun Feb 16 16:33:46 2014 TCPv4_SERVER link remote: [undef]
Sun Feb 16 16:33:46 2014 MULTI: multi_init called, r=256 v=256
Sun Feb 16 16:33:46 2014 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0
Sun Feb 16 16:33:46 2014 MULTI: TCP INIT maxclients=1024 maxevents=1028
Sun Feb 16 16:33:46 2014 Initialization Sequence Completed
  • Il est ensuite souhaitable de modifier le paramétrage de votre système afin qu'il autorise le forward des paquets au travers du serveur :
vim /etc/sysctl.conf

On dé-commente (vers la ligne 28) :

net.ipv4.ip_forward=1

et on lance les deux commandes suivantes

sysctl -p
/etc/init.d/networking reload
  • Il est désormais nécessaire de modifier les règles Iptables afin de permettre aux paquets de transiter au travers de votre passerelle VPN (pour vous servir de votre serveur VPN comme d'une passerelle vers d'autres réseaux). Pour ce faire on crée puis on édite un fichier "firewall.rules" que l'on place dans "/etc". Afin de faciliter la mise en œuvre du système j'ai créé un fichier qui laisse entrer tous les flux ( :INPUT ACCEPT dans la section "Filter"). Vous devez bien entendu l'adapter en fonction de vos besoins ...
vim /etc/firewall.rules

Voici le contenu du fichier

*nat
:PREROUTING ACCEPT
:INPUT ACCEPT
:OUTPUT ACCEPT
:POSTROUTING ACCEPT
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT

*filter

:INPUT ACCEPT
:FORWARD DROP
:OUTPUT ACCEPT

-A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i tun0 -o eth0 -j ACCEPT

COMMIT
  • On crée ensuite le fichier d'initialisation du firewall (qui va utiliser les directives données au sein de /etc/firewall.rules)
vim /etc/init.d/firewall

Voici le contenu du fichier

#!/bin/sh
/sbin/iptables-restore /etc/firewall.rules

On donne les droits d’exécution à ce script

chmod 755 /etc/init.d/firewall

On lance une première fois manuellement ce script

/etc/init.d/firewall

Et on indique au système que ce script doit être lancé automatiquement au démarrage du système

update-rc.d firewall defaults
  • et pour finir côté serveur on lance le service "OpenVPN"
service openvpn start
  • On passe ensuite à la génération des certificats et des clés destinés aux clients : remplacez nom_du_user par le nom de l'utilisateur (pas d'espace, pas de caractères spéciaux ...)
cd /etc/openvpn/easy-rsa
source vars
./build-key nom_du_user

Répondez aux questions (pour le CN - Common Name - utilisez la même chaine que pour nom_du_user)

  • A l'issue de cette opération on récupère les fichiers suivants dans le répertoire /etc/openvpn/easy-rsa/keys (ces derniers devront être déposés sur votre client)
Nom du fichier Contenu
nom_du_user.crt Certificat de l'utilisateur
nom_du_user.key Clé privée associée au certificat de l'utilisateur
ca.crt Certificat de l'autorité de certification
  • Il faut ensuite créer le fichier de conf (côté client) qui sera fourni au logiciel OpenVPN pour se connecter. Vous pouvez utiliser n'importe quel éditeur de texte sur votre OS habituel. Voici ce qu'on doit trouver dans ce fichier (extension .conf pour Linux/MacOS ou .ovpn pour les clients Windows et Android). Respectez l'extension c'est important ! Sous Windows le fichier de conf doit être déposé au sein du répertoire "C:\Program Files\OpenVPN\config\". N'oubliez pas de placer également les 3 fichiers cités ci-dessus (.crt/.key) au sein de ce répertoire de configuration de votre client.

Voici le contenu du fichier de configuration du client :

client
dev tun
proto tcp
remote INDIQUEZ_ICI_L_IP_DE_VOTRE_SERVEUR 443
resolv-retry infinite
nobind

ca ca.crt
cert nom_du_user.crt
key nom_du_user.key

persist-key
persist-tun

comp-lzo

verb 3
  • Si vous utilisez Windows voici deux points importants à vérifier (qui vous feront gagner du temps 😉 ) :

  • que votre fichier de configuration porte bien l'extension ".ovpn" (Windows à souvent la bonne idée d’ajouter un .txt derrière ... on se retrouve alors un .ovpn.txt le .txt étant bien entendu masqué ...).

  • que OpnVpn GUI soit bien lancé avec les droits d'administrateur (autrement ça ne fonctionne pas !)

Sous Windows il ne vous reste plus qu'à cliquer-droit sur l'icone OpenVPN GUI dans la barre de tâche et de choisir "connecter" !

Pour les autres plateformes je vous laisse vous reporter à la documentation fournie avec votre client Open VPN en sachant que le fichier de conf ainsi que les certificats et clés sont compatibles sur tous les OS.

Si vous repérez des erreurs, imprécisions, omissions (et oui ça peut arriver ...) n'hésitez pas à me l'indiquer dans les commentaires !

Linux // Surveillez vos processus avec HTOP

htopComme tout administrateur Linux vous devez certainement utiliser "top" pour surveiller les process fonctionnant sur vos machines. "top" fonctionne bien mais il existe toutefois une alternative plus sympa à utiliser : Htop.

Les différences avec "top" ?

  • une interface plus sympa (et personnalisable --> pressez la touche F2 ...)
  • une visualisation plus simple (sous forme de bar graph) de la charge du (des) processeur(s) et de la mémoire
  • la possibilité de scroller horizontalement et verticalement au sein de la liste des processus
  • la possibilité d'effectuer une recherche basée sur le nom d'un process
  • la possibilité de killer ou de changer la proirité (nice) d'un process d'une manière plus rapide (sans avoir à saisir l'ID du processus)
  • une utilisation plus intuitive grâce à l'utilisation d'un menu accessible avec les touches de fonction
  • ...

Enfin bref, "htop" est, à l'usage, vraiment plus agréable à utiliser que "top" (si vous voulez en savoir plus sur les différences entre ces 2 utilitaires allez jeter un oeil ICI)

Pour les utilisateurs de Debian "htop" s'installe avec un simple :

apt-get install htop

Pour les autres distributions (ou si vous souhaitez installer à partir des sources) je vous conseille de vous rendre ICI

DTRX : le « couteau suisse » de l’extraction de fichiers pour Linux

image titre

Si vous travaillez souvent sous Linux, en ligne de commande, il vous est certainement déjà arrivé de galérer pour extraire le contenu d'une archive portant une extension un peu exotique...

J'ai découvert récemment un petit utilitaire qui va probablement vous simplifier la vie : DTRX (pour "Do The Right eXtraction").

Son fonctionnement est des plus simple :

dtrx le_nom_de_l_archive

L'utilitaire va automatiquement reconnaître le type d'archive (tar, zip, cpio, deb, rpm, gem, 7z, cab, lzh, rar, gz, bz2, lzma, xz, exe...) et la décompresser dans un dossier dédié le tout en fixant les droits et permissions nécessaires pour que l'utilisateur puisse y accéder. Impossible donc de se retrouver avec l'intégralité des fichiers extraits au beau milieu de la racine ... certains comprendront certainement de quoi je parle :-).

Concernant les pré-requis : disposer d'un système équipé de Python (2.4 minimum) et des outils de compression / archivage concernés (DTRX n'est en fait qu'un module destiné à appeler correctement les programmes d'extraction). La liste des outils nécessaires est fournie au sein du fichier INSTALL du package d'installation. La plupart des systèmes Linux récents devraient toutefois, par défaut, déjà embarquer l’ensemble des utilitaires nécessaires.

Pour les utilisateurs de Debian un simple "apt-get install dtrx" devrait être suffisant !

Le site officiel est disponible ICI

Crédit photo Let Ideas Compete

« Adminer » : une bonne alternative à PhpMyAdmin

logo_adminerJusqu'à maintenant, lorsque j'installais un serveur LAMP j'avais pour habitude d'y ajouter systématiquement PhpMyAdmin. Non pas que je sois allergique à la ligne de commande (ça serait même plutôt l'inverse ...) mais il faut reconnaître que pour manipuler rapidement une base de données MySQL une interface web n'est pas de trop !

Malheureusement, au fil du temps, PhpMyAdmin est devenu de plus en plus lourd et de plus en plus complexe. C'est donc avec plaisir que j'ai découvert, essayé et approuvé "Adminer". Il s'agit d'une alternative intéressante à PhpMyAdmin pour les raisons suivantes :

- Adminer tient dans un seul et même script PHP. Et oui vous avez bien lu : pour l'installer il suffit de télécharger le script (un peu moins de 300ko), de le placer au sein de votre espace d'hébergement, de faire pointer votre navigateur dessus et le tour est joué !

- bien que l'interface soit particulièrement simple et sobre (ce qui n'est pas sans me déplaire) toutes les fonctions de PhpMyAdmin semblent être présentes (du moins je n'ai pas constaté de fonction manquante pour mes usages) ;

- Adminer est également compatible avec d’autres bases de données : PostgreSQL, SQLite, MS SQL & Oracle (mais là je n'ai pas essayé ...) ;

- Les mises à jour sont simplifiées à l’extrême : vous remplacez tout simplement l'ancien script par le nouveau.

adminer_screen_db

Petite information pour les utilisateurs de Debian (mais certainement aussi pour les autres distribs) il est nécessaire d'ajouter préalablement le module php5-mysql à l'aide de la commande "apt-get install php5-mysql" (nécessaire pour que Adminer puisse communiquer avec votre base de données Mysql).

Plus d'infos sur Adminer ? C'est par ICI

Gérez « AWS Glacier » en ligne de commande

AWS_LOGO_RGB_300px

Pour ceux qui seraient passés à côté, Amazon Glacier est un système de stockage sur le cloud d'Amazon (un peu comme S3) dédié à la conservation "longue durée" de vos données (un système d'archivage en quelque sorte).

Par rapport à S3 le principal avantage de cette solution est le prix. En effet avec un coût de $0,01 par Go et par mois il s'agit certainement là de la solution de stockage la plus économique du marché (10€ / 1To / mois difficile de faire mieux) - A titre de comparaison 1To stocké sur S3 coûte 95$ / mois !

Bon à ce tarif là vous devez vous douter qu'il y a quelques inconvénients. Le plus significatif est certainement le délai de récupération des données. En effet si l'upload d'informations est immédiat, toute opération de récupération de données va nécessiter une attente préalable d'au moins 4 h ! Et ce délai concerne toutes les opérations : même une demande d’inventaire (un "ls" en quelque sorte) du contenu d'un dépôt va demander le même délai (4h) avant d'obtenir le résultat de votre requête ...

Il est donc clair qu'avec une telle contrainte il faut réserver l'usage de Glacier à des seules fins d'archivage ...

A l'inverse de S3 il n’existe pas (pour le moment) d'interface web (fournie par Amazon) permettant de gérer le contenu de ses archives. Plusieurs logiciels dédiés existent toutefois sur le marché. J'ai par exemple testé "FastGlacier" sur une des mes machines Windows (ce soft est gratuit pour un usage non commercial). Toutefois, dans certains cas, il est plus pratique d'utiliser directement une interface en ligne de commande (pour archiver le contenu d'un serveur Linux par exemple). Il existe, pour ce faire, un ensemble de scripts Python totalement fonctionnels et qui permettent d'agir sur vos archives. Il s'agit de "glacier-cmd".

L'installation (et l'utilisation) de "glacier-cmd" ne pose pas vraiment de problème, mais j'ai quand même décidé de faciliter la tâche à ceux (celles) d'entres vous qui ont quelques petites difficultés avec la langue anglaise et/ou démarrer rapidement à partir d'un document de synthèse.

C'est parti ...

Ce how-to est basé sur l'utilisation d'une distribution Debian 6 "out of the box" sans particularité. Bien entendu aucune interface graphique n'est nécessaire (c'est d’ailleurs un peu l'objectif de ce how-to ...)

La première chose à faire est de s'assurer que Python est bien installé sur votre système.

Un petit "python -V" devrait vous retourner la version de Python installée

Dans le doute vous pouvez toujours lancer un "apt-get install python" ça ne peut pas faire de mal !

Il faut ensuite passer à l'installation de "Git" (qui vous permettra de faciliter l'installation de "glacier-cmd")

apt-get install git

On récupére ensuite l'intégralité de glacier-cmd avec une seule ligne de commande :

git clone https://github.com/uskudnik/amazon-glacier-cmd-interface.git

On entre dans le répertoire où ont été récupérées les sources

cd amazon-glacier-cmd-interface/

On installe un module supplémentaire pour Python nécessaire au lancement du script d'installation

apt-get install python-setuptools

Et on lance finalement le script d'installation

python setup.py install

On va ensuite créer un fichier de configuration pour glacier-cmd.

vi /etc/glacier-cmd.conf

Le fichier va ressembler à ça :


[aws]
 access_key=Identifiant de clé d’accès
 secret_key=Clé d’accès secrète

[glacier]
 region=us-east-1
 logfile=~/.glacier-cmd.log
 loglevel=INFO
 output=print

Pour récupérer (ou créer les clés AWS) il faut se connecter ICI

Ce fichier de conf va également vous permettre de sélectionner la zone géographique où seront hébergés vos données (les tarifs varient légèrement en fonction de ce paramètre : toutes les infos sont ICI ).

Les valeurs possibles pour "region" sont donc les suivantes :


us-east-1 pour : US - Virginia
us-west-1 pour : US - N. California
us-west-2 pour : US - Oregon
eu-west-1 pour : EU - Ireland
ap-northeast-1 pour : Asia-Pacific - Tokyo

On peut ensuite passer à l'utilisation de glacier-cmd. Les principales commandes sont les suivantes :

  • Pour créer un dépôt ("vault") de stockage (afin d'y déposer ensuite des archives)
    glacier-cmd mkvault <le_nom_de_votre_dépôt>
    
  • Pour lister les dépôts disponibles :
    glacier-cmd lsvault
  • Pour obtenir le contenu (liste des archives/fichiers) d'un dépôt (attention le résultat de cette commande ne sera disponible qu'après 4h d'attente ...)
    glacier-cmd inventory <le_nom_de_votre_dépôt>
  • Pour uploader une archive (fichier) au sein d'un dépôt :
    glacier-cmd upload <nom_de_votre_dépôt> <nom_du_fichier_a_uploader> --description "la_description_du_fichier"
  • Pour télécharger les archives (fichiers) contenues au sein d'un dépôt  :

    L'opération se déroule en deux temps:

    1) On lance une demande de récupération de l'archive avec la commande suivante :

    glacier-cmd getarchive <nom_de_votre_dépôt> <id_de_l'archive_à_récupérer>

    NB : On récupère l'id de l'archive avec la commande "inventory" (voir ci-dessus)

    2) Après environ 4h d'attente vous pouvez demander le téléchargement de l'archive avec cette commande :

    glacier-cmd download <nom_de_votre_dépôt> <id_de_l'archive_à_récupérer> --outfile <nom_du_fichier>

    Donc pour résumer une récupération "type" s'effectue en 8h : 4h pour obtenir le contenu du dépôt (avec les identifiants d'archives) puis 4h pour obtenir une archive prête à être téléchargée et enfin le temps nécessaire au téléchargement du fichier ! Mieux vaut ne pas être pressé ...

  • Pour obtenir la liste de jobs en cours (inventaire, récupération ...) :
glacier-cmd listjobs nom_de_votre_dépôt

Ce how-to n'a bien entendu pas vocation à être exhaustif. Si vous souhaitez découvrir l'intégralité des fonctionnalités proposées par glacier-cmd, je vous invite à consulter la documentation disponible ICI .

Dans un prochain billet, je vous présenterai une solution permettant d'automatiser le backup d'un serveur Linux vers Glacier ...

[HOWTO] Automatisez la sauvegarde de vos serveurs avec « Rdiff-Backup »

Si vous administrez des serveurs Linux vous vous êtes déjà probablement interrogé sur la meilleure façon de sauvegarder vos systèmes et données. La télé-sauvegarde est une option particulièrement intéressante. Bien que Rsync paraîsse naturellement le dispositif le mieux adapté à cette tâche une autre solution existe : Rdiff-backup.

Moins connu, ce dernier présente de nombreux avantages : une gestion optimisée des incréments, la création d'un miroir de fichiers ou de répertoires, la gestion automatisée de l'effacement des anciens incréments, la compression des données transférées ... Rdiff-Backup est utilisable en "local" mais également dans le cadre d'un système de télé-sauvegarde. Dans ce cas les échanges sont cryptés en utilisant (de manière transparente) le protocole SSH.

L'objectif de ce how-to est de présenter une méthode permettant de réaliser une sauvegarde à distance, sécurisée, automatisée, sans aucune intervention de la part de l'administrateur (les procédures d'authentification reposant sur un système de clés asymétriques).

La distribution utilisée pour la création de ce how-to est une "Ubuntu 10.04 LTS server", mais il ne devrait pas y avoir beaucoup de différences si vous utilisez un autre Linux. Un serveur SSH doit également être présent sur les 2 machines.

Dernière précision : afin de simplifier cette procédure j'utilise volontairement l'utilisateur "root" pour réaliser la sauvegarde. Pour optimiser la sécurité, les "puristes" pourront bien entendu adapter cette  méthode  avec un autre compte utilisateur ...

Dans le cadre de ce tutoriel nous allons utiliser deux serveurs :

  • "srv-prod ": qui correspond au serveur "à sauvegarder" (IP dans ce how-to : 192.168.0.157)
  • "srv-backup" : qui correspond au serveur destiné à héberger la sauvegarde de srv-prod

On procède tout d'abord à l'installation de "Rdiff-Backup" en lançant (sur les 2 serveurs) la commande

apt-get install rdiff-backup

On va ensuite générer les clés SSH nécessaires à l'authentification de "srv-backup" auprès de "srv-prod". Créez (si ce n'est pas déjà fait) sur "srv-backup" un répertoire nommé "/root/.ssh/". On lance ensuite (sur ce même serveur)  la commande suivante :

ssh-keygen -t rsa -b 4096

Répondez de la manière suivante aux questions posées par l'application :

Enter file in which to save the key (/root/.ssh/id_rsa): /root/.ssh/rdiff_id_rsa

Ne rien mentionner en réponse à la question "Enter passphrase (empty for no passphrase):". Idem pour "Enter same passphrase again:"

Suite à cette opération, vous trouverez 2 fichiers au sein du répertoire "/root/.ssh" :

  • rdiff_id_rsa : qui correspond à votre clé privée
  • rdiff_id_rsa.pub : votre clé publique (qui devra, par la suite, être positionnée sur le serveur de production ...

Pour ce faire il est nécessaire d'éditer le fichier "rdiff_id_rsa.pub" (avec un petit "cat /root/.ssh/rdiff_id_rsa.pub" par exemple). Vous devriez obtenir une chaîne de la forme :

Bien entendu le contenu de votre fichier sera différent car il s'agit de clés générées aléatoirement (heureusement ... 😉 )

Copiez ensuite cette chaîne de caractères afin de pouvoir la coller dans le fichier "/root/.ssh/authorized_keys2" du serveur de production ("srv-prod"). Dans l'hypothèse où ce répertoire (".ssh") et ce fichier ("authorized_keys2") n'existent pas il sera nécessaire de les créer manuellement. Attention aux droits à appliquer sur le fichier "authorized_keys2" qui doivent être positionnés à 644 ("chmod 644 /root/.ssh/authorized_keys2"). Il faut également s'assurer de copier la chaîne de caractères tel-quel sans y ajouter aucun caractère n'y retour chariot.

Une fois la clé copiée, il est nécessaire d'y ajouter (sur "srv-prod") certaines options comme illustré dans l'exemple ci-dessous :

Les directives à placer devant la clé sont les suivantes (il ne vous reste plus qu'à copier / coller ...) : "command="rdiff-backup --server --restrict-read-only /",no-port-forwarding,no-X11-forwarding,no-pty ". Il s'agit de mesures de sécurités complémentaires. En effet le serveur de backup s'authentifiant de manière automatisée, il est intéressant de limiter les opérations réalisables avec ce compte (pas de terminal, opération en lecture seule uniquement, pas de forward de ports ...).

Sur le serveur "srv-backup" créez le fichier "/root/.ssh/config". Ce dernier va intégrer les éléments nécessaires à la connexion automatique au serveur de production. Le contenu de ce fichier est le suivant :

host 192.168.0.157
hostname 192.168.0.157
user root
identityfile /root/.ssh/rdiff_id_rsa
compression yes
protocol 2

Bien entendu vous devez remplacer l'IP (192.168.0.157) par l'adresse de votre serveur de prod (ou bien par son nom pleinement qualifié). Vous pouvez également modifier le paramètre "compression" en le passant à "no" si vous ne souhaitez pas compresser les données échangées entre les deux serveurs.

Créez ensuite, sur "srv-backup" un répertoire au sein duquel seront stockées les données sauvegardées. Par exemple "mkdir /backup"

Il ne reste plus qu'à essayer de générer une sauvegarde d'un des répertoires du serveur de production ("/etc" par exemple) en utilisant une commande du style :

rdiff-backup -v 5 root@192.168.0.157::/etc /backup/etc

Vous allez voir apparaître un message du type :

The authenticity of host '192.168.0.157 (192.168.0.157)' can't be established.
RSA key fingerprint is 60:6b:12:0a:6f:bf:98:da:83:5c:43:16:f2:72:3c:29.
Are you sure you want to continue connecting (yes/no)?

répondez "yes" (cette question ne sera plus posée par la suite). Vous devriez voir la sauvegarde se réaliser. Un petit contrôle du répertoire "/backup/etc" confirme la présence des fichiers.

Vous pouvez automatiser (via le crontab) cette tâche de sauvegarde en vous inspirant, après adaptation, de ce script (merci à  @ledeuns pour sa contribution ) :

#!/bin/bash</p>
RETCODE=""

### Sauvegarde ###

/usr/bin/rdiff-backup  root@192.168.0.157::/var /backup/var
if [ $? -ne 0 ]; then RETCODE="VAR;"; fi
/usr/bin/rdiff-backup  root@192.168.0.157::/etc /backup/etc
if [ $? -ne 0 ]; then RETCODE="ETC;$RETCODE"; fi
/usr/bin/rdiff-backup root@192.168.0.157::/home /backup/home
if [ $? -ne 0 ]; then RETCODE="HOME;$RETCODE"; fi
/usr/bin/rdiff-backup root@192.168.0.157::/root /backup/root
if [ $? -ne 0 ]; then RETCODE="ROOT;$RETCODE"; fi
/usr/bin/rdiff-backup root@192.168.0.157::/usr /backup/usr
if [ $? -ne 0 ]; then RETCODE="USR;$RETCODE"; fi

### Effacement des increments datant de plus de 2 semaines (2W) ###

/usr/bin/rdiff-backup --force --remove-older-than 2W /backup/var/
if [ $? -ne 0 ]; then RETCODE="DELVAR;$RETCODE"; fi
/usr/bin/rdiff-backup --force --remove-older-than 2W /backup/etc/
if [ $? -ne 0 ]; then RETCODE="DELETC;$RETCODE"; fi
/usr/bin/rdiff-backup --force --remove-older-than 2W /backup/home/
if [ $? -ne 0 ]; then RETCODE="DELHOME;$RETCODE"; fi
/usr/bin/rdiff-backup --force --remove-older-than 2W /backup/root/
if [ $? -ne 0 ]; then RETCODE="DELROOT;$RETCODE"; fi
/usr/bin/rdiff-backup --force --remove-older-than 2W /backup/usr/
if [ $? -ne 0 ]; then RETCODE="DELUSR;$RETCODE"; fi

### Envoi du rapport par mail ###

if [ -z $RETCODE ]; then
echo "" | mail -s "Sauvegarde effectuee" votre@adresse.fr
else
echo "$RETCODE" | mail -s "Sauvegarde en erreur" votre@adresse.fr
fi

Ce how-to n'ayant pas vocation à décrire d'une manière exhaustive le fonctionnement de Rdiff-Backup, je vous invite à consulter le manuel détaillé disponible à cette adresse (vous pourrez y découvrir l'ensemble des commandes et options disponibles) !

  • Le site officiel est disponible ICI