SSH on Zwindler's Reflection

OpenSSH : Écouter sur des ports différents en fonction de l’interface

Tue, 19 Jun 2018 11:45:55 +0000

Pour quelle raison je pourrais vouloir écouter mon serveur OpenSSH sur des ports différents en fonction de l’interface ?

Tout simplement, pour éviter de se faire spammer par tous les bots et les scripts kiddies qui polluent l’Internet et vos logs de connexion OpenSSH.

Idéalement il faudrait n’autoriser la connexion que depuis un réseau local ou un VPN comme le propose M4vr0x dans ses tutos pour Proxmox VE.

Mais dans une certaine mesure, bien que ça ne soit pas une mesure de sécurité, on peut s’économiser beaucoup de « bruit de fond » dans les logs de sécurité en changeant simplement le port d’OpenSSH.

L’inconvénient de ce changement, c’est que dans ce cas là, les outils qui reposent sur le port par défaut devront être reconfigurés voire ne marcheront plus comme le clustering de Proxmox, qui demande explicitement une connexion sur le port 22.

2 méthodes

Dans les deux cas, la modification est risquée. Rien de dramatique mais une fausse manipulation et vous pourriez vous couper la patte. Comme je n’en suis pas à mon premier utilisateur du blog mécontent, je préfère le redire ;-)

Méthode 1, configurer OpenSSH

La première méthode, que personnellement je préfère, consiste à configurer OpenSSH pour le faire, car c’est prévu pour !

Voici le bout de configuration qu’il faut modifier, dans le fichier ssh_config (souvent situé dans /etc/ssh)

# /etc/ssh/sshd_config
Port 7022
ListenAddress 0.0.0.0
ListenAddress [@IP_interne]:22

Cette méthode permet de ne pas ouvrir le 22 sur Internet. Seul le 7022 sera accessible et le nombre de connexions par jour sera bien plus limité.

Attention, la prise en compte nécessite un redémarrage. Cependant si vous avez fait une bêtise, il vous reste toujours une chance de vous en sortir => OpenSSH est bien conçu et même un redémarrage ne coupe pas les connexions en cours (comme le ferait Apache ou le redémarrage des cartes réseaux).

Le corollaire de cette information et que, la connexion fonctionnant toujours, vous pourriez penser que tout fonctionne alors que dès que vous fermerez la connexion active, vous ne pourrez plus jamais vous connecter.

Assurez vous donc TOUJOURS de pouvoir ouvrir une nouvelle connexion avant de fermer la précédente (1ère chose que j’ai apprise en SSII).

Méthode 2, IPtables

OK, c’est obvious, cette méthode ne fonctionne que si vous utilisez IPtables sur votre OS (ahahah).

Toute la puissance d’IPtables est qu’il peut servir à un très grand nombre de choses qui vont au delà du simple firewalling, comme la redirection de trafic avec des pré/post traitement.

Ici, on se contente simplement de rediriger le trafic entrant sur le port 7022 depuis l’interface externe vers le 22 en interne. Ensuite, on indique à OpenSSH de n’écouter QUE sur l’interface réseau locale.

# /etc/ssh/sshd_config
Port 22
ListenAddress [@IP_interne_uniquement]

On ajoute la règle et (si ça marche !) on la persiste au démarrage d’IPtables :

/sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 7022 -j DNAT --to [@IP_interne_uniquement]:22
iptables-save > /etc/iptables/rules.v4 #Debian/Ubuntu
#ou
iptables-save > /etc/sysconfig/iptables #RHEL/CentOS

Cependant, si vous avez un souci sur IPtables ou vos règles pour une raison ou pour une autre, vous ne pourrez plus accéder votre serveur.

Or, connaissant la complexité (et la richesse) d’IPtables, il me parait plus simple de faire une erreur sur IPtables que sur la configuration d’OpenSSH.

Mais c’est à vous de voir ;)

Sources

Le site de Fatphil [EN]

Déployer des VM VMware avec Ansible – part 2

Tue, 14 Nov 2017 12:45:27 +0000

Où est ce qu’on en était ?

La dernière fois qu’on a parlé de [machines virtuelles déployées à l’aide d’Ansible sur une infrastructure VMware][1], on avait un playbook fonctionnel, mais il me manquait encore un petit quelque chose.

En fait, à l’issue du déploiement de la VM, je n’avais pas encore trouvé la possibilité d’enchaîner sur l’exécution d’autres playbooks permettant de configurer la VM. L’objectif ultime étant de faire en une seule étape de :

déployer la VM (que j’appellerai « déploiement »)
et de la configurer, c’est à dire modifier les fichiers de configuration de la VM, installer les logiciels, etc… (que j’appellerai « configuration »).

Premier problème, connection:local

Pour rappel, le premier problème quand on veut déployer une VM qui n’existe pas encore… est justement le fait qu’elle n’existe pas encore !

Si j’exécute un playbook deploy_vm.yml sur une VM « ma-vm » tel quel, je vais me prendre un message d’erreur (pour plus de détails, lire l’article précédent) car Ansible tente de se connecter à la machine pour récupérer des informations sur elle.

