Configuration et administration à distance de systèmes dans Trusted Extensions (liste des tâches)

Après l'activation de l'administration à distance et avant la réinitialisation du système distant sur Trusted Extensions, vous pouvez configurer le système à l'aide de la technologie VNC ou du protocole ssh.

Tâche	Description	Voir
Activation de l'administration à distance d'un système Trusted Extensions	Active l'administration des systèmes Trusted Extensions à partir de clients `ssh` spécifiés.	Activation de l'administration à distance sur un système Trusted Extensions distant
Activation de VNC	A partir de n'importe quel client, utilise le serveur Xvnc du système Trusted Extensions distant pour afficher la session multiniveau du serveur sur le client.	Configuration d'un système Trusted Extensions à l'aide de Xvnc pour un accès à distance
Connexion à distance à un système Trusted Extensions	Prend un rôle sur le système distant pour l'administrer.	Connexion et administration d'un système Trusted Extensions distant

Remarque - Consultez votre stratégie de sécurité pour déterminer les méthodes d'administration à distance possibles sur votre site.

Activation de l'administration à distance sur un système Trusted Extensions distant

Dans cette procédure, vous autorisez l'authentification basée sur des hôtes sur un système distant Oracle Solaris avant d'y ajouter la fonction Trusted Extensions. Le système distant est le serveur Shell sécurisé.

Avant de commencer

Le système distant est installé avec Oracle Solaris, et vous pouvez accéder à ce système. Vous devez être dans le rôle root.

Sur les deux systèmes, activez l'authentification basée sur des hôtes.
Pour connaître la procédure, reportez-vous à la section Procédure de configuration de l’authentification basée sur l’hôte pour Secure Shell du manuel Administration d’Oracle Solaris 11.1 : Services de sécurité.

Remarque - N'utilisez pas la commande cat. Copiez et collez la clé publique via une connexion Shell sécurisé. Si votre client Shell sécurisé n'est pas un système Oracle Solaris, suivez les instructions de votre plate-forme permettant de configurer un client Shell sécurisé avec l'authentification basée sur des hôtes.

Une fois cette étape terminée, vous disposez d'un compte d'utilisateur sur les deux systèmes qui est habilité à prendre le rôle root. Les comptes reçoivent un UID, un GID et une assignation de rôle identiques. Vous avez également généré des paires de clé publique ou privée et partagé des clés publiques.
Sur le serveur Shell sécurisé, assouplissez la stratégie ssh afin d'autoriser la connexion à distance pour root.
```
# pfedit /etc/ssh/sshd_config
## Permit remote login by root
PermitRootLogin yes
```
Une étape ultérieure limite la connexion de root à un système et un utilisateur particulier.

Remarque - Etant donné que·l'administrateur prendra le rôle root, vous n'avez pas besoin d'assouplir la stratégie de connexion qui empêche la connexion à distance de root.
Sur le serveur Shell sécurisé, redémarrez le service ssh.
```
# svcadm restart ssh
```
Sur le serveur Shell sécurisé, dans le répertoire personnel de root, indiquez l'hôte et l'utilisateur de l'authentification basée sur des hôtes.
```
# cd
# pfedit .shosts
client-host username
```
Le fichier .shosts autorise username du système client-host à prendre le rôle root sur le serveur, lorsque une clé publique ou privée est partagée.

Sur le serveur Shell sécurisé, assouplissez les deux stratégies PAM.

Copiez /etc/pam.d/other vers /etc/pam.d/other.orig.
```
# cp /etc/pam.d/other /etc/pam.d/other.orig
```

Modifiez l'entrée pam_roles pour permettre la connexion à distance par rôles.

# pfedit /etc/pam.d/other
...
# Default definition for Account management
# Used when service name is not explicitly mentioned for account management
# ...
#account requisite    pam_roles.so.1
# Enable remote role assumption
account requisite    pam_roles.so.1   allow_remote
...

Cette stratégie autorise username du système client-host à prendre un rôle sur le serveur.

Modifiez l'entrée pam_tsol_account pour autoriser les hôtes sans étiquette à contacter le système distant Trusted Extensions.

# pfedit /etc/pam.d/other
# Default definition for Account management
# Used when service name is not explicitly mentioned for account management
# ...
#account requisite    pam_roles.so.1
# Enable remote role assumption
account requisite    pam_roles.so.1   allow_remote
#
account required     pam_unix_account.so.1
#account required     pam_tsol_account.so.1
# Enable unlabeled access to TX system
account required     pam_tsol_account.so.1  allow_unlabeled

Testez la configuration.
1. Ouvrez un nouveau terminal dans le système distant.
2. Dans une fenêtre appartenant à username, sur client-host, prenez le rôle root sur le système distant.
```
% ssh -l root remote-system
```
Une fois le bon fonctionnement de la configuration avéré, activez Trusted Extensions sur le système distant, puis réinitialisez-le.
```
# svcadm enable -s labeld
# /usr/sbin/reboot
```

Exemple 12-1 Affectation d'un type d'hôte CIPSO pour l'administration à distance

