Intéressé par des cours d'informatique en ligne ?
Visitez mon nouveau site https://www.yesik.it !


Par défaut, lors de la connexion à un serveur distant par SSH (Secure Shell) l'authentification se fait avec le mot de passe du compte utilisateur sur lequel vous vous connectez. Cette technique est simple et pratique. Mais parfois elle n'est pas souhaitable: Parce que vous voulez autoriser plusieurs utilisateurs à accéder à un même compte distant, sans pour autant vouloir leur donner à tous le mot de passe de ce compte. Ou encore, parce que vous considérez que l'utilisation d'un mot de passe seul n'est pas assez fiable pour vous.

Une alternative possible est d'utiliser une clé. En informatique, une clé est représentée par une séquence de bits (supposée) infalsifiable qui permet de prouver l'identité d'un correspondant. Plusieurs algorithmes permettent de générer des clés. OpenSSH – la version de SSH disponible sous Linux et de nombreux autres Unix-like – permet notamment d'utiliser l'algorithme de signature numérique DSA. Celui-ci utilise deux clés:

  • la clé publique à diffuser largement;
  • la clé privée qui doit être gardée confidentielle.

Avec cet algorithme, seule la clé publique est nécessaire au destinataire pour vérifier l'authenticité d'un message signé avec la clé privée.

Dans le cas de ssh, cette signature numérique peut être utilisée à la place du mot de passe du compte utilisateur pour se connecter à un système distant. C'est ce que nous allons faire maintenant.

Mise en oeuvre

Générer la paire de clés

La première étape va être de générer la paire de clé. C'est une opération à faire sur la machine cliente à l'aide de l'utilitaire ssh-keygen(1):

sylvain@mobal$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/sylvain/.ssh/id_dsa): 
Enter passphrase (empty for no passphrase): ********************
Enter same passphrase again: ********************
Your identification has been saved in /home/sylvain/.ssh/id_dsa.
Your public key has been saved in /home/sylvain/.ssh/id_dsa.pub.
The key fingerprint is:
6b:2b:1e:34:e0:33:dd:e4:5e:b5:bc:3f:a6:fe:04:a2 sylvain@mobal
The key's randomart image is:
+--[ DSA 1024]----+
|                 |
|                 |
|    .   .   .    |
|   . o +   o .   |
|    + + S o +    |
|     + o + . o   |
|      . E   . .  |
|      .o .   oo  |
|     ....  .o+o. |
+-----------------+

Un certain nombre de points sont à noter en observant la transcription ci-dessus.

Tout d'abord, ssh-keygen vous demande où enregistrer les fichiers créés. Les parce qu'il y en a deux: un pour la clé publique, l'autre pour la clé privée. Je vous laisse deviner qui est qui:

D'ailleurs en accord avec leur rôles respectifs, ceux-ci se voient doter des permissions adéquates:

sylvain@mobal$ ls -ld /home/sylvain/.ssh/id_dsa*
-rw------- 1 sylvain sylvain 736 2010-06-22 12:45 /home/sylvain/.ssh/id_dsa
-rw-r--r-- 1 sylvain sylvain 603 2010-06-22 12:45 /home/sylvain/.ssh/id_dsa.pub

Ainsi, la clé publique est en lecture pour tout le monde. La clé privée, uniquement pour son possesseur. Ceci dit, pour vous assurer de la confidentialité de votre clé privée, je vous engage à systématiquement vérifier ces permissions – et le propriétaire des fichiers. Et le cas échéant à les changer.

Toujours au chapitre de ce qu'il faut faire, vous voudrez sans aucun doute donner une passphrase lors de la création de votre clé. C'est une protection, sans laquelle le simple fait de posséder la clé privée suffit à prouver votre identité. Avec une passphrase, nous entrons dans le règne de l'authentification à deux niveaux (parfois appelée authentification forte): il faut que la passphrase et la clé soient compromises toutes les deux pour usurper votre identité.

Une remarque: si l'on parle de passphrase ici et pas de password, c'est bien pour insister sur le fait que celle-ci doit être longue (10 à 30 caractères). Par contre, elle ne doit pas former une phrase grammaticalement correcte, puisque la plupart des langages ont une entropie beaucoup trop faible pour créer des passphrases fiables.

Key's randomart

The key's randomart image is:
+--[ DSA 1024]----+
|                 |
|                 |
|    .   .   .    |
|   . o +   o .   |
|    + + S o +    |
|     + o + . o   |
|      . E   . .  |
|      .o .   oo  |
|     ....  .o+o. |
+-----------------+