La méthode pour s’affranchir de ce genre de problèmes est de feinter Ansible en lui disant :

de ne pas récupérer les informations de la machine
d’exécuter le playbook sur une autre machine (le plus simple c’est localhost)

Pour le premier point, la solution est mettre en haut du playbook l’option gather_facts: false. Cela aura un impact mais on verra ça plus loin.

Pour le second point, il existe 2 solutions. La première, que je préconisais dans l’article précédent, consiste à utiliser en haut du playbook l’option connection: local. Cette option permet d’exécuter l’ensemble du playbook sur la machine locale et non pas la machine qu’on déploie.

En réalité, il est en fait plus simple d’utiliser l’option delegate_to, qui se limite à une seule tâche ou à un rôle, ce qui permet de déléguer la partie déploiement à localhost, puis tenter d’exécuter les autres playbooks sur la VM qu’on veut configurer.

Un problème de nom … pas si facile à résoudre

Vous avez vu le jeu de mot ? Ok, je sors…

Bien sûr, on va se heurter à plusieurs problèmes… Le premier est la résolution de nom. A moins d’avoir réalisé la mise à jour de votre DNS à l’avance (à la main du coup… c’est nul), dès que le déploiement sera terminé et qu’on passera à la partie configuration de la VM, Ansible essayera de contacter votre nouveau serveur.

Le plus propre serait d’ajouter à la partie « déploiement » une tâche permettant de mettre à jour le DNS. Dans mon environnement professionnel, le service DNS est géré par un serveur Windows Active Directory. La simple mise à jour du DNS depuis Linux est un vrai casse tête et le plus simple est d’intégrer la machine (qu’elle soit Windows ou Linux) dans le domaine Active Directory qui se charge alors de mettre à jour le DNS lui même.

C’est un gros sujet et je ferai un article à part dessus. Dans un premier temps on peut se contenter de juste mettre à jour le fichier /etc/hosts de la machine localhost.

- name: add to /etc/hosts file
lineinfile:
dest: /etc/hosts
line: '{{ custom_ip }} {{ inventory_hostname }} {{ inventory_hostname }}.zwindler.fr'
with_items: '{{play_hosts}}'
when: "hostvars[item].inventory_hostname == inventory_hostname"
delegate_to: localhost

Accès concurrents

Si vous vous y connaissez un peu en Ansible, vous remarquerez que je ne me suis pas contenté d’un simple lineinfile, mais que j’ai utilisé un with_items et un when.

En fait, on peut utiliser mon playbook pour déployer en parallèle un grand nombre de VMs en même temps. Le souci que j’ai rapidement eu a été un accès concurrent sur le fichier, et des noms de VMs ont alors manqué.

Il existe une fonction « serial » qui permet de désactiver la parallélisation des tâches, mais malheureusement, on ne peut l’appliquer qu’au playbook entier. Peut être qu’un jour la fonctionnalité sera ajoutée (la demande est référencée sur Github)

J’ai donc du passer par une boucle pour enregistrer tous les serveurs du play courant.

Clé SSH

OK, maintenant, on sait résoudre la (ou les) machine(s) qu’on vient d’ajouter. Cependant on est pas sorti de l’auberge !

En partant du principe que vous n’avez pas oublié de déposer la clé SSH du serveur localhost pour qu’Ansible puisse se connecter sur votre nouvelle machine, voilà ce qui va se passer :

TASK [gather facts] *************************************************************************************************************************************************************************
The authenticity of host 'zwindler01 (x.x.x.x)' can't be established.
Are you sure you want to continue connecting (yes/no)? The authenticity of host 'zwindler02 (x.x.x.x)' can't be established.
Are you sure you want to continue connecting (yes/no)? The authenticity of host 'zwindler03 (x.x.x.x)' can't be established.

Ansible bloque à la première connexion SSH vers votre VM nouvellement crée car il faut accepter l’empreinte de chaque VM manuellement au préalable. Même si on essaye de renseigner yes à toutes les questions, ce n’est clairement pas idéal et encore moins automatisé !

La solution temporaire, host_key_checking=False

Il existe un paramètre dans Ansible qui permet de passer outre la vérification de l’empreinte de la machine, soit en modifiant le fichier de configuration ansible.cfg, soit ajouter un flag à l’exécution de playbook, soit configurer une variable d’environnement.

ansible-playbook -l zwindler* -i hosts_deploy -e 'host_key_checking=False' deploy_vmware_guest.yml
#OU
export ANSIBLE_HOST_KEY_CHECKING=False
ansible-playbook -l zwindler* -i hosts_deploy deploy_vmware_guest.yml

Vous trouverez plus d’informations sur cette solution de contournement sur les sites suivants :

Cette solution de contournement est à proscrire en production, car elle va ignorer l’empreinte de TOUTES les machines et pour TOUS vos playbooks. Au delà du problème évident de sécurité que ça pose, si vous enlevez l’option à un moment donné, c’est retour à la case départ. Vous aurez de nouveau la question sur tous les serveurs dont vous n’avez pas explicitement accepté l’empreinte.

ssh-keyscan à la rescousse

