Archives pour l'étiquette SSH

Rebond ssh utilisable avec CsshX sous Mac OSX

Je cherchais un truc simple pour faire un unique rebond ssh sur la machine portail d’une plate-forme et utilisable avec CsshX que j’utilise. Et bien voila j’ai trouvé cela il y à quelque temps, rien de nouveau sous le soleil, merci netcate. Parfois il est nécéssaire de relire les doc des autres pour ce rafraîchir la mémoire.

rebond ssh automatique via netcat

Perso j’ai introduit un méta caractère dans ma règle ssh de mon fichier config pour m’éviter de dupliquer des informations. Le tips cible donc uniquement les serveurs comportant « web » dans leur hostname.

Host <span style="color: #000000; font-weight: bold;">*</span>-web<span style="color: #000000; font-weight: bold;">*</span> User root ProxyCommand <span style="color: #c20cb9; font-weight: bold;">ssh</span> gate <span style="color: #ff0000;">&quot;nc `basename %h ` %p&quot;</span> IdentityFile ~<span style="color: #000000; font-weight: bold;">/</span>.<span style="color: #c20cb9; font-weight: bold;">ssh</span><span style="color: #000000; font-weight: bold;">/</span>karles<span style="color: #000000; font-weight: bold;">@</span>boulot.id-dsa

Du coup pour lancer CsshX et avoir un terminal d’ouvert sur chacun des serveurs d’un pool au travers d’un rebond sur la machine portal c’est des plus simple

CsshX frontal-web1 frontal-web2 frontal-web3 frontal-web4 frontal-web5

Attention, si je ferme brutalement CsshX, les processus nc on tendance à rester sur la machine portail.

Debian et OpenSSL

Faille dans le package OpenSSL de Debian

Le 13 Mai 2008 le projet Debian annonçait que Lucian Bello avait trouvé une faille dans le package OpenSSL qui était distribué depuis la 17 septembre 2006. La bug en question est causé par la suppression des lignes suivante du fichier md_rand.c :


MD_Update(&m,buf,j);
[ .. ]
MD_Update(&m,buf,j); /* purify complains */

Après ma note du 19 mai 2008 Découverte d’une faille de sécurité critique dans OpenSSL de Debian qui comportait beaucoup de référence et de source d’information à consulter. Je vous invite aujourd’hui à lire l’article Debian OpenSSL Predictable PRNG Toys de H D Moor.

Dilbert Ramdom Generator

Aléatoire & Random….ou pas

Comme expliqué dans l’article préconisé avoir retiré ce code à pour effet de limité la génération de valeur aléatoire au seul numéro d’ID du processus générant la clé. Or, sous linux, par defaut, le nombre d’ID est limité a 32768. Ce qui est pour le moins un faible nombre de valeur possible.

Découverte d’une faille de sécurité critique dans OpenSSL de Debian

Une jolie faille dans l’implémentation de openssl sur les systèmes linux de la famille DEBIAN [1] à été découverte et corrigée par une mise à jour le 14 mai 2008 : DSA-1571-1 openssl — predictable random number generator

Dit comme cela c’est pas trop flippant c’est voir même courant.

MAIS !

Cette faille implique que toute les clefs générer depuis le 17 septembre 2009 via openssl, ssh-keygen ou openvpn —keygen sont vulnérable et corruptible. [2]

EN PLUS !

Les clefs de type DSA ou DSS sont compromise / vulnérable car reposant exclusivement sur la génération de nombre aléatoire. DSA-1576-1 openssh — predictable random number generator

Pour comprendre les implications et les mesures à prendre je vous invite à prendre connaissance de cette note du blog Entierement.nu : Branle-bas SSH/SSL

En conclusion :

Mise à jours sur tout les serveurs de la et invalidation ou blocage de toute utilisation de clés potentiellement corrompues. Ceci représente une gros travail tel que décrit sur le wiki DEBIAN SSLkeys.

Ce n’est pas sans impacts (fichiers authorized_keys & know_hosts obsolètes…). Même problème pour les certificats : j’espère que personne n’a mis en place de PKI sous Debian depuis 2006, il va falloir regénérer les certificats…


