Nous prescrivons une procédure d'accès d'urgence aux hôtes SSH avec des clés matérielles

Nous prescrivons une procédure d'accès d'urgence aux hôtes SSH avec des clés matérielles

Dans cet article, nous développerons une procédure d'accès d'urgence aux hôtes SSH à l'aide de clés de sécurité matérielles hors ligne. Ceci n’est qu’une approche, et vous pouvez l’adapter à vos besoins. Nous stockerons l'autorité de certification SSH de nos hôtes sur la clé de sécurité matérielle. Ce schéma fonctionnera sur presque tous les OpenSSH, y compris SSH avec authentification unique.

A quoi ça sert tout ça ? Eh bien, c'est une option de dernier recours. Il s'agit d'une porte dérobée qui vous permettra d'accéder à votre serveur lorsque, pour une raison quelconque, rien d'autre ne fonctionne.

Pourquoi utiliser des certificats plutôt que des clés publiques/privées pour un accès d'urgence ?

  • Contrairement aux clés publiques, les certificats peuvent avoir une durée de vie très courte. Vous pouvez générer un certificat valable 1 minute voire 5 secondes. Passé ce délai, le certificat deviendra inutilisable pour de nouvelles connexions. C’est idéal pour un accès d’urgence.
  • Vous pouvez créer un certificat pour n'importe quel compte sur vos hôtes et, si nécessaire, envoyer de tels certificats « uniques » à vos collègues.

Ce dont vous avez besoin

  • Clés de sécurité matérielle prenant en charge les clés résidentes.
    Les clés résidentes sont des clés cryptographiques entièrement stockées dans la clé de sécurité. Parfois, ils sont protégés par un code PIN alphanumérique. La partie publique de la clé résidente peut être exportée à partir de la clé de sécurité, éventuellement avec le descripteur de clé privée. Par exemple, les clés USB de la série Yubikey 5 prennent en charge les clés résidentes. Il est conseillé qu'elles soient destinées uniquement à un accès d'urgence à l'hôte. Pour cet article, je n'utiliserai qu'une seule clé, mais vous devriez en avoir une supplémentaire pour la sauvegarde.
  • Un endroit sûr pour stocker ces clés.
  • OpenSSH version 8.2 ou supérieure sur votre ordinateur local et sur les serveurs auxquels vous souhaitez avoir un accès d'urgence. Ubuntu 20.04 est livré avec OpenSSH 8.2.
  • (facultatif, mais recommandé) Un outil CLI pour vérifier les certificats.

Formation

Tout d'abord, vous devez créer une autorité de certification qui sera située sur la clé de sécurité matérielle. Insérez la clé et exécutez :

$ ssh-keygen -t ecdsa-sk -f sk-user-ca -O resident -C [security key ID]

En commentaire (-C) j'ai indiqué [email protected]afin que vous n'oubliiez pas à quelle clé de sécurité appartient cette autorité de certification.

En plus d'ajouter la clé à la Yubikey, deux fichiers seront générés localement :

  1. sk-user-ca, un handle de clé qui fait référence à la clé privée stockée dans la clé de sécurité,
  2. sk-user-ca.pub, qui sera la clé publique de votre autorité de certification.

Mais ne vous inquiétez pas, la Yubikey stocke une autre clé privée qui ne peut pas être récupérée. Par conséquent, tout est fiable ici.

Sur les hôtes, en tant qu'utilisateur root, ajoutez (si ce n'est pas déjà fait) ce qui suit à votre configuration SSHD (/etc/ssh/sshd_config) :

TrustedUserCAKeys /etc/ssh/ca.pub

Ensuite sur l'hôte, ajoutez la clé publique (sk-user-ca.pub) à /etc/ssh/ca.pub

Redémarrez le démon :

# /etc/init.d/ssh restart

Nous pouvons maintenant essayer d'accéder à l'hôte. Mais nous avons d’abord besoin d’un certificat. Créez une paire de clés qui sera associée au certificat :

$ ssh-keygen -t ecdsa -f emergency

Certificats et paires SSH
Il est parfois tentant d’utiliser un certificat en remplacement d’une paire de clés publique/privée. Mais un certificat seul ne suffit pas à authentifier un utilisateur. Chaque certificat est également associé à une clé privée. C'est pourquoi nous devons générer cette bi-clé « d'urgence » avant de nous émettre un certificat. L'important est que nous montrions le certificat signé au serveur, en indiquant la paire de clés pour laquelle nous disposons d'une clé privée.