On va donc ajouter la tâche suivante à notre playbook de déploiement :

- name: accept new ssh fingerprints
shell: ssh-keyscan {{ custom_ip }},{{inventory_hostname}} >> ~/.ssh/known_hosts
with_items: '{{play_hosts}}'
when: "hostvars[item].inventory_hostname == inventory_hostname"
delegate_to: localhost

Je sais… c’est terrible : la solution que j’ai à l’heure actuelle, bien que fonctionnelle, N’EST PAS IDEMPOTENTE… :-( mais elle fonctionne.

Et on fini par un petit setup pour récupérer les facts.

- name: gather facts
setup:

Et maintenant ?

Et bien ! Maintenant, ça marche ! Vous pouvez enchainer d’autres tâches (ou des rôles) en ne mettant plus delegate_to, et ces tâches de « configuration » seront bien lancées sur le serveur que vous venez de déployer, dans un seul et même playbook.

---
- hosts: all
gather_facts: false
vars_prompt:
- name: "vsphere_password"
prompt: "vSphere Password"
- name: "esxi_host"
promt: "ESXi host"
private: no
- name: "notes"
prompt: "VM notes"
private: no
default: "Deployed with ansible"
roles:
- deploy_vmware_guest
- other_role_for_configuration

Pari réussi !

Et le playbook, il est où ?

Une fois de plus, je suis sympa, je vous donne un exemple de code sur mon Github !

Signez votre console web Proxmox avec Let’s Encrypt, c’est trivial !

Tue, 02 May 2017 12:00:47 +0000

Vraiment, vous aurez votre petit cadenas vert Let’s Encrypt en 2 minutes

Difficile pour un geek d’avoir éviter la vague Let’s Encrypt.

Pendant longtemps, faire signer son site web en HTTPS par une autorité de certification était à la fois couteux et complexe. Le résultat : pendant des années, les sites en HTTPS ont été autosignés et des entreprises se sont fait du gras sur le dos des professionnels qui souhaitaient « faire les choses bien ».

Il y a bien eu quelques initiatives pour essayer de libérer les Internautes de ce système, mais rien qui n’ait vraiment percé… Jusqu’à Let’s Encrypt :

Let’s Encrypt is a free, automated, and open certificate authority brought to you by the non-profit Internet Security Research Group (ISRG).

Cool, on peut maintenant obtenir simplement un certificat reconnu dans tous les navigateurs, et suffisament simplement pour que des gens commencent à automatiser le processus (certbot de l’EFF par exemple) !

Et le moins qu’on puisse dire, c’est que l’effet a été massif. regardez par vous même l’évolution des sites certifiés :

Et Proxmox VE alors ?

Depuis la version 4 de ProxMox, il existe un script qui permet d’ajouter un certificat avec Let’s Encrypt de manière triviale. Vous n’aurez qu’à taper ces quelques commandes dans votre terminal (soit depuis la console web, soit en SSH)

#Renseignez votre email pour être au courant en cas d'échec
EMAIL=admin@example.org
#Installez git
apt-get install git -y
#Copiez le script sur le compte github Neilpang
git clone https://github.com/Neilpang/acme.sh.git acme.sh-master
#Creez un dossier dans le répertoire de configuration de ProxMox
mkdir /etc/pve/.le
#Exécutez le script
cd /root/acme.sh-master
./acme.sh --install --accountconf /etc/pve/.le/account.conf --accountkey /etc/pve/.le/account.key --accountemail "$EMAIL"
#On vérifie que la configuration est bonne dans le fichier de configuration account.conf Généré
cat /etc/pve/.le/account.conf
#On vérifie que la commande suivante renvoie bien le FQDN que l'on souhaite certifier et avec lequel on voudra se connecter (ici, l'adresse sera https://proxmox.example.org)
hostname -f
proxmox.example.org

Pour que ça fonctionne, vous devrez cependant avoir le port 80 ouvert vers votre ProxMox.

A priori c’est une des limitations de Let’s Encrypt encore présente, on ne peut pas être en « full HTTPS ». N’oubliez pas de l’ouvrir pour que le client puisse demander à Let’s Encrypt de se connecter chez vous pour générer le certificat.

Maintenant que tout est prêt, on peut maintenant créer le certificat avec cette commande :

./acme.sh --issue --standalone --keypath /etc/pve/local/pveproxy-ssl.key --fullchainpath /etc/pve/local/pveproxy-ssl.pem --reloadcmd "systemctl restart pveproxy" -d `hostname -f`

A noter : Si la commande hostname -f ne renvoie pas le même FQDN que celui que vous souhaitez certifier, remplacez juste « -d `hostname -f` » par « -d proxmox.example.org » ; mais si vous ne savez pas pourquoi vous faites ça, c’est probablement une mauvaise idée ;-).

TA-DAH

Mais un certificat, ça expire…

Et oui, les certificats ça expire !

C’est notamment une des raisons pour lesquelles les certificats avaient parfois « mauvaise presse » auprès des admins systèmes. Il fallait faire très attention que les certificats soient renouvelés et livrés dans l’application dans les temps, au risque de se retrouver avec une erreur sur le site web pouvant effrayer les utilisateurs.

