Pourquoi vous avez besoin de certificats dans SSH ?

Thu 25 July 2024

Introduction
Les périls des clés privées : pourquoi le partage ou une mauvaise gestion est risqué
Cas d’utilisation : accès SRE et développeur SSH avec Hashicorp Vault
Générer et distribuer un certificat SSH
Comment les développeurs peuvent se connecter avec des certificats signés SSH
- Étape 1 : Demander un certificat : En tant que développeur, je souhaite signer mes clés ssh
- Étape 2 : Connexion SSH : En tant que développeur, je souhaite me connecter sur mes instances via ssh
Conclusion
Liens :

Introduction¶

Lorsque vous travaillez dans le cloud, sécuriser l’accès aux serveurs Linux de production est essentiel car votre charge de travail est confrontée à Internet. Les grandes entreprises jonglent avec les besoins critiques : maintenir un contrôle strict, appliquer un accès granulaire et garantir le plus haut niveau de sécurité.

Les clés SSH traditionnelles, bien qu’elles constituent la pierre angulaire de l’accès à distance, peuvent présenter des défis dans ces domaines. Cet article de blog explique pourquoi les certificats SSH, en combinant la puissance de Vault, offrent une alternative intéressante aux clés SSH traditionnelles.

Nous aborderons les aspects cruciaux de la gestion de l’accès aux environnements de production :

Contrôle centralisé et informations d’identification expirantes : les certificats SSH, émis et gérés par une autorité de certification (CA) centrale, fournissent un point de contrôle unique pour l’accès. Contrairement aux clés SSH statiques, les certificats peuvent avoir une durée de vie définie, garantissant que les informations d’identification compromises sont automatiquement révoquées après expiration.
Banishing Root Login : Les dangers inhérents à la connexion root sont déjà bien documentés. Les certificats SSH vous permettent d’appliquer un accès non root, en promouvant un principe de moindre privilège et en minimisant les dommages potentiels.
Visibilité granulaire et contrôle d’accès : les certificats offrent un niveau granulaire de contrôle d’accès. Vous pouvez définir non seulement qui peut accéder à un serveur, mais aussi quelles commandes ils peuvent exécuter et dans quelles conditions (permit-pty, port-forwarding, …). Ce niveau de détail fournit une piste d’audit claire et minimise la surface d’attaque.

En mettant en œuvre des certificats SSH, les entreprises peuvent gagner un avantage significatif dans la sécurisation de leurs environnements de production.

Les périls des clés privées : pourquoi le partage ou une mauvaise gestion est risqué¶

Il existe plusieurs raisons pour lesquelles les utilisateurs/Administrateurs peuvent conserver leurs clés privées SSH sur leur ordinateur.

C’est indéniablement pratique. Avoir votre clé privée à portée de main permet un accès rapide et facile aux serveurs sans avoir besoin de saisir un mot de passe à chaque fois. Cela peut représenter un gain de temps considérable, en particulier pour ceux qui se connectent fréquemment à plusieurs serveurs.
Certains utilisateurs comprennent mal les implications en matière de sécurité. Ils pourraient croire que tant que leur ordinateur est sécurisé (mots de passe forts, pare-feu, etc.), la clé privée qui y est stockée est également sécurisée.

Mais:

Si votre clé privée tombe entre de mauvaises mains, les attaquants obtiennent un accès complet à n’importe quel serveur auquel vous pouvez accéder avec cette clé. Cela pourrait leur permettre de voler des données, d’installer des logiciels malveillants ou de perturber des opérations critiques.
si vous perdez votre clé privée, vous serez exclu des serveurs auxquels vous devez accéder. Cela peut entraîner des temps d’arrêt et des perturbations importants.

