walk-hoary

Messages étiquettés ssh

Communiquer entre l’hôte et les containers LXC

Aujourd’hui j’utilise un Raspberrry Pi comme routeur chez moi. Il me permet de me passer de la box internet et d’isoler les équipements de mon réseau avec des VLAN.

J’ai dans l’optique de rassembler différents services sur un seul hôte afin de réduire le nombre d’appareils, en commençant par Home-assistant et le système de routage/DHCP. Plus tard, ce sera d’autres service comme tvheadend qui permet de broadcaster la TNT reçue à mon domicile par une clé USB vers un serveur multimédia Jellyfin dans le cloud.

Quel hyperviseur sous Raspberry Pi ?

Pour cela, je me suis penché sur docker, mais cela ne me satisfait pas entièrement à cause des contraintes au niveau réseau qui sont souvent mal documenté ou géré par les mainteneurs des images. Proxmox était pour moi le candidat idéal, mais non supporté sur ARM64. Je me suis donc tourné vers LXC qui est la couche de conteneurisation utilisé par Proxmox. A noter que LXD convient également, il s’agit d’une implémentation plus évoluée de LXC, mais la direction de l’éditeur LXD me semble floue et incertaine et ne l’ai donc pas utilisé.

Un réseau simple

Un point important dans l’architecture est que je veux avoir accès aux différentes couches et d’une façon la plus naturelle possible, c’est à dire se rapprochant d’une architecture matérielle. Je trouve cela beaucoup plus facile à se le représenter et à l’exploiter, surtout si je dois y intervenir rarement.

Je veux par exemple, me connecter en SSH sur le RaspberryPi et rebondir en SSH sur différents containers. Et bien sachez que ce n’est pas possible naturellement sous docker ou LXC, il vous faudra créer une interface macvlan pour chaque container sur vôtre hôtes. Ça me parait beaucoup et ajoute une complexité à l’architecture que je ne veux pas.

Solution

La solution que j’ai trouvé est de se baser sur des interfaces bridges. Ainsi, les containers sont capables de communiquer avec l’extérieur mais surtout avec l’hôte.

Voici la configuration réseau du Raspberry Pi. Avec ceci, vous pourrez utiliser les liens habituels VETH avec LXC.

# /etc/network/interfaces.d/eth0
auto eth0
iface eth0 inet static
        address 192.168.0.1/24

# /etc/network/interfaces.d/br7
auto eth0.7
iface eth0.7 inet manual

auto br7
iface br7 inet static
        bridge_ports eth0.7
        bridge_fd 0
        bridge_maxwait 120
        address 10.35.7.1/24

Note : eth0.7 est une syntaxe qui vous permet d’avoir une interface qui ne communiquera qu’avec le traffic tagué VLAN 7. (Au même titre que eth0:1 vous permet d’avoir une nouvelle interface alias de eth0)

Tags: ,

Être averti des connexions SSH

Vous avez un serveur SSH, il peut être  interessant d’être notifié lorsque quelqu’un se connecte sur votre serveur / votre machine.

Remplacez votre@email par l’email voulu.

Voici un bout de code à mettre à la fin de votre ~/.bashrc des comptes concernés :

SSH_CONNECTION_CLIENT_IP=`echo $SSH_CONNECTION | cut -d" " -f1`
SSH_CONNECTION_CLIENT_HOSTNAME=`host $SSH_CONNECTION_CLIENT_IP | cut -d" " -f5`
SSH_CONNECTION_CLIENT_PORT=`echo $SSH_CONNECTION | cut -d" " -f2`
SSH_CONNECTION_SERVEUR_IP=`echo $SSH_CONNECTION | cut -d" " -f3`
SSH_CONNECTION_SERVEUR_HOSTNAME=`host $SSH_CONNECTION_SERVEUR_IP | cut -d" " -f5`
SSH_CONNECTION_SERVEUR_PORT=`echo $SSH_CONNECTION | cut -d" " -f4`
SSH_CONNECTION_LOGIN=`whoami`
SSH_CONNECTION_HOST=`hostname`
SSH_CONNECTION_HEURE=`date`
SSH_CONNECTION_LOAD=`cat /proc/loadavg`
SSH_CONNECTION_OS=`cat /proc/version | cut -d"#" -f1`
SSH_CONNECTION_LISTWHO=`who`
echo -e "Accès Shell sur $SSH_CONNECTION_LOGIN@$SSH_CONNECTION_HOST depuis $SSH_CONNECTION_CLIENT_IP ($SSH_CONNECTION_CLIENT_HOSTNAME)
------------------------------------
IP client     : $SSH_CONNECTION_CLIENT_IP :$SSH_CONNECTION_CLIENT_PORT ($SSH_CONNECTION_CLIENT_HOSTNAME)
IP Serveur    : $SSH_CONNECTION_SERVEUR_IP :$SSH_CONNECTION_SERVEUR_PORT ($SSH_CONNECTION_SERVEUR_HOSTNAME)
Heure serveur : $SSH_CONNECTION_HEURE
Load average  : $SSH_CONNECTION_LOAD
OS            : $SSH_CONNECTION_OS
Connexions    :
$SSH_CONNECTION_LISTWHO
------------------------------------" | mail -s "Accès Shell sur Accès Shell sur $SSH_CONNECTION_LOGIN@$SSH_CONNECTION_HOST depuis $SSH_CONNECTION_CLIENT_IP ($SSH_CONNECTION_CLIENT_HOSTNAME)" votre@email &