[1] Ubuntu, Mepis, Linspire, Knoppix, tout ce qui marche en .deb mais pas le reste (RH, Fed, Gentoo etc.)

[2] OpenSSH, OpenVPN, certificat X.509, postfix, exim4, sendmail, imapd, https, sftp etc..

Gerer un groupe de serveur avec cluster ssh

Mais comment mettre à jour l’ensemble des serveurs virtuels xen herbergés sur une même machine physique ? Comment exécuter la même commande, au même instant sur l’ensemble d’une ferme de serveur simplement ? Comment éviter de me logger et delogger de chaque serveur pour lancer la même commande ?

Installation de Cluster ssh

ClusterSSH permet de contrôler plusieurs dizaine d’xterm depuis une interface graphique tres simple sous x windows. Cluster ssh permet ainsi d’intervenir en parallèles sur plusieur terminaux et donc interagir avec de multiple serveur via une connexion ssh.


apt-get install clusterssh

Pour lancer cluster ssh c’est ultra simple


cssh &

Pour ouvrir un par un chaque terninal et lancer une connexion ssh vous cliquez sur Host puis Add Host et vous saisissez le nom du serveur demandé.

Configuration de cluster ssh

Le fichier de configuration est .csshrc à créé dans votre home directory. Ceci pouvant être fastidieux il existe une façon de faire automatisé et rapide.


$ cssh -u > $HOME/.csshrc

Et voila votre propre fichier de configuration de cluster ssh avec les paramètres par défaut qu’il ne vous reste plus qu’a personnaliser.

Cluste ssh utilise par defaut xterm mais il est parfaitement possible de lui faire utiliser un autre terminal. Personnellement j’ai garder xterm et changer les paramètres de présentation de comme ceci :


terminal=/usr/bin/xterm
terminal_allow_send_events=-xrm 'XTerm.VT100.allowSendEvents:true'
terminal_args=-bg black -fg green
terminal_decoration_height=0
terminal_decoration_width=0
terminal_font=6x13
terminal_reserve_bottom=20
terminal_reserve_left=0
terminal_reserve_right=0
terminal_reserve_top=0
terminal_size=100x20
terminal_title_opt=-T

J’ai jouer sur la couleur et la taille du terminal. Mais sur tout j’ai jouer sur le reserve pour éviter tout chevauchement de fenêtre sur mon écran.

Et pour ouvir plus xterm en même temps ?

Oui parce que ouvir un par un les terminaux c’est aussi ce que l’ont souhaite éviter. Et bien c’est toujours aussi simple bien que peu clair dans les page de man. Dans votre fichier .csshrc ajouter un alias ou nom de cluster désignant l’ensemble des machines correspondante comme ceci :


EnsembleServeur1= Toto.domaine.tld Titi.domaine.tld Tutu.domaine.tld Tata.domaine.tld

Toujours dans votre fichier .csshrc indiquer que cette ligne désigne un cluster, un ensemble de machine.


clusters= EnsembleServeur1 EnsembleServeur2

Maintenant vous pouvez lancer cluster ssh en lui passant en paramètre le nom du cluster de machine que vous souhaitez administrer.


cssh EnsembleServeur1

Suite à cela un xterm et une connexion ssh sera ouvert pour chaque machine du cluster.

A suivre par ici

Site du projet Cluster ssh
Le man de Cluster ssh

ssh sous windows

par Jean-Baptiste Marchand (19/11/2001)

Administration distante de systèmes Windows en ligne de commande Première partie : administration avec ssh (OpenSSH/Cygwin et PuTTY)

Introduction

Cette brève (en deux parties) présente deux techniques pour l’administration distante de systèmes Windows utilisant des interfaces en ligne de commande. Elle n’aborde pas les techniques d’administration donnant accès à l’interface graphique de Windows telles que VNC ou Terminal Server.

Les deux techniques présentées diffèrent par la méthode utilisée :