La mise en œuvre et la gestion des certificats SSH, en particulier pour ceux qui ne les connaissent pas, peuvent sembler une étape supplémentaire complexe par rapport à la simplicité d’utilisation d’une clé privée. Cependant, l’utilisation d’outils de fournisseurs cloud tels que AWS SSM Connect ou GCP oslogin peut être une solution. Mais l’utilisation de certificats SSH offre l’avantage d’être nativement compatible multi-cloud, offrant une approche unifiée dans différents environnements cloud.

💡💡💡 ** Nous avons donc besoin d’un outil pour nous aider ** 💡💡💡

Cas d’utilisation : accès SRE et développeur SSH avec Hashicorp Vault¶

Une équipe de développement a besoin d’accéder à un serveur de production à des fins de dépannage et de débogage. L’équipe SRE est responsable de la gestion de l’accès et de la sécurité du serveur.

Générer et distribuer un certificat SSH¶

Prérequis:¶

Une instance Vault
Une compréhension de base des concepts de Vault tels que les “secrets engines”, “policies”, et “roles”.

Activez le “SSH Secrets Engine”:¶

Avant de plonger dans la configuration, il est essentiel de comprendre ce que fait le moteur de secrets SSH. Il fournit un moyen sécurisé de gérer les informations d’identification SSH, offrant des fonctionnalités telles que :

Génération d’informations d’identification SSH dynamiques
Authentification basée sur un certificat
Contrôle d’accès basé sur les rôles
Intégration avec d’autres fonctionnalités de Vault

Pour activer le moteur de secrets SSH, vous utiliserez la CLI Vault. Voici la commande :

vault secrets enable -path=ssh ssh

Cette commande monte le moteur de secrets SSH sur le chemin /ssh. Vous pouvez personnaliser le chemin si nécessaire.

Créer une autorité de certification pour le coffre-fort hashicorp¶

Nous disposons de deux méthodes pour établir une autorité de certification (CA) : l’interface de ligne de commande (CLI) et Terraform.

Pour générer une CA via bash :

vault write ssh/config/ca generate_signing_key=true

Soit pour générer une CA via terraform :

resource "vault_mount" "ssh_signer" {
  path        = "ssh-client-signer"
  type        = "ssh"
  description = "Sign ssh public keys"
}

resource "vault_ssh_secret_backend_ca" "user" {
  backend              = vault_mount.ssh_signer.path
  generate_signing_key = true
}
output "pub_key" {
  value = vault_ssh_secret_backend_ca.user.public_key
}

Ajout d’une autorisation de rôles pour les développeurs dans Hashicorp Vault¶

Pour gérer efficacement l’accès des développeurs aux certificats SSH dans Hashicorp Vault, nous devons configurer les autorisations SSH pour signer les demandes des développeurs.

Avec terraform

resource "vault_ssh_secret_backend_role" "user" {
  name                    = "mgoulin"
  backend                 = vault_mount.ssh_signer.path
  key_type                = "ca"
  allow_user_certificates = true
  default_extensions = {
    "permit-agent-forwarding" = ""
    "permit-pty"              = ""
    "permit-port-forwarding"  = ""
  }
  ttl = "1h"
}

Étape 0 : Injection de l’autorité de certification dans les serveurs AWS, Azure et GCP¶

L’injection de clés publiques SSH dans des instances cloud est une pratique courante pour permettre un accès SSH sécurisé. Voici comment procéder en tant que SRE sur AWS, Azure et GCP.

AWS¶

Ajoutez la clé publique à un objet paire de clés dans le service EC2 à l’aide de la commande aws ec2 import-key-pair.

echo "cert-authority $(vault read -field public_key ssh-client-signer/config/ca)" > /tmp/authorized_keys.txt
aws ec2 import-key-pair --key-name "dev-key" --public-key-material fileb:///tmp/authorized_keys.txt

GCP¶

Ajoutez la clé publique aux métadonnées de l’instance à l’aide de la commande gcloud compute project-info add-metadata.

