Chrooter apache
Matériel
Ajout disque dur
Ajout carte
Audit des disques durs
Gestion des peripheriques
Disquette d'installation
Ajout d'un scanner
Astuces
Ajout d'une imprimante
Réseau
Configuration reseau
Dns
Serveur cvs
Proxy squid 
Installation serveur ftp
Installation qmail 
Installation serveur courrier sous debian
Outil TCP/IP 
Le serveur samba
Connexion a distance securisee
Client/serveur vnc
Configurer apache
Dyndns
Sécurité
Chiffrer un fichier/dossier
Securiser son poste
Mur pare feu pas a pas
Authentification ht-access
Surveillance de serveur CACTI
Snort
Snort-inline
Securiser Apache avec mod_security
Filtrage squid/squidguard/dansguardian
Auditer son site web
Sécuriser son linux
Installer un Lamp avec ssl
Contrer les scans de ports
Traitement anti-spam
Installer/Utiliser tripwire
Faire des sauvegardes incrémentales
Rsync
Nessus
Divers
Elisa, le multimédia facile
Utilisation de lilo
Les commandes Linux
Le multi-tache
Le crontab
Exploration de la configuration
Quotas
Messagerie
Installer une application
Debugger ses applications
Le format RPM
Mise a jour du noyau
Qemu
Tour d'horizon des principaux p2p
Récupération du système
Bips d'un pc
Astuces windows
Table Ascii
Lamerland
Conversion de fichiers musicaux
Compiler ses rpms
Graver en ligne de commande
Graver un fichier avi pour un dvd de salon
Liens
hakin9
Secureroot.com
Hackerthreads.org
Defcon
Hackerlounge
Les derniers exploits
Tous les codes sources
Securite sous Linux
Les logiciels libres quotidiens
Ezine divers
Madchat
Textes divers
Archives
 
Traductions LG
Toutes les traductions
Traductions Phrack
Toutes les traductions

Il y a actuellement 2 visiteurs connectés sur le site !

Google

Connexion à distance sécurisée
Connexion a distance securisee

 

Introduction
Se connecter
Authentification par mot de passe
Authentification par clef publique
Exécution d'une commande à distance
Message d'erreur
Transférer des fichiers
De la machine locale à la machine distante
De la machine distante à la machine locale
Utiliser Konqueror pour accéder à des fichiers distants
SSh et les tubes
Tunnels SSH
Changement de port
Changement pour ssh2
Le fichier de configuration du serveur

 

Introduction

Il existe plusieurs protocoles Internet permettant de se connecter à un ordinateur distant : telnet, les r-commandes (rlogin, rsh ou encore rcp), ssh (Secure Shell). Alors que telnet et les r-commandes font circuler les informations en clair sur le réseau, ssh est beaucoup plus sûr :

* le client (par exemple, vous) et le serveur (serveur) s'authentifient mutuellement, ce qui évite que des pirates se fassent passer pour l'un ou pour l'autre * les données échangées sur le réseau par le biais de ssh sont chiffrées, ce qui garantit leur confidentialité

Pour ces deux raisons, nous vous conseillons vivement d'abandonner telnet et rlogin pour adopter ssh. Le piratage, ça n'existe pas que dans les films. Vous pensez peut-être que rien sur votre compte n'intéresse un pirate, et que donc il n'est pas utile de prendre vos précautions. Vous avez tort à deux titres : le pirate peut se servir de votre compte pour attaquer une autre machine... Bonne chance alors pour convaincre la DST que ce n'était pas vous. Ensuite, en vous exposant au danger, vous mettez ensuite en danger les autres . Alors soyez responsables. À savoir : le protocole SSH n'est pas une particularité UNIX. Vous pouvez vous tout aussi bien vous connecter par ssh avec Windows ou Mac OS.

Se connecter

L'utilisation de ssh pour se connecter à une machine est extrêmement simple. Définitions : par machine locale, on entend la machine devant laquelle vous vous trouvez. Dans ce tutorial, on l'appelle machineloc. La machine distante, c'est celle à laquelle vous voulez vous connecter. Dans ce tutorial, on l'appelle machinedist. Par exemple, si vous êtes dans votre thurne et que vous voulez vous connecter au serveur, la machine locale est votre propre ordinateur, la machine distante est serveur.

