Installation d’X2Go sur Debian Jessie

X2go est une application client/serveur qui permet de rediriger l’affichage d’un serveur X sur une autre machine. Dans mon cas personnel, j’ai une machine sous GNU/Linux Debian Jessie qui me permet de surfer sur internet et d’exécuter quelques applications graphiques, j’ai donc un environnement graphique MATE auquel j’accède via la console VMware, mais cela n’est pas toujours pratique (besoin de s’identifier côté VMware, de lancer la console et de se connecter ensuite à la machine). Afin de pouvoir me connecter à la machine comme je me connecterai en RDP à une machine Windows, je vais donc installer le composant serveur d’X2go sur ma machine GNU/Linux et le client sur les systèmes à partir desquels je vais accéder à Debian.

X2go se sert de SSH pour communiquer avec le serveur X présent sur le serveur. Cela signifie que tous les flux sont sécurisés et qu’il est nécessaire que le port 22 soit en écoute afin que l’on puisse se connecter, bien qu’il soit possible de modifier le port d’X2go.

Installation du serveur 

Ajouter le dépôt pour les paquets d’X2go, car ils ne sont pas fournis par défaut dans les dépôts officiels de Debian. On créé un fichier x2go.list dans /etc/apt/sources.list.d et on y ajoute la ligne suivante :



deb http://packages.x2go.org/debian jessie main

Puis on y installe le premier paquet x2go-keyring qui va permettre de communiquer avec les dépôts d’X2go et de gérer la partie sécurité de ceux-ci. Étant donné qu’il n’est pas encore installé, on aura un message d’avertissement lors de la mise à jour de la liste, il est à ignorer et ne reviendra pas par la suite.

apt-get update 
apt-get install x2go-keyring
apt-get update

Et enfin, on installe le paquet x2goserver, et toutes les dépendances nécessaires qui seront ajoutées automatiquement.

apt-get install x2goserver

Installation du client et configuration d’un hôte

 

Il est possible de récupérer le setup d’installation pour la plateforme désirée sur le site d’X2go. Dans cet exemple, je vais partir sur un client pour Windows. L’installation est des plus standard : suivant, suivant, suivant…

Une fois l’installation terminée, il faut configurer la session à ouvrir :

Le chemin peut-être laissé par défaut, tandis qu’il est nécessaire de saisir le serveur, l’identifiant de connexion, et le mot de passe associé. Le type de session indique l’environnement graphique que l’on va ouvrir : dans mon cas, j’ai choisi MATE mais de nombreux autres environnements sont disponibles : KDE, GNOME, XFCE… Dans les autres onglets sont disposés plusieurs autres paramètres : la vitesse de connexion, le partage réseau de dossiers, la gestion du copier-coller, l’écoute du périphérique audio de la machine serveur, etc. Une fois tous les paramètres saisis, il est possible de se connecter ; il faudra accepter le hash de la clef SSH du serveur, et si vous êtes sous Windows en fonction de vos GPO ou de vos réglages, autoriser l’application à communiquer à travers le pare-feu.

Et voilà ! Une simple exécution du client, un double-clic sur la connexion et je peux accéder à ma machine de la même manière que j’ouvrirais une session RDP sur une machine Windows.

Installation de TeamViewer 12 sur Debian Jessie

Je voulais installer TeamViewer sur une machine Linux afin de prendre en main à distance ma machine chez moi.

Cependant, sur ma machine virtuelle qui est installée sous Debian Jessie avec un environnement graphique MATE, le paquet que l’on peut obtenir via le site de TeamViewer ne peut s’installer. En effet, le paquet est conçu pour une architecture i386 et mon Debian est une amd64.

Afin que le paquet puisse s’installer correctement, quelques petites commandes dans le terminal ainsi que l’installation de gdebi pour une meilleure gestion des dépendances du paquet sont nécessaires.

En su, ou alors en précédant les commandes de sudo, on va ajouter à dpkg l’installation de paquets en i386, puis installer gdebi qui pourra installer le paquet teamviewer et toutes les dépendances, car il y en a un paquet (vous aurez noté le jeu de mots…)

dpkg –add-architecture i386
apt-get install gdebi
gdebi teamviewer_12.0.71510_i386.deb

Et normalement, le paquet est installé. Si il y a des dépendances que ne peut résoudre gdebi, ce qui ne devrait pas arriver, il est possible de corriger cela avec la commande suivante :

apt-get install -f

Les dépendances seront corrigées et le paquet teamviewer installé. Il est désormais disponible au lancement.

Plus de réseau sur Debian Jessie

Alors que je souhaitais faire un petit tour de passe-passe sur mes machines GNU/Linux afin d’y faire les mises à jour des paquets, j’ai été surpris de ne pouvoir me connecter en SSH à l’une de mes machines.

Je tente alors de la joindre par un ping, et pas de réponse. Les requêtes ICMP atterrissant bien à la normale sur le serveur, j’ai pensé à un crash sévère de la machine ou de l’interface réseau. Je lance alors la console VMware et arrive sur le prompt du login sans soucis.

