User Tools

Site Tools


informatique:logiciels:ssh

This is an old revision of the document!


logiciels sécurité

SSH

recueil d'informations concernant SSH

SSH, ou Secure SHell permet de communiquer avec une machine distante de manière chiffrée, donc sécurisée.

Configuration du serveur

aptitude install openssh-server

Le fichier de configuration /etc/ssh/sshd_config par défaut se suffit à lui-même ; cependant on peut modifier/ajouter les directives suivantes :

# désactivation du login pour le compte root
PermitRootLogin no
# limiter les connexions au seuls utilisateurs toto, et titi depuis la machine 1.2.3.4
AllowUsers toto titi@1.2.3.4
 
# on n'accepte que les utilisateurs membres du groupe ssh_users
AllowGroup ssh_users
 
# on veut que le serveur écoute sur un port supplémentaire
Port 22 2222
 
# Limiter les tentatives de login à 5
MaxAuthTries 5
 
# bon, là ça rentre en conflit avec la directive ci-dessus mais c'est pour l'exemple
# 10 tentatives de connexion simultanées max ; puis 30% de refus : puis 100% à la 15e
MaxStartups 10:30:15
 
# pour partager une redirection de port avec n'importe qui qui se connecte dessus
# en gros la redirection se fait sur 0.0.0.0:x et non plus 127.0.0.1:x donc elle redirige tous
# les paquets arrivant sur son port x, pas seulement ceux en provenance de ma connexion SSH
GatewayPorts yes

On (re)lance le service :

/etc/init.d/ssh restart

Mep d'une bannière

Par défaut la bannière qui est utilisée est le contenu du fichier /etc/motd. On peut donc modifier le contenu de ce fichier, ou utiliser la directive

banner <fichier>

dans le fichier de conf.

Limitation d'une paire de clé

Pour ne permettre à un utilisateur s'authentifiant avec une paire de clé à ne lancer qu'une seule commande, il faut spécifier command=<cmd> devant la clé dans le fichier .ssh/authorized_keys :

command="ls" ssh-rsa AAAB3[..]

Dans le cas précédent, la commande ls sera lancée, puis la connexion se terminera.

Utilisation du client

On l'utilise dans un terminal (ou grâce à Putty si on tourne sous Windows) selon la syntaxe de base :

ssh -p <port> [login@]server

Si c'est la première connexion SSH depuis ce client vers ce serveur, il vous demande si le fingerprint de la clé publique présentée par le serveur est bien le bon. Si c'est la bonne, répondez “yes” : la clé publique du serveur est alors rajoutée au fichier ~/.ssh/known_hosts.

Se connecter sans mdp

Sur la machine cliente :

  • générer un couple de clé rsa :
cd ~/.ssh
ssh-keygen -t rsa
 Generating public/private rsa key pair.
 Enter file in which to save the key (/home/<user>/.ssh/id_rsa): 
 Enter passphrase (empty for no passphrase): 
 Enter same passphrase again: 
 Your identification has been saved in /home/<user>/.ssh/id_rsa.
 Your public key has been saved in /home/<user>/.ssh/id_rsa.pub.
 The key fingerprint is:
 5a:1d:34:b1:44:dc:1f:94:58:f2:e9:ae:ab:5c:0c:97 <user>@<host>

id_rsa est la clé privée ; id_rsa.pub la clé publique La passphrase n'est pas indispensable, mais recommandée pour des questions de sécurité.

  • envoyer sa clé publique sur le serveur <host>
ssh-copy-id [-i [identity_file]] [user@]machine

… ou moins simple en copiant à la main sa clé publique dans ~/.ssh/authorized_keys

cat ~/.ssh/id_rsa.pub | ssh <user>@<host> "cat - >> ~/.ssh/authorized_keys"

NB : la commande ssh-copy-id ne gère pas plusieurs arguments (wtf ?!) ; donc, si le serveur SSH distant est sur un port autre que celui par défaut (tcp/22), vous devez passer les arguments entre “ ” ; exemple :

ssh-copy-id -i /home/dude/.ssh/id_rsa.pub 10.0.0.1:2222
ssh: Could not resolve hostname 10.0.0.1:2222: Name or service not known
 
ssh-copy-id -i /home/dude/.ssh/id_rsa.pub -p 2222 10.0.0.1
ssh: Could not resolve hostname umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys: Name or service not known
 
# la solution :
ssh-copy-id -i /home/dude/.ssh/id_rsa.pub "-p 2222 10.0.0.1"