machineloc ~ $ ssh login@machinedist
On peut aussi utiliser la syntaxe équivalente :
machineloc ~ $ ssh machinedist -l login
Pour indiquer la machine à distance, vous pouvez utiliser aussi bien le nom de la machine (serveur.ens.fr, horus.ens.fr, etc.) que son adresse IP (pour serveur, 129.199.121.1).
Si vous avez le même login sur les deux machines en question, ce n'est pas la peine de le mentionner, tapez simplement :
machineloc ~ $ ssh machinedist
Si c'est la première fois que vous vous connectez par ssh sur cette machine, vous verrez un message tel que celui-ci :
machineloc ~ $ ssh toto@machinedist The authenticity of host 'machinedist' (111.222.333.4)' can't be established. RSA1 key fingerprint is 1z:2y:3x:4w:56:78:98:78:ab:cd:ef:01:23:45:67:89. Are you sure you want to continue connecting (yes/no)?
Ne paniquez pas ! Tout est parfaitement normal, on vérifie qu'il s'agit de la bonne machine. Il suffit de répondre 'yes' pour continuer. ssh vous dira alors :
Warning: Permanently added 'machinedist,111.222.333.4' (RSA1) to the list of known hosts.
Ce qui signifie que ssh ne vous embêtera plus à poser la question. Notez au passage le « RSA1 » entre parenthèses. Il s'agit du type de clef utilisée par la machine distante. Cette information peut vous servir par la suite pour générer une clef.

Authentification par mot de passe

La façon la plus simple de s'identifier est le mot de passe. Par défaut, ssh vous le réclamera.
serveur ~ $ ssh machine.monlabo.fr
toto@machine's password:

Il vous suffit de taper votre mot de passe. Attention, pour des raisons de sécurité (un coup d'½il sur l'écran de son voisin est un mode de piratage basique mais efficace) celui n'apparaître pas à l'écran, vous devrez taper en aveugle. Si vous pensez avoir commis une erreur dans votre mot de passe, faites Ctrl+u et retapez le en entier. Si vous avez tapé correctement votre mot de passe, vous aurez à votre disposition un shell sur la machine distante. Sinon, vous lirez « Permission denied. » et il faudra recommencer.

Authentification par clef publique

Une autre méthode utilise ce qu'on appelle une « clef publique », c'est-à-dire un code qui vous identifie. Si vous suivez la procédure décrite ci-dessous, vous pourrez vous connecter par ssh sur une machine distante sans avoir à taper de mot de passe.
Type de clef

Il existe différentes versions de SSH. Suivant le type de version utilisé sur la machine distante, le type de clef à générer diffère. Cette information vous est donnée par exemple lors de votre première connexion ssh sur cette machine (voir ci-dessus). Si vous ne vous en souvenez plus, sachez que SSH1 utilisegénéralement des clefs RSA1, et SSH2 des clefs DSA. Pour connaître la version de SSH utilisée sur la machine distante, tapez ssh -v sur la machine distante.
À l'ENS, depuis décembre 2003, les ordinateurs utilisent SSH2. Si vous aviez déjà une clef publique pour vous connecter à l'ENS, il vaut mieux en changer. Il vous suffit de générer une nouvelle clef, de type DSA, et de suivre de nouveau la procédure ci-dessous.

serveur ~ $ ssh -v
OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003
Usage: ssh [options] host [command]
Le « SSH protocols 1.5/2.0 » vous indique qu'il s'agit d'un ssh récent qui peut faire du SSH1 ou du SSH2.

Générer la clef
Pour ce faire, commencez par taper la commande ssh-keygen (comme key generator) sur la machine locale (et pas sur la machine à distance).
machineloc ~ $ ssh-keygen
Avec un ssh récent, qui peut faire du SSH1 ou du SSH2, il faut indiquer le type de clef à générer (voir ci-dessus). Par exemple, pour générer une clef DSA (SSH2) :
machineloc ~ $ ssh-keygen -t dsa
Le générateur de clefs va en générer deux, une clef publique et une clef privée. Il va placer la clef privée (sous forme chiffrée) dans un endroit qui, par défaut, est $HOME/.ssh/id_dsa pour SSH2 et $HOME/.ssh/identity pour SSH1 :
machineloc ~ $ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/usr/home/toto/.ssh/id_dsa):