– la connexion à distance via une session ssh est, en quelque sorte, une méthode d’administration locale. Une fois l’administrateur connecté sur la machine, il utilise les outils fonctionnant en local sur la machine. Ceci est l’objet de cette première partie. – l’utilisation des Appels de Procédures à Distance (RPC, Remote Procedure Call en anglais) d’administration de Windows est une vraie méthode d’administration distante qui n’utilise pas les outils locaux de la machine à administrer. Ceci sera l’objet de la seconde partie.

Note : Le terme ‘système Windows’ désigne les systèmes d’exploitation Microsoft récents issus de la famille NT (New Technology) : Windows NT 4.0, Windows 2000 et Windows XP/.NET server.

Administration via SSH

SSH (Secure SHell) est un logiciel de type client-serveur permettant l’administration sécurisée d’un système distant via une interface en ligne de commande. Ce logiciel est devenu un standard de fait pour l’administration des systèmes de type Unix (la version 2 du protocole ssh est en cours de normalisation à l’IETF).

Le principal avantage de ssh comparé à un outil tel que telnet est l’utilisation de mécanismes cryptographiques afin d’assurer la sécurité d’une session distante. ssh permet ainsi de réaliser de l’authentification (serveur vis à vis du client, utilisateur vis à vis du système) et d’assurer la confidentialité de la communication, en utilisant des algorithmes de chiffrements symétriques éprouvés.