Ici, si je ne me trompe pas, le certificat Let’s Encrypt expire au bout de 90 jours. Ça parait très court et ça serait très pénible à renouveler à la main. Heureusement, tout est prévu ;-).

En réalité, le script vérifie au lancement si le certificats est sur le point d’expirer ou pas. On peut donc le lancer régulièrement, sans risque ! Le plus simple est bien entendu de l’ajouter en crontab.

crontab -e
45 0 * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" > /dev/null

On peut tester à la main pour voir :

"/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh"
[lundi 20 février 2017, 22:55:29 (UTC+0100)] Renew: 'proxmox.example.org'
[lundi 20 février 2017, 22:55:29 (UTC+0100)] Skip, Next renewal time is: vendredi 21 avril 2017, 21:55:01 (UTC+0000)
[lundi 20 février 2017, 22:55:29 (UTC+0100)] Add '--force' to force to renew.
[lundi 20 février 2017, 22:55:29 (UTC+0100)] Skipped proxmox.example.org

Aller plus loin sur Let’s Encrypt

Quelques articles beaucoup plus poussés sur le sujet, certains peut être un peu outdated mais c’est toujours intéressant :

Réinventons la roue : j’automatise des actions via SSH+mdp avec un script expect

Thu, 11 Aug 2016 17:30:13 +0000

Dans quels cas ne pas utiliser ce script expect

Attention : je met en ligne ce script juste pour information. Cela peut aussi être utile si vous avez un besoin spécifique qui nécessite l’utilisation du binaire expect.

Si vous avez très rapidement besoin de réaliser sur un ensemble de serveur un tâche répétitive via SSH, le mieux est de jeter un œil vers Ansible. Les modules sont nombreux, les possibilités infinies, la facilité du langage déconcertante. Et contrairement aux autres (puppet, chef, salt), c’est sans agent !

Alors pourquoi j’ai pris du temps pour développer un script expect ?

Il y a deux ans, j’ai été chargé de réaliser une petite étude sur Puppet, un gestionnaire de configuration qui permet de définir un standard pour un groupe de machine. Un exemple simple est la gestion du NTP. En prenant le temps d’apprendre, on peut assez facilement définir sous Puppet un template qui stipule que tous les serveurs Linux doivent avoir le démon NTPd installé et opérationnel avec le bon fichier de configuration.

Pour autant, la nécessité de déployer des agents sur des centaines de serveurs et le langage un peu pompeux (pour le néophyte que j’étais) m’avait freiné. Car bien sûr, j’avais besoin TOUT de suite de quelque chose d’opérationnel, je n’avais pas le temps de :

Mettre en production un serveur puppet
Déployer les agents sur les machines
Tester mes templates avant de passer la modification sur tous les serveurs

Une solution simple aurait été de déposer une clé SSH sur tous les serveurs et de réaliser une simple boucle. Dans le même temps, certains de mes collègues étaient en train de travailler sur ce sujet précis. Pour préserver la paix de l’openspace, je ne souhaitais pas leur marcher sur les pieds.

Pour résoudre dans l’immédiat mon problème, j’ai utilisé expect.

« We do not forgive, we do not forget, … »

Pour ceux qui ne connaissent pas l’outil, il s’agit d’un binaire qui permet d’automatiser des tâches en fonction du retour renvoyé par le terminal. Cela peut être utile pour réaliser un ensemble de tâche sur via des outils tels que FTP (ou TFTP pour des switchs dans cet exemple (lien mort, j’utilise Internet Archive)). Et un script bash classique dans lequel vous ne pourrez **pas ** entrer un mot de passe (le prompt du mot de passe nécessite un « vrai » terminal). Expect lui peut le faire.

Deuxième avantage d’expect, il existe un langage de script qui permet d’automatiser relativement facilement vos actions avec des structures conditionnelles de base. J’ai rédigé un script qui m’a permis de copier des fichiers sur un liste de triplet de type hostname;username;password;.

Je l’ai mis à disposition sur Github et voici comment cela fonctionne.

Dans cet exemple je modifie le fichier repository yum sur un (seul) serveur distant et je nettoie le cache de yum.

./expect.us scp serveur_distant root votremotdepasseenclair source/newrepo_el7.1.repo /etc/yum.repos.d/newrepo_el7.1.repo
./expect.us ssh serveur_distant root votremotdepasseenclair "yum clean all"

Et dans cet exemple, le met à jour le fichier resolv.conf sur une liste de serveur avec un csv

#!/bin/bash
for line in `cat expect_dns_no_nm.csv`
do
hostname=`echo $line | cut -d";" -f1`
username=`echo $line | cut -d";" -f2`
password=`echo $line | cut -d";" -f3`
./expect.us ssh $hostname $username $password "cp /etc/resolv.conf /etc/resolv.conf.20151103"
./expect.us scp $hostname $username $password source/resolv.conf /etc/resolv.conf
done

Le mot de la fin

Entre le moment où j’ai écris le script et aujourd’hui où j’écris cet article (oui j’ai toujours du retard), j’ai découvert Ansible. Quand j’écrivais expect.us je savais que je réinventais la roue.