On peut rencontrer des problèmes d'authentification si les droits du fichier authorized_keys ne sont pas en 600 (il ne doit pas être lisible par les autres utilisateurs du système). Le dossier ~/.ssh/ doit être en 700 parait-il (à vérifier).

Pour interdire à cet utilisateur de lancer un shell, il faut ajouter no-pty devant sa clé, par exemple :

vi ~/.ssh/authorized_keys
no-pty ssh-dss AAAAB3NzaC..qxX/27ZZ9X5vAVA= backup
  • si l'on utilise une passphrase, il faudra la saisir à chaque ssh qu'on fera. Pour ne pas avoir à la retaper à chaque fois, on utilise ssh-agent :
eval 'ssh-agent'
SSH_AUTH_SOCK=/tmp/ssh-00021836aa/agent.21836; export SSH_AUTH_SOCK;
SSH_AGENT_PID=5683; export SSH_AGENT_PID;
echo Agent pid 5683;
ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/<user>/.ssh/id_rsa: 
Identity added: /home/<user>/.ssh/id_rsa (/home/<user>/.ssh/id_rsa)

On lance ssh-agent, qui est un processus qui va saisir la passphrase à notre place ; puis on lui spécifie notre clé privée (id_rsa) et on saisit (une fois pour la session) notre passphrase. Tant que la session sera ouverte, ssh-agent sera en mémoire et dispensera de saisir la passphrase.

  • pour plus de sécurité on peut restreindre l'utilisation des clés à une machine ou un sous-domaine en rajoutant from=“<host>” en début de ligne correspondante dans le fichier authorized_keys :
cat authorized_keys
from="*.stuff.net" ssh-rsa AAA..

Ici on filtre sur le sous-domaine stuff.net

Transfert de fichier avec SCP

Ssh CoPy (SCP) est une commande qui permet de transférer des fichiers par une connexion SSH. Sous Windows il existe les programmes pscp (en ligne de commande) et l'excellent WinSCP. Sous Linux, il est possible d'utiliser gFTP si l'on veut un interface graphique. Sous Mac j'utilise Fugu.

La syntaxe est la suivante :

scp fichier_local user@serveur.com:/path

Il faut noter qu'un path relatif (sans le “/”) est par défaut la home de l'utilisateur sous lequel on s'est connecté (voir 1er exemple).

exemple 1 : uploader test.txt (qui est un fichier local) dans la home de l'utilisateur toto sur serveur.com :

scp test.txt toto@serveur.com:

exemple 2 : télécharger dans le répertoire courant (.) test.txt, qui se trouve sur serveur.com

scp toto@serveur.com:test.txt .

exemple 3 : uploader l'intégralité (récursivement avec -r) du sous-répertoire test du répertoire courant vers le sous répertoire incoming de la home de l'utilisateur toto de la machine serveur.com :

scp -r test toto@serveur.com:incoming