Appuyez sur Enter pour accepter la localisation de la clef (il est plus simple d'accepter la localisation proposée). ssh-keygen vous demande ensuite une « passphrase » (équivalent d'un mot de passe, mais sous forme de phrase). Cette phrase sert à fortifier la clef pour la rendre plus difficilement cassable. À partir de là, deux solutions :
* si vous tapez une phrase, votre connection sera plus sûre, mais vous devrez utiliser ssh-agent pour ne pas avoir à la retaper à chaque fois (voir plus bas)
* vous ne tapez pas de phrase (et appuyez seulement sur Enter), votre connexion sera moins sûre
Que vous tapiez une phrase ou pas, à la fin vous verrez quelque chose comme
Your identification has been saved in /usr/home/toto/.ssh/id_dsa.
Your public key has been saved in /usr/home/toto/.ssh/id_dsa.pub.
The key fingerprint is:
1a:2a:3e:4a:1a:65:1c:89:10:92:9c:5c:1f:75:cc:de
toto@machineloc


Que faire de la clef
Si l'on récapitule, ssh-keygen a généré deux clefs :
* une clef privée (chiffrée si vous avez donné une phrase, non chiffrée sinon) qui est $HOME/.ssh/identity (ou $HOME/.ssh/id_dsa si c'est du SSH2) et qui n'est accessible qu'à vous
* une publique (non chiffrée) qui est $HOME/.ssh/id_dsa.pub (ou $HOME/.ssh/identity.pub si c'est du SSH1) et qui peut être lue par tout le monde
Définition : qu'est-ce que ce « $HOME » ? $HOME est ce qu'on appelle une variable d'environnement, qui sert à indiquer aux programmes quel est votre répertoire personnel (la racine de votre compte). Faites echo $HOME pour savoir quel est le vôtre. Sur serveur, c'est /users/promo/matiere/login. Pour en savoir plus, voir l'article « Concept : arborescence » dans le n°3 du Hublot.
Maintenant, sur la machine distante, allez dans le répertoire .ssh et éditez le fichier authorized_keys : ajoutez à la fin, et sur une seule ligne (attention aux éditeurs qui coupent les lignes) la clef publique (identity.pub pour SSH1 ou id_dsa.pub pour SSH2) que vous venez de générer. Procédez ainsi pour toutes les machines distantes auxquelles vous voulez vous connecter sans avoir à taper votre mot de passe. Et voilà !
Utiliser ssh-agent
Si vous avez opté pour la solution « phrase de passe », bravo, votre connexion est plus sûre. Mais vous devez taper à chaque fois ladite phrase... Solution, utiliser ssh-agent.
D'abord, il faut lancer ssh-agent, qui gère les clefs d'identification. Si vous êtes logué dans une salle informatique de l'ENS avec la config conscrits, pas de problème, ssh-agent est déjà lancé. Si ce n'est pas le cas, il faut le lancer vous-même.
Comme l'agent est disponible dans tous les programmes qui découlent, on le lance au début d'une session. Par exemple, quand vous êtes en mode texte et que vous lancez le serveur X :
machineloc ~ $ ssh-agent startx
Quand vous vous loguez à distance, c'est plutôt :
machinedist ~ $ exec ssh-agent $SHELL
Une fois lancé, l'agent vous suit dans toutes vos connexions à distance, et ainsi il est disponible partout. Il faut donner à l'agent votre clef à gérer en tapant ssh-add. On vous demande alors votre phrase de passe :
machine ~ $ ssh-add
Need passphrase for /home/toto/.ssh/identity (toto@machine)
Enter passphrase:
Identity added: /home/toto/.ssh/identity (toto@machine)

Exécution d'une commande à distance

Vous pouvez également utiliser ssh pour exécuter une commande à distance. Par exemple, vous voulez, de votre machine personnelle, connaître l'heure sur serveur, pour savoir si votre machine est en retard, en avance ou à l'heure.

machineloc ~ $ ssh serveur.ens.fr date Fri Jul 4 12:01:49 MET DST 2003
N'oubliez pas de préciser toto@machine si vos logins sont différents entre les deux machines. Si vous voulez exécuter à distance une commande avec des options, mieux vaut mettre des guillemets. Par exemple, je veux savoir si brick est une station Sun ou un PC, en utilisant la commande uname.
machineloc ~ $ ssh toto@brick.ens.fr "uname -p" i386
La réponse est « i386 », dénomination utilisée pour les PC.

Message d'erreur

Il est possible que vous voyiez un jour le message d'erreur suivant :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle
attack)!
It is also possible that the host key has just been changed.
Please contact your system administrator.

Ce message signifie que la clef ssh (l'identification) de la machine distante a changé. En effet, à chaque fois que vous vous connectez à une machine par ssh, celle-ci présente à votre machine une sorte de carte d'identité, ainsi vous êtes sûr qu'il s'agit bien de la bonne machine et pas d'un pirate. Ou bien la machine a réellement changé de clef ssh (à l'ENS, cela arrive de temps à autres quand le SPI upgrade une machine), ou bien c'est une attaque de pirate. Il vaut mieux écrire au SPI pour savoir ce qu'il en est.

Transférer des fichiers

Il y a d'autres commandes associées à ssh qui vous permettent, de manière tout aussi sûre, de transférer des fichiers d'une machine à une autre. En l'espèce, scp (Secure Copy) a un fonctionnement aussi simple que celui de ssh.
Les explications qui suivent sous pour les sytèmes UNIX. Pour savoir comment faire sous Windows, reportez-vous au tutorial des WinTuteurs sur WinSCP.

De la machine locale à la machine distante.

Pour envoyer des fichiers de votre machine locale à la machine distante, faites :
machineloc ~ $ scp machinedist:

Attention, n'oubliez pas les deux points à la fin. Vous devrez taper votre mot de passe (sauf si vous utilisez l'authentification par clef publique, voir ci-dessus), puis ssh se lancera dans le transfert en vous indiquant sa progression :
machineloc ~ $ scp tagada.txt machinedist: toto@machinedist's password: tagada.txt 100% |***************************************| 2263 00:00
Pour énumérer les fichiers à copier, mettez-les simplement à la suite, séparés par une espace, sans virgule.
Pour transférer un répertoire entier, il faut utiliser l'option -r (comme recursive), sinon ssh vous dira « : not a regular file ».
machineloc ~ $ scp -r machinedist:
Dans ces premiers examples, le(s) fichier(s) sera ou seront copié(s), avec le même nom sur la machine distante, à la racine de votre compte. Nous allons compliquer progressivement les choses. Maintenant, vous voulez changer le nom du fichier en cours de route, renommer tagada.txt en coincoin.txt :
machineloc ~ $ scp tagada.txt machinedist:coincoin.txt
Maintenant, nous allons envoyer notre fichier tagada.txt à un endroit précis sur le compte distant, dans le répertoire $HOME/divers/blagues :
machineloc ~ $ scp tagada.txt machinedist:divers/blagues