Depuis que j’utilise Ansible mon travail au quotidien a complètement changé.

Dans le cas où vous souhaitez automatiser des tâches et que vous êtes pressés par le temps, allez absolument voir Ansible.

Mise en place de Guacamole 0.9.5 sur CentOS 7

Sun, 31 May 2015 09:49:36 +0000

Pour information : je me suis basé sur le très bon article de Deviant Engineer, qui est concis, s’affranchit de la conf par fichier plat au profit du module MySQL, et surtout qui fonctionne, ce qui n’est pas le cas de tous les tutoriels que j’ai pu croiser sur la toile.

Aujourd’hui, au même titre que l’informatique s’est généralisée, Internet est de plus en plus présent, où qu’on se trouve. Mais ce n’est pas toujours un Internet comme à la maison.

Pour des raisons de sécurité et/ou de bande passante, certains ports/protocoles/site web sont souvent bloqués sur les points d’accès public ou d’entreprise. Il n’est pas rare que seul l’HTTP et l’HTTPS soient disponible, me privant ainsi de mes accès SSH/VPN/FTP/…
C’est un vrai casse tête pour moi : je déploie des services chez moi et j’en deviens dépendant au point d’être agacé de ne pas y avoir accès en toutes circonstances. Et plutôt que de relativiser cet absence d’accès absolu à mes services/données, je préfère chercher des moyens de contournement ;).

Si l’autohébergement d’applications web et l’utilisation d’un reverse proxy (Vulture/Apache) répond à une partie de cette problématique, des fois, j’ai parfois besoin d’avoir accès aux machines qui hébergent ces services. C’est pourquoi j’utilisais jusqu’à présent Ajaxterm, puis Gateone pour disposer d’un accès SSH à mes serveurs en cas de filtrage.

Cependant, j’ai aussi besoin de me connecter en mode graphique sur mes serveurs. En présentant au travers d’une interface HTML5 des clients pour les protocoles SSH, VNC et RDP, Guacamole répond à ce besoin.

Quelques ressources pour bien commencer :

La documentation officielle décrit comment l’installer à partir des sources. Cependant, sur certains systèmes, les applications ont été packagées et sont disponibles (0.8.4 si je ne m’abuse sur RHEL et CentOS). Je voulais avoir la version la plus récente, je me suis donc penché sur la solution « compilation ».

Et pour avoir une compatibilité maximale en terme de fonctionnalités, il faut disposer de Tomcat 7, présent nativement dans RHEL7/CentOS7, que j’ai donc installé (mon premier CentOS7, youhou !)

Prérequis

Forcément, la première chose à faire lorsqu’on installe une application web un peu exotique sur un CentOS, c’est d’installer les dépôts additionnels pour les dépendances (ici EPEL).

rpm -Uvh http://mirror.metrocast.net/fedora/epel/7/x86_64/e/epel-release-7-5.noarch.rpm # EPEL Repo
yum -y install wget
wget http://download.opensuse.org/repositories/home:/felfert/Fedora_19/home:felfert.repo && mv home\:felfert.repo /etc/yum.repos.d/ # Felfert Repo
yum -y install tomcat libvncserver freerdp libvorbis libguac libguac-client-vnc libguac-client-rdp libguac-client-ssh
yum -y install cairo-devel pango-devel libvorbis-devel openssl-devel gcc pulseaudio-libs-devel libvncserver-devel \
freerdp-devel uuid-devel libssh2-devel libtelnet libtelnet-devel tomcat-webapps tomcat-admin-webapps java-1.7.0-openjdk.x86_64

Installation du composant « serveur »

Le logiciel est découpé en deux parties. Une partie « serveur » qui correspond au portail web, et une partie dite « cliente », qui se charge de la connexion aux différents serveurs SSH/~~telnet~~/VNC/RDP que vous aurez configurés. J’ai rayé telnet car je refuse d’utiliser ce protocole (à l’exception de certaines contraintes de travail très particulières).

cd /distrib
wget http://sourceforge.net/projects/guacamole/files/current/source/guacamole-server-0.9.5.tar.gz
tar -xzf guacamole-server-0.9.5.tar.gz && cd guac*0.9.5
./configure --with-init-dir=/etc/init.d
make
make install
ldconfig

Installation du du composant « client »

La partie client peut directement être récupérée tel quel sur le site du projet.

mkdir -p /var/lib/guacamole && cd /var/lib/guacamole/
wget http://sourceforge.net/projects/guacamole/files/current/binary/guacamole-0.9.5.war -O guac.war
ln -s /var/lib/guacamole/guac.war /var/lib/tomcat/webapps/
rm -rf /usr/lib64/freerdp/guacdr.so
ln -s /usr/local/lib/freerdp/guacdr.so /usr/lib64/freerdp/

MariaDB (MySQL)