Conçu à l’origine pour les systèmes Unix, ssh est aussi disponible sur les systèmes Windows. Différentes mises en oeuvre de ssh sont disponibles, aussi bien côté client que côté serveur, qu’elles soient propriétaires ou libres (voir http://www.freessh.org/windows.html et http://www.openssh.com/windows.html pour une liste complète des logiciels existants).

Nous nous intéressons ici à la seule mise en oeuvre libre de serveur ssh disponible sous Windows : il s’agit du démon sshd du projet OpenSSH (http://www.openssh.com/ , mise en oeuvre de ssh en logiciel libre de loin la plus évoluée et active) fonctionnant avec la couche de compatibilité Unix écrite par Cygnus, Cygwin (http://www.cygwin.com/ ).

Côté client, PuTTY (http://www.chiark.greenend.org.uk/ sgtatham/putty/ ) est le client libre le plus fonctionnel et avancé. Il dispose notamment d’un émulateur de terminal bien fait, ce qui l’avantage par rapport à l’utilisation du client OpenSSH avec Cygwin, qui fonctionne dans le terminal texte particulièrement peu évolué de Windows.

Installation du serveur SSH

Pour l’installation du serveur SSH, il y a une alternative avec deux possibilités : – installer OpenSSH dans le cadre d’un environnement Cygwin – installer OpenSSH dans le cadre d’un environnement Windows

OpenSSH en environnement Cygwin

Pour comprendre cette première possibilité, rappelons que Cygwin est un projet lancé initialement par Cygnus (aujourd’hui RedHat), avec le but de fournir une couche de compatibilité Unix sur les systèmes Windows, afin de faire fonctionner , après une simple recompilation, des programmes écrits pour Unix.

Cette couche de compatibilité permet aujourd’hui de faire tourner de nombreuses applications, dont les nombreux utilitaires shell standards tels que awk, cut, grep, sed ou différents shells comme bash ou zsh.

En pratique, Cygwin se compose d’une DLL (cygwin1.dll), dans laquelle se trouve la couche de compatibilité Unix et d’une arborescence dans un sous-répertoire de la machine Windows, recréant l’arborescence classique d’une machine Linux (/bin, /etc/, /usr, /lib, …).

L’environnement Cygwin dispose d’un programme d’installation permettant de choisir les packages à installer. Ces packages sont classés par catégorie. Pour une installation d’OpenSSH, les packages des catégories suivantes doivent être installés : – Admin : cygrunsrv – Base : tous les packages – Interpreters : gawk

A la fin du programme d’installation, les programmes mkpasswd et mkgroup sont lancés, afin de créer les fichiers /etc/passwd et /etc/group, à partir des comptes du système Windows. Tout compte souhaitant être utilisé pour une connexion ssh doit apparaître dans le fichier /etc/passwd ; le fichier doit donc être récrée avec mkpasswd si un compte est ajouté.

Une fois l’installation de Cygwin terminée, la configuration du serveur se fait dans un shell Cygwin avec la commande ssh-host-config. Ce programme génère les clés du serveur et installe le démon comme service Win32, sous le nom de sshd, via le programme cygrunsrv. Le service est configuré par défaut pour se lancer au démarrage. Cependant, le lancement au démarrage échoue souvent, ce qui oblige à lancer le service à la main, par exemple avec la commmande ‘net start sshd’.

Cygwin recréant un environnement Unix, chaque utilisateur dispose d’un répertoire personnel sous /home. Les unités de disque Windows sont accessibles sous le répertoire virtuel (C : est par exemple sous /cygdrive/c). Une façon simple d’y accéder est de créer un lien symbolique pour chaque unité de disque du système, par exemple /c pointant vers /cygdrive/c.

Par défaut, le shell utilisé est bash, ce qui permet de retrouver un environnement de travail familier pour des administrateurs Unix. La plupart des utilitaires shell fonctionnant avec Cygwin sont disponibles, en plus des commandes standards de Windows. Cette méthode d’installation convient donc le mieux à des administrateurs Unix.

OpenSSH en environnement Windows

L’autre possibilité d’installation d’OpenSSH est de n’installer de l’environnement Cygwin que le strict nécéssaire et de travailler dans un environnement Windows classique, avec l’interpréteur de commandes cmd de Windows.

Cette configuration est plus simple à installer puisqu’elle est disponible sous la forme d’un programme d’installation autonome. Ce programme est disponible à l’adresse http://www.networksimplicity.com/openssh/ . A la fin de l’installation, le programme propose d’éditer le fichier /etc/passwd : il suffit de renseigner la liste des utilisateurs pouvant se connecter en ssh.

Par défaut, le shell lancé est cmd.exe, lancé via le programme switch.exe. L’utilisateur retrouve donc l’environnement Windows familier, identique à celui qu’il pourrait trouver en lançant une fenêtre de commande en mode interactif.

Installation du client SSH

PuTTY est le client SSH libre le plus avancé sous Windows. Il est développé activement et est très complet, avec notamment le support du protocole SSHv2. De plus, le manuel (en anglais), bien qu’encore incomplet, en fait un logiciel bien documenté.

L’installation de PuTTY est très simple et consiste en un seul executable (putty-x86.exe) à télécharger. Il est préférable d’utiliser les versions de développement, qui sont stables en pratique et ont des fonctionnalités supplémentaires intéressantes.

PuTTY offre quelques possibilités intéressantes telles que : – enregistrement de sessions (adresse du serveur, protocole, login, commande à exécuter à la connexion…) – configuration fine des options du terminal texte (caractères de contrôle, sonnette…) – gestion des connexions telnet, rlogin et mode brut – établissement de tunnels (redirection de ports et X11)

Cette dernière possibilité est très intéressante car elle permet d’établir des tunnels SSH, afin de sécuriser des protocoles transitant en clair sur le réseau.

Exemple : vous souhaitez administrer un serveur distant avec VNC, sur lequel vous pouvez installer un serveur ssh. Pour chiffrer le contenu de la session VNC, vous pouvez utiliser un tunnel ssh entre votre station d’administration et le serveur VNC. Sur votre station, vous connectez votre client VNC à un port local, qui est redirigé, via le tunnel ssh, vers le port VNC (5900) du serveur distant.

Une fois la redirection de port lancée, toute connexion établie vers le port 5900 de la machine locale est redirigée, via le tunnel ssh, vers le port 5900 du serveur VNC distant.

Pour réaliser cette configuration avec PuTTY, il faut : – aller dans l’onglet Connection/SSH/Tunnels – ajouter le numéro du port local redirigé (5900 ici) dans la case ‘Source Port’, en s’assurant que la marque ‘Local’ est activée. – indiquer la destination, c’est à dire la machine distante (serveur VNC) et le numéro de port (5900 pour VNC) – ajouter ce tunnel en cliquant sur ‘Add’.

Il suffit alors de se connecter de façon interactive vers le serveur SSH ; le tunnel sera établi à partir de cet instant.

Note : s’il n’est pas possible d’installer un serveur ssh sur le serveur VNC lui-même, il est possible d’utiliser une autre machine comme terminaison du tunnel SSH. Cependant, le trafic entre le serveur SSH et le serveur VNC transitera en clair. Cette possibilité n’est donc envisageable que si les deux serveurs sont sur un même réseau protégé.

Authentification par clés

En plus de l’authentification traditionnelle par login/mot de passe, ssh peut authentifier l’utilisateur grâce à des algorithmes de cryptographie à clés publiques (RSA, DSA). L’utilisateur place sa clé publique sur les serveurs ssh sur lesquels il souhaite se connecter et garde sa clé privée sur sa station de travail. Lors d’une connexion vers un serveur, le client ssh utilise la clé privée du poste local pour prouver au serveur l’identité de l’utilisateur.

Avant de pouvoir utiliser cette méthode, il faut commencer par créer un couple de clés : une clé privée et sa clé publique correspondante. Le programme PuTTYgen sert à cela. PuTTYgen peut générer des clés RSA (SSHv1 et SSHv2) et DSA (SSHv2) (DSA étant déconseillé par les développeurs de PuTTY), il faut donc choisir parmi ces 3 types avant de lancer la génération des clés. Afin d’accumuler une quantité suffisante d’aléa, il faut déplacer la souris de façon désordonnée lorsque le programme le demande.

Une fois le couple généré, il est conseillé de protéger la clé privée par une passe-phrase. Cette passe-phrase sert de clé symétrique pour chiffrer la clé privée et est demandée à chaque connexion. Si aucune passe-phrase n’est spécifiée, l’authentification se fera sans intervention de l’utilisateur _mais_ si la clé privée est compromise, il sera possible à un attaquant de se connecter sur tous les serveurs SSH contenant la clé publique de l’utilisateur.

La clé publique est à placer dans le répertoire .ssh/ du répertoire racine de l’utilisateur sur les serveurs SSH, sous le nom authorized_keys (l’utilisation du fichier authorized_keys2 pour les clés utilisées par SSHv2 est désormais obsolète depuis la version 2.9.9 d’OpenSSH). La clé privée est à stocker sur la machine locale, dans un fichier lisible uniquement par l’utilisateur et dont l’emplacement est à spécifier dans PuTTY, sous l’onglet de configuration Connection/SSH/Auth, pour chaque session définie dans PuTTY.

Dernier point, si vous disposez de plusieurs couples de clés que vous utilisez régulièrement et dont les clés privées sont protégées par une passe-phrase, il est pratique d’utiliser le programme Pageant, qui permet de charger une fois pour toute des clés privées, en ne saisissant qu’une seule fois la passe-phrase pour chaque clé. Par la suite, PuTTY interroge Pageant pour savoir s’il dispose d’une clé permettant de réaliser l’authentification. Ce programme est l’équivalent de l’outil ssh-agent d’OpenSSH.

Note : les clés privées générées par PuTTYgen autres qu’au format RSA1 (RSA SSHv1) ne sont lisibles que par le client PuTTY. Si vous vous connectez avec le client OpenSSH, préférez le programme ssh-keygen pour générer vos couples de clés.

Mise en garde

Il est important de garder à l’esprit que l’utilisation de l’environnement Cygwin doit être restreint à des personnes de confiance (typiquement des administrateurs). En effet, l’environnement Cygwin utilise des zones de mémoire partagée pour stocker des informations sur les processus. Ces zones n’étant en aucun cas protégées, il est potentiellement possible qu’un programme malin puisse modifier le comportement d’un autre programme en exécution de cette façon.

Références

Cygwin : http://www.cygwin.com/ OpenSSH : http://www.openssh.com/ PuTTY : http://www.chiark.greenend.uk/ sgatatham/putty/

Pour toute remarque : Jean-Baptiste.Marchand Mise en page, actualisation : karlesnine