De la machine distante à la machine locale

Pour rapatrier des fichiers de la machine distante à votre machine locale, la même syntaxe est utilisée, mais inversée :

machineloc ~ $ scp machinedist:tagada.txt .
Le . (point) à la fin signifie que scp devra mettre le fichier ici, dans le répertoire dans lequel vous vous trouvez actuellement. Évidemment, vous pouvez lui indiquer un autre répertoire :
machineloc ~ $ scp machinedist:tagada.txt divers
Et ainsi de suite, vous pouvez appliquez les mêmes techniques que pour le transfert machine locale -> machine distante, décrites ci-dessus.

Utiliser Konqueror pour accéder à des fichiers distants

Si ssh s'exécute sur une machine distante à laquelle vous devez accéder, vous pouvez réduire énormément la quantité de saisie nécessaire grâce à Konqueror. Pour accéder à un hôte distant de cette manière, utilisez sftp:// dans la barre d'URL de Konqueror. Ajoutez ensuite votre nom d'utilisateur suivi du caractère « @ » et du nom de l'hôte. Voici un exemple :

sftp://willy@10.197.99.55/home/willy

....me permet d'accéder à un ordinateur en local sur mon réseau domestique, tandis que :

sftp://willy@www.linuxgazette.com/

....me permet d'accéder au site de la Gazette Linux.