Ne soyez pas surpris de découvrir MariaDB. MariaDB, c’est MySQL. Ou plutôt ce que MySQL aurait du devenir. Il s’agit d’un fork de MySQL initié par son créateur qui a réalisé qu’Oracle (qui a racheté Sun Microsystems en 2009) risquait d’envoyer le produit dans le mur (en concurrence avec Oracle Database).
MariaDB a donc progressivement remplacé MySQL dans les communautés Open Source et les entreprises (citons Google en 2013), et RedHat a suivi le mouvement avec la version 7 de RHEL.
Pas de mauvaise surprise si vous êtes habitués à MySQL : tout est identique en terme d’administration. Vos scripts fonctionneront toujours, les binaires n’ont pas changés.

Installation de la base de données

yum -y install mariadb mariadb-server
cd /distrib
wget http://sourceforge.net/projects/guacamole/files/current/extensions/guacamole-auth-mysql-0.9.5.tar.gz
tar -zxf guacamole-auth-mysql-0.9.5.tar.gz
wget http://dev.mysql.com/get/Downloads/Connector/j/mysql-connector-java-5.1.32.tar.gz
tar -zxf mysql-connector-java-5.1.32.tar.gz
mv mysql-connector-java-5.1.32/mysql-connector-java-5.1.32-bin.jar guacamole-auth-mysql-0.9.5/lib/
mkdir /var/lib/guacamole/classpath/
cp /distrib/guacamole-auth-mysql-0.9.5/lib/* /var/lib/guacamole/classpath/
systemctl restart mariadb.service

Configuration de la base de données

mysqladmin -u root password MySQLRootPass
mysql -u root -p # Enter above password
create database guacdb;
create user 'guacuser'@'localhost' identified by 'guacDBpass';
grant select,insert,update,delete on guacdb.* to 'guacuser'@'localhost';
flush privileges;
quit

Création du schéma pour Guacd

cd /distrib/sqlauth/guacamole-auth-mysql-0.9.5/schema/
cat ./*.sql | mysql -u root -p guacdb # Enter SQL root password set above

Configuration, création du fichier « .properties »

mkdir -p /etc/guacamole/ && vi /etc/guacamole/guacamole.properties
# Hostname and port of gucamole proxy
guacd-hostname: localhost
guacd-port: 4822
# Location to read extra .jar's from
lib-directory: /var/lib/guacamole/classpath/
# Authentication provider class
auth-provider: net.sourceforge.guacamole.net.auth.mysql.MySQLAuthenticationProvider
# MySQL properties
mysql-hostname: localhost
mysql-port: 3306
mysql-database: guacdb
mysql-username: guacuser
mysql-password: guacDBpass
# Additional settings
mysql-disallow-duplicate-connections: false

Post-installation

Ne pas oublier de nettoyer les répertoires contenant les sources (dans /distrib chez moi), ajouter un lien symbolique vers le fichier de configuration et ajouter le démarrage automatique des services

mkdir -p /usr/share/tomcat/.guacamole
ln -s /etc/guacamole/guacamole.properties /usr/share/tomcat/.guacamole/
systemctl enable tomcat.service && systemctl enable mariadb.service && chkconfig guacd on

Le serveur devrait être accessible à l’adresse http://@IP_serveur:8080/gucamole**/**. A partir de là, vous pouvez configurer vos serveurs SSH/RDP/VNC, créer des utilisateurs et vous connecter.

Deux derniers points :

les logs ne sont pas toujours très locaces. Chez moi, il se trouvent dans /var/log/messages et /var/log/tomcat/
il manque selon moi un menu pour gérer les connexions actives. Typiquement, dans le cas de VNC, le soft m’indique que j’ai 4 ou 5 sessions ouvertes. Elles n’ont pas l’air concurrentes (je n’en ai qu’une réellement active), mais me parait potentiellement même problématique

ESXi – Problèmes de configuration : SSH a été activé. Non désolé, vraiment pour moi ce n’est pas un problème

Mon, 27 Oct 2014 10:38:11 +0000

Vous l’avez peut être remarqué, depuis la version 5 de VMware, lorsque vous activez le SSH ou le Shell ESXi (anciennement réservé à la maintenance sur la version 3.5/4.0, voir </2010/04/28/esxi-4-0-explorons-lhidden-console-part-1/>) le client desktop ainsi que le client Web vous informe d’une erreur dans votre configuration.

Soyons clairs, si vous le faites, c’est généralement que vous savez pourquoi vous l’avez fait (A vos risques et périls, bien entendu). Vous n’avez pas envie que le client vous le rabâche, au risque de passer à côté d’un d’autre warning autrement plus grave (RAM, CPU, que sais je encore).

Pour le désactiver, la façon qui me parait la plus simple est d’aller modifier la variable prévue pour, en SSH justement ;-)

Connectez vous en root et exécutez la ligne suivante :

vim-cmd hostsvc/advopt/update UserVars.SuppressShellWarning long 1

Pour peu que vous soyez pris de remords par la suite et que vous vouliez les remettre, rien de plus simple

vim-cmd hostsvc/advopt/update UserVars.SuppressShellWarning long 0

A noter, il est également possible d’éditer ce paramètre directement depuis les propriétés avancées (vous savez, ce menu là, où personne ne touche jamais rien ? ) dans le client Desktop ou le client Web

Plus d’infos sur le KB officiel (lien mort, j’utilise Internet Archive)

