Étiquette : SSH

Pas de commentaire

Utilisation de rClone avec Amazon Drive

  de

Mise à jour du 18 mai 2017 : à partir de ce jour, Amazon Cloud Drive a décidé de bannir rClone des applications autorisées à se connecter à l’API, ce qui signifie qu’il n’est plus possible à ce jour d’utiliser rClone pour se connecter et accéder aux fichiers stockés sur un compte Amazon Cloud Drive. J’ai rédigé un billet concernant le dysfonctionnement en date du 19 mai 2017 (cliquez pour y accéder).

J’utilise deux serveurs Plex pour mes séries, films, musiques et autres contenus multimédias, afin que je puisse y accéder depuis tous mes appareils sans perdre la continuité de ceux-ci. Le stockage est déporté sur Amazon Cloud Drive et non en local, pour sa capacité « illimitée » (en réalité, elle semble être de 100 To, ce qui laisse tout de même une marge plus qu’énorme). Cependant, afin que Plex puisse voir les fichiers d’Amazon Cloud Drive (abrégé ACD par la suite), il faut une application sur le système – non pas pour synchroniser les fichiers auquel cas le stockage en ligne est inutile – mais pour simuler leur présence afin que Plex puisse les détecter et y accéder si la lecture est demandée.

Jusqu’à hier, j’utilisais une application nommée acd_cli. Cependant, depuis hier soir, elle ne semble plus fonctionner, car il semblerait que le quota de requêtes fixé par Amazon a été dépassé. En effet, Amazon applique un quota de requêtes par heure sur l’API en fonction du nombre d’utilisateurs d’une application donnée. Il y a plusieurs workarounds proposés par le développeur d’acd_cli mais j’ai préféré sauter sur l’occasion pour abandonner cette solution temporairement (elle est toujours installée sur le système, mais je ne monte plus ACD avec acd_cli) et passer sur rClone, qui fait exactement la même chose, mais qui peut fonctionner avec bien plus de fournisseurs de stockage en ligne.

Je vais partir du principe que vous possédez déjà un système GNU/Linux Debian prêt à l’utilisation et que vous avez obtenu une élévations de droits, avec su ou en précédant les instructions de sudo. J’ai procédé à l’installation sur un serveur équipé de 4 vCPU, 4 Go de mémoire vive et avec un disque dur de 60 Go.

1. Prérequis

Tout d’abord, mettre à jour le système, puis installer FUSE ainsi que screen – si vous ne connaissez pas screen, il s’agit d’un outil permettant de simuler un terminal pour une application – puisqu’il nous sera utile lorsqu’on aura monté ACD avec rClone. rClone étant compressé au format zip, unzip sera nécessaire.

apt-get update && apt-get dist-upgrade
apt-get install fuse screen unzip

2. Téléchargement et installation de rClone

Le lien de la version peut évoluer avec le temps, mais un autre lien existe pour référence dans un script par exemple, il est possible d’utiliser l’un des deux liens, au choix (à noter qu’il est également possible d’installer rClone via git) :

wget https://downloads.rclone.org/rclone-v1.36-linux-amd64.zip

ou

wget https://downloads.rclone.org/rclone-current-linux-amd64.zip

Une fois que le fichier est récupéré, on va le décompresser (bien sûr, adapter le nom du fichier à la version récupérée, ou à current si vous avez pris le deuxième lien) :

unzip rclone-v1.36-linux-amd64.zip

On va se placer dans le répertoire extrait, puis copier le contenu vers /usr/sbin/rclone afin de pouvoir commencer à configurer l’application et à l’exécuter :

cd rclone-v1.36-linux-amd64
cp rclone /usr/sbin

L’installation est terminée, il faut désormais configurer l’application.

3. Configuration de rClone

On peut lancer l’assistant de configuration en saisissant :

rclone config

Si cela ne marche pas (ce qui m’est arrivé avec un autre utilisateur que root…), il faut simplement rajouter /usr/sbin devant rclone :

/usr/sbin/rclone config

L’assistant apparaît, et c’est là qu’on va déclarer notre compte ACD. On créé donc un nouveau « remote ». Plusieurs paramètres vont être à saisir, il faut être vigilant lors de cette partie sous peine d’avoir à reconfigurer le compte :

  • Le nom : dans cet exemple, je l’ai appelé amazondrive. Ce nom sera utilisé dans l’instruction permettant de monter ACD.
  • Le type de compte à monter : plusieurs choix sont disponibles, mais le « 1 » est Amazon Cloud Drive, il faut donc saisir 1.
  • Les Amazon Application Client ID et Client Secret sont utiles si vous êtes développeur Amazon et que vous utilisez votre propre application. Etant donné que rClone n’est pas votre propre application, les champs sont à laisser vides.
  • On refuse la configuration automatique : en effet, on a besoin d’une clé d’authentification qui permet de lier rClone à ACD : clé qu’on récupère lorsqu’on s’identifie sur ACD et qu’on autorise rClone à lire et écrire sur ACD, lors de l’étape suivante.
L’étape qui consiste à récupérer la clé d’authentification peut être un peu plus chiante si vous n’avez pas d’environnement graphique sur le serveur sur lequel vous installez rClone.