Après avoir appuyé sur la touche Entrée, vous obtenez une boite de dialogue qui vous demande un nom d'utilisateur et un mot de passe. Comme votre nom d'utilisateur devrait être déjà renseigné, il vous suffit de saisir votre mot de passe pour voir apparaître le contenu de votre répertoire par défaut dans la fenêtre du navigateur.

sftp: n'a rien à voir avec le protocole ftp: : il utilise réellement ssh pour tout ce qui concerne la gestion des répertoires et des fichiers.

Suivant vos permissions sur l'hôte distant, vous pouvez lire, écrire, supprimer et copier des fichiers de cette manière. Cette méthode fonctionne aussi en conjonction avec d'autres fonctionnalités de Konqueror qui ont été abordées dans la Gazette Linux ; par exemple, vous devriez être en mesure de générer des miniatures et des pages web, comme l'explique Hal Stanton dans son article Créer une galerie d'images avec Konqueror, pour autant que vous utilisiez Konqueror comme gestionnaire de fichiers.

Notez que vous pouvez vous servir de la fonction du clic droit de Konqueror telle que Ouvrir avec, ou Enregistrer sous..., mais que si vous ouvrez un document avec un traitement de texte et l'éditez, vous ne pourrez pas l'enregistrer à nouveau dans l'hôte distant depuis le traitement de texte. Dans ce cas, enregistez une copie locale et copiez-la. Néanmoins, vous pouvez faire la copie dans une autre fenêtre ou onglet de Konqueror. En outre, si la connexion ssh expire, une invite pour saisir à nouveau votre mot de passe apparaît lorsque vous effectuez une opération sur les fichiers.

Si cela ne fonctionne pas, voici une liste pour vous dépanner :
1. Veillez à démarrer ssh sur l'hôte auquel vous souhaitez accéder.
2. Vérifiez que vous avez un nom d'utilisateur et un mot de passe valides sur ce système.
3. Vérifiez que le port 22 (le port ssh) est bien ouvert sur tous les pare-feu à traverser pour atteindre l'hôte distant.
4. Notez que sftp: n'étant pas un protocole habituellement enregistré, il est très probable qu'il n'opère pas sur d'autres navigateurs.

SSH et les tubes

Une grande partie de la puissance du shell réside dans l’utilisation des tubes, permettant de relier la sortie d’une commande à l’entrée d’une autre. Le fait de passer par SSH ne rompt pas cette chaîne, et il est ainsi possible de brancher la sortie de commandes locales sur des commandes distantes, et vice-versa. Tout d’abord, il est possible d’utiliser SSH pour exécuter une simple commande sur la machine distante et récupérer sa sortie. Il suffit de passer la commande à exécuter après le nom d’hôte (de préférence entre guillemets pour la protéger) :

moi@machine1$ ssh lui@machine2 «ls»
Password:
Desktop bin monfichier.txt
moi@machine1$


Notez que la connexion est coupée dès que la commande distante est exécutée. Voyons maintenant comment nous pouvons tirer partie de cette forme d’appel à SSH. Un problème récurrent pour bon nombre d’entre nous consiste à faire des sauvegardes de ses données les plus importantes. Par sécurité, il est pertinent de stocker ces données sauvegardées sur une autre machine. En combinant bash et SSH, nous allons rendre cette opération possible en une seule ligne de commande qui pourra facilement être définie comme tâche périodique à l’aide de cron. Lorsque l’on demande à SSH d’exécuter une simple commande distante, cette commande peut être branchée avec une commande locale. SSH redirige en effet son entrée standard vers l’entrée standard de la commande distante, et la sortie standard de la commande distante vers la sienne. Voici la ligne permettant de faire une sauvegarde du répertoire Documents sur machine2 :

$ tar czf - Documents |ssh machine2 «cat >sauvegarde.tar.gz»

Le paramètre - donné à tar lui demande de sortir le flux compressé sur la sortie standard. Ce flux est récupéré par SSH qui le transfère sur machine2 et l’utilise comme entrée standard de cat. Tel qu’il est appelé, cat ne fait que copier son entrée standard vers le fichier sauvegarde.tar.gz. Ainsi, nous avons réalisé une sauvegarde distante et compressée en une seule ligne. On peut également, si la bande passante n’est pas une ressource critique, réaliser la compression côté serveur :

