SSL/HTTPS

Tunnel SSH vers un ordinateur depuis votre ordinateur

Le tunneling SSH permet bien des choses, dans cet article je vais vous présenter une méthode pour accéder au shell d’un ordinateur situé n’importe où dans le monde (et à condition que les conditions soient réunies pour le faire) depuis votre ordinateur.

Par exemple on a le scénario suivant : vous êtes en télétravail, un autre collègue est en télétravail, vous êtes tous les deux développeurs (cela va de soi), et pour une raison quelconque, vous avez besoin d’accéder à son ordinateur, mais plus précisément à son shell, parce qu’il n’arrive pas à faire une tâche en ligne de commande.

Vous avez plusieurs solutions, dont une qui est de prendre le controle de son ordinateur via un logiciel comme TeamViewer, mais bon, la connexion n’est pas géniale, et c’est overkill pour un terminal.

L’autre solution consiste à ouvrir un tunnel vers son poste grâce à un serveur SSH, puis vous vous connectez à son ordinateur via ce même serveur SSH, voir le dessin ci-dessous.

Principe d’utilisation d’un serveur dédié pour faire du tunneling SSH

D’abord ouvrir un tunnel vers l’ordinateur de votre collègue, cette manipulation sera faite par lui depuis son shell, le port 8080 du serveur sera redirigé vers le port 22 de son ordinateur :

ssh -R 8080:127.0.0.1:22 son_compte@hostname-ou-ip

Ensuite le tunnel étant ouvert entre le serveur SSH et son ordinateur (un serveur SSH est en fait n’importe quel serveur dédié qui a permis l’ouverture du tunnel), vous allez vous connecter au serveur SSH sur le port 8080 (vous vous connectez sur le serveur et non à l’ordinateur de votre collègue hein ?)

ssh://hostname-ou-ip:8080

Vous aurez une invitation à ouvrir un terminal, ensuite le terminal s’ouvre et vous devez entrer le mot de passe du poste de votre collègue. Et voilà !

Les conditions pour que le serveur dédié puisse rediriger la connexion

Améliorer ses connaissances Shell

Un écran de veille Matrix pour votre shell

https://codeburst.io/install-and-setup-cmatrix-on-mac-a2076daee420

Un multiplexeur de terminal TMux

Tmux vous permet d’avoir quelque chose comme ci-dessous sur la photo

C’est un outil bien pratique pour avoir plusieur fenêtre à sa portée sans avoir besoin de switcher entre différentes onglets ou fenêtres

Dans le contexte Tmux pour scroller vous devez faire une combinaison de touche