Tags: , ,

Redirection de port via SSH

Rediriger un port peut s’avérer très utile lorsque par exemple vous n’avez pas accès au port tant convoité sur un serveur.

Dans mon cas, je souhaite pouvoir utiliser la base de donnée mysql située sur un serveur principal, depuis un site qui se situe sur une autre serveur (dit de secours).

Ce schema illustre bien mon exemple, pour réaliser cela, il suffira d’ouvrir une connexion ssh depuis le serveur principale vers le serveur secondaire en utilisant la redirection de port. 😉

Tags: , , ,

Comment sauvegarder votre serveur ?

Posséder ou gérer un serveur c’est bien, mais en oublier ses sauvegardes c’est mal !

Je vous propose ici une méthode pour faire des sauvegardes complètes et incrémentales très simples pour vos données. Je vous parlerais de la sauvegarde du système par la suite.

Que sauvegarder ?

On va s’occuper uniquement des données modifiables par vous et vos application, je parle bien sûr de vos scripts, bases de données et tout ce qui est hors système.

Quand sauvegarder ?

Cela va dépendre de la vitesse de changement de vos données, il va de soi que nous n’aurons pas besoin d’une sauvegarde toute les heures pour un site personnel.
Personnellement, j’estime à 2 heures de perte maximum pour mes bases de données et 24H pour les fichiers.

Où sauvegarder ?

Sauvegarder sur la même machine n’a qu’un intérêt très limité, en cas d’erreur humaine sur la machine ou accident matériel, nous perdons la machine et ses sauvegardes.
Il est donc important de placer ses sauvegardes sur un support géographiquement décalé par rapport à la machine à sauvegarder.

De quel façon sauvegarder ?

Nous utiliserons ssh pour réaliser nos transferts d’un serveur à l’autre. Le serveur de sauvegarde lancera de lui même les opérations par tache cron.

Nous allons dans cette exemple faire une sauvegarde par jour, et conserver les sauvegardes des 2 derniers jours, 2 dernières semaines, et 2 derniers mois.
Le principe est simple et a déjà fait ses preuves, nous utilisons les hardlinks :

  1.  On imagine que une sauvegarde de la veille existe déjà sur le serveur des sauvegardes.
  2. On déplace la sauvegarde de la veille dans « backup_J-1 »
  3. On duplique ce répertoire avec des hardlinks, notre copie sera donc très légère par rapport à une sauvegarde complète, mais tout le fichiers sont présents.
  4. On synchronise cette copie avec la machine à sauvegarder

Pour les bases de données, j’utilise un script qui crée une archive par base de données ; le script a la faculté de découvrir toutes les bases de l’utilisateur employé.

Le script

Voici mon script lancé une fois par jour :
#!/bin/shdirbackups='/home/user/backups'
dirtoarchive='user@machine:/home/linuxquimp'
targetdumps=$dirbackups/day-1/mysql
bdduser=user_bdd
bddpass='pass_bdd'
bddhost='machine'

#Deplacement des archives
mv $dirbackups/day-3 $dirbackups/day-3-deleted
rm -rf $dirbackups/day-3-deleted
mv $dirbackups/day-2 $dirbackups/day-3
mv $dirbackups/day-1 $dirbackups/day-2
mv $dirbackups/day $dirbackups/day-1