Pour ceux qui se demandent ce qu'est le randomart de la clé, il s'agit d'une nouveauté de OpenSSH5.1 basée sur les travaux de Adrian Perrig et Down Song: "Hash Visualization: a New Technique to improve Real-World Security", Perrig A. and Song D., 1999, International Workshop on Cryptographic Techniques and E-Commerce (CrypTEC '99)".

L'idée est d'avoir un moyen plus simple pour un humain de vérifier le signataire d'un message.

En effet, habituellement, le signataire est identifié par son empreinte. C'est à dire une séquence de bits – par exemple exprimée sous la forme de chiffres hexadécimaux. Or, ce moyen est peu adapté à l'utilisateur final: comparer de visu deux empreintes est une tâche lente et qui peut être source d'erreur. Par exemple, laquelle des signatures suivantes correspond bien à l'empreinte (fingerprint) donnée plus haut?

6b:2b:1e:34:e8:33:dd:e4:5e:b5:bc:3f:a6:fe:04:a2
6b:2b:1e:34:e8:33:dd:e4:5e:bc:b5:3f:a6:fe:04:a2
6b:2b:1e:34:e0:33:dd:e4:5e:b5:bc:3f:a6:fe:04:a2
6b:2b:1e:34:e0:33:dd:e4:5e:b5:6c:3f:a6:fe:04:a2
6b:2b:1e:34:e0:33:dd:e4:5e:b5:6c:3f:a6:fe:04:a2

Le randomart cherche à pallier cet inconvénient en utilisant une représentation graphique ou pseudo-graphique de l'empreinte, plus rapide et fiable à vérifier d'un coup d'oeil.

Sur OpenSSH5.1 cette fonctionnalité est encore expérimentale, et l'algorithme de génération du graphique est encore sujet à modifications.

Installer la clé sur le serveur

A cette étape, ssh peut vous demander votre passphrase pour dévérouiller l'accès à la clé DSA. Cela n'est pas nécessaire. En effet, la clé publique n'est pas encore sur le serveur. Refusez l'accès à cette clé, et ssh finira par vous demander le mot de passe du compte distant.

Maintenant que nous disposons de notre paire de clé, il faut diffuser la clé publique. Pour que ssh la trouve, celle-ci doit être ajoutée au fichier ~/.ssh/authorized_keys du compte distant. C'est à dire qu'à cette étape, vous devez avoir accès au serveur. Éventuellement en vous y connectant par ssh, mais avec la technique classique. Ici, je vais utiliser ssh-copy-id(1) pour faire cette copie à distance:

# Copier la clé PUBLIQUE sur le serveur
sylvain@mobal$ ssh-copy-id -i /home/sylvain/.ssh/id_dsa.pub bigboote@host-01
bigboote@host-01's password: **********
Now try logging into the machine, with "ssh 'bigboote@host-01'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

En réalité, ssh-copy-id est juste un script shell qui ajoute le contenu du fichier désigné par l'option -i à la fin du fichier authorized_keys du compte destinataire. Comme ce script ne vérifie pas le contenu du fichier source, il est susceptible de copier n'importe quoi dans le fichier authorized_keys. D'où le message d'avertissement qu'il affiche.

Manuellement, vous pouvez faire sensiblement la même opération avec la séquence de commandes suivantes:

sylvain@mobal$ cat /home/sylvain/.ssh/id_dsa.pub | ssh bigboote@host-01 'umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys' 
bigboote@host-01's password: **********


Se connecter

Si vous avez associé, comme je vous le recommande, une passphrase à votre clé privée, celle-ci va vous être demandée. Éventuellement via le gestionnaire de clés de votre environnement graphique. Comprenez bien que c'est la clé qui prouve que vous êtes autorisé à vous connecter. Pas la passphrase. Celle-ci ne sert qu'à dévérouiller la clé.
De façon imagée, la passphrase ouvre la boite qui contient la clé qui permet de se connecter.

Maintenant que la clé publique a été copiée, il devient possible de l'utiliser pour se connecter au serveur ssh. Désormais, c'est la passphrase associée à la clé qu'il faudra donner. Et plus le mot de passe du compte utilisateur distant:

sylvain@mobal$ ssh bigboote@host-01
Linux host-01 2.6.26 #2 Tue May 25 07:25:33 UTC 2010 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Jun 21 18:48:36 2010 from 10.129.37.99
bigboote@host-01:~$ 