CTRL-b puis [
https://superuser.com/questions/209437/how-do-i-scroll-in-tmux

Customisez votre prompt pour savoir dans quelle branche Git vous êtes

Grâce à un script qui customise votre prompt, vous saurez votre branche active sans avoir à perdre le temps de faire la commande git branch

https://gist.github.com/justintv/168835

debian

Linux SSH sélectionner une clé publique

Récemment j’ai eu un problème, je n’arrivais pas à faire en sorte de ne pas avoir à me logger à un hôte distant que je me connectais en ssh ou avec rsync.

Un utilisateur peut avoir plusieurs clés SSH

Vous pouvez pour un utilisateur plusieurs clés SSH. Le problème est donc de sélectionner la bonne clé SSH à utiliser. Le problème que j’ai eu était que j’avais généré une seconde clé SSH pour l’utilisateur root sans savoir qu’il en avait déjà une. Comme j’avais besoin d’avoir un accès sur un autre serveur sans avoir à m’authentifier (pour faire du Rsync ou du ssh par exemple).  J’ai vais déposé la clé publique que je venais de généré, mais l’authentification était quand même demandé ! Grâce à l’étude d’un service qui marchait, j’ai pu constater que a clé n’était pas la même.

Il existe un fichier de configuration pour une utilisation avancée

 

Ne regardant de nouveau dans le répertoire j’ai vu qu’il y avait deux fichiers avec l’extension .pub, donc deux clés. Il y avait aussi un fichier config (droit 644), qui est le fichier de configuration des clé. Ce fichier vous permet de spécifier quelle clé utiliser pour quel hôte.

Host myshortname realname.example.com
    HostName realname.example.com
    IdentityFile ~/.ssh/realname_rsa # la clé privée
    User remoteusername

Host myother realname2.example.org
    HostName realname2.example.org
    IdentityFile ~/.ssh/realname2_rsa
    User remoteusername

Mais on peut tout simplement avoir seulement la directive IdentityFile

IdentityFile /root/.ssh/id_ns666817

où id_ns666817 est la clé privée. C’est ce cas de figure que j’ai eu, et explique pourquoi il n’y avait qu’une clé SSH qui était opérationnelle.

Plus d’info : Question sur StackOverflow

 

 

Mettre en place un certificat SSL pour avoir https

Sécuriser son site web avec SSL

Vous voulez avoir un site web plus sécurisé ? vous espérez avec ça que votre site soit mieux classé? Il faut mettre en place un certificat SSL !

Je ne peux vous garantir la requête numéro une mais il est clair que votre site sera plus sécurisé. Il y a bien d’autres aspects que le paraitre plus sécurisé,  comme le fait de vouloir mettre en place le moyen de paiement Stripe, qui exige que votre site soit sécurisé SSL.

il y a plusieurs niveaux de certificat SSL

Pour faire simple il y en a 3, pas au même prix bien sûr.

Certificat à validation de domaine

pour un nom de domaine, installation rapide, Niveau d’entrée.

Certificat à validation d’organisation

Délivré lorsque votre société est enregistré à la chambr de commerce, donc c’est plutôt destiné aux entreprise, les individuels ne sont pas concernés.

Certificat à validation étendue : le must mais le plus cher

prend 5 à 8 jours, contrôle de l’existence de l’entreprise à la chambre de commerce,contrôle Whois, 2 validations téléphonique (service administratif et service du personnel, c’est le seul certificat qui vous permet la belle barre verte (exemole : mozilla, paypal)

SSL EV

Procédure de mise en place d’un certificat SSL pour votre site web.

La validité d’un certificat SSL est en général de 1 an, mais vous pouvez renouveler pour des durée différente. Par exemple Let’sEncrypt (fournisseur de certificats SSL de niveau Domaine) fournit des certificat qui expirent au bout de 90 jours.

Ce qui suit suppose que vous ayez un accès SSH sur votre serveur.

Créez sur un CSR certificate Signing Request).

 

Avant qu vous puissiez acheter un certificat SSL, il vous faut créer un CSR pour votre serveur. C’est la clé privée qui va être générée et porte l’extension KEY, et aussi une requête de certificat que vous allez envoyer au vendeur de certificat SSL.

Que contient le CSR : c’est un fichier encodé qui contient les informations sur le type de chiffrage,ce fichier vous allez l’envoyer chez le vendeur de certificat SSL, qui après paiement va vous envoyer un jeu de fichier qui sont des clé d’encryption.

On crée un CSR par certificat SSL.

Commande pour générer un CSR :

openssl req -newkey rsa:2048 -nodes -sha256 -keyout www.votre-domaine.fr.key -out www.votre-domaine.fr.csr

Il faut répondre à quelques questions :

Country Name : code ISO, pour la France c’est FR, c’est l’adresse du siège de l’entreprise qui décide du code, pas l’extension de domaine

State or Province Name : Département pour la France

Locality Name : Ville

Organization Name : Nom de l’entreprise ou votre Nom si pour site personnel

Organization Unit Name : Département (Informatique, Marketing etc)

Common Name : (server host name) www.monsite.com

Challenge password : Ne rentrer rien pas de mot de passe

Optional Company Name : ne rien mettre sauf si besoin

B/ Installez les certificats SSL d’encryption

Prérequis : activer le module SSL d’Apache si ce n’est déjà fait, pour ce faire allez dans le fichier de configuration httpd.conf, cherchez la section LoadModule, décomemnter au besoin. Une méthode alternative est une commande shell :

$ a2enmod ssl

Les certificats SSL sont simplement des fichiers texte, avec une longue chaine de caractères. Elles peuvent avoir l’extension cer. Il y en a trois, un certificat SSL racine, un certificat SSL intermédiaire, et un certificat pour votre domaine.

Ensuite, il faut éditer votre fichier de configuration de serveur virtuel, sous Apache sous Debian, c’est httpd.conf qui doit inclure entre autre les fichiers default.conf et defaultSSL.conf, ces deux derniers fichiers doivent contenir les mêmes vhost (virtual host ou serveur virtuel), à la différence que dans defaultSSL.conf, ce sont les vhost qui écoutent sur les port 443, qui est de facto les port d’écoute des requêtes https.

Dans un premier temps vous allez recopier les vhost de default.conf vers defautlSSL.conf, et remplacer le port 80 par le port 443.

Apache doit écouter le prot 443, la directive se trouve dans httpd.conf :

Listen 443

Ensuite après la balise ouvrante VirtualHost, ajoutez les lignes suivantes :

# Activation du SSL
SSLEngine On

# Activation de tous les protocoles sécurisés (TLS v1.0, TLS v1.1 et TLS v1.2) tout en désactivant les protocoles non sécurisés (SSL v2 et v3)
SSLProtocol All -SSLv3 -SSLv2

# On active les méthodes de chiffrement, et on désactive les méthodes de chiffrement non sécurisés (par la présente d'un !)
SSLCipherSuite HIGH:!aNULL:!MD5:!ADH:!RC4:!DH

# Le navigateur devra choisir une méthode de chiffrement en respectant l'ordre indiquée dans SSLCipherSuite
SSLHonorCipherOrder on

# Chemin vers le certificat SSL de votre nom de domaine
SSLCertificateFile "/etc/ssl/www-nom-domaine-fr/www-nom-domaine-fr.cer"

# Chemin vers la clé privée du certificat SSL de votre nom de domaine
SSLCertificateKeyFile "/etc/ssl/www-nom-domaine-fr/www-nom-domaine-fr.key"

# Chemin vers le certificat SSL racine, puis vers le certificat SSL intermédiaire. Attention : L'ordre est important.
SSLCACertificateFile "/etc/ssl/www-nom-domaine-fr/certificat-racine.cer"
SSLCACertificateFile "/etc/ssl/www-nom-domaine-fr/certificat-intermediaire.cer"

Indiquez le chemin vers les certificats SSL, respectez scrupuleusement l’ordre.

Pour aller plus loin : activer le HSTS

Pour obtenir une note A+ sur le benchmark de SSLLabs il faut activer le HSTS. Pour ce faire il faut activer le module header d’Apache avec la commande suivant ou dans le fichier httpd.conf :

$ a2enmod headers

Testez votre site en SSL !

Installer SSL sur son site n’est que le début, une fois le cerficaton en route, redémarrez le serveur, testez votre site web pour vous assurer que tout va bien. Le problème avec certains sites web est que les liens sont codés en « dur » en http, ceci ne vous offre pas la flexibilité de switcher de http en https. Dans ce cas il vous faudra remplacer un par un les http en https !

certificat let's encrypt

Installer un certificat avec Let’s Encrypt

Installer certbot-auto

Je suis sous Debian 7, et apache 2.2

Obtenir la copie de certbot-auto sur son serveur

$ wget https://dl.eff.org/certbot-auto

Rendre exécutable

$ chmod a+x certbot-auto

Exécutez le script :

$./certbot-auto

Patienter quelques minutes le temps d’installer Python et autre configuration, répondez Yes à la question. Ensuite entrez un email pour recevoir des emails, utile en cas de problème, notification de renouvellement, sécurité.

Ensuite le programme va vous lister les domaines qui sont sur votre serveur dédié, entrez les domaine séparés par une virgule ou espace (les nombres pas les noms de domaine). Le message suivant vous demande de sauvegarder le répertoire où tous les fichiers seront sauvegardés.

 To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address.
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.

Créer un certificat SSL pour un domaine

Pour ajouter un certificat SSL tapez la commande suivante:

./certbot-auto certonly --webroot -w /home/domaine/public_html -d www.domaine.com -d domaine.com -w /home/sousdomaine/public_html -d sous.domaine.com -w /home/autredomaine/public_html -d www.autredomaine.fr

Que fait certbot-auto avec cette commande?

Il va d’abord créer des CSR, et ensuite les fichiers pem qui sont les clé SSL proprement dites. Un fichier de configuration à inclure au format .conf est créé qui contient les directives SSL pour Apache. Le fichier httpd.conf doit inclure ce fichier pour comprendre les certificats SSL.

Contenu du fichier options-ssl-apache.conf :

# Baseline setting to Include for SSL sites

SSLEngine on

# Intermediate configuration, tweak to your needs
SSLProtocol             all -SSLv2 -SSLv3
SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder     on
SSLCompression          off

SSLOptions +StrictRequire

# Add vhost name to log entries:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" vhost_combined
LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common

#CustomLog /var/log/apache2/access.log vhost_combined
#LogLevel warn
#ErrorLog /var/log/apache2/error.log

# Always ensure Cookies have "Secure" set (JAH 2012/1)
#Header edit Set-Cookie (?i)^(.*)(;\s*secure)??((\s*;)?(.*)) "$1; Secure$3$4"

On retrouve les directives qui font fonctionner le SSL :

SSLEngine on

SSLProtocol

SSLCipherSuite

SSLHonorCipherOrder

SSLCompression

SSLOptions

Remarque vous devez avoir activé le module SSL pour Apache avec la commande a2enmod ssl

Les clés au format pem sont dans le sous répertoire live. Il y en a 4, cert.pem, chain.pem (pour Nginx), fullchain.pem (le certificat) et privkey.pem la clé privée (très important à ne pas divulguer). Ces fichiers qu’il ne faut surtout pas déplacer, sont à la base du fonctionnement.

Créer un fichier pour la version https du site

Il faut créer un fichier pour la version SSL (https) de votre site sans quoi ça ne marcherait pas. En gros c’est des lignes de configuration de la même  manière que http, mais englobé dans une directive <IfModule mod_ssl.c>

Voici un exemple

<IfModule mod_ssl.c>
<VirtualHost 163.172.63.51:443>
SuexecUserGroup "#1027" "#1025"
ServerName www.domaine.net

FcgidMaxRequestLen  2000000

DocumentRoot /home/domaine/public_html
ErrorLog /home/domaine/logs/ssl_error_log
CustomLog /home/domaine/logs/ssl_access_log combined
 
<Directory /home/domaine/public_html>
Options -Indexes +IncludesNOEXEC +SymLinksIfOwnerMatch +ExecCGI
allow from all
AllowOverride All Options=ExeCGI,Includes,IncludesNOEXEC,Indexes,Multiviews,SymlinksIfOwnerMatch
AddHandler fcgid-script .php
AddHandler fcgid-script .php5
FCGIWrapper /home/domaine/fcgi-bin/php5.fcgi .php
FCGIWrapper /home/domaine/fcgi-bin/php5.fcgi .php5
AddType application/x-httpd-php .php
Require all granted
</Directory>
SSLCertificateFile /etc/letsencrypt/live/www.domaine.net/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.domaine.net/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/www.domaine.net/chain.pem


</VirtualHost>
</IfModule>

J’ai oublié d’ajouter un sous-domaine comment faire?

Le problème survient lorsque vous vous rendez compte que vous auriez aimé aussi émettre un certificat pour un sous-domaine sub.domaine.com, voire tout simplement domaine.com, en effet Let’s Encrypt n’émet que des certificats pour sous domaine, il n’émet pas un certificat qui gère tous les sous-domaines. Dans le commerce il existe des certificats (wildcard) qui gèrent les sous-domaines, ils sont en général trois fois plus chers que les certificats non wildcards.

Pas de problème, car il suffit d’indiquer les sous-domaines pour lesquels vous voulez un certificat.

Cela se fait avec l’argument expand. (**Voir la nouvelle méthode plus efficace**)

certbot-auto --expand -d existing.com,example.com,newdomain.com

« expand » va dire à certbot de mettre à jour le certificat existant avec un nouveau certificat qui contient les domaines existants et va y ajouter le ou les nouveaux domaines (ou sous domaine). En fait ce que je viens de dire signifie que pour deux domaines distincts, vous pouvez créer deux certificats distincts OU un seul certificat qui va fonctionner pour les deux domaines distinct. Voir la documentation officielle pour ces manipulations.

Vous devez indiquer tous les sous-domaines y compris les sous-domaine déjà pris en compte par le certificat, c’est un peu fastidieux à écrire, sinon vous allez exclure le ou les sous-domaines non énumérés dans la commande.

update : maintenant il y a une meilleure façon de faire plus précise et plus intuitive en utilisant le flag –cert-name

./certbot-auto --cert-name www.domaine.com -d www.domaine.com,blog.domaine.com,support.domaine.com

Vous devez indiquer tous les sous-domaines y compris les sous-domaine déjà pris en compte par le certificat, c’est un peu fastidieux à écrire, sinon vous allez exclure le ou les sous-domaines non énumérés dans la commande.

$ ./certbot-auto --apache certonly --expand -d domaine.com,www.domaine.com
la sortie à l'écran :
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for domaine.com
tls-sni-01 challenge for www.domaine.com
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0003_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0003_csr-certbot.pem

N’oubliez pas de redémarrer Apache en faisant :

service apache2 restart

Comment effacer un certificat?

Effacer un certificat en effaçant simplement les répertoire, mais non en fait ce n’est pas une bonne solution. Il y a une commande exprès pour ça :

certbot-auto delete --cert-name mondomaine.com

La validité des certificats de Lets’Encrypt est seulement de 90 jours, au-delà il vous faut renouveler avec la commande renew. Vous pouvez effacer à la main en utilisant un programme comme WinSCP par exemple.

Nous allons automatiser ce renew pour ne pas l’oublier, avec un crontab.

Le flag -n veut dire qu’on n’est pas en interactif, c’est à dire que le prompt ne va pas vous demander de taper une touche du clavier pour continuer le process, c’est nécessaire quand vous voulez fiare une tache CRON qui va renouveler automatiquement.

Efface un certificat Letsencrypt The Right Way!

Mais avant je vais vous lister une commande pour lister les certificats déjà en place:

Lister les certificats générés

./certbot-auto certificates

Found the following certs:
 Certificate Name: www.domaine.fr
 Domains: www.domaine.fr
 Expiry Date: 2017-12-29 15:11:49+00:00 (VALID: 78 days)
 Certificate Path: /etc/letsencrypt/live/www.domaine.fr/fullchain.pem
 Private Key Path: /etc/letsencrypt/live/www.domaine.fr/privkey.pem
 Certificate Name: www.domaine.com
 Domains: www.domaine.com
 Expiry Date: 2017-12-23 18:28:00+00:00 (VALID: 72 days)
 Certificate Path: /etc/letsencrypt/live/www.domaine.com/fullchain.pem
 Private Key Path: /etc/letsencrypt/live/www.domaine.com/privkey.pem

Cette commande est très utile, elle vous donne la liste des certificats et les jours avant expiration.

$./certbot-auto delete --cert-name www.domaine.com



-------------------------------------------------------------------------------
Deleted all files relating to certificate www.domaine.com.
-------------------------------------------------------------------------------

Supplément : rediriger les anciennes url vers la version sécurisée:

RedirectMatch permanent ^/(.*) https://www.domaine.fr/$1

Vous pouvez mettre cette directive dans le fichier de configuration du virtual host.

Les pièges du certificat SSL

Toujours considérer la version non www

J’insisterai en particulier sur la création pour le sous-domaines sans www. Par exemple www.domaine.com, www est le sous domaine, en vrai le domaine c’est domaine.com.

Donc si vous avez un site www.domaine.com et que vous vouliez rediriger domaine.com vers www.domaine.com, il vous faut aussi intégrer ce sous-domaine dans le certificat. Parce que si vous ne le faites pas, tout requête de domaine.com  va se solder par un avertissement comme quoi le site n’est pas sécurisé et qu’il vous faut confirmer l’exception de sécurité. Cela étant déjà un roblème pour un humaine, imaginez Google !

Non mais j’ai fait une redirection 301 vers le www.domaine.com

Et non ça ne marche pas comme ça ! Quand vous faites une requête HTTP à domaine.com, il doit le résoudre domaine.com avec de faire le redirection, et sans certificat SSL, il ne pourra le résoudre, dans votre redirection 301 tombe à l’eau.

Ok je m’en fiche Google aura une erreur sur ce sous-domaine c’est pas grave

Là encore je suis désolé, dans le cas où vous avez un dédié tournant sous Apache (cas que je connais) avec plusieurs virtual host (donc plusieurs domaines), si le domaine.com est résolu manuellement (forçage SSL), il va pointer sur un autre site, en fait le premier qu’Apache aura trouvé.

Retour en haut