L’échange de clés publiques est donc toujours bien vivant. Cela fonctionne même avec des certificats. Les certificats éliminent simplement la nécessité pour le serveur de stocker des clés publiques.

Ensuite, créez le certificat lui-même. J'ai besoin de l'autorisation de l'utilisateur Ubuntu toutes les 10 minutes. Vous pouvez le faire à votre manière.

$ ssh-keygen -s sk-user-ca -I test-key -n ubuntu -V -5m:+5m emergency

Il vous sera demandé de signer le certificat en utilisant votre empreinte digitale. Vous pouvez ajouter des noms d'utilisateur supplémentaires séparés par des virgules, par exemple -n ubuntu,carl,ec2-user

Ça y est, vous avez désormais un certificat ! Ensuite, vous devez spécifier les autorisations correctes :

$ chmod 600 emergency-cert.pub

Après cela, vous pouvez visualiser le contenu de votre certificat :

$ step ssh inspect emergency-cert.pub

Voilà à quoi ressemble le mien :

emergency-cert.pub
        Type: [email protected] user certificate
        Public key: ECDSA-CERT SHA256:EJSfzfQv1UK44/LOKhBbuh5oRMqxXGBSr+UAzA7cork
        Signing CA: SK-ECDSA SHA256:kLJ7xfTTPQN0G/IF2cq5TB3EitaV4k3XczcBZcLPQ0E
        Key ID: "test-key"
        Serial: 0
        Valid: from 2020-06-24T16:53:03 to 2020-06-24T17:03:03
        Principals:
                ubuntu
        Critical Options: (none)
        Extensions:
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc

Ici, la clé publique est la clé d'urgence que nous avons créée, et sk-user-ca est associé à l'autorité de certification.

Enfin, nous sommes prêts à exécuter la commande SSH :


$ ssh -i emergency ubuntu@my-hostname
ubuntu@my-hostname:~$

  1. Vous pouvez désormais créer des certificats pour n'importe quel utilisateur sur un hôte qui fait confiance à votre autorité de certification.
  2. Vous pouvez supprimer l'urgence. Vous pouvez enregistrer sk-user-ca, mais ce n'est pas nécessaire car il figure également sur la clé de sécurité. Vous souhaiterez peut-être également supprimer la clé publique PEM d'origine de vos hôtes (par exemple dans ~/.ssh/authorized_keys pour l'utilisateur Ubuntu) si vous l'avez utilisée pour un accès d'urgence.

Accès d'urgence : plan d'action

Collez la clé de sécurité et exécutez la commande :

$ ssh-add -K

Cela ajoutera la clé publique et le descripteur de clé de l'autorité de certification à l'agent SSH.

Exportez maintenant la clé publique pour créer un certificat :

$ ssh-add -L | tail -1 > sk-user-ca.pub

Créez un certificat avec une date d'expiration, par exemple, d'au plus une heure :

$ ssh-keygen -t ecdsa -f emergency
$ ssh-keygen -Us sk-user-ca.pub -I test-key -n [username] -V -5m:+60m emergency
$ chmod 600 emergency-cert.pub

Et maintenant à nouveau SSH :

$ ssh -i emergency username@host

Si votre fichier .ssh/config pose des problèmes lors de la connexion, vous pouvez exécuter ssh avec l'option -F none pour le contourner. Si vous devez envoyer un certificat à un collègue, l'option la plus simple et la plus sécurisée est Trou de ver magique. Pour ce faire, vous n'avez besoin que de deux fichiers - dans notre cas, Emergency et Emergency-cert.pub.

Ce que j'aime dans cette approche, c'est le support matériel. Vous pouvez mettre vos clés de sécurité dans un coffre-fort et elles ne mèneront nulle part.

Comme la publicité

Serveurs épiques - Est VPS pas cher avec des processeurs puissants d'AMD, fréquence de base du processeur jusqu'à 3.4 GHz. La configuration maximale vous permet de résoudre presque tous les problèmes - 128 cœurs de processeur, 512 Go de RAM, 4000 XNUMX Go de NVMe. Rejoignez-nous!

Nous prescrivons une procédure d'accès d'urgence aux hôtes SSH avec des clés matérielles

Source: habr.com

Ajouter un commentaire