Dans .ssh/authorized_keys vous devriez trouver votre clé publique (sur une seule grande ligne):

bigboote@host-01:~$ cat .ssh/authorized_keys 
ssh-dss AAAAB3NzaC1kc3MAAACBAMeZBR1Huz2Zoq+Jwbbz80l7qociCkDdd/t7yREGniPqXgwMTD6RGuYOD+tRzcR8eTKFYNA9Z5dRxTzDBtO8tzG/p396gAbOOnFTM8ygtigbbNtuvsvXiv9/GqbSBvGJTh3sQF2LI2UDL4+e4drkusRJuE7qZqfBptVe+MTsXknRAAAAFQD32Ik9NVJTuROUzOkRU/fN66m/HwAAAIEAnEblGOhCbh+7ZQKH/Nt1HFvwUZea+8QSK2tz6+g3WsaHL7FENTqg2pyjaCc54VyIYmDa0CT5NnjBPv9UDt+fBbx2Kl8mKm8eemaiPk2LXsSjmfEjJhs/Qzhsad4fmYik8bi1GQ05nYM8FQ9ceBJRmCvm05A1w4G1wSWkFG1oyl8AAACAIhfU6eunSIsoDCUXQS7JnQyTROvZzDADjwTWPpH0MbPaui7l5f59UQrgpSttSfM1wcVt16jhWqCCpIbXU9NUTDEBoQPcTGAmEyiPpR2D3OIMqQMoIYGR+nneLxLT558QjkZjC/tOwXtNws2NWpDmj7jNQ+KK42Sz3X54NAi6On8= sylvain@mobal

Ce fichier peut contenir plusieurs clés publiques. Une pour chaque personne autorisée à se connecter à ce serveur et sous cette identité. Chaque clé doit être sur une ligne.

Identités multiples

Un des avantages de l'authentification forte est que l'utilisation de clés permet de mieux gérer l'accès aux comptes distants. En effet, avec ce système, autoriser ou révoquer l'accès d'un compte à un utilisateur revient simplement à ajouter ou supprimer la clé publique correspondante dans le fichier authorized_keys.

Par ailleurs, toujours en copiant sa clé publique dans les fichiers adéquats, il est possible de permettre à un même utilisateur d'accéder à plusieurs comptes et/ou plusieurs hôtes sans lui imposer de mémoriser de nombreux mots de passe:

sylvain@mobal$ ssh-copy-id -i /home/sylvain/.ssh/id_dsa.pub lizardo@host-02
lizardo@host-02's password: mot de passe du COMPTE DISTANT
Now try logging into the machine, with "ssh 'lizardo@host-02'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.
[...]
sylvain@mobal$ ssh lizardo@host-02
Enter passphrase for key '/home/sylvain/.ssh/id_dsa': passphrase de la CLE PRIVEE
lizardo@host-02:~$ 

En résumé, le principe de déploiement est simple: pour chaque compte et/ou machine à laquelle un utilisateur est autorisé à se connecter, il faut copier la clé publique. Cette étape nécessite de pouvoir accéder au compte distant. Soit en y accédant physiquement. Soit via ssh. Cette opération n'est à faire qu'une fois. Ensuite, tout ce qui est nécessaire à l'utilisateur distant pour se connecter, c'est sa clé privée et la passphrase correspondante. Même clé et même passphrase quelque soit le compte distant.

La même clé peut être utilisée pour accéder à différents comptes.

De la même manière, le jour où l'autorisation d'accès à un compte d'un utilisateur est révoquée – ou le jour où sa clé privée est compromise – il suffit de retirer la clé publique correspondante du serveur pour qu'il ne puisse plus s'y connecter avec cette clé.

Gérer plusieurs identités

Si la même paire de clés peut être utilisée pour permettre à un utilisateur d'accéder à plusieurs comptes différents – à l'inverse il est possible pour un même utilisateur d'utiliser une clé différente pour chaque compte. Il est aussi possible d'envisager de pouvoir accéder à un même compte avec deux clés différentes. On parle dans ces cas d'identités multiples.

Un même utilisateur peut posséder plusieurs paires de clés – représentant chacune une de ses identités virtuelles. L'une ou l'autre, et éventuellement plusieurs d'entres-elles, peuvent être installées sur un compte distant pour lui permettre d'y accéder.