Les paramètres disponibles sont :

  • -P port pour préciser un port spécifique
  • -r pour les transfert récursifs (copier le contenu d'un dossier par exemple)

Tunnels SSH

Faire un tunnel SSH, c'est créer une connexion SSH pour y faire passer (encapsuler) des données de manière sécurisée. En lançant une connexion SSH depuis mon poste client vers serveurSSH.com, je spécifie que tous les paquets à destination de mon port local 10080 seront envoyés dans le tunnel SSH, reçus par serveurSSH.com, qui les redirigera à destination de serveurWEB.com sur le port 80 :

ssh -L 10080:serveurWEB.com:80 serveurSSH.com

Concrètement, en saisissant dans mon navigateur http://localhost:10080, on accèdera à http://serveurWEB.com via serveurSSH.com (dans les logs de serveuWEB.com c'est donc l'IP de serveurSSH qui apparaitra).

La syntaxe est la suivante : -L <port_local>:<IP cible>:<port de l'IP cible>.

Les redirections des ports systèmes (<1024 ) nécessitent l'accès root sur le serveur SSH.

Exemple d'application : contourner les restrictions (excessives bien sur) du réseau de votre boulot.
But : avoir accès à tous les sites web en évitant les filtrages éventuels d'un admin réseau fasciste.
Condition : que ledit réseau d'entreprise ne filtre pas les paquets qui initient une connexion SSH, et qu'il ne fasse pas de l'analyse application (niveau 7) avec un IPS par exemple.

Situation :

  • installer un proxy (Squid par exemple) sur un PC chez soi, sur le port 3128 (c'est le port par défaut). Inutile de préciser que vous devez connaitre l'IP du PC, le laisser allumé, qu'il doit faire tourner un serveur SSH, et avoir configurer votre firewall éventuel pour accepter les connexions sur ce port.
  • lancer la commande ssh -L 1111:127.0.0.1:3128 toto@<votre-ip> depuis un poste distant, pour créer le tunnel sécurisé.
  • dans la configuration de votre navigateur, régler le proxy sur l'adresse 127.0.0.1 et le port 1111.

C'est tout. Votre navigateur va interroger la machine sur lequel vous surfez (127.0.0.1 c'est l'adresse IP locale) sur le port 1111. Or tout ce qui est envoyé à destination de ce port est envoyé dans le tunnel SSH. La requête arrive donc sur l'ordinateur <votre-IP>, qui va rediriger le flux vers l'IP:port spécifié lors de la création du tunnel, soit 127.0.0.1:3128. Cette IP on la reconnait, c'est l'IP locale ; le port c'est le 3128, soit celui du serveur proxy Squid qui tourne sur votre PC “serveur”.

Inutile de préciser que dans cet exemple il y a 2 IP locales distinctes (127.0.0.1). Cette IP désigne la machine elle-même : elle est relative à la machine. Dans le premier cas il s'agit du poste client, dans le second du serveur SSH distant.

CQFD, tout votre trafic Internet sera masqué par le tunnel et vous pourrez surfer sans restriction de site (le traffic Internet est chiffré pour le réseau d'entreprise). Attention toutefois, ce n'est pas de cas à partir de votre PC : lorsque vous surferez, les sites visitez vous verrons comme si vous étiez en train de surfer depuis le PC de chez vous.

Back connexion

Il existe un moyen de faire une back connexion, c'est à dire une redirection de requête via une autre machine. Supposons que je sois sur une machine (cliente) A et que je veuille rediriger les requêtes qu'une machine B (serveur) fait sur le port 8022

Sur la machine A je fais un :

ssh -R 8022:toto.com:22 B

Sur la machine B je fais un :

ssh -p 8022 localhost

Cette dernière commande envoie une requête en local sur la machine B, sur le port 8022. Or ce port est redirigé vers la machine A, via la connexion ssh établie précédemment, et envoyé vers toto.com:22 à partir de A, soit vers son serveur SSH.

Export display

L'export display consiste à se logguer à distance en mode graphique, comme on le fait avec un client et un serveur SSH en mode texte. On peut alors exécuter des applications graphiques sur le serveur distant : la fenêtre graphique de l'application et son contenu seront envoyés par le réseau vers la machine cliente. Il faut cependant avoir une bonne connexion.

Sur le serveur SSH, dans le fichier /etc/ssh/sshd_config, vérifier la présence de la directive

X11Forwarding yes

Sur le client, qui doit être muni d'un serveur X :

ssh -X [-C] serveur

-X permet l'export display et -C (facultatif) permet d'activer la compression des données (permet un gain de bande passante au détriment de la consommation CPU).

Puis lancer une application graphique.

Pour les postes clients sous Windows, on peut passer par l'installation de Cygwin avec un serveur X (http://cygwin.com/ Cygwin ou http://x.cygwin.com/ Cygwin/X). Dans le cas de Cygwin/X : on le lance, on lance le serveur X

startxwin.sh

Cela lance un xterm (et une icone dans la taskbar). Ensuite on procède comme normalement :

ssh -X serveur

(il parait que ça marche aussi avec putty, en activant le X11 Forwarding, mais ça ne marche pas chez moi : normal il n'y a pas de serveur X lancé sans Cygwin !..)

Tips

Stream audio over SSH

Stream audio over SSH : on transmet le fichier file.mp3 dans la connexion SSH ; le flux est lu par le logiciel mpg321 sur le serveur distant.

ssh [user]@[address] "mpg321 -" < file.mp3

Lister les options du sshd

Pour lister les paramètres effectifs avec lesquels se lance le démon sshd (c'est utile notamment pour voir la valeur des paramètres non spécifiés dans le fichier de configuration /etc/ssh/sshd_config) :

sshd -T

Mode debug/verbose

Pour débugger une connexion SSH récalcitrante, utiliser l'option -v pour activer le mode bavard (~ debug). Il existe 3 niveaux de verbosité que l'on spécifie en fonction du nombre de “v” : par exemple pour le debug2 (niveau intermédiaire mais déjà très causant) :

ssh -vv user@server
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to server [10.1.1.51] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
[..]

Liens

informatique/logiciels/ssh.1439978328.txt.gz · Last modified: 2015/08/19 09:58 by pteu