ESXi 4.0 : Explorons l’Hidden Console Part 3

Fri, 10 Sep 2010 08:11:49 +0000

Il y a un moment, j’avais promis une dernière partie sur l’hidden console, qui n’est jamais venue parce que j’ai zappé. Du coup maintenant ce n’est plus très frais dans mon esprit. Je vais quand même faire un effort pour me souvenir de l’essentiel dans cette partie où j’aborderai surtout la création d’utilisateurs supplémentaires (plutôt que de n’avoir que root).

Enfin, j’essayerai d’écrire un dernier article qui parlera de l’application de patchs à l’aide des bundles, le tout en local (ou via SSH).
Quelques autres infos que je ne sais pas vraiment où mettre : depuis la 4.1, il est possible d’activer depuis le menu gris/jaune l’hidden console, qui n’est plus vraiment cachée, du coup. Cette « toute nouvelle fonctionnalité » s’appelle le Tech Support Mode, et vous permet de faire … la même chose qu’avant! En gros, accès en direct à la console, mais aussi support d’accès à distance via SSH. Ça évite la petite gymnastique VIesque, ce qui peut rassurer certains.
Mais revenons à nos moutons virtuels…

Accéder en SSH sur votre ESXi, c’est bien, mais si vous êtes obligés de le faire en temps qu’utilisateur root à chaque fois, des considérations quant à la sécurité relative de la chose vont peut être vous faire tiquer, et vous aurez bien raison. Du coup, la première idée qui vous vient à l’esprit est « je n’ai qu’à créer un nouvel utilisteur », et vous aurez la encore totalement raison. Ca ne sera peut être pas forcément très sécurisé, mais c’est toujours mieux que de devoir passer votre mot de passe root à chaque fois.

Dans un vieux tuto du net, j’ai lu qu’il n’était pas possible d’avoir un autre utilisateur que root pour faire du SSH avec ESXi. Ce n’est pas tout à fait vrai…

Déjà, il faut savoir qu’il est possible de créer des utilisateurs directement depuis le client vSphere. Ok, cela demande un petit effort car dans la version 4.0 U1 (celle dont je dispose, mais c’est probablement pareil depuis au moins VMware Infrastructure) du client, l’opération fonctionne très bien. Ce genre d’utilisateurs peuvent être utilisés pour donner accès à une machine spécifique à un utilisateur, ou bien, comme dans l’exemple qui va suivre, créer un compte possédant des droit read-only pour servir de compte de monitoring dans Nagios (avec check_esx3, par exemple).

Dans la console vSphere, cliquer sur votre serveur, sélectionnez l’onglet groupes et utilisateurs. Dans la partie utilisateurs, faites un clic droit, puis ajouter. Une fenêtre apparait, entre toutes les informations nécessaires, c’est à dire au moins un login, un password, et ajoutez le au groupe user.

Une fois créé, il est possible d’accorder des permission dans l’onglet permissions du serveur. Clic droit dans le tableau qui s’affiche, ajouter permission, une fenêtre s’ouvre. Dans cette fenêtre, il faut ajouter un utilisateur, puis lui appliquer le privilège qui convient. Dans l’exemple, je lui attribue Read-only. Validez, et hop, c’est fait, nous disposons d’un utilisateur non privilégié qui nous servira pour nos sondes nagios.

Mais si on essaye de se connecter, effectivement, on se rend compte que cet utilisateur read_only_guy n’a pas accès à SSH. Pourquoi? Tout simplement parce qu’il n’a pas accès à la console tout court. Pour des raisons de sécurité, les utilisateurs créés dans le client vSphere ne peuvent pas se loguer sur la console. Ça parait logique : un utilisateur à qui vous avez donné les droits sur une VM n’a aucune raison d’aller se balader sur votre serveur (encore moins quand on est dans la pensée VMware qui est que seuls les techniciens VMware ont le droit d’utiliser la console)…

« Comment fonctionne cette limitation? ». Vous allez rire, mais c’est tout simplement que le shell utilisé lors de la connexion de l’utilisateur est un programme qui refuse tout accès.

Sous Unix, quand on veux créer un utilisateur pour un service (apache par exemple) mais qu’on ne veux pas que quelqu’un utilise se compte pour se connecter. Au lieu d’attribuer un shell /bin/sh (ou /bin/ash dans ESXi 4) au compte, on lui attribue /bin/false, qui renvoie toujours « faux ». Plus récemment, pour être plus explicite, on spécifie que le compte se connecte avec un shell /sbin/nologin, même si c’est strictement la même chose.

Pour pouvoir disposer d’un compte SSH non-root sur votre ESXi, vous avez donc deux solutions :

Soit vous créez un compte ssh_guy depuis vSphere, et vous allez vous connecter en root, le temps d’éditer le fichier /etc/passwd pour remplacer**/bin/false** par /bin/ash dans la ligne correspondant à votre utilisateur. Enfin, il faut impérativement lui créer un dossier home, sans quoi il pourra se loguer mais aucun prompt n’apparaitra.

# mkdir /home
# mkdir /home/ssh_guy

Soit vous créez directement le compte avec le shell qui vous convient depuis votre accès root, de la façon suivante :

