Les capacités de journalisation SSH sont-elles équivalentes à la journalisation su pour l'authentification par clé privée / publique?

Ici au travail, nous avons un compte de connexion partagé non root sur UNIX qui est utilisé pour administrer une application particulière. La stratégie consiste à ne pas autoriser les connexions directes au compte partagé; vous devez vous connecter en tant que vous-même et utiliser la commande "su" pour passer au compte partagé. C'est à des fins de journalisation / sécurité.

J'ai commencé à utiliser l'authentification par clé publique / privée SSH avec un agent pour me permettre d'entrer mon mot de passe une fois par jour et laisser le transfert de l'agent éliminer les invites de mot de passe pour le reste de la journée. C'est vraiment gentil.

Cependant, certains systèmes sont verrouillés, je dois donc vraiment utiliser la commande "su" pour accéder au compte partagé. Arg! Retour à la saisie des mots de passe tout le temps!

Y a-t-il suffisamment d'informations enregistrées avec l'authentification par clé publique / privée SSH pour que je puisse avoir une chance raisonnable de demander un changement de stratégie pour autoriser les connexions à distance à un compte partagé si des clés publiques / privées sont utilisées?

J'ai eu un regard d'administrateur dans / var / log / secure et cela dit simplement qu'une clé publique a été acceptée pour un compte d'utilisateur à partir d'une adresse IP particulière. Il n'a pas indiqué qui était la clé publique, ni la clé privée qui a fait l'authentification.

Il existe de nombreux niveaux de journalisation disponibles via le sshd_configfichier. Consultez la page de manuel et recherchez LogLevel. Le niveau par défaut est, INFOmais il est trivialement facile de le remonter VERBOSEou même l'un des DEBUG#niveaux.

De plus, vous devriez explorer sudocomme alternative à su. Une discussion approfondie des avantages de ce sudoserait une question à part entière. Mais je peux dire qu'avec sudovous, vous pouvez personnaliser la fréquence à laquelle vous devez entrer votre mot de passe, quelles commandes peuvent être exécutées, etc., toutes contrôlables via le fichier de configuration sudoers .

Une autre façon serait de authorized_keyssortir de la portée de l'utilisateur (par exemple pour /etc/ssh/authorized_keys) afin que seuls les administrateurs système contrôlent les clés publiques qui peuvent être utilisées pour se connecter à des comptes donnés.

Nous avions l'habitude de changer la AuthorizedKeysFiledirective en sshd_configquelque chose comme ceci.

AuthorizedKeysFile /etc/ssh/authorized_keys/%u

Ensuite, créez et remplissez un /etc/ssh/authorized_keysrépertoire avec des fichiers pour chaque utilisateur qui est censé pouvoir se connecter, en vous assurant que le rootfichier est lisible / inscriptible uniquement à la racine et que d'autres fichiers sont lisibles par un utilisateur approprié, comme ceci:

-rw-------  1 root root    1,7K 2008-05-14 14:38 root
-rw-r-----  1 root john     224 2008-11-18 13:15 john

Chaque fichier contient un ensemble de clés publiques qui seront autorisées à se connecter à un compte donné. Il est assez courant pour chaque compte d'utilisateur qu'il existe également un groupe respectif.

L'utilisation de clés publiques / privées est une méthode bien meilleure pour contrôler l'accès des utilisateurs distants. Vous n'avez pas à changer le mot de passe tous les mois (vous n'avez pas à le définir non plus), et vous n'avez pas à le changer simplement parce qu'un employé a quitté votre entreprise vient de retirer sa clé publique; et bien sûr, avec les options SSH ( http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8#SSHRC), vous pouvez préciser à quoi et à partir duquel un utilisateur donné peut avoir accès.

L'authentification par clé publique / privée SSH est distincte de l'authentification hôte. Vous n'avez pas de chance ici. Vous pouvez cependant demander que les membres d'un groupe particulier soient autorisés à exécuter certaines commandes d'administration via sudosans mot de passe - comme l'exemple ci-dessous permet aux utilisateurs du secretariesgroupe de gérer les comptes:

# file: /etc/sudoers
...
%secretaries    ALL= NOPASSWD: /usr/bin/adduser, /usr/bin/rmuser   
...