Dans cet exemple, l'administrateur utilise un système Trusted Extensions pour configurer un hôte Trusted Extensions distant. Pour ce faire, l'administrateur utilise la commande tncfg sur chaque système distant pour définir le type d'hôte du système homologue.

remote-system # tncfg -t cipso add host=192.168.1.12 Client-host

client-host # tncfg -t cipso add host=192.168.1.22 Remote system

Etant donné qu'un système sans étiquette peut également configurer l'hôte Trusted Extensions distant, l'administrateur conserve l'option allow_unlabeled dans le fichier pam.d/other de l'hôte distant.

Configuration d'un système Trusted Extensions à l'aide de Xvnc pour un accès à distance

La technologie VNC (Virtual Network Computing) connecte un client à un serveur distant et affiche le bureau du serveur distant dans une fenêtre sur le client. Xvnc est la version UNIX de VNC, laquelle est basée sur un serveur X standard. Dans Trusted Extensions, les clients de n'importe quelle plate-forme peuvent se connecter à un serveur Xvnc exécutant Trusted Extensions accéder au serveur Xvnc, puis visualiser et travailler dans un bureau multiniveau.

Pour plus d'informations, reportez-vous aux pages de manuel Xvnc(1) et vncconfig(1).

Avant de commencer

Vous avez installé et configuré Trusted Extensions sur ce système qui sera utilisé en tant que serveur Xvnc. La zone globale de ce système possède une adresse IP fixe, c'est-à-dire qu'elle n'utilise pas le profil de configuration réseau automatique, comme décrit dans la page de manuel netcfg(1M).

Ce système reconnaît les clients VNC par nom d'hôte ou par adresse IP. Plus précisément, le modèle de sécurité admin_low identifie explicitement ou à l'aide d'un caractère générique les systèmes susceptibles d'être des clients VNC de ce serveur. Pour plus d'informations sur la configuration de la connexion sécurisée, reportez-vous à la section Limitation des hôtes pouvant être contactés sur le réseau de confiance.

Si une session GNOME est en cours d'exécution sur la console du futur serveur Xvnc de Trusted Extensions, l'option Desktop Sharing (Partage du bureau) n'est pas activée.

Vous endossez le rôle root dans la zone globale du futur serveur Xvnc de Trusted Extensions.

Chargez ou mettez à jour le logiciel Xvnc.
```
# packagemanager &
```
Dans l'interface graphique du gestionnaire de packages, (Package Manager) recherchez les" vnc" et choisissez parmi les serveurs disponibles. Une première option est le logiciel du serveur TigerVNC X11/VNC.
Si vous ne parvenez pas à ouvrir l'interface graphique, ajouter le compte root local à la liste de contrôle d'accès du serveur X. Exécutez cette commande en tant qu'utilisateur ayant ouvert une session dans le serveur X.
```
% xhost +si:localuser:root
```
Pour plus d'informations, reportez-vous aux pages de manuel xhost(1) et Xsecurity(5).
Activez le protocole X Display Manager Control Protocol.
Modifiez le fichier de configuration personnalisée GNOME Display Manager (gdm). Dans le fichier /etc/gdm/custom.conf, saisissez Enable=true sous le titre [xdmcp],
```
[xdmcp]
Enable=true
```
Dans le fichier /etc/gdm/Xsession, insérez la ligne suivante autour de la ligne 27.
Astuce - Enregistrez une copie du fichier Xsession d'origine avant d'apporter la modification.
```
DISPLAY=unix:$(echo $DISPLAY|sed -e s/::ffff://|cut -d: -f2)
```
Les fichiers à l'Étape 2 et à l'Étape 3 sont marqués avec un attribut de package preserve=true. Pour plus d'informations sur l'effet de cet attribut sur vos fichiers modifiés au cours des mises à niveau et des corrections de package, reportez-vous à la page de manuel pkg(5).
Activez le service du serveur Xvnc.
```
# svcadm enable xvnc-inetd
```
Fermez toutes les sessions GNOME actives sur ce serveur.
```
# svcadm restart gdm
```
Attendez environ une minute que le gestionnaire de bureau redémarre. Il est ensuite possible pour un client VNC de se connecter.
Vérifiez que le logiciel Xvnc est activé.
```
# svcs | grep vnc
```
Sur chaque client VNC de ce serveur Xvnc, installez le logiciel client VNC.
Pour le système client, vous disposez d'un choix de logiciels. Vous pouvez utiliser le logiciel VNC à partir du référentiel Oracle Solaris.
(Facultatif) Effectuez un audit des connexions VNC.
Pour plus d'informations sur les événements d'audit de présélection par système et par utilisateur, reportez-vous à la section Configuration du service d’audit (tâches) du manuel Administration d’Oracle Solaris 11.1 : Services de sécurité.
Pour afficher l'espace de travail du serveur Xvnc sur un client VNC, effectuez les opérations suivantes :
1. Dans une fenêtre de terminal du client, connectez-vous au serveur.
```
% /usr/bin/vncviewer Xvnc-server-hostname
```
  Pour les options de commande, reportez-vous à la page de manuel vncviewer(1).