$ tar cf - Documents |ssh machine2 «gzip -c >sauvegarde.tar.gz»

La restauration de cette sauvegarde pourra se faire de la manière suivante :

$ ssh machine2 «cat sauvegarde.tar.gz» |tar xzf

On peut donc faire passer les sorties standards de commandes à travers une connexion SSH. Ce serait dommage de s’arrêter là – on peut en effet y faire passer bien d’autres choses !

Tunnels SSH

Pour ce scénario, nous allons compléter notre schéma réseau : machine1 et machine2 ne sont pas dans le même réseau local, mais appartiennent à deux réseaux différents connectés par internet. machine2 est derrière un pare-feu qui filtre tous les ports à l’exception du port 22 (le port utilisé par SSH). Derrière machine2 se trouve arthur, qui est un serveur POP3 (email). À partir de machine1, nous voudrions bien récupérer nos mails qui se trouvent sur arthur. Il y a plusieurs problèmes ici. Premièrement, arthur n’est pas directement accessible depuis machine1. Seul machine2 a une adresse internet publique, arthur n’étant pas visible de l’extérieur du réseau. Deuxièmement, le pare-feu filtre tous les ports à l’exception du port 22. Or, le serveur POP3 écoute sur le port 110... SSH va nous permettre de nous affranchir de ces contraintes.
L’option -L de SSH permet de créer un tunnel. Sous ce nom se cache le fait d’employer un port de la machine locale pour transporter des données à travers la connexion SSH et les rediriger où l’on veut à partir de la machine distante. Le tunnel est également utilisable en sens inverse. Cette option est très puissante. Dans notre cas, nous voulons nous servir de machine2 comme intermédiaire pour nous connecter à arthur, comme le montre la figure 2. Nous allons ouvrir notre tunnel avec la commande suivante:

$ ssh -L 2500:arthur:110 machine2

Nous demandons à SSH de nous connecter à machine2. Jusque-là tout est normal. Mais en plus, l’option -L demande à rediriger le port local 2500 vers le port 110 de l’hôte arthur. Celui-ci est spécifié du point de vue de machine2 – rappelons qu’arthur n’est même pas visible pour machine1. Le tunnel se fermera avec la session ssh. Du côté du client mail, il suffira de d’indiquer localhost comme serveur de mail, avec le port 2500. Et voilà ! Tant que la connexion SSH restera ouverte, le fait de nous connecter sur le port 2500 de machine1 équivaudra à se connecter sur le port 110 de arthur, et nous pourrons récupérer nos mails à partir de ce dernier, qui transiteront cryptés dans le tunnel SSH.

Changement de port

Par défaut, SSH écoute sur le port 22. Les attaquants ont coutume d'utiliser des scanners pour savoir quelles machines utilisent SSH. Si le port SSH est modifié en un numéro supèrieur à 1024, la plupart des scanners (dont nmap) seront leurés.

Ouvrez le fichier /etc/ssh/sshd_config et changez la ligne
Port 22
Avec le nombre de votre choix et redémarrez le service SSH
service sshd restart

Changer pour le protocole 2

IL existe deux versions de SSH. La version 2 seulement est plus sûre; la version 1 est sujette à des problémes de sécurité incluant les attaques man-in-the-middle et d'insertion. Editez le fichier /etc/ssh/sshd_config et à la ligne

Protocol 2,1

Changez la ligne pour n'avoir que le protocole 2.


Le fichier de configuration du serveur

Il s'agit du fichier sshd_config, et voici expliquées les différentes directives :

Port 22

Port d'écoute du serveur, il est préférable de changer ce port pour des raisons de sécurité et de relancer ensuite le serveur

Protocol 2

C'est le protocole utilisé par SSH2, plus sécurisé que SSH1

hostkey /etc/ssh/ssh_host_rsa_key, permet de préciser les fichiers contenant les clés RSA de la machine