# Creation de la copie de day-1/ sur day/
mkdir -p $dirbackups/day
cp -al $dirbackups/day-1/* $dirbackups/day/
rm -rf $dirbackups/day/mysql

# Synchronisation
rsync --delete --stats --rsync-path=/home/user/cron/rsync-2.6.9/rsync $dirtoarchive/ $dirbackups/day

databases=(`echo 'show databases;' | mysql -h $bddhost -u $bdduser --password=$bddpass | grep -v ^Database$`)
test -d $targetdumps || mkdir -p $targetdumps
for d in "${databases[@]}"; do
if [[ $d != 'tmp' && $d != 'test' && $d != 'information_schema' ]]
then
mysqldump --host=$bddhost --user=$bdduser --password=$bddpass --quick --add-drop-table --all ${d} | gzip > $targetdumps/${d}.sql.gz
fi
done

Rien de ne vous empeche d’utiliser la partie qui sauvegarde les bases de données dans un cron lancé plusieurs fois par jour/ par heure.

Je pense que vous aurez compris qu’il faille aussi toute les semaines et tout les mois lancer les autres scripts qui permettent de deplacer les backups dans les bons repertoires.

Toute les 2 heures :
#!/bin/sh

dirtoarchive='user@machine:/home/linuxquimp'
targetdumps=$dirbackups/day/mysql
bdduser=user_bdd
bddpass='pass_bdd'
bddhost='machine'

databases=(`echo 'show databases;' | mysql -h $bddhost -u $bdduser --password=$bddpass | grep -v ^Database$`)
ladate=(`date +%F_%H-%M-%S`)
test -d $targetdumps || mkdir -p $targetdumps
for d in "${databases[@]}"; do
if [[ $d != 'tmp' && $d != 'test' && $d != 'information_schema' ]]
then
mysqldump --host=$bddhost --user=$bdduser --password=$bddpass --quick --add-drop-table --all ${d} | gzip > $targetdumps/${d}_$ladate.sql.gz
fi
done

Toute les semaines avant le backup du jour :
Dans ce script je supprime les dumps mysql faits chaque heure
#!/bin/sh
dirbackups='/home/user/backups'

# deplacement des archives

rm $dirbackups/week-2
mv $dirbackups/week-1 $dirbackups/week-2
mv $dirbackups/day-3 $dirbackups/week-1

#Suppression des dump horaires database
#rm -rf $dirbackups/week-1/mysql
rm $dirbackups/week-1/mysql/*_*-*-*_*-*-*.sql.gz

Tous les mois avant le backup de la semaine :
#!/bin/sh
dirbackups='/home/user/backups'

#deplacement des archives
mv $dirbackups/month-3 $dirbackups/month-3-deleted
rm -rf $dirbackups/month-3-deleted
mv $dirbackups/month-2 $dirbackups/month-3
mv $dirbackups/month-1 $dirbackups/month-2
mv $dirbackups/week-2 $dirbackups/month-1

Il y a surement des erreurs mais le principe est là… 😉

Tags: , , , , ,

Authentification automatique par SSH sans mot de passe

Simplement avec un système de certificat.

Voici comment ça fonctionne

Imaginons un poste client et un poste serveur, nous tentons évidement d’etablir une connexion ssh du client vers le serveur.
Habituellement, nous tapons la commande : ssh user@machine , puis on entre le mot de passe.

Pour éviter cela, nous allons faire 2 choses :

  1. Créer un jeu de clés (clé publique et clé privée) sur le client
  2. Copier la clé publique du client sur le serveur.

Voici comment procéder

Générer le jeu de clé/certificat sur le client

ssh-keygen -t dsa
On vous demandera où placer ce jeu, répondez par default.
On vous demandera une passphrase pour crypter votre certificat, vous pouvez ne rien mettre si vous estimez que vous seul pouvez acceder à votre compte local du client.

Copiez la clé publique sur le serveur

ssh-copy-id -i ~/.ssh/id_dsa.pub user@machine
Cette commande ne fait qu’ajouter votre clé publique dans un fichier sur le serveur. Voici une commande équivalente :
cat ~/.ssh/id_dsa.pub | ssh user@machine "cat - >> ~/.ssh/authorized_keys"

Voila, vous pouvez desormais vous identifier sur le serveur sans mot de passe.

Tags: , , , ,

Je n'aime pas les boîtes noires.