Si vous avez un environnement graphique avec un navigateur web : ouvrez un terminal avec le même utilisateur que vous avez utilisé jusqu’ici, puis saisissez : rclone authorize amazon cloud drive.
Si vous n’avez pas d’environnement graphique : répétez la procédure d’installation de rClone sur un système Windows, GNU/Linux ou encore OS X, mais sans la configuration. Saisissez simplement rclone authorize amazon cloud drive.
Dans les deux cas, une fenêtre de navigateur va s’ouvrir, avec un prompt d’identification. On va donc saisir l’identifiant et le mot de passe du compte ACD, et autoriser rClone à accéder à ACD. Une fois que la manipulation est faite, la fenêtre va afficher un « Success » et la clé sera affichée dans le terminal. Il est possible de la copier-coller temporairement dans un fichier texte, mais il faudra surtout la coller une fois que l’assistant de configuration le demande, c’est-à-dire, juste après avoir demandé de saisir « rclone authorize amazon cloud drive ». Il est très important de prendre toute la clé, c’est-à-dire accolades comprises.
Il ne reste plus qu’à confirmer la clé, et la configuration est terminée. rClone peut se connecter à ACD sans problèmes, il ne reste plus qu’à monter ACD.

4. Montage d’ACD

Il est nécessaire d’avoir un répertoire vide dans lequel on va monter ACD. Dans cet exemple, on va lancer rCloud avec l’utilisateur amazon, on va donc monter ACD dans son répertoire personnel :
rclone mount amazondrive: /home/amazon/
Le problème, c’est que rClone occupe le terminal. Ce qui peut être gênant si il n’est pas possible de laisser le terminal SSH ouvert par exemple. C’est pourquoi on va utiliser screen qui va nous permettre de simuler un terminal pour rClone afin qu’on puisse quand même couper la connexion SSH sans pour autant tuer le processus rClone.
On créé le nouveau terminal, que l’on va nommer rcloneacd :
screen -S rcloneacd
Une fois dans ce screen – lorsque l’on a validé la commande précédente – on peut donc saisir de nouveau la commande de montage. Attention, il n’est pas possible sans workaround de créer un screen si vous avez utilisé une élévation de droits ou un changement d’utilisateurs avec su. Il faut donc lancer le screen en tant qu’utilisateur simple et ensuite effectuer une élévation de droits si besoin, dans le screen. Lorsque rClone est lancé et le partage monté, il suffit de presser CTRL+A puis D pour quitter le screen sans le fermer.
Il est possible d’y accéder de nouveau au terminal exécutant rClone en saisissant cette commande :
screen -R rcloneacd

Enfin, pour démonter ACD :

fusermount -u /home/amazon

Normalement, le répertoire /home/amazon/ contient tous les fichiers de votre ACD, mais virtuellement. Cela signifie que grâce à FUSE, votre système voit les fichiers comme si ils étaient présents, et une bonne majorité d’applications sont également bernées. En cas d’accès en lecture ou en écriture, rClone se charge de télécharger les données, et FUSE de les rendre exploitable comme si ils étaient disponibles sur un système de fichiers standard.
Pas de commentaire

Installation d’X2Go sur Debian Jessie

  de

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.

Pas de commentaire

Restriction de l’accès SSH sur ESXi 6.5

  de

Pour des raisons de sécurité, je désactivais toujours l’accès SSH à mon serveur ESXi, laissant donc l’administration via la console web (que je n’aime pas trop par ailleurs) et le vClient.

Seulement, il n’y a pas si longtemps, les services de management ont crashé, rendant impossible la connexion via l’interface web ou le vClient, que ce soit via une machine virtuelle situé sur l’ESX ou bien en distant. Le serveur ne répondait pas non plus aux requêtes PowerCLI. J’ai donc dû demander un KVM sur le serveur afin de pouvoir prendre le shell en direct et relancer les services.

Depuis, je me suis dit qu’avoir quand même la main sur le shell pouvait être une option intéressante si besoin. Par contre, je voulais tout de même garder une certaine sécurité en ne le laissant pas ouvert depuis l’extérieur.

Via le vClient, il est possible de filtrer les connexions au serveur SSH par adresse IP ou blocs d’IP, ce qui dans mon cas m’intéresse puisque je vais lui demander d’autoriser seulement les connexions provenant de l’adresse IP LAN de mes machines virtuelles.

Dans le vClient, onglet Configuration > Profil de Sécurité > Modifier les propriétés du pare-feu puis Serveur SSH

Ensuite, la tentative de connexion depuis mon ordinateur personnel chez moi ne renvoie rien :

Depuis le réseau interne, cela fonctionne bien :

Par contre, par défaut, l’accès est possible en root uniquement. Etant donné que je possède un utilisateur standard afin d’accéder aux consoles et faire de la gestion rapide avec des privilèges limités, je voulais interdire la connexion en SSH avec l’utilisateur root et autoriser mon compte standard en connexion pour ensuite procéder à une élévation des droits avec su – mais cela ne semble plus être possible dans les dernières versions d’ESXi (testé sur 6.0 et 6.5).