2. Dans la fenêtre qui s'affiche, saisissez votre nom d'utilisateur et votre mot de passe.
  Poursuivez la procédure de connexion. Pour une description des étapes restantes, reportez-vous à la section Connexion à Trusted Extensions du manuel Guide de l’utilisateur Trusted Extensions.

Exemple 12-2 Utilisation de Vino pour partager un bureau dans un environnement de test

Dans cet exemple, deux développeurs utilisent le service GNOME Vino pour partager l'affichage à partir du menu Launch (Lancer)→ System (Système)→ Preferences (Préférences)→ Desktop Sharing (Partage du bureau). En plus de ces étapes, ils assouplissent la stratégie Trusted Extensions en activant l'extension XTEST.

# pfedit /usr/X11/lib/X11/xserver/TrustedExtensionsPolicy
## /usr/X11/lib/X11/xserver/TrustedExtensionsPolicy file
...
#extension XTEST
extension XTEST
...

Connexion et administration d'un système Trusted Extensions distant

Cette procédure vous permet d'utiliser la ligne de commande et l'interface graphique txzonemgr permettant d'administrer un système Trusted Extensions distant.

Avant de commencer

L'utilisateur, le rôle et l'assignation de rôles sont définis de façon identique dans les systèmes locaux et distants, comme décrit dans la section Activation de l'administration à distance sur un système Trusted Extensions distant.

Sur le système du bureau, activez les processus à partir du système distant à afficher.
```
desktop $ xhost + remote-sys
```
Assurez-vous que vous êtes l'utilisateur nommé à l'identique sur les deux systèmes.
A partir d'une fenêtre de terminal, connectez-vous au système distant.
Utilisez la commande ssh pour vous connecter.
```
desktop $ ssh -X -l identical-username remote-sys
Password: Type the user's password
remote-sys $
```
L'option -X permet d'afficher les interfaces graphiques.
Dans la même fenêtre de terminal, prenez le rôle qui est défini à l'identique sur les deux systèmes.
Par exemple, prenez le rôle root.
```
remote-sys $ su - root
Password: Type the root password
```
Vous êtes à présent dans la zone globale. Vous pouvez maintenant utiliser cette fenêtre de terminal pour administrer le système distant à partir de la ligne de commande. Les interfaces graphiques s'affichent sur votre écran. Reportez-vous à l'Exemple 12-3.

Exemple 12-3 Configuration des zones étiquetées sur un système distant

Dans cet exemple, l'administrateur utilise l'interface graphique txzonemgr pour configurer des zones étiquetées sur un système distant étiqueté à partir d'un système de bureau étiqueté. Comme dans Oracle Solaris, l'administrateur autorise le serveur X à accéder au système du bureau à l'aide de l'option -X de la commande ssh. L'utilisateur jandoe est défini à l'identique sur les deux systèmes et peut prendre le rôle remoterole.

TXdesk1 $ xhost + TXnohead4

TXdesk1 $ ssh -X -l jandoe TXnohead4
Password: Ins1PwD1
TXnohead4 $

Pour atteindre la zone globale, l'administrateur utilise le compte jandoe afin de prendre le rôle remoterole. Ce rôle est défini à l'identique sur les deux systèmes.

TXnohead4 # su - remoterole
Password: abcd1EFG

Dans le même terminal, l'administrateur dans le rôle remoterole démarre l'interface graphique txzonemgr.

TXnohead4 $ /usr/sbin/txzonemgr &

Le gestionnaire de zones étiquetées (Labeled Zone Manager) s'exécute sur le système distant et s'affiche sur le système local.

Exemple 12-4 Connexion à une zone étiquetée distante

L'administrateur souhaite modifier un fichier de configuration sur un système distant sous l'étiquette PUBLIC.

L'administrateur dispose de deux options.

Soit il se connecte à distance à la zone globale, affiche l'espace de travail de la zone globale distante, modifie l'espace de travail sur l'étiquette PUBLIC, puis ouvre une fenêtre de terminal et modifie le fichier.
Soit il se connecte à la zone PUBLIC à l'aide de la commande ssh à partir d'une fenêtre de terminal PUBLIC, puis modifie le fichier.

Notez que si le système distant exécute un démon de service de noms (nscd) pour toutes les zones, et si le système distant utilise le service de noms de fichiers; le mot de passe de la zone PUBLIC distante est le mot de passe qui était en vigueur lors de la dernière réinitialisation de la zone. Si le mot de passe pour la zone PUBLIC distante a été modifié et si la zone n'a pas été réinitialisée après la modification, le mot de passe d'origine permet l'accès.

Erreurs fréquentes

Si l'option -X ne fonctionne pas, l'installation d'un package peut être nécessaire. Le transfert X11 est désactivé lorsque le binaire xauth n'est pas installé. La commande suivante permet de charger le fichier binaire : pkg install pkg:/x11/session/xauth.

Ignorer les liens de navigation
Quitter l'aperu
	Configuration et administration de Trusted Extensions Oracle Solaris 11.1 Information Library (Français)