Une fois connecté, un petit ifconfig me renvoie les informations suivantes :

Je comprends pourquoi ma machine est injoignable : pas d’IP affectée, pas même une IPv6. Normalement, tout est géré par DHCP, les serveurs Linux ayant un bail permanent (les machines Windows en IP fixe afin de pouvoir avoir en DNS primaire le serveur ActiveDirectory et en secondaire l’appliance pfSense, bien qu’ils aient en secours un bail DHCP fixe aussi).

Naturellement, un ping de mon appliance pfSense ainsi que du DNS Windows ne renvoient rien. Par ailleurs, je voulais tenter un ifdown eth0 et un ifup eth0, sans succès vu que l’interface eth0 ne semble pas être configurée tout court.

Tout d’un coup, mon cerveau fait tilt, et je me souviens avoir déconnecté tous les lecteurs optiques des VM une fois les installations des OS terminées. Or, sur le client web ESXi, la case de déconnexion du lecteur optique est juste en dessous… de la case de déconnexion de la carte réseau.

Une fois la carte réseau connectée suite à cette fausse manipulation, un petit redémarrage du serveur (bien que je pense qu’un simple redémarrage du service networking aurait suffit) et la connectivité réseau est revenue !

Mise en place d’OpenFire sur Debian Jessie

Depuis quelques temps, je cherchais une solution de chat permettant de m’affranchir de Facebook et des autres plateformes comme WhatsApp ou Skype, afin de pouvoir satisfaire ma curiosité à ce sujet et essayer de convertir une partie de mes proches sur un outil de chat peut-être moins fringuant mais plus privé et personnel.

Après quelques recherches, je me suis donc orienté vers OpenFire qui est un serveur utilisant le protocole XMPP, qui fonctionne sous Windows, GNU/Linux et OS X. Dans mon cas précis, je vais réaliser l’installation de ce serveur sur un système d’exploitation Debian dans sa version Jessie (8.7).

1. Prérequis

 

Une fois l’OS de base installé, j’ajoute toujours par habitude fail2ban et proftpd, afin de pouvoir protéger le serveur par la suite et proftpd afin de faciliter le dépôt de fichiers sur la machine depuis mon filer. Ma machine étant hébergée sur un ESXi, j’installe les VMware tools.

apt-get install fail2ban
apt-get install proftpd
apt-get install open-vm-tools

A noter que par la suite, j’ajouterai certaines règles à fail2ban afin qu’il surveille les tentatives d’authentification sur le serveur OpenFire lui-même.

Dans un même souci de sécurité, je vais désactiver la connexion en root sur le serveur via SSH :

nano /etc/ssh/sshd_config

Je modifie de cette manière la ligne suivante (ancienne valeur en rouge, nouvelle valeur en vert) :

PermitRootLogin without-password
PermitRootLogin no

 Puis, un redémarrage du serveur SSH pour prendre en compte la modification :

/etc/init.d/ssh restart

Plus tard, lors de la configuration, je vais choisir l’authentification par ActiveDirectory. J’ai donc créé dans mon AD un groupe « OpenFire Users » avec le compte utilisateur dont je vais me servir afin de pouvoir me connecter à l’application. Pour des raisons de sécurité, je ne vais pas utiliser le même compte que mon compte usuel sur ma plateforme Windows mais un utilisateur tout simple. Je vais également créer un compte de service qui permettra à l’application d’avoir un accès en lecture seule uniquement à l’AD, afin de ne pas avoir à renseigner le compte d’administrateur du domaine ou mon compte d’administration personnel. Pour ce faire, je vais passer par une délégation de contrôle.

Clic droit sur le domaine « domaine.local » puis Délégation de contrôle

En choisissant le compte de service en question sur le domaine, je vais créer une tâche personnalisée à déléguer, sur ce dossier et les objets qui s’y trouvent. Enfin, je vais accorder les autorisations en lecture, en cochant Lire et Lire toutes les propriétés. Si tout s’est bien passé, le compte de service pourra lire le contenu du domaine.

2. Installation

 

Le paquet pour Debian fourni par l’éditeur d’OpenFire ne contient pas l’environnement Java nécessaire. Il faut donc l’installer préalablement. Etant donné que mon système est tout juste installé, je n’ai pas pris la peine de réaliser un apt-get update avant de lancer la commande suivante :

apt-get install default-jre

apt va installer la JRE présente dans les dépôts de Debian. La version requise par l’application est la version 1.7. Un simple java -version permet de renvoyer la version installée :

Une fois dans le répertoire dans lequel j’ai calé le paquet, un petit dpkg -i et l’installation se déroule. J’obtiens une notification comme quoi le répertoire créé pour l’utilisateur ne lui appartient pas : j’affecte un password à l’utilisateur et le rend propriétaire de son répertoire.

3. Configuration

 

