\documentclass{report}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{textcomp}
\usepackage{geometry}
\geometry{top=15mm, bottom=15mm, left=1cm, right=1cm}
\usepackage[french]{babel}
\usepackage{pslatex}
\usepackage[colorlinks=true,urlcolor=black]{hyperref}
\usepackage{graphicx}
\usepackage{fancyhdr}
\pagestyle{fancy}
\renewcommand{\footrulewidth}{0.4pt}
\fancyfoot[L]{Uubu.fr}
\fancyfoot[R]{jeu. juin 15 09:15:31 CEST 2017}
\lfoot{\Large \textit{Uubu.fr}}
\hypersetup{pdfinfo={
Title={ssh},
Author={Sylvain Girod},
Creator={Bash script from uubu.fr's format version 1},
Producer={Bash script and PDFLaTeX},
Subject={programme de connexion distante},
CreationDate={D:20170615091531},
ModDate={D:20170615091531},
Keywords={ssh;sécurité;openssh}
}}
\begin{document}
 
\begin{center}
{\Huge ssh }
\end{center}
\vspace{1cm}
 
\begin{flushleft}
 
{\large programme de connexion distante}
 
\vspace{10mm}
 
\vspace{1cm}{\huge OPTIONS }
 
\
 
\begin{description} \normalsize
\item[\hspace{1mm} -4]{Force l'utilisation d'IPv4 uniquement}
\item[\hspace{1mm} -6]{Force l'utilisation d'IPv6 uniquement}
\item[\hspace{1mm} -A]{Autorise le forwarding de l'agent d'authentification. Peut être spécifié par hôte dans un fichier de configuration.}
\item[\hspace{1mm} -a]{Désactive le forwarding de l'agent d'authentification}
\item[\hspace{1mm} -b bind\_address]{Utilise l'adresse locale spécifiée pour la connexion}
\item[\hspace{1mm} -C]{Demande la compression des données. Utile pour les connexions lentes, mais ralentit le traffic dans les réseaux rapide}
\item[\hspace{1mm} -c cipher\_spec]{Liste de chiffrements dans l'ordre de préférence pour le chiffrement de la session}
\item[\hspace{1mm} -D \texttt{[}bind\_address:\texttt{]}port]{Spécifie un port forwarding locale dynamique. Cela fonctionne en allouant un socker d'écoute sur le port côté local, optionnellement lié à l'adresse spécifiée. Quand une conexion est faite sur ce port, la connexion est envoyés au canal sécurisé, et le protocole d'application est ainsi utilisé pour déterminer où se connection depuis la machine distante. Actuellement les protocoles SOCKS4 et SOCKS5 sont supportés, et ssh agit comme un serveur SOCKS.}
\item[\hspace{1mm} -E log\_file]{Ajoute les logs débug à log\_file au lieu de l'erreur standard}
\item[\hspace{1mm} -e escape\_char]{Définis le caractère d'échappement pour les sessions avec un pty (défaut: \textasciitilde). Ce caractère est seulement reconnu au début d'une ligne. Ce caractère suivi par un '.' ferme la connexion. Suivi par control-Z suspend la connexion, et suivi par lui-même envoie le caractère échappé une fois.}
\item[\hspace{1mm} -F configfile]{Spécifie un fichier de configuration par utilisateur alternatif. Défaut: \textasciitilde/.ssh/config}
\item[\hspace{1mm} -f]{ssh se place en tâche de fond juste avant l'exécution}
\item[\hspace{1mm} -G]{Affiche sa configuration après avoir évalué Host et Match, puis quitte}
\item[\hspace{1mm} -g]{Autorise les hôte distants à se connecter aux ports forwardés. Si utilisé dans une connexion multiplexée, cette option doit être spécifiée dans le processus maître}
\item[\hspace{1mm} -I pkcs11]{Spécifie la librairie PKCS\#11 utilisé pour communiquer avec un jeton pkcs\#11}
\item[\hspace{1mm} -i identity\_file]{Fichier contenant la clé privée. Défaut: \textasciitilde/.ssh/id\_dsa, \textasciitilde/.ssh-id\_ecdsa, \textasciitilde/.ssh/id\_ed25519, et \textasciitilde/.ssh/id\_rsa.}
\item[\hspace{1mm} -J \texttt{[}user@\texttt{]}host\texttt{[}:port\texttt{]}]{Se connecte à l'hôte spécifié en créant d'abord un saut vers cet hôte, et en établissant un forwarding TCP vers la destination. Plusieurs sauts peuvent être spécifiés séparés par des ','}
\item[\hspace{1mm} -K]{Active l'authentification GSSAPI et le forwarding GSSAPI}
\item[\hspace{1mm} -k]{Désactive le forwarding GSSAPI}
\item[\hspace{1mm} -L \texttt{[}bind\_address:\texttt{]}port:host:hostport]{}
\item[\hspace{1mm} -L \texttt{[}bind\_address:\texttt{]}port:remote\_socket]{}
\item[\hspace{1mm} -L local\_socket:host:hostport]{}
\item[\hspace{1mm} -L local\_socket:remote\_socket]{Spécifie que les connexion au port TCP ou socket unix donné dans l'hôte locla doivent être forwardés à l'hôte:port, ou socket unix donné}
\item[\hspace{1mm} -l login\_name]{Spécifie l'utilisation de connexion sur la machine distante.}
\item[\hspace{1mm} -M]{Place le client ssh en mode master pour le partage de connexion. Peut être spécifié plusieurs fois pour ajouter une confirmation avant que les connexions esclaves soient acceptée}
\item[\hspace{1mm} -m mac\_spec]{Liste d'algorithmes MAC, dans l'ordre de préférence.}
\item[\hspace{1mm} -N]{Ne pas exécuter une commande à distance. Utile pour un simple port forwarding}
\item[\hspace{1mm} -n ]{Redirige stdin depuis /dev/null. Doit être utilisé quand ssh tourne en tâche de fond.}
\item[\hspace{1mm} -O ctl\_cmd]{Contrôle une connexion active multiplexant un processus maître. ctl\_md est interprété et passé au processus maître. (check, forwald, cancel, exit, stop)}
\item[\hspace{1mm} -o option]{Spécifie une option tel que trouvé dans le fichier de configuration}
\item[\hspace{1mm} -p port]{Port de connexion sur l'hôte distant}
\item[\hspace{1mm} -Q query\_option]{Affiche les algorithmes supportés pour sshv2. (cipher, cipher-auth, mac, kex, key, key-cert, key-plain, protocol-version)}
\item[\hspace{1mm} -q]{mode silencieux}
\item[\hspace{1mm} -R \texttt{[}bind\_address:\texttt{]}port:host:hostport]{}
\item[\hspace{1mm} -R \texttt{[}bind\_address:\texttt{]}port:local\_socket]{}
\item[\hspace{1mm} -R remote\_socket:host:hostport]{}
\item[\hspace{1mm} -R remote\_socket:local\_socket]{Spécifie que les connexions au port TCP ou socket unix donné dans l'hôte distant doivent être forwardés à l'hôte:port ou socket unix donné, localement. Cela foncionne en alouant un socket pour écouter soit un port TCP ou un socket unix dans l'hôte distant. Quand une connexion est fait, elle est forwardée dans un canal sécurité, et une connexion est faite à l'hôte:port ou au socket, depuis la machine locale.}
\item[\hspace{1mm} -S ctl\_path]{Spécifie l'emplacement d'un socket de contrôle pour le partage de connexion, ou 'none' pour désactiver le partage de connexion}
\item[\hspace{1mm} -s]{Peut être utilisé pour demander l'invocation d'un sous-système dans le système distant. Les sous-système facilitent l'utilisation de SSH comme transport sécurisé pour d'autres application.}
\item[\hspace{1mm} -T]{Désactive l'allocation d'un pseudo-terminal}
\item[\hspace{1mm} -t]{Force l'allocation d'un pseudo-terminal.}
\item[\hspace{1mm} -v]{mode verbeux}
\item[\hspace{1mm} -W host:port]{Demande que l'entrée et la sortie standard dans le client soient forwardés à l'hôte:port via un canal sécurisé. Implique -N, -T, ExitOnForwardFailure et ClearAllForwarding}
\item[\hspace{1mm} -w local\_tun\texttt{[}:remote\_tun\texttt{]}]{Demande un forwarding avec le tunnel spécifié entre le client et le serveur}
\item[\hspace{1mm} -X]{Active le forwarding X11.}
\item[\hspace{1mm} -x]{Désactive le forwarding X11}
\item[\hspace{1mm} -Y]{Active le forwarding X11 trusté, qui ne sont pas sujets aux extensions de contrôle X11 SECURITY}
\item[\hspace{1mm} -y]{Envoie des informations en utilisant syslog, au lie de stderr}
\end{description}
 
\vspace{1cm}{\huge Authentification }
 
\
 
\hspace{1mm}  Les méthodes disponibles pour l'authentification sont: authentification basée sur GSSAPI, authentification basé sur l'hôte, authentification à clé publique, authentification par challenge-response, et authentification par mot de passe.
\vspace{5mm} \\
 
 
\hspace{1mm}  L'authentification basé sur l'hôte fonctionne comme suit: si la machine sur laquelle l'utilisateur se log est listé dans /etc/hosts.equiv ou /etc/shosts.equiv dans la machine distante, et que les noms d'utilisateur sont les même des 2 côté, ou si les fichiers \textasciitilde/.rhosts ou \textasciitilde.shosts existent dans le répertoire personnel de l'utilisation dans la machine distante et contient une ligne contenant le nom de la machine cliente et le nom de l'utilisation dans cette machine, l'utilisateur est autorisé. Additionnellement, le serveur doit être capable de vérifie la clé hôte du client. Cette méthode d'authentification est peut sécurisé à cause de l'IP spoofing, DNS spoofing, et routing spoofing.
\vspace{5mm} \\
 
 
\hspace{1mm}  L'authentification à clé publique fonctionne comme suit: Le schéma est basé sur la cryptographie à clé publique, en utilisant les cryptosystems où le chiffrement et le déchiffrement sont fait en utilisant des clés séparées, et il est impossible de dériver la clé de déchiffrement depuis la clé de chiffrement. L'idée et que chaque utilisateur créé une paire de clé publique/privée pour l'authentification. Le serveur connaît la clé publique, et seul l'utilisateur connaît la clé privée. ssh supporte les algorithmes DSA, ECDSA, Ed25519 et RSA.
\vspace{5mm} \\
 
 
\hspace{1mm}  Le fichier \textasciitilde/.ssh/authorized\_keys liste les clés publiques qui sont permisses pour le logging. Quand l'utilisateur se log, ssh indique au serveur quel paire de clé utiliser pour l'authentification. Le client prouve qu'il a accès à la clé privéue et le sereur vérifie que la clé correspondante est autorisée à accéder au compte
\vspace{5mm} \\
 
 
\hspace{1mm}  L'utilisateur créé sa paire de clé avec ssh-keygen, stocke la clé privée dans \textasciitilde/.ssh/id\_dsa, /.ssh/id\_ecdsa, \textasciitilde/.ssh/id\_ed25519, ou \textasciitilde/.ssh/id\_rsa. et stocke la clé publique dans \textasciitilde/.ssh/id\_dsa.pub, \textasciitilde/.ssh/id\_ecdsa.pub, \textasciitilde/.ssh/id\_ed25519.pub, ou \textasciitilde/.ssh/id\_rsa.pub. L'utilisateur doit ensuite copier la clé publique dans \textasciitilde/.ssh/authosized\_keys dans le répertoire distant dans la machine distante. Ce fichier correspond au fichier rhosts conventionnel, et a une clé par ligne. Après ça, l'utilisateur peut se connecter sans donner de mot de passe
\vspace{5mm} \\
 
 
\hspace{1mm}  Une variation de l'authentification à clé publique est disponible sous la forme d'une authentification par certificat. Au lieu de définir des clés publique/privées, des certificats signés sont utilisé. La manière la plus simple d'utilisation cette méthode d'authentification est avec un agent d'authentification, comme ssh-agent et optionnellement a directive AddKeysToAgent.
\vspace{5mm} \\
 
 
\hspace{1mm}  L'authentification par challenge-réponse fonctionne comme suit: Le serveur envoie un challenge arbitraire, et demande une réponse. Des examples d'authentification par challenge-réponse incluent l'authentification BSD et PAM.
\vspace{5mm} \\
 
 
\hspace{1mm}  Finallement, si d'autres méthodes d'authentification échouent, ssh demande un mot de passe. Le mot de passe est envoyé à l'hôte distant pour vérification; cependant, vu que toutes les communications sont chiffrées, le mot de passe ne peut pas être vu par quelqu'un qui écoute le réseau.
\vspace{5mm} \\
 
 
\hspace{1mm}  ssh maintient et vérifie automatiquement une base d'identification pour tous les hôte qu'il à vu. Les clés d'hôte sont stockés dans \textasciitilde/.ssh/known\_hosts. De plus, /etc/ssh/ssh\_known\_hosts est automatiquement vérifié pour les hôtes connus. Tout nouvel hôte est automatiquement ajouté au fichier de l'utilisateur. Si l'identification d'un hôte change, ssh alerte et désactive l'authentification par mot de passe. L'option StrictHostKeyChecking peut être utilisée pour contrôler les login sur les machine dont la clé hôte n'est pas connue ou a changé.
\vspace{5mm} \\
 
 
\hspace{1mm}  Quand l'identité d'un utilisateur a été acceptée par le serveur, le serveur exécute soit la commande donnée dans une session non-interactive ou, si aucune commande n'est spécifiée, donne un shell. Toute communication avec la commande distante ou le shell sont automatiquement chiffrés
\vspace{5mm} \\
 
 
\hspace{1mm}  Si un pseudo-terminal a été alloué l'utilisateur peut utiliser les caractèse d'échappement ci-dessous
\vspace{5mm} \\
 
 
\hspace{1mm}  Si aucun pseudo-terminal n'a été alloué, la session est transparent et peut être utilisée pour transférer des données binaire. Dans la plupart des systèmes, définis le caractère d'échappement à none va créer une session transparente même si un tty est utilisé
\vspace{5mm} \\
 
 
\hspace{1mm}  La session se termine quand la commande ou le shell se termine et que toutes les connexions TCP et X11 ont été fermées.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Caractères d'échappement }
 
\
 
\hspace{1mm}  Quand un pseudo-terminal est demandé, ssh supporte certaines fonctions utilisées via un caractère d'échappement:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} \textasciitilde.]{Déconnexion}
\item[\hspace{1mm} \textasciitilde\textasciicircum Z]{mise en tâche de fond}
\item[\hspace{1mm} \textasciitilde\#]{Lister les connexions forwardées}
\item[\hspace{1mm} \textasciitilde\&]{mise en tâche de fond à la déconnexion en attendant que la connexion forwardée/session X11 se termine}
\item[\hspace{1mm} \textasciitilde?]{Affiche la liste des caractères d'échappement}
\item[\hspace{1mm} \textasciitilde B]{Envoie un BREAK au système distant}
\item[\hspace{1mm} \textasciitilde C]{Ouvre une ligne de commande. Actuellement, ajoute le port forwarding en utilisant les options -L, -R, et -D. Permet également d'annuel un port forwarding existant avec -KL[bind\_address:]port, -KR[bind\_address:]port et -KD[bind\_address:]port. !command permet à l'utilisateur d'exécuter une commande locale si PermitLocalCommand est autorisée}
\item[\hspace{1mm} \textasciitilde R]{rekeying de la connexion}
\item[\hspace{1mm} \textasciitilde V]{Diminue la verbosité}
\item[\hspace{1mm} \textasciitilde v]{Augmente la verbosité}
\end{description}
 
\vspace{1cm}{\huge TCP forwarding }
 
\
 
\hspace{1mm}  Le forwarding des connexions TCP via un canal sécurisé peut être spécifié soit sur la ligne de commande ou dans un fichier de configuration. Une application possible est une connexion sécurisé pour un serveur de messagerie.
\vspace{5mm} \\
 
 
\hspace{1mm}  Dans l'exemple ci-dessous, on cherche à chiffrer les communications entre un client IRC et un serveur, même si le serveur IRC ne supporte pas directement le chiffrement des communication. Cela foncion comme suit: l'utilisateur se connecte à l'hôte distant en utilisant ssh, en spécifiant un port à utiliser pour forwarder les connexions au serveur distant. Après ça, il est possible de démarrer le service qui est chiffré dans la machine client, en se connectant au même port local, et ssh chiffre et forward la connexion.
\vspace{5mm} \\
 
 
\hspace{1mm} L'exemple suivante tunnelise une session IRC depuis la machine cliente 127.0.0.1 sur le serveur distant server.example.com: \\
\hspace{1mm} \textbf{ssh -f -L 1234:localhost:6667 server.example.com sleep 10} \\
\hspace{1mm} \textbf{irc -c '\#users' -p 1234 pinky 127.0.0.1} \\
 
\hspace{1mm}  Cela tunnélise une connexion au serveur IRC server.example.com, en joignant le canal \#users, avec le pseudo pinky sur le port 1234. Le port n'est pas important du moment qu'il est supérieur à 1023, et qu'il n'est pas en conflit avec un port déjà utilisé. La connexion est redirigée au port 6667 sur le serveur distant.
\vspace{5mm} \\
 
 
\hspace{1mm}  L'option -f met ssh en tâche de fond et la comande distant sleep 10 est spécifiée pour permettre de démarrer le service tunnélisé.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge X11 Forwarding }
 
\
 
\hspace{1mm}  Si la variable ForwardX11 est à yes, et que l'utilisateur utilis X11 (la variable DISPLAY doit être définie), la connexion à l'affichage X11 est automatiquement forwardée dans le canal chiffré, et la connexion au vrai serveur X est faite depuis la machine locale.
\vspace{5mm} \\
 
 
\hspace{1mm}  La valeur DISPLAY définie pas ssh va pointer vers le serveur, mais avec un numéro d'affichage supérieur à 0. C'est normal parce que ssh créé un serveur X proxy sur la machine serveur pour forwarder les connexions.
\vspace{5mm} \\
 
 
\hspace{1mm}  ssh définis également autematiquement Xauthority sur le serveur. Il génère un cookie d'autorisation aléatoire, le stocke dans Xauthority et vérifie que toutes les connexions forwardée connaissent ce cookie et le remplace par le vrai cookie quand la connexion est ouverte. Le vrai cookie d'authentification n'est jamais envoyé au serveur.
\vspace{5mm} \\
 
 
\hspace{1mm}  Si la variable ForwardAgent est à yes, et que l'utilisateur utilise un agent d'authentification, la connexion à l'agent est automatiquement forwardée au serveur.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Vérifier les clés hôte }
 
\
 
\hspace{1mm} En se connectant à un serveur pour la première fois, une empreinte de la clé publique est présentée à l'utilisateur (sauf si StrictHostKeyChecking a été désactivé). Les empreintes peuvent être déterminés par ssh-keygen: \\
\hspace{1mm} \textbf{ssh-keygen -l -f /etc/ssh/ssh\_host\_rsa\_key} \\
 
\hspace{1mm}  Si l'empreinte est déjà connue, elle est matchée et la clé peut être acceptée ou rejetée. Si seul les empreintes MD5 sont disponibles, ssh-keygen -E peut être utilisé pour adapter l'algorithme de l'empreinte.
\vspace{5mm} \\
 
 
\hspace{1mm}  Vu qu'il est difficile de comparer des clé hôte en regardant simplement les empreintes, il y a également un support pour comparer les clé hôte visuellement, en utilisant un moyen aléatoire. Avec VisualHostKey à yes, un petit graphique ASCII est affiché à chaque login au serveur. En apprenant le motif qu'un serveur connu produit, un utilisateur peut facilement voir qu'une clé a changé quand un motif complètement différent est affiché. Ces motifs pouvant être ambigûes, un motif qui semble être similaire ne donne qu'une bonne probabilité que la clé hôte soit la même, sans garantie.
\vspace{5mm} \\
 
 
\hspace{1mm} Pour obtenir une liste des empreintes avec leur motif aléatoire: \\
\hspace{1mm} \textbf{ssh-keygen -lv -f \textasciitilde/.ssh/known\_hosts} \\
 
\hspace{1mm}  Si l'empreinte est inconnue, une méthode alternative de vérification est disponible: les empeintes SSH vérifiés par DNS. Un enregistrement de ressource (RR), SSHFP, est ajouté à un fichier de zone et le client est capable de matche l'empreinte avec la clé présentée.
\vspace{5mm} \\
 
 
\hspace{1mm} Dans cet exemple, un client se connecte au serveur, host.example.com. Le RR SSHFP doit être présent dans le fichier de zone: \\
\hspace{1mm} \textbf{ssh-keygen -r host.example.com} \\
\hspace{1mm} Les lignes affichées sont ajoutées dans la zone. Pour vérifier que la zone réponde à la demande d'empreinte: \\
\hspace{1mm} \textbf{dig -t SSHFP host.example.com} \\
\hspace{1mm} Finalement le client se connecte \\
\hspace{1mm} \textbf{ssh -o "VerifyHostKeyDNS ask" host.example.com} \\
\hspace{1mm} Voir l'option VerifyHostKeyDNS \\
 
\vspace{1cm}{\huge VPN basés sur SSH }
 
\
 
\hspace{1mm}  ssh support les tunnels VPN en utilisant les périphériques tun, permetant à 2 réseaux d'être joint de manière sécurisé. L'option PermitTunnel contrôle si le serveur le supporte et quel niveau.
\vspace{5mm} \\
 
 
\hspace{1mm} L'exemple suivant connecte un réseaux client 10.0.50.0/24 avec un réseau distant 10.0.99.0/24 en utilisant une connection point-à-point de 10.1.1.1 vers 10.1.1.2, le serveur ssh dans la gateway vers le réseau distant 192.168.1.15, l'autorise. Dans le client: \\
\hspace{1mm} \textbf{ssh -f -w 0:1 192.168.1.15 true} \\
\hspace{1mm} \textbf{ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252} \\
\hspace{1mm} \textbf{route add 10.0.99.0/24 10.1.1.2} \\
\hspace{1mm} Dans le serveur: \\
\hspace{1mm} \textbf{ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252} \\
\hspace{1mm} \textbf{route add 10.0.50.0/24 10.1.1.1} \\
\hspace{1mm} L'accès client peut être personnalisé plus finement via /root/.ssh/authorized\_keys et l'option serveur PermitRootLogin. L'entrée suivante permet les connexions dans tun1 par l'utilisateur jane, et dans tun2 par john, si PermitRootLogin est à forced-commands-only: \\
\hspace{1mm} \textbf{tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane} \\
\hspace{1mm} \textbf{tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john} \\
 
\vspace{1cm}{\huge Variables d'environnement }
 
\
 
\hspace{1mm}  ssh définis les variables d'environnement suivants:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} DISPLAY]{Emplacement du serveur X11, automatiquement définis par ssh}
\item[\hspace{1mm} HOME]{Répertoire personnel de l'utilisateur}
\item[\hspace{1mm} LOGNAME]{Nom de l'utilisateur}
\item[\hspace{1mm} MAIL]{Emplacement de la boite mail de l'utilisateur}
\item[\hspace{1mm} PATH]{PATH par défaut, tel que spécifié à la compilation de ssh}
\item[\hspace{1mm} SSH\_ASKPASS]{Si définis, exécute le programme spécifié et ouvre une fenêtre X11 pour lire la passphrase}
\item[\hspace{1mm} SSH\_AUTH\_SOCK]{Identifie le chemin d'un socket UNIX utilisé pour communiquer avec l'agent}
\item[\hspace{1mm} SSH\_CONNECTION]{Identifie le client et le serveur de la connexion. Contient 4 valeurs: IP, port client, IP, port serveur.}
\item[\hspace{1mm} SSH\_ORIGINAL\_COMMAND]{Contient la ligne de commande originale si une commande forcée est exécutée.}
\item[\hspace{1mm} SSH\_TTY]{Définis le nom du tty associé avec le shell ou la commande courante}
\item[\hspace{1mm} TZ]{Affecte le timezone utilisé}
\item[\hspace{1mm} USER]{nom de l'utilisateur}
\end{description}
 
\hspace{1mm}  Additionnellement, ssh lit \textasciitilde/.ssh/environment, voir PermitUserEnvironment
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Fichiers }
 
\
 
\begin{description} \normalsize
\item[\hspace{1mm} \textasciitilde/.rhosts]{Utilisé pour l'authentification basé sur l'hôte}
\item[\hspace{1mm} \textasciitilde/.shosts]{idem .rhosts, mais sans login permit avec rlogin/rsh}
\item[\hspace{1mm} \textasciitilde/.ssh/]{Répertoire de configuration par défaut pour le utilisateurs}
\item[\hspace{1mm} \textasciitilde/.ssh/authorized\_keys]{Liste des clés publiques qui peuvent être utilisé pour se connecter avec cet utilisateur.}
\item[\hspace{1mm} \textasciitilde/.ssh/config]{Fichier de configuration de l'utilisateur}
\item[\hspace{1mm} \textasciitilde/.ssh/environment]{Contient des définitions additionnels pour les variables d'environnement}
\item[\hspace{1mm} \textasciitilde/.ssh/id\_dsa]{}
\item[\hspace{1mm} \textasciitilde/.ssh/id\_ecdsa]{}
\item[\hspace{1mm} \textasciitilde/.ssh/id\_ed25519]{}
\item[\hspace{1mm} \textasciitilde/.ssh/id\_rsa]{Clé publique pour l'authentification.}
\item[\hspace{1mm} \textasciitilde/.ssh/known\_hosts]{Contient une liste de clés hôte pour tous les hôtes sur lesquels l'utilisateur s'est connecté}
\item[\hspace{1mm} \textasciitilde/.ssh/rc]{Exécuté par ssh quand l'utilisateur se logs, juste avant de lancer le shell ou la commande}
\item[\hspace{1mm} /etc/hosts.equiv]{Fichier pour l'authentification basé sur l'hôte. doit être writable par root uniquement}
\item[\hspace{1mm} /etc/shosts.equiv]{idem sans autoriser rlogin/rsh}
\item[\hspace{1mm} /etc/ssh/ssh\_config]{Fichier de configuration global.}
\item[\hspace{1mm} /etc/ssh/ssh\_host\_key]{}
\item[\hspace{1mm} /etc/ssh/ssh\_host\_dsa\_key]{}
\item[\hspace{1mm} /etc/ssh/ssh\_host\_ecdsa\_key]{}
\item[\hspace{1mm} /etc/ssh/ssh\_host\_ed25519\_key]{}
\item[\hspace{1mm} /etc/ssh/ssh\_host\_rsa\_key]{Contient la clé privée de l'hôte}
\item[\hspace{1mm} /etc/ssh/ssh\_known\_hosts]{Liste globale de clés hôtes connus. Ce fichier devrait être préparé par l'administrateur système}
\item[\hspace{1mm} /etc/ssh/sshrc]{Exécuté par ssh quand l'utilisateur se log, juste avant de lancer le shell ou la commande.}
\end{description}
 
\vspace{1cm}{\huge Code de sortie }
 
\
 
\hspace{1mm}  ssh quitte avec le statut de sortie de la commande distante, ou avec 255 si une erreur s'est produite.
\vspace{5mm} \\
 
\end{flushleft}
\end{document}
