Ignorer les liens de navigation | |
Quitter l'aperu | |
Guide d'administration système : Services de sécurité |
Partie I Présentation de la sécurité
1. Services de sécurité (présentation)
Partie II Sécurité du système, des fichiers et des périphériques
2. Gestion de la sécurité de la machine (présentation)
3. Contrôle de l'accès aux systèmes (tâches)
4. Contrôle de l'accès aux périphériques (tâches)
5. Utilisation de l'outil de génération de rapports d'audit de base (tâches)
6. Contrôle de l'accès aux fichiers (tâches)
7. Utilisation d'Automated Security Enhancement Tool (Tâches)
Partie III Rôles, profils de droits et privilèges
8. Utilisation des rôles et des privilèges (présentation)
9. Utilisation du contrôle d'accès basé sur les rôles (tâches)
10. Contrôle d'accès basé sur les rôles (référence)
Partie IV Services cryptographiques
13. Structure cryptographique Oracle Solaris (présentation)
14. Structure cryptographique Oracle Solaris (tâches)
15. Structure de gestion des clés Oracle Solaris
Partie V Services d'authentification et communication sécurisée
16. Utilisation des services d'authentification (tâches)
19. Utilisation d'Oracle Solaris Secure Shell (tâches)
20. Oracle Solaris Secure Shell (référence)
Caractéristiques des sessions dans Secure Shell
Authentification et échange de clés dans Secure Shell
Acquisition d'informations d'identification GSS dans Secure Shell
Exécution des commandes et transmission de données dans Secure Shell
Configuration des clients et des serveurs dans Secure Shell
Configuration des clients dans Secure Shell
Configuration du serveur dans Secure Shell
Paramètres spécifiques à l'hôte dans Secure Shell
Secure Shell et les variables d'environnement de connexion
Mise à jour des hôtes connus dans Secure Shell
Packages Secure Shell et initialisation
21. Introduction au service Kerberos
22. Planification du service Kerberos
23. Configuration du service Kerberos (tâches)
24. Messages d'erreur et dépannage de Kerberos
25. Administration des principaux et des stratégies Kerberos (tâches)
26. Utilisation des applications Kerberos (tâches)
27. Service Kerberos (référence)
Partie VII Audit Oracle Solaris
28. Audit Oracle Solaris (présentation)
29. Planification de l'audit Oracle Solaris
30. Gestion de l'audit Oracle Solaris (tâches)
Le démon Secure Shell (sshd) est démarré normalement au moment de l'initialisation lorsque les services réseau sont démarrés. Le démon détecte les connexions des clients. Une session Secure Shell commence lorsque l'utilisateur exécute une commande ssh, scp ou sftp. Un nouveau démon sshd est cloné pour chaque connexion entrante. Le démon cloné gère l'échange de clés, le chiffrement, l'authentification, l'exécution des commandes et l'échange de données avec le client. Ces caractéristiques de session sont déterminées par les fichiers de configuration côté client et côté serveur. Les arguments de la ligne de commande peuvent remplacer les paramètres des fichiers de configuration.
Le client doit s'authentifier auprès du serveur et vice-versa. Après la réussite de l'authentification, l'utilisateur peut exécuter des commandes à distance et copier des données entre les hôtes.
Le comportement côté serveur du démon sshd est contrôlé par les paramètres de mot-clé dans le fichier /etc/ssh/sshd_config. Par exemple, le fichier sshd_config détermine les types d'authentification qui sont autorisés pour l'accès au serveur. Le comportement côté serveur peut également être contrôlé par les options de la ligne de commande lorsque le démon sshd est démarré.
Le comportement côté client est contrôlé par les mots-clés Secure Shell dans l'ordre de priorité suivant :
Options de ligne de commande
Fichier de configuration de l'utilisateur, ~/.ssh/config
Fichier de configuration à l'échelle du système, /etc/ssh/ssh_config
Par exemple, un utilisateur peut remplacer un paramètre Ciphers de configuration à l'échelle du système qui préfère aes128-cen en spécifiant -c aes256-cen,aes128-cen,arcfour sur la ligne de commande. Le premier chiffre, aes256-cen, est désormais préféré.
Les protocoles Secure Shell, v1 et v2, prennent en charge l'authentification de l'utilisateur/hôte client et l'authentification de l'hôte serveur. Les deux protocoles impliquent l'échange de clés cryptographiques de session pour la protection des sessions Secure Shell. Chaque protocole fournit plusieurs méthodes pour l'authentification et l'échange de clés. Certaines de ces méthodes sont facultatives. Secure Shell prend en charge un certain nombre de mécanismes d'authentification client, tel qu'illustré dans le Tableau 19-1. Les serveurs sont authentifiés à l'aide de clés publiques d'hôte connu.
Pour le protocole v1, Secure Shell prend en charge l'authentification de l'utilisateur avec des mots de passe. Le protocole prend également en charge les clés publiques utilisateur et l'authentification avec des clés publiques d'hôte de confiance. L'authentification du serveur est effectuée avec une clé publique d'hôte. Pour le protocole v1, toutes les clés publiques sont des clés RSA. Les échanges de clé de session impliquent l'utilisation d'une clé de serveur éphémère qui est régulièrement regénérée.
Pour le protocole v2, Secure Shell prend en charge l'authentification de l'utilisateur et l'authentification interactive générique, qui implique généralement des mots de passe. Le protocole prend également en charge l'authentification avec des clés publiques utilisateur et des clés publiques d'hôte de confiance. Il peut s'agir de clés RSA ou DSA. Les échanges de clés de session sont des échanges de clés éphémères Diffie-Hellman qui sont signées à l'étape d'authentification du serveur. En outre, Secure Shell peut utiliser des informations d'identification GSS pour l'authentification.
Pour utiliser GSS-API pour l'authentification dans Secure Shell, le serveur doit disposer des informations d'identification de l'accepteur GSS-API et le client doit disposer des informations d'identification de l'initiateur GSS-API. La prise en charge est disponible pour mech_dh et pour mech_krb5.
Pour mech_dh, le serveur dispose des informations d'identification de l'accepteur GSS-API si root a exécuté la commande keylogin.
Pour mech_krb5, le serveur dispose des informations d'identification de GSS-API lorsque l'hôte principal qui correspond au serveur possède une valeur correcte dans /etc/krb5/krb5.keytab.
Le client dispose des informations d'identification de l'initiateur pour mech_dh si l'une des actions ci-après a été effectuée :
La commande keylogin a été exécutée.
Le module pam_dhkeys est utilisé dans le fichier pam.conf.
Le client dispose des informations d'identification de l'initiateur pour mech_krb5 si l'une des actions ci-après a été effectuée :
La commande kinit a été exécutée.
Le module pam_krb5 est utilisé dans le fichier pam.conf.
Pour l'utilisation de mech_dh dans le RPC sécurisé, reportez-vous au Chapitre 16Utilisation des services d'authentification (tâches) . Pour l'utilisation de mech_krb5, reportez-vous au Chapitre 21Introduction au service Kerberos. Pour plus d'informations sur les mécanismes, reportez-vous aux pages de manuel mech(4) et mech_spnego(5).
Une fois l'authentification terminée, l'utilisateur peut utiliser Secure Shell, généralement en demandant un shell ou en exécutant une commande. Par l'intermédiaire des options de commande ssh, l'utilisateur peut effectuer des demandes. Les demandes peuvent inclure l'allocation d'un pseudo-tty, la transmission des connexions X11 ou TCP/IP, ou l'activation d'un programme d'authentification ssh-agent via une connexion sécurisée.
Les composants de base d'une session utilisateur sont les suivants :
L'utilisateur demande un shell ou l'exécution d'une commande, ce qui lance le mode de session.
Dans ce mode, les données sont envoyées ou reçues par le biais du terminal sur le côté client. Sur le côté serveur, les données sont envoyées par l'intermédiaire du shell ou d'une commande.
Lorsque la transmission des données est terminée, le programme utilisateur s'arrête.
L'ensemble de la transmission X11 et de la transmission TCP/IP est arrêté, sauf pour les connexions qui existent déjà. Les connexions X11 et TCP/IP existantes restent ouvertes.
Le serveur envoie un message d'état de sortie au client. Lorsque toutes les connexions sont fermées, telles que les ports transmis qui étaient restés ouverts, le client ferme la connexion au serveur. Ensuite, le client se ferme.