L’installation étant terminée, j’ouvre donc un navigateur afin d’accéder à l’installateur web, qui va s’occuper de la création de la configuration de base ainsi que de la base de données. J’ai laissé les paramètres par défaut (encryption Blowfish, et les ports de la console d’administration, qui de toutes façons ne seront pas routés vers l’extérieur). 

Concernant la base de données, si je voulais utiliser mon serveur MySQL, vu le peu de criticité et de besoin pour l’instant, je me suis retourné vers une base de données embarquée. Si selon l’éditeur les performances sont en retrait, cela m’importe peu dans le cadre de mon utilisation personnelle. Je verrai éventuellement pour déporter la partie base vers mon serveur MySQL si l’envie m’en prend.

Vient ensuite la partie authentification. Je vais me baser sur mon domaine ActiveDirectory. La connexion se passe sans accrocs grâce aux autorisations que nous avons accordées durant les prérequis. Les DN (distinguishedName) se déduisent facilement ou peuvent être trouvées grâce à ADSI Edit.

Je laisse par défaut les configurations de mapping utilisateur et groupes, puis je spécifie temporairement mon compte comme administrateur de l’application. Je créerai un compte d’administration de l’application plus tard.

 

4. Administration

 

En me connectant avec le login déclaré comme administrateur de l’application, je peux parcourir les différents réglages de l’application. Les délégations permettent à l’application de bien parcourir le domaine, cependant l’application ne gère pas l’écriture dans un annuaire LDAP, par conséquent, la création d’utilisateurs, la modification de mot de passe ou autres opérations ne sont pas possibles ; il faudra se connecter sur une console ActiveDirectory pour procéder à une quelconque manipulations sur les comptes.

La première chose que je vais réaliser est un blocage des comptes d’utilisateurs qui ne sont pas dans le groupe « OpenFire Users » que j’ai créé au départ. Ainsi, des utilisateurs peuvent se connecter à l’application sans avoir forcément de comptes sur mes machines, ou un accès à une machine ne donne pas forcément d’accès à l’application.

L’option est des plus explicites. Dans la liste des utilisateurs visibles, on y retrouve un icône en plus d’avoir son nom barré pour signifier que cet utilisateur n’aura pas d’accès à l’application.

Ensuite, étant donné que je suis situé derrière un pare-feu et que j’utilise le NAT pour n’utiliser qu’une seule IP pour toutes mes machines virtuelles, je vais devoir faire quelques opérations de routage sur mon appliance pfSense (que j’aurai l’occasion d’aborder dans un futur billet). Dans l’interface d’administration, chaque port est plutôt bien détaillé.

Je vais changer les ports qui ont été inscrits par défaut, et en profiter pour forcer des connexions sécurisées afin que les données ne transitent pas en clair sur le réseau. En fonction de mes besoins au départ, il y a des connexions que je ne vais pas autoriser. Quelques paramètres de sécurité méritent également le détour (qui peut se connecter, plages IP autorisées, inscriptions en ligne…).

5. Tests de connectivité cliente

 

Maintenant que tout est configuré côté serveur – même si il y a sans doute de quoi peaufiner – il ne reste plus qu’à faire un essai en local, et un essai depuis le web.
Je réaliserai l’essai en local depuis une machine virtuelle Debian. Le client qui se connecte à OpenFire s’appelle Spark et il est édité par la même communauté. Tout comme le serveur, le client est disponible sur Windows, OS X et GNU/Linux. Et tout comme le serveur, le paquet pour Debian est livré sans Java, il faudra donc l’installer à part. Java étant déjà installé sur ma machine, je suis donc parti pour un dpkg -i du paquet spark, cependant, je me suis heurté à un mur :

 

J’ajoute dans ma liste de dépôts les dépôts jessie-backports sans oublier de les rafraîchir juste après :

deb http://ftp.fr.debian.net/debian jessie-backports main

Puis, je lance un aptitude install -s afin de simuler une installation du paquet et de voir exactement ce qui merde. En cause, des dépendances non satisfaites à cause de la différence de version entre les paquets dans la branche usuelle et la branche backports de Jessie.

aptitude install -s permet de simuler une installation des paquets pour diagnostiquer ce qui ne fonctionne pas correctement.
Je finis par accepter l’installation de ce paquet dans la version la plus récente, disponible dans le dépôt ajouté précédemment.
Le paquet s’installe bien.

Enfin, je peux conclure en installant le paquet Java final.

Je peux enfin réaliser mon dpkg -i spark_2_8_3.deb et exécuter l’application.

Vu que je ne possède pas de certificats, je vais cocher les deux options pour accepter tous les certificats et pour ne pas vérifier le nom du serveur afin de pouvoir me connecter. Je saisis ensuite mes identifiants… Et ça marche !

Il ne me reste plus qu’à réaliser un test de connexion depuis l’extérieur, ajouter les quelques règles fail2ban si nécessaires… et demander à mes proches d’installer cette petite appli pour discuter en tout temps. Le serveur étant plus orienté utilisation professionnelle que personnelle, il n’y a pas d’application tout du moins sur iOS.