UsePrivilegeSeparation yes ; Permet de sécuriser le focntionnement du serveur, Lorsqu'une connexion arrive, elle sera traitée par une copie du serveur en mémoire, qui ne posséde aucun privilége

KeyRegenerationInterval 3600:

Elle est spécifique à SSH1

ServerKeyBits 766

OPtion inutile pour SSH2, Détermine la taille de la clé de session SSH1

SyslogFacility AUTH

Définit le type de message à mettre dans les journaux système

LoginGraceTime 120

Détermine le nombre de secondes après lequel un utilisateur sera déconnecté s'il n'arrive pas à s'authentifier

PermitRootLogin yes

Autorise root à se connecter, à déconseiller, se connecter plutôt en utilisant en compte normal, puis utiliser sudo

StrictNodes yes

Renforce la sécurité en demandant la vérification des permissions sur les fichiers utilisés par OPENSSH

RSAAuthentification yes

Encore une option pour SSH1, Permet de spécifier que l'authentification par clé RSA est permise

PubKeyAuthentification yes

Même chose mais pour SSH2

IgnoreRhost yes

Ignore les fichiers .rhosts et .shosts

RhostsRSAAuthentification no

Option pour SSH1, qui permet de faire une authentification basée sur les hôtes

HostbaseAuthentification no

Equivalente à la directive précédente pour SSH2

PermitEmptyPasswords no

Interdit l'utilisation de mots de passe vides dans le cas d'une authentification par mot de passe

X11Forwarding yes

Le forwarding X11 permet de faire transiter les données d'une application graphique X au travers de SSH Ainsi, si vous utilisez l'option -X de la commande SSH, (ssh -X utilisateur@machine), la fenêtre apparaitra sur votre écran

X11DisplayOffset 10

Spécifie le premier système d'affichage utilisable par Openssh

PrintNotd no

Permet de spécifier que le contenu du fichier motd ne doit pas être affiché

PrintLastLog yes

Permet d'afficher avec la connexion, la date, l'heure et et la source de la précédente connexion

TCPkeepAlive yes

Permet de conserver les connexions vivantes, en envoyant règulièrement des données pour tester l'état

AcceptEnv LANG LC_*

Permet de préciser quelles variables d'environnement peuvent être copiées du client vers le serveur

UsePam yes

Permet d'utiliser le système centralisé d'authentification

Subsystem sftp /usr/lib/openssh/sftp-server

Cette option permet de mettre en place un serveur sFTP

Sources de l'article


 

Forum
Forum d'entraide
Blog
Le blog
Boutique
La boutique du Geek
Php/Mysql
Formulaire en php
Administrer un serveur Mysql
Session en php
Gerer ses bases mysql
Les bases php
Securiser ses scripts PHP
Controler ses programmes avec RATS
Convertir une base sql en utf8
Astuces php
Le fichier php.ini
Programmation
Python rapide
Tutorial Python
Tutorial Perl
Tutorial Perl complet
Tutoriel ruby
Tutoriel C
Introduction à gawk
Filtres et utilitaires
Find
Programmation Shell
Ecriture de scripts bash
Expressions regulieres
Vi
Introduction a Javascript
Compiler avec gcc
Astuces en Bash
Cracking
Tutoriel Assembleur
Guide du cracking pour débutant
Assembleur
Manual Unpacking
Techniques de Protection
Différentes failles Web
Arp spoofing dans un réseau switché
Les intrusions
Les attaques externes
Defacage
Defacage complet
Buffer overflow
Netcat
Injection sql
Injection sql(suite)
John the Ripper
Spoofer un email
Utiliser google
La faille system
Usurper une identité
Le rooting
Shellcode sous Unix
La faille race condition
La faille xss
La faille xss (2)
Attaques sur un routeur
P2P
Azureus pas-a-pas
News
Lire les news de Linux-pour-lesnuls.com au format RSS
Distros
Gestion des paquets debian
101 commandes debian
Jeu
Webtarot
Graphisme
Effet neon dans GIMP
Effet vapeur dans GIMP
Cours fonctionnalités de GIMP
Redimentionner une image avec GIMP
Redimentionner une photo pour en faire un cadre avec gimp
Morphing avec gimp
Détourer avec gimp
Réduire le poids d'une image avec gimp
Humour
Ensemble
Divers