Authentification par clé publique/privée:
Depuis l'utilisateur sur le serveur (pit@www.chepi.fr), créer une clé publique et une clé privée qui seront placées dans ~/.ssh/
ssh-keygen -t rsa
Mettre une passphrase! Copier le contenu d'id_rsa.pub dans ~/.ssh/authorized_keys (toujours du serveur) et copier id-rsa sur chaque client dans le répertoire ~/.ssh/ de l'utilisateur par lequel on accède au serveur. Faire un chmod 400 sur l'id_rsa, l'authorized_keys et les id_rsa.pub
Pour n'avoir qu'une passphrase à entrer en début de session graphique:
pacman -S keychain x11-ssh-askpass
et ajouter dans ~/.xinitrc:
export SSH_ASKPASS=/usr/lib/ssh/x11-ssh-askpass eval `ssh-agent -s` /usr/bin/ssh-add
Pour changer la passphrase:
ssh-keygen -p
OBSD
Pour générer clé et certificat d'un serveur:
Se placer dans /etc/ssl
./gencrt.sh nomduserveur
- clé privée /etc/ssl/private/nomduserveur.key
- certificat /etc/ssl/certs/nomduserveur.crt
Faire un chmod 400 nomduserveur.key pour que seul root puisse lire la clef
Controle certificat
[root@www ssl]# openssl x509 -noout -text -in /chemin/du/*.crt
Sur le client(r11), il semblerait qu'Obsd lance lui-même “ssh-agent -s”, aucune manip pour n'avoir qu'une passphrase à entrer en début de session n'est nécessaire, autre que l'ajout de id_rsa dans /home/pierre/.ssh/
Pour simplifier encore la demande de connexion depuis pierre@client sur pit@www.chepi.fr, (valable sous Linux et Obsd), on crée dans les /home/pierre/.ssh/ un fichier config:
- /home/pierre/.ssh/config:
Host www Hostname www.chepi.fr User pit
On modifie les droits pour que seul pierre puisse lire le fichier:
chmod 400 /home/pierre/.ssh/config
Letsencrypt
Nous allons proposer en exemple d’obtenir un certificat via letsencrypt.org, une autorité de certification gratuite dont un client est disponible sous OpenBSD nativement : acme-client. Cette démarche est décrite dans la partie concernant httpd car nous en auront besoin pour “communiquer” avec letsencrypt. C’est un service absolument génial tout à fait adapté à l’auto-hébergement. Ces certificats pourront tout aussi bien être utilisés pour un site web qu’un serveur mail ou autre service en ayant besoin.
⚠ Attention : vérifiez que le port 80 est bien ouvert sur votre parefeu (et si vous utilisez un adressage privé, vérifiez vos renvois de ports, beaucoup d’erreurs viennent de là) ! En effet, acme-client doit rendre disponible sur votre serveur des “fichiers secrets” pour obtenir le certificat.
Cet outil va vérifier que vous avez bien accès au domaine pour lequel vous souhaitez un certificat. Il procède ainsi :
Il demande à letsencrypt un fichier unique, une sorte d’empreinte, qui est enregistrée dans /var/www/acme. Ensuite, letsencrypt tente de récupérer ce fichier en allant sur votre site dans le dossier .well-known/acme-challenge pour certifier que c’est bien votre serveur qui a fait la demande. Ce fichier est supprimé aussitôt après. En gros, il demande http://chezmoi.tld/.well-known-acme-challenge/unfichiersecret.
Cependant, votre site web est sans doute enregistré dans /var/www/htdocs/votresite, un autre dossier. Il faut donc rendre disponible le dossier /var/www/acme lorsque letsencrypt cherche à récupérer le fichier en question.
Ajoutez ces quelques lignes dans votre fichier /etc/httpd.conf.
server "chezmoi.tld" {
root "/htdocs/super-site"
listen on * port 80
location "/.well-known/acme-challenge/*" {
root "/acme"
request strip 2
}
}
Quelques explications :
location “/.well-known/acme-challenge/*” { : Lorsqu’une requête est faite pour une adresse ressemblant à http://chezmoi.tld/.well-known/acme-challenge/nimportequoi , alors on applique la configuration qui suit :
root “/acme” : La nouvelle racine, c’est le dossier /acme. Ce dernier est dans le chroot d’httpd, donc il s’agit bien de /var/www/acme.
request strip 2 : On retire de l’URL la partie avec “.well-known/acme-challenge” pour éviter que soit demandé http://chezmoi.tld/acme/.well-known/acme-challenge qui n’a rien à voir.
⚠ Attention, il faut mettre cette portion pour chaque sous-domaine indiqué dans la partie alternative names du fichier de configuration d’acme-client détaillé ci-dessous. Il sera donc plus pratique d’utiliser des instructions include dans la configuration d’httpd comme indiqué dans la partie des astuces pour httpd.
Avant d’utiliser acme-client, nous allons le configurer dans le fichier /etc/acme-client.conf qu’il faudra créer si besoin. Vous pouvez copier l’exemple situé dans /etc/examples/acme-client.conf.
Dans ce dernier fichier, nous allons donc mettre ces lignes :
authority letsencrypt {
api url "https://acme-v02.api.letsencrypt.org/directory"
account key "/etc/acme/letsencrypt-privkey.pem"
}
authority letsencrypt-staging {
api url "https://acme-staging-v02.api.letsencrypt.org/directory"
account key "/etc/acme/letsencrypt-staging-privkey.pem"
}
domain chezmoi.tld {
alternative names { webmail.chezmoi.tld www.chezmoi.tld }
domain key "/etc/ssl/private/chezmoi.tld.key"
domain certificate "/etc/ssl/chezmoi.tld.crt"
domain chain certificate "/etc/ssl/chezmoi.tld-chain.crt"
domain full chain certificate "/etc/ssl/chezmoi.tld-fullchain.pem"
sign with letsencrypt
}
Remplacez les éléments suivants :
chezmoi.tld par votre nom de domaine.
alternative names { … } par les noms de domaines et sous-domaines à certifier.
Adaptez l’emplacement de la clé et du certificat obtenus dans domain key, domain certificate, domain chain certificate et domain full chain certificate. Ce sont ces fichiers que vous préciserez lorsque vous voudrez utiliser ces certificats, le plus important étant le “fullchain”. Ces noms de fichiers sont modifiés dans la partie sur relayd pour tirer profit du fichier “fullchain” justement.
Changez éventuellement le répertoire où se trouve votre site dans challengedir.
Assurez-vous que les dossiers nécessaires sont bien créés (normalement ils le sont déjà):
# mkdir -p -m 700 /etc/ssl/private # mkdir -p -m 755 /var/www/acme
Vérifiez que votre configuration est correcte, une faute de frappe est vite arrivée :
# acme-client -n
Si tout est bon, alors la commande précédente ne renvoie aucun message 😉.
Vous pourrez ensuite générer vos certificats avec cette commande :
# acme-client -v chezmoi.tld
Conseil : La première fois, je vous conseille de tester qu’il n’y a pas d’erreurs dans votre configuration en utilisant sign with letsencrypt-staging dans le fichier /etc/acme-client.conf. Lorsque tout fonctionne comme prévu, vous forcerez l’obtention d’un certificat avec l’option -F après avoir modifié la configuration d’acme-client.
Pour renouveler les certificats, il suffira d’entrer à nouveau la commande précédente.
Je vous invite à ajouter cette ligne dans le fichier /etc/weekly.local pour un renouvellement régulier :
/usr/sbin/acme-client -v chezmoi.tld && /usr/sbin/rcctl reload httpd
L’utilisation de “&&” permet de recharger httpd seulement si les certificats ont été renouvelés. Vous devriez recharger les autres services utilisant ce certificat (dovecot par exemple).
Maintenant, nous allons utiliser notre certificat en activant l’accès https dans la configuration de httpd :
# extrait de /etc/httpd.conf
server "chezmoi.tld" {
listen on * tls port 443
root "/htdocs/monsupersite"
tls {
certificate "/etc/ssl/chezmoi.tld-fullchain.pem"
key "/etc/ssl/private/chezmoi.tld.key"
}
hsts
# n'oubliez pas d'ajouter la configuration
# specifique liee à votre site
location "/.well-known/acme-challenge/*" {
root "/acme"
request strip 2
}
Vous remarquerez que la connexion se fait désormais sur le port 443 (https), qu’il faut ouvrir dans le parefeu et rediriger dans le routeur.
L’option hsts rend l’échange des clés et donc la qualité du chiffrement plus sûrs. Pour un mot en plus, ça ne fait pas de mal.
Afin de diriger les visiteurs qui arriveraient avec l’adresse http://chezmoi.tld vers la version “https” de votre site, on ajoute le bloc suivant :
# extrait de /etc/httpd.conf
server "chezmoi.tld" {
listen on * port 80
block return 301 "https://$SERVER_NAME$REQUEST_URI"
}
Ce dernier morceau est important 😉
Facultatif : enregistrements CAA
Vous pouvez ajouter à votre zone DNS des enregistrements de type CAA. Ce n’est pas obligatoire, mais ça permet de démontrer que vous, le propriétaire de ce domaine, avez autorisé letsencrypt à vous donner un certificat. Ça démontre que le certificat n’est pas là de façon fortuite. Cette étape est une preuve de bonne foi supplémentaire. Dans votre zone, il y aura donc :
@ 300 IN CAA 0 issue "letsencrypt.org"