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.

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

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

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

 

 

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é.