# mkdir /home
# useradd ssh_guy-s /bin/ash
# passwd ssh_guy
[entrer le mot de passe pour ssh_guy]

Dans un soucis de sécurisation de la connexion SSH, vous pouvez donc imaginer un scénario où le login root pour SSH est interdit, et de passer par un utilisateur ssh_guy qui passe root si nécessaire grâce à su - , ce qui évite de devoir faire circuler le mot de passe root partout sur le réseau.

Pour interdire le login root via SSH, il suffit de modifier votre inetd.conf en ajoutant un -w à la fin de la ligne correspondant à l’accès SSH. Moyennant un redémarrage du démon inetd, il ne devrait plus être possible de se loguer directement root via SSH sur votre ESXi.

ESXi 4.0 : Explorons l’Hidden Console Part 2

Fri, 30 Apr 2010 13:49:03 +0000

Dans la partie 1, j’introduisais la console cachée de l’ESXi (aussi bien valable pour la version 3.5 que la version 4.0) et vous donnais LA tips hyper répandue pour y accéder. Allons voir un peu plus loin.

La console de l’ESXi ressemble beaucoup à un environnement en ligne de commande du même type qu’un système Unix. Et pour cause! Il s’agit en fait d’une version simplifiée appelée Busybox. La plupart des commandes Unix incontournables et l’arborescence typiques sont donc de la partie:

ls : lister le contenu du dossier courant
cd [destination]: changer de répertoire courant
cp [destination] : copier des fichiers
mv [destination] : déplacer des fichiers
cat [fichier] : afficher à l'écran le contenu d'un fichier, mais aussi utilisé pour écrire dans des fichier en redirigeant les flux vers les entrées/sorties standards
more [fichier] : afficher à l'écran le contenu d'un fichier
vi : l'Editeur de texte (avec un grand E)
ps : lister les processus
grep : recherches dans un texte
kill : envoyer des signaux aux processus, notamment pour les arrêter de façon peu orthodoxe (hin hin hin!)
/ la racine
/etc pour l'aspect configuration du système et des démons/programmes
dev pour accéder aux périphériques, dont les partitions du disque
...

J’en passe… A ces classiques s’ajoutent les commandes spécifiques à VMWare, qui permettent la configuration de l’ESXi telle que nous la connaissons :

esxtop : l'équivalent de top sous Unix pour voir la charge prise du serveur
esxcfg-* : liste de commandes pour modifier des paramètres de l'ESXi. Ces commandes sont les équivalents des commandes vicfg-* utilisée par le vCli. Je citerai notamment *esxcfg-swscsi* qui permet de gérer l'émulation logicielle du support du scsi par l'ESX(i), qui m'a notamment permit de débugger un ESX qui ne voyait pas des LUN sur le réseau (et mon vCenter était HS).
esxupdate : la commande qui permet de mettre à jour le système ESX(i)
vim-cmd : commande permettant d'accéder à des informations concernant les machines virtuelles, et effectuer certains opérations de bases sur celle ci (du même genre qu'avec la GUI).

Le détail de ces commandes peut se trouver dans le document décrivant l’utilisation du VCLI sous vSphere 4 (lien cassé, j’utilise Internet Archive).

A partir de là, un des trucs funs et simples à faire est l’activation du ssh. Et oui, là encore, VMWare nous mens, car ESXi est tout à fait capable de communiquer en SSH, il suffit de configurer le démon inetd correctement pour qu’il gère ssh (il n’y a pas de sshd dédié).

Ouvrir la configuration du démon inetd à l’aide de vi /etc/inetd.conf (pour les neophytes de vi, accrochez vous, et lisez quelques tutos sur le net, sous peine de vous arracher les cheveux)
Supprimer le # devant la ligne qui commence par « ssh » (le # sert à commenter la ligne)
Entrer ps aux | grep inetd et récupérer le pid ID du processus inetd actif
Entrer kill -HUP [ID]. On tue le processus inetd pour éviter des soucis lors du redémarrage des services
Entrer services.sh restart pour redémarrer les agents de management

Une fois activé, le SSH permet(par exemple) d’effectuer des transferts depuis un client connecté sur le même réseau vers notre ESXi. Par exemple, on peut utiliser un client WinSCP pour se connecter sur le serveur à l’aide du protocole SCP.

Dernier point sur lequel je vais revenir encore et toujours : Le SSH sur l’ESXi n’est pas une fonctionnalité prévue. En conséquence, son utilisation peut provoquer des dysfonctionnements de votre système. Je vous déconseille donc de l’utiliser, sauf si vous n’avez vraiment pas d’autres choix. De plus, d’éminents blogueurs ont l’air de penser que le SSH de notre Busybox n’étant pas vraiment configuré, l’utilisation de celui ci puisse présenter une faille en terme de sécurité. N’y connaissant pas grand chose en sécurité du protocole SSH s’il est mal configuré, je m’en remet à leur expertise et prône le principe de précaution!

Prochaine partie: Mettre à jour l’ESXi depuis l’hidden console, et autres subtilités en vrac sortant de mon REX

HF !