export USERNAME=dev
echo "$USERNAME:cert-authority $(terraform output -r pub_key)" > /tmp/authorized_keys.txt
cloud compute project-info add-metadata --metadata-from-file=ssh-keys=authorized_keys.txt

Azure¶

Ajoutez la clé publique aux métadonnées de l’instance à l’aide de la commande az sshkey.

echo "cert-authority $(vault read -field public_key ssh-client-signer/config/ca)" > /tmp/authorized_keys.txt
az sshkey create --name "dev-key" --public-key "@/tmp/authorized_keys.txt" --resource-group "myResourceGroup"

Custom OnPrem Instances¶

Ajoutez la clé publique à l’instance en tant que root en ajoutant la ligne suivante au fichier /home/$USERNAME/authorized_keys.

export USERNAME=dev
echo "cert-authority $(vault read -field public_key ssh-client-signer/config/ca)" >> /home/$USERNAME/authorized_keys

Comment les développeurs peuvent se connecter avec des certificats signés SSH¶

Traditionnellement, les connexions SSH reposaient sur des paires de clés publiques et privées pour l’authentification. Bien qu’efficace, cette méthode présente des défis en termes de gestion des clés, de révocation et de contrôle d’accès. Avec Certificate-Authority et HashicorpVautl, les certificats lient l’identité d’un utilisateur à sa clé publique, permettant une authentification plus forte et un contrôle d’accès granulaire.

Avec les certificats SSH, les développeurs peuvent se connecter en toute sécurité aux serveurs distants sans avoir besoin de gérer directement les clés privées. Le processus implique :

Étape 1 : Demander un certificat : En tant que développeur, je souhaite signer mes clés ssh¶

Les développeurs demandent un certificat SSH à une autorité centralisée, souvent via un portail en libre-service ou en appelant l’API Vault.

Cela peut être fait avec la commande vault suivante. Lors de la requête, les développeurs fournissent leur clé publique, généralement stockée sous id_rsa.pub.

vault write -field=signed_key ssh/sign/dev \ 
    public_key=@$HOME/.ssh/id_rsa.pub > signed-cert.pub

Étape 2 : Connexion SSH : En tant que développeur, je souhaite me connecter sur mes instances via ssh¶

Les développeurs utilisent le certificat signé précédemment émis : signed-cert.pub, souvent appelé certificat client, pour s’authentifier auprès du serveur cible. Ce certificat, généralement au format PEM, contient la clé publique du développeur signée par l’autorité de certification (CA) de confiance, qui dans ce cas est Vault.

Lors de la connexion au serveur, le client SSH présente le certificat signé. Le serveur vérifie ensuite l’authenticité et la validité du certificat par rapport à la clé publique de l’autorité de certification. En cas de succès, la connexion est établie et le développeur accède au serveur.

ssh -i ./signed-cert.pub -v -i ~/.ssh/id_rsa dev@<target_server>

Conclusion¶

En adoptant les certificats SSH et en tirant parti d’un outil de gestion de l’autorité de certification centralisée tel que Hashicorp Vault, les organisations peuvent améliorer considérablement leur posture de sécurité SSH. Cette approche offre une solution robuste aux défis posés par la gestion traditionnelle des clés SSH, offrant un contrôle granulaire, une auditabilité améliorée et une gestion rationalisée des accès.

En passant aux certificats SSH, les organisations peuvent atténuer les risques associés aux clés compromises, faciliter la rotation des clés et appliquer des politiques d’accès strictes. Cela conduit finalement à une infrastructure SSH plus sécurisée et efficace.

Même si la mise en œuvre de certificats SSH nécessite une planification et une configuration minutieuses, les avantages à long terme en termes de sécurité et de facilité de gestion dépassent de loin l’investissement initial.

En suivant les directives décrites dans cet article, les organisations peuvent déployer avec succès des certificats SSH et récolter les fruits d’un environnement SSH plus sécurisé et contrôlé.

Cloud Ops Chronicles