La commande ssh-keygen permet de créer autant de paires de clés que vous le voulez. Chaque paire constitue une identité. Dans chaque paire, la clé privée permet de signer sous l'identité correspondante. Et la clé publique associée permet de vérifier cette identité. Il n'y a pas de lien entre les différentes identités!

# Créer une paire de clé pour l'identité "lizardo"
sylvain@mobal$ ssh-keygen -t dsa -f ~/.ssh/lizardo
Generating public/private dsa key pair.
Enter passphrase (empty for no passphrase): *********
Enter same passphrase again: *********
Your identification has been saved in /home/sylvain/.ssh/lizardo.
Your public key has been saved in /home/sylvain/.ssh/lizardo.pub.
The key fingerprint is:
38:92:70:b1:d1:17:21:0a:49:8a:17:0e:a7:cb:12:f1 sylvain@mobal
The key's randomart image is:
+--[ DSA 1024]----+
|o.=.o.. oo       |
|.O.o =...        |
|= E +  .         |
|.+ o . .         |
|o.  o o S        |
|.    . .         |
|                 |
|                 |
|                 |
+-----------------+
# Créer une paire de clé pour l'identité "whorfin"
sylvain@mobal$ ssh-keygen -t dsa -f ~/.ssh/whorfin
Generating public/private dsa key pair.
Enter passphrase (empty for no passphrase): *********
Enter same passphrase again: *********
Your identification has been saved in /home/sylvain/.ssh/whorfin.
Your public key has been saved in /home/sylvain/.ssh/whorfin.pub.
The key fingerprint is:
28:85:42:9d:ee:7b:96:b0:8b:36:a5:0b:e4:e1:7e:bd sylvain@mobal
The key's randomart image is:
+--[ DSA 1024]----+
|  .. .           |
| .  o.           |
|  ... .          |
|   ... .         |
| o .. . S        |
|+ . +.           |
|.o o.+ .         |
|..+oo.+          |
| o+o.E.          |
+-----------------+

Les clés publiques sont à copier comme d'habitude:

# Installer les clés publiques des deux identités sur "whorfin@host-03"
sylvain@mobal$ ssh-copy-id -i ~/.ssh/lizardo whorfin@host-03
sylvain@mobal$ ssh-copy-id -i ~/.ssh/whorfin whorfin@host-03

A partir de maintenant, pour choisir l'identité sous laquelle se connecter, la méthode la plus simple est d'utiliser l'option -i (comme identity) de ssh:

sylvain@mobal$ ssh -i ~/.ssh/whorfin whorfin@host-03
Enter passphrase for key '/home/sylvain/.ssh/whorfin': ********* 

whorfin@host-03:~$ 
sylvain@mobal$ ssh -i ~/.ssh/lizardo whorfin@host-03
Enter passphrase for key '/home/sylvain/.ssh/lizardo': ********* 

whorfin@host-03:~$

Gérer plusieurs identités, version avancée

S'il est possible de choisir une identité en précisant systématiquement l'option -i de la commande ssh, il est aussi possible d'agir un peu plus élégamment.

En effet, le client ssh peut utiliser le fichier de configuration ~/.ssh/config pour gérer automatiquement un certain nombre de paramètres. Dont le choix d'une identité.

Ici, nous nous intéresserons uniquement à l'option IdentityFile qui répond à notre besoin. Ainsi, le fichier de configuration suivant précise d'utiliser systématiquement lors de la connexion à un client sur host-03:

sylvain@mobal$ cat ~/.ssh/config
host host-03
    IdentitiesOnly  yes
    IdentityFile    ~/.ssh/lizardo

Avec cette configuration, il n'est plus nécessaire de préciser explicitement l'identité à utiliser lors de l'invocation de ssh:

sylvain@mobal$ ssh whorfin@host-03
Enter passphrase for key '/home/sylvain/.ssh/lizardo': 
whorfin@host-03:~$

Options et identités multiples

Si on peut aisément comprendre qu'un utilisateur souhaite utiliser différentes identités pour se connecter à différents comptes, on peut se poser la question de l'utilité de pouvoir accéder à un même compte sous plusieurs identités.

Cette possibilité révèle tout son intérêt quand elle est couplée avec l'utilisation d'options dans le fichier authorized_keys. Celles-ci permettent de modifier le comportement de la session SSH en fonction de l'identité utilisée pour se connecter.

Concrètement, on peut préfixer chaque ligne contenant une clé publique dans authroized_keys par une ou plusieurs options séparées par une virgule. L'option la plus pratique est sans doute command= qui permet de spécifier la commande à lancer lors de la connexion sous cette identité.

En pratique

Prenons un exemple: on souhaite permettre à une utilisatrice (penny) d'examiner l'état des connexions réseau d'un système distant (labo). Pour ce faire, on va l'autoriser à se connecter par SSH à un compte utilisateur (buckaroo), mais en imposant l'utilisation exclusive de la commande ifconfig(8). La première étape va consister pour penny à se créer une identité pour cette tâche:

penny@home:~$ ssh-keygen -t dsa -f ~/.ssh/penny_network
Generating public/private dsa key pair.
[...]
Your identification has been saved in /home/penny/.ssh/penny_network.
Your public key has been saved in /home/penny/.ssh/penny_network.pub.
[...]

Maintenant, Penny transfert par un moyen quelconque sa clé publique (/home/penny/.ssh/penny_network.pub) à l'utilisateur propriétaire du compte buckaroo. Celui-ci, va ensuite installer cette clé dans son fichier authorized_keys, mais en prenant soin de préciser en option que c'est la commande ifconfig qui va être lancée lors de la connexion sous cette identité:

# D'une manière ou d'une autre, Buckaroo a récupéré la clé publique de Penny:
buckaroo@labo:~$ ls penny*
penny_network.pub
# Installer la clé en précisant l'option "command=":
buckaroo@labo:~$ echo 'command="/sbin/ifconfig"' | paste - penny_network.pub >> .ssh/authorized_keys
# On peut vérifier que la clé est convenablement installée:
buckaroo@labo:~$ tail -1 .ssh/authorized_keys 
command="/sbin/ifconfig"	ssh-dss AAAAB3NzaC1kc3MAAACBALNHaseZL1CDSgcSEeMP79H+uwti6NxnT3nt+VQx9/7OUbVDbyAmI/bfoNZfP99IVnTYNoWWNCidRXSOb3zHNFId6R9R08vGJmBfHpdzUTsgAOIygnD36D0JODkqA/UasML7lnKLGB8wkc6s0q+TIMhbMspLBc8TtNs34ZTCsnapAAAAFQC9fyXPg4gMU8xTm3Cnq/rkldxjiwAAAIAVhQp9bxXqsFJ9hx0uEr7wQ9FhMnccSDgv81k6mw6WmmOK6SHEDNrpawB2tjyzVFPhDjbdQ8Npmx128AAKi+ceUzFJz4bHskoUoBhQxxq8QHA3poPbW3jscxA2hGSyzetdtUhb4ezkDOmU5YGuUd1qNOTWJNdR/v6aN8uYF/OADQAAAIA0zJ6VU4H2ZS93l9ll8a51E9PQxO1133+3F+O0AhD0Xk3B4c/s3ctaejeuwP4G0qCZyStqFomrqrOjJi+21B1ruzTNb+KYgHuaRRhLuqpFv06xGhAkk4V+FW5SDs05g6Oo0QQFOSmBFM7IforBa9m5huBq/eQ9wvQjgQ2QqdLqog== penny@home

N'oubliez pas les guillemets!

Les paramètres des options sont à placer entre guillemets:

command="/sbin/ifconfig"	ssh-dss AAAAB3NzaC1kc3MAAACBALNHaseZL1CDSgcSEeMP79H+uwti6NxnT3nt+VQx9/7OUbVDbyAmI/bfoNZfP99IVnTYNoWWNCidRXSOb3zHNFId6R9R08vGJmBfHpdzUTsgAOIygnD36D0JODkqA/UasML7lnKLGB8wkc6s0q+TIMhbMspLBc8TtNs34ZTCsnapAAAAFQC9fyXPg4gMU8xTm3Cnq/rkldxjiwAAAIAVhQp9bxXqsFJ9hx0uEr7wQ9FhMnccSDgv81k6mw6WmmOK6SHEDNrpawB2tjyzVFPhDjbdQ8Npmx128AAKi+ceUzFJz4bHskoUoBhQxxq8QHA3poPbW3jscxA2hGSyzetdtUhb4ezkDOmU5YGuUd1qNOTWJNdR/v6aN8uYF/OADQAAAIA0zJ6VU4H2ZS93l9ll8a51E9PQxO1133+3F+O0AhD0Xk3B4c/s3ctaejeuwP4G0qCZyStqFomrqrOjJi+21B1ruzTNb+KYgHuaRRhLuqpFv06xGhAkk4V+FW5SDs05g6Oo0QQFOSmBFM7IforBa9m5huBq/eQ9wvQjgQ2QqdLqog== penny@home

Si vous les oubliez, ça ne marchera pas – mais vous n'aurez pas non plus de message d'erreur...

A partir de maintenant, Penny peut accéder au compte buckaroo sous l'identité penny_network. Cependant, seule la commande ifconfig sera exécutée:

penny@home:~$ ssh -i ~/.ssh/penny_network buckaroo@labo
Enter passphrase for key '/home/penny/.ssh/penny_network': ************
eth0      Link encap:Ethernet  HWaddr 02:03:e8:ff:00:02  
          inet addr:10.129.37.83  Bcast:10.129.37.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2769 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1415 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:268215 (261.9 KiB)  TX bytes:210090 (205.1 KiB)
          Interrupt:5 

[...]

Connection to labo closed.

Comme vous le voyez, une fois la connexion effectuée, la commande ifconfig est exécutée, puis la session fermée à l'issue de cette commande.

Une identité par service

Muni de ces informations, on comprend que l'on peut de la même manière définir d'autres services en les associant à des identités différentes. Ainsi, pour savoir qui est connecté on peut associer une identité à la commande who(1):

penny@home:~$ ssh-keygen -t dsa -f ~/.ssh/penny_who
Generating public/private dsa key pair.
[...]

Puis une fois la clé donnée à Buckaroo par un moyen ou un autre:

buckaroo@labo:~$ echo 'command="/usr/bin/who"' | paste - penny_who.pub >> .ssh/authorized_keys

Désormais, Penny peut voir qui est connecté sur l'hôte labo:

penny@home:~$ ssh -t -i ~/.ssh/penny_who buckaroo@labo
Enter passphrase for key '/home/penny/.ssh/penny_who': ************
root     tty0         2010-06-25 14:52
buckaroo pts/0        2010-06-30 15:32 (labo)
Connection to labo closed.

Attention:

Si cette technique est séduisante, il faut quand même être très prudent avant d'y voir une technique de sécurisation d'accès. En effet, beaucoup de commandes interactives offrent des moyens d'évasion en permettant de lancer un shell. Cela serait par exemple le cas avec la commande mail(1):

buckaroo@labo:~$ echo 'command="/usr/bin/mail"' | paste - penny_mail.pub >> .ssh/authorized_keys

Dans l'exemple ci-dessus, on peut croire ne permettre à Penny que de relever le courrier électronique du compte buckaroo. Mais comme la commande mail permet de lancer un shell interactif, en réalité, on vient de donner à Penny l'entier accès au compte buckaroo:

penny@home:~$ ssh buckaroo@labo
Mail version 8.1.2 01/15/2001.  Type ? for help.
"/var/mail/buckaroo": 1 message 1 new
>N  1 root@host-01       Tue Jun 22 13:50   20/565   Oscillation Overthruster data sheet
& sh
buckaroo@labo:~$ 

Autres options

Pour terminer, citons brièvement quelques autres options:

no-port-forwarding
Pour empêcher d'utiliser ssh comme tunnel TCP pour rediriger le trafic réseau
no-agent-forwarding
Pour empêcher de transmettre les requêtes d'authentification à un agent externe
no-X11-forwarding
Pour ne pas utiliser ssh comme tunnel pour la communication avec le serveur X
no-pty
Pour ne pas allouer de pseudo-terminal (pas de gestion écran/clavier – surtout utile lorsqu'on lance un service plutôt qu'une commande utilisateur)

Si je cite ces options parmi celles possibles, c'est parce qu'elles seront souvent nécessaires pour réellement limiter ce que peuvent faire les utilisateurs distants. En particulier, dans les quelques exemples précédents forçant les commandes ifconfig ou who, je ne bloquais aucune des possibilités de forwarding de ssh. Malgré un accès limité, il était donc toujours possible d'utiliser ces commandes ssh pour ouvrir un tunnel vers des services accessibles à l'hôte distant.

Pour plus de sécurité, il aurait donc été préférable de configurer l'accès ainsi:

buckaroo@labo:~$ echo 'command="/sbin/ifconfig",no-port-forwarding,no-agent-forwarding,no-X11-forwarding' | paste - penny_network.pub >> .ssh/authorized_keys

Ressources