Add: Articles about SSH

config.toml

@@ -309,13 +309,13 @@ title = "Stéphane HUC :: IT Log"
         pre        = ""
         url         = "/sec/GPG"
         weight     = 42
-    #[[languages.fr.menu.main]]
-    #    identifier  = "ssh"
-    #    name        = "SSH"
-    #    parent      = "sec"
-    #    pre        = ""
-    #    url         = "/sec/SSH"
-    #    weight     = 43
+    [[languages.fr.menu.main]]
+        identifier  = "ssh"
+        name        = "SSH"
+        parent      = "sec"
+        pre        = ""
+        url         = "/sec/SSH"
+        weight     = 43
     #[[languages.fr.menu.main]]
     #    identifier  = "secsys"
     #    name        = "Sécurité :: Système"

content/fr/sec/gpg/_index.md

@@ -1,9 +1,10 @@
 ---
 title: "GPG"
 date: 2017-07-23T18:41:14+01:00
+description: "Différents articles autour de GPG : comment l'utiliser proprement, guide pratique de génération et d'usage des clés GPG"
 draft: false
 noindex: true
-tags: []
+tags: ['GPG']
 ---
 
-Différents articles à-propos de GPG.
+Différents articles à-propos de {{< abbr GPG "GNU Privacy Guard" >}}.

content/fr/sec/ssh/_index.md

@@ -0,0 +1,10 @@
+---
+title: "SSH"
+date: 2017-07-23T18:41:14+01:00
+description: "Différents articles autour de SSH : mieux comprendre son fonctionnement, son utilisation, son évolution"
+draft: false
+noindex: true
+tags: ['SSH']
+---
+
+Différents articles à-propos de {{< abbr SSH "Secure SHell" >}}.

content/fr/sec/ssh/chroot-directory-fatal.md

@@ -0,0 +1,53 @@
+---
+title: "SSH : ChrootDirectory fatal: bad ownership or modes for chroot directory"
+date: 2017-07-23T22:17:44+01:00
+draft: false
+tags: ["SSH", "ChrootDirectory", "Erreur"]
+---
+
+## Description
+
+S'il y a bien un mode qui en fait baver, c'est l'option
+**ChrootDirectory** pour le serveur SSH !
+
+En effet, vous avez défini des utilisateurs qui ont le droit d'utiliser
+- *{{< abbr "càd" "c'est-à-dire" >}} de se connecter* - à votre serveur SSH, et mieux, vous gérez cela finement
+par des accès de groupe, mais vous tenez absolument à emprisonner les
+utilisateurs dans leur répertoire privé, et c'est très bien !
+
+Une règle, telle que la suivante devrait permettre d'agir ainsi, dans
+le fichier de config `/etc/ssh/sshd_config` :
+
+{{< code "sec-ssh-chrootdirectory-fatal-match" >}}
+
+{{< note tip >}}
+Bien-sûr, votre prison peut-être définie ailleurs,
+tel que dans le répertoire `$HOME`, par exemple ; dans ces cas, adaptez,
+adaptez, adaptez… <br>
+et vérifiez que votre utilisateur fasse bien
+partie du groupe ssh dédié, que vous aurez précédemment créé -
+*il se nommera certainement autrement que celui nommé dans cet exemple 'sshusers'* :)
+{{< /note >}}
+
+Mais, voilà, à chaque tentative de connexions, le serveur SSH vous jette
+et vous avertit de l'erreur suivante :
+
+{{< blockquote "sec-ssh-chrootdirectory-fatal-blockquote" >}}
+
+Ce qui bloque, ce sont les droits d'accès, vers le répertoire prison !
+
+Il faut {{< color red >}}impérativement que les droits soient attribués à `root`, et
+en accès `0755`{{< /color >}}…
+
+Puis ensuite créer le répertoire utilisateur, et attribuer les droits à l'utilisateur en question
+
+{{< code "sec-ssh-chrootdirectory-fatal-code" >}}
+
+ **Si vous aviez déjà créé les répertoires en question,
+        <span em>vérifiez les droits d'accès et d'appartenances
+        utilisateurs</span> !**
+
+Voilà, à partir de ce moment-là, vous devriez pouvoir réussir enfin la
+connexion ssh.
+
+----

content/fr/sec/ssh/configuration-securisee.md

@@ -0,0 +1,147 @@
+---
+title: "SSH : Configuration Securisee"
+date: 2017-07-27T14:26:58+01:00
+description: "Comment configurer SSH pour une utilisation plus sécurisée, et une génération correcte des clés SSH."
+draft: false
+lastmod: 2020-02-19T16:53:01+01:00
+tags: ["SSH"]
+---
+
+## Description
+
+Après quelques lectures intéressantes, certaines à ce jour dites
+"vieilles", je me fais la même réflexion agissante que d'autres de
+mieux configurer le serveur SSH. <br>
+Cela nécessite <span hi>que votre
+version du serveur OpenSSH soit supérieure à la version 6.5</span> !
+
+## Configuration
+
+Au choix des fichiers de configuration, il faut absolument reconfigurer
+le fichier de configuration de votre serveur `/etc/ssh/sshd_config`, et
+côté client, le plus simple est de modifier votre fichier de
+configuration, dans votre home personnel, `~/.ssh/config`…
+
+----
+
+Bien sûr, hormis le fait de n'utiliser que la version 2 du protocole,
+et de ne pas permettre au compte root de se connecter, de désactiver
+l'authentification par mot de passe, en utilisant l'authentification
+par clés, veillez aux choses ci-dessous :
+
+### HostKey
+
+ **Config serveur : commentez** les déclarations `HostKey` pour
+        <span em>ne garder que celles relatives au chiffrement RSA et
+        ED25519</span>. Puis, toujours sur le serveur, <span hi>recréez
+        de nouvelles clés, selon les chiffrements RSA et ED25519</span>.
+
+`cd /etc/ssh` <br>
+`rm ssh_host_*` <br>
+`ssh-keygen -t ed25519 -f ssh_host_ed25519_key > /dev/null` <br>
+`ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key > /dev/null` <br>
+
+ **Attention** : ne mettez pas de passphrases lors de la
+        génération, sinon le serveur ne sera pas capable de les lire….
+        le fichier `/var/log/auth` vous le dira, de toute façon !
+
+### Sandbox
+
+{{< note warning >}}
+Cette option est <span em>obsolète depuis
+la version 7.5</span> Veillez à ne plus l'utiliser !
+{{< /note >}}
+
+
+### Chiffrements
+
+`Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr`
+
+Si votre serveur est supérieur à la v6.5, n'utilisez QUE les trois premiers chiffrement, les plus sécurisés. <br>
+Néanmoins, sachez que dans certains cas, tels que Filezilla, Putty,
+il vous faudra certainement utiliser le paramétrage des trois derniers.
+
+À vérifier au cas par cas… regardez donc le log d'authentification
+sur votre serveur !
+
+### Échange de clés
+
+`KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256`
+
+### Message Authentication Codes
+
+`MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256`
+
+## Utilisation
+
+{{< note warning >}}
+ **Attention** : {{< color red >}}ne pas utiliser les protocoles de chiffrement DSA, ECDSA{{</color>}},
+        mais **utilisez {{< anchor RSA "nouvelle-clé-RSA" >}} en forçant le nombre de bits** *- de
+        4096 à 16384 -*, **ET en utilisant PKBDF**, ou mieux
+        **utilisez directement {{< anchor ED25519 "nouvelle-clé-ed25519" >}}, avec PKBDF**.
+{{< /note >}}
+
+Les configurations suivantes sont à faire côté client, bien sûr !
+
+### Mettre-à-jour vos clés
+
+`ssh-keygen -o -p -f id_rsa -a 64`
+
+* L'option `-f` spécifie le fichier de clé privée à utiliser.
+* L'option `-o` est celle qui utilise le durcissement PKBDF.
+* et pour finir, l'option `-a` définit le nombre de tours "de moulinettes" que va effectuer la génération.
+
+{{< note info >}}
+Si cette option n'est pas spécifiée, la valeur par défaut est `16`.
+Vous pouvez lui demander `1000` tours, néanmoins pour les paranoïaques
+la valeur de `64` semble préférable ET suffisante.
+{{< /note >}}
+
+### Nouvelles clés
+
+#### Nouvelle clé ED25519
+
+{{< note info >}}
+Il n'est pas nécessaire de spécifier l'usage de l'option `-o` ; en effet,
+la génération des clés Ed25519 utilise toujours ce format par défaut !
+{{< /note >}}
+
+`ssh-keygen -t ed25519 -f fichier_id -a nb_tours`
+
+Tel que, par exemple :
+
+`ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -a 64`
+
+#### Nouvelle clé RSA
+
+`ssh-keygen -t rsa -b nb_bits -f fichier_id -o -a nb_tours`
+
+Tel que, pour l'exemple :
+
+`ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -o -a 64`
+
+## Astuces
+
+Si vous avez paramétré l'option `LoginGraceTime`, pensez à
+**augmenter sa valeur, sinon** vous aurez **le droit à ne pas
+pouvoir vous connecter, sans aucun message d'erreur** dans le log
+d'authentification.
+
+En effet, selon le nombre de tours que vous avez paramétrés pour la
+génération de votre clé, ou sa mise-à-jour, le déchiffrement et la
+réponse du serveur prendra plus de temps, peut-être plus que le temps
+d'ouverture, de la fenêtre de connexion, autorisé.
+
+Je mets à disposition mon [script shell de génération de
+clés](https://git.framasoft.org/hucste/tools/blob/master/mng_key_ssh),
+basé sur lesdites informations…
+
+## Documentations
+
+* Quand [Martin Kleppman a écrit](https://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html) sur le propos d'améliorer la sécurité de ses clés privées SSH…
+* [Pat Regan](http://blog.patshead.com/2013/09/generating-new-more-secure-ssh-keys.html) nous fait un petit rappel historique de comment utiliser PKCS#8 pour en aboutir à la conclusion d'utiliser PKBDF…
+* ou comment [Ted Unangst](http://www.tedunangst.com/flak/post/new-openssh-key-format-and-bcrypt-pbkdf) nous explique comment monter à niveau ses vieilles clés en utilisant PKBDF…
+* Voici une très bonne lecture, sur le propos de [sécuriser son serveur SSH](https://stribika.github.io/2015/01/04/secure-secure-shell.html), en utilisant les bons algorithmes, et autres méthodes d'authentification…
+* Voire le [référentiel de sécurité](https://www.ssi.gouv.fr/uploads/2014/01/NT_OpenSSH.pdf) de l'ANSSI à-propos des recommandations de sécurité autour de SSH. *(cf : https://www.ssi.gouv.fr/administration/guide/recommandations-pour-un-usage-securise-dopenssh/ )*
+
+----

content/fr/sec/ssh/connaitre-protocole-ssh.md

@@ -0,0 +1,160 @@
+---
+title: "SSH : Mieux Connaître le Protocole SSH"
+date: 2017-07-28T14:59:05+01:00
+description: "Apprendre ce qu'est SSH : son protocole, son usage correct au quotidien, ses particularités."
+draft: false
+lastmod: 2020-02-19T15:51:05+01:00
+tags: ["SSH"]
+---
+
+## Installation d'OpenSSH
+
+### Debian & *Buntu
+Sur une Debian GNU/Linux, ou une *Buntu, et autre dérivées :
+`apt install ssh`…
+
+Quelle que soit la distribution Linux utilisé, le fichier de
+configuration se trouve être `/etc/ssh/sshd_config*`.
+
+### OpenBSD
+
+Sur OpenBSD, c'est installé dans le système de base !
+
+## Utilisation de SSH
+
+SSH est très facile à utiliser :
+
+### Connexion à distance vers le serveur
+
+`ssh server.domaine.com` ou `ssh adresse_ip` est la méthode de base.
+
+Dans ce cas, si la connexion se fait, il vous sera demandé votre nom
+d'utilisateur sur ce serveur, et le mot de passe correspondant.
+
+`ssh votre_nom_user@server.domaine.com` ou
+`ssh -l votre_nom_user server.domaine.com` est la manière de spécifier
+explicitement votre nom d'utilisateur.
+
+Dans ce cas, dès la connexion établie, il ne vous sera demandé plus que
+le mot de passe correspondant à votre identifiant utilisateur.
+
+### Exécution de commandes à distance
+
+Il suffit d'établir une connexion avec la commande à lancer : <br>
+`ssh votre_nom_user@server.domaine.com date`
+
+Précisément, cette commande interroge le serveur pour connaître ses date
+et heure.
+
+### Copie de fichier à distance
+
+C'est la commande `scp`, tout autant sécurisée, qui le permet aussi
+simplement.
+
+`scp monfichier votre_nom_user@server.domaine.com:/~/` enverra le
+fichier dans votre répertoire personnel sur le serveur en question.
+
+`scp votre_nom_user@server.domaine.com:/~/monfichier monfichier` ira
+chercher sur le serveur votre fichier et le déposera dans votre
+répertoire en cours.
+
+Pour faire une copie récursive d'un répertoire :
+`ssh -r /votre_rep votre_nom_user@server.domaine.com:/~/`
+
+### Transfert ftp
+
+Le transfert de fichiers par ftp, de manière sécurisée, est aussi
+possible…
+
+Utilisez la commande suivante : `sftp votre_nom_user@server.domaine.com`
+
+Certains clients FTP graphique acceptent ce mode de connexion, il suffit
+de choisir le mode de connexion **sftp over SSH2**.
+
+## Authentification sécurisée par SSH
+
+### Configuration du service
+
+OpenSSH permet des méthodes diverses d'authentification, et ce en
+fonction de la politique de sécurité privilégiée.
+
+- Une des premières choses à faire est d'interdire l'accès au compte root, afin de ne pas "tenter le diable" : <br> Il faut donc modifier la ligne `PermitRootLogin` en lui donnant la valeur **no**.
+- Forcer la sécurité sur la deuxième version du protocole est à envisager sérieusement ; <br> par la modification de la ligne **Protocol** en lui donnant la valeur `2` *(version de protocole plus sécurisée)*
+- Créer l'authentification par mot de passe, et interdire les mots de passe vides. <br> Donc s'assurer que la ligne `PasswdAuthentication` soit à `yes` et que `PermitEmptypasswords` soit à `no`.
+- Encourager l'authentification par clé publique est à promouvoir ; car une clé appartient à un utilisateur et un seul... <br> Cela signifie positionner la ligne `PubkeyAuthentication` à `yes` et supprimer le symbole dièze devant la ligne `AutorizedKeysFile`.
+- Pour finir par supprimer les protocoles moins sécurisés : <br> ce qui signifie d'imposer aux lignes `RSAAuthentication`, `RhostsAuthentication`, `RhostsRSAAuthentication` et `HostbasedAuthentication` la valeur `no` et d'ignorer `IgnoreRhosts` par `yes`, si elles sont présentes dans le fichier !
+- Pour information, il est possible de manière rudimentaire et exclusive de spécifier les autorisations uniquement à certains utilisateurs ou à un groupe d'utilisateurs. <br> On se servira pour cela des directives `AllowUsers` et `AllowGroups` que l'on ajoutera au fichier de configuration.
+
+Une fois le fichier `sshd_config` modifié, pensez donc à
+(re)démarrer le service : <br>
+`/etc/init.d/sshd restart` ou `service ssh restart`
+
+### Usage de clé publique
+
+L'usage de clé publique ayant été notifié dans le fichier de
+configuration et aux utilisateurs,il est possible de les créer par la
+commande suivante `ssh-keygen`.
+
+* `ssh-keygen -t rsa -b 2048`
+
+{{< note warning >}}
+ATTENTION : Il est recommandé les deux choses suivantes :
+
+- {{< color red >}}ne pas générer des clés plus petites que 2048 bits{{< /color >}}, **préférez** une valeur de
+**4096 bits** ;
+- de même, {{< color red >}}les protocoles de chiffrement **DSA** et
+**ECDSA** ne doivent plus être utilisés{{< /color >}}… **utilisez RSA** ou au mieux un protocole de chiffrement à courbes elliptiques, tel ed25519 !
+
+Pour plus d'informations, veuillez lire mon autre {{< inside2 l="sec:ssh:configuration-securisee" t="article" >}}
+{{< /note >}}
+
+Lors de la génération de celle-ci, il vous sera demandé de taper une
+passphrase que vous choisirez consciencieusement.
+
+Dans un cas, comme dans l'autre, cela crée une clé privée et une clé
+publique dans votre répertoire personnel `$HOME/.ssh/` ; <br> pour les
+clés RSA, ce sont les fichiers **id_rsa** et **id_rsa.pub**,
+et réciproquement pour les autres clés.
+
+<span em>Veillez à ne jamais fournir la clé privée, et ce sous aucun
+prétexte. Votre sécurité en dépend fortement !</span>
+
+Une fois, vos clés générées, copiez votre clé publique sur le serveur : <br>
+`scp -p $HOME/.ssh/id_rsa.pub votre_nom_user@server.domaine.com:/~/.ssh/authorized_keys`
+
+Ensuite on va garder en mémoire la passphrase dans notre ordinateur afin
+de ne pas être obligé de la taper à chaque fois : <br>
+`eval ssh-agent ssh-add` <br>
+Pour la dernière fois, il va vous être demandé de taper votre passphrase, faites-le.
+
+Lors de vos prochaines connexions en SSH sur le serveur, il ne vous
+restera plus… qu'à travailler !
+
+### Création de Tunnel
+
+Pour créer un tunnel de connexion ssh, qui permette d'encapsuler
+d'autres protocoles, il vous faut vous l'écrire ainsi : <br>
+`ssh -L numero_port_encapsulé:adresse_ip_local:numero_port_routé adresse_ip_server`
+
+* L'option `-L` indique l'exécution locale,
+* L'option `-R` indique l'exécution à distance.
+
+### Tunnel X
+
+Pour créer un tunnel graphique X-Windows, il faut d'abord vérifier que
+l'option `X11 Forwarding` soit à `yes` dans le fichier
+`/etc/ssh/sshd_config`.
+
+Cela étant fait, il ne vous reste plus qu'à vous connecter à votre hote
+distant : <br> `ssh -X nom_machine.nom_domaine.tld`
+
+Il est possible de lancer en même temps une application : <br>
+`ssh -X nom_machine.nom_domaine.tld nom_logiciel &`
+
+----
+
+Ce mémo a été écrit la première fois, par mes soins, sur mon autre site
+"[Mémoire Grise
+Libérée](https://memoire-grise-liberee.fr.eu.org/Linux/securite/ssh/)".
+
+----

content/fr/sec/ssh/home-chiffre.md

@@ -0,0 +1,57 @@
+---
+title: "SSH : Gestion de connexion avec Home chiffré"
+date: 2017-07-29T11:30:24+01:00
+description: "Comment configurer SSH pour arriver à se connecter à son répertoire personnel chiffré !"
+draft: false
+tags: ["SSH", "HOME", "Erreur"]
+---
+
+## Description
+
+Eh, oui, lorsqu'on utilise des comptes utilisateurs sur un
+ordinateur/serveur avec un "/home" chiffré… Adieu la connexion SSH avec les clés d'authentification !
+
+Mais non… nous allons remédier à la situation.
+
+## Création d'un répertoire hors Home chiffré
+
+Le plus simple est de créer un répertoire hors votre Home chiffré, tel
+que `$HOME/.ssh/$USER`. Ce dernier peut être absolument ailleurs, tel
+que dans `/etc/ssh`… pourvu qu'il soit lisible hors chiffrement du
+répertoire Home.
+
+{{< code "sec-ssh-home-chiffre-make" >}}
+
+Bien sûr vous remplacez la mention `USER` par l'identifiant utilisateur
+désiré.
+
+Puis vous créez avec vos droits utilisateurs un fichier nommé
+`authorized_keys` où vous copiez votre clé d'authentification SSH, de
+préférence ED25519.
+
+N'oubliez pas de mettre des droits minimum dessus, tel que :
+
+`$ chmod 0600 /home/.ssh/USER/authorized_keys`
+
+## Modification fichier sshd_config
+
+Maintenant, il faut modifier le fichier de configuration du serveur SSH,
+à savoir `/etc/ssh/sshd_config`, pour modifier la ligne
+`AuthorizedKeysFiles` de telle manière :
+
+`# sed -i -e "s#AuthorizedKeysFile     %h/.ssh/authorized_keys#AuthorizedKeysFile      /home/.ssh/%u/authorized_keys#" /etc/ssh/sshd_config`
+
+Vérifiez les droits d'accès et d'appartenances utilisateurs !
+
+Ou, par tout autre moyen de votre crû, avec des droits administrateurs,
+bien sûr !
+
+Puis, relancez le service ssh ;-)
+
+Et, voilà !
+
+## Remerciements
+
+* [source](https://stephen.rees-carter.net/thought/encrypted-home-directories-ssh-key-authentication)
+
+----

content/fr/sec/ssh/rfc4716.md

@@ -0,0 +1,44 @@
+---
+title: "SSH : au format RFC 4716"
+date: 2017-08-17T17:37:53+01:00
+draft: false
+description: "Comment transformer votre clé SSH au format spécifié par la RFC 4716"
+tags: ["SSH", "RFC", "RFC4716"]
+---
+
+## Description
+
+SSH a son propre format de génération de ses clés. Or, dans certains
+contextes, tel que le projet [OMV](http://openmediavault.org),
+il est nécessaire de fournir votre clé publique au format RFC 4716 !
+
+La norme RFC 4716 est une simple présentation de la clé privée ou
+publique dans un format texte, dit ASCII, ni plus, ni moins ;-)
+
+## Génération
+
+Comme pour {{< inside "sec:ssh:configuration-securisee" "créer sa clé" >}},
+on utilise l'outil `ssh-keygen`, de telle manière :
+
+=> Pour une clé ed25519 : <br>
+`$ ssh-keygen -e -f ~/.ssh/id_ed25519 > id_ed25519_rfc4716.pub`
+
+=> Idem pour une clé RSA :<br>
+`$ ssh-keygen -e -f /home/zou/.ssh/id_rsa > id_rsa_rfc4716.pub`
+
+Il ne vous reste plus qu'à copier-coller le contenu du fichier dans
+l'interface ou sur le serveur où ce format vous est demandé.
+
+----
+
+Bien-sûr il est possible de la générer directement dans votre terminal ;
+pour cela, n'utilisez pas la redirection de sortie :
+
+`ssh-keygen -e -f ~/.ssh/id_ed25519`
+
+
+## Documentation
+
+ * https://tools.ietf.org/html/rfc4716
+
+----

content/fr/sec/ssh/write-failed-broken-pipe.md

@@ -0,0 +1,66 @@
+---
+title: "SSH : Write Failed: broken pipe"
+date: 2017-07-23T22:30:06+01:00
+description: "Comment remédier à l'erreur SSH nommée 'Write Failed: broken pipe' !"
+draft: false
+tags: ["SSH", "Erreur"]
+---
+
+## Description
+
+Ahhh, les joies de SSH, n'est-ce pas ?!
+
+- Ce matin, vous vous
+levez, vous cherchez à vous connecter à votre serveur… et très
+rapidement, vous vous faites déconnecter avec ce, *pas joli du tout*,
+message : **Write Failed: broken pipe**. <br>
+Vous vous reconnectez, et rebelote !!!
+
+## Informations
+
+Il y a plusieurs raisons possibles à ce genre de déconnexions
+intempestives, et fortement désagréables, et aucunes de particulières.
+
+## Configuration
+
+De fait, il existe trois options SSH à configurer qui permettent
+d'améliorer sensiblement la tenue de la connexion, dont une
+`TCPKeepAlive yes` qui peut être paramétrée côté serveur et
+côté client !
+
+### Côté serveur
+
+Ouvrez votre fichier `/etc/ssh/sshd_config`, et rajoutez ces deux options
+:
+
+* `ClientAliveInterval` : est le nombre de secondes pendant lequel le serveur va attendre avant d'envoyer un paquet null au client - le but étant de garder la connexion vivante.
+* `ClientAliveCountMax` : est la limite donnée à un client pendant lequel il est autorisé à ne pas donner de réponse, sans se faire déconnecter - sa valeur par défaut est : `3`
+
+### Côté client
+
+Ouvrez votre fichier `~/.ssh/config`, et ajoutez ces deux options
+correspondantes :
+
+* `ServerAliveInterval` : est le nombre de secondes pendant lequel le client va attendre avant d'envoyer un paquet null au serveur - le but étant toujours de garder vivante la connexion.
+* `ServerAliveCountMax` : valeur par défaut est de : `3`
+
+### Explications
+
+Ces options ont pour propos de **maintenir la connexion en vie** ;
+le processus est le suivant :
+
+* Quand le timing relatif aux options `ClientAliveInterval` et `ServerAliveInterval` est arrivé à son terme, un signal "`<span lang="en">`hello-are-you-there`</span>`" est envoyé…
+* le paramétrage des options `ClientAliveCountMax` et `ServerAliveCountMax` est le nombre de fois où ce signal "hello" va être envoyé.
+* S'il n'y a pas de réponse de l'un ou de l'autre au final, la connexion se fermera.
+
+Le calcul est très simple : `ClientAliveInterval` x `ClientAliveCountMax` secondes, côté serveur, et réciproquement pour les options "Server", côté client.
+
+{{< note warning >}}ATTENTION** : Mettre à `0` ses options les désactivent !{{< /note >}}
+
+----
+
+Cela devrait améliorer la situation, mais ne la résout pas forcément !
+
+Très utile avec l'usage du fameux projet [SSLH](http:*www.rutschle.net/tech/sslh.shtml) - le multiplexeur de connexion HTTPS/SS(H|L)/VPN, etc…
+
+----

content/fr/web/hugo/hugo-shortcodes.md

@@ -87,8 +87,7 @@ Mon shortcode est un poil plus évolué, car le site étant multilangue, il appe
 
 L'appel du shortcode est :
 
-* Normalement : `{{``< blockquote "quote" >}}`
-* <del>Sauf si vous avez besoin d'appeler du code HTML, il faut l'utiliser ainsi : <br> `{{``% blockquote "quote" %}}`</del>
+* Normalement : `{{``< blockquote "fichier-blockquote" >}}`
 
 ----
 
@@ -112,10 +111,10 @@ Mon shortcode, un poil plus évolué , du fait d'être multilangue :
 ----
 
 L'appel du shortcode : <br>
-`{{``< code "example-code" language >}}`
+`{{``< code "fichier-code" language >}}`
 
-* `/example-code` est le nom du fichier à appeler contenant le contenu d'un code à montrer.
-* `language` est le nom du langage cible, tel `sh`, `PHP`, `python`, etc… Pour ne préciser aucun langage en soit, utilisez `""` - *deux fois les double quotes* -.
+* `example-code` est le nom du fichier à appeler contenant le code à montrer.
+* `language` est le nom du langage cible, tel `sh`, `PHP`, `python`, etc… - Pour ne préciser aucun langage en soit, utilisez `""` - *deux fois les double quotes* -.
 
 ____
 

content/inc/sec-ssh-chrootdirectory-fatal-blockquote

@@ -0,0 +1,2 @@
+Feb 12 19:56:30 server sshd[64689]: Accepted password for user from 192.168.xxx.yyy port 40829 ssh2
+Feb 12 19:56:30 server sshd[64691]: fatal: bad ownership or modes for chroot directory "/chroot/user"

content/inc/sec-ssh-chrootdirectory-fatal-code

@@ -0,0 +1,6 @@
+# avec les droits administrateurs:
+chmod 0755 /chroot
+chown root:root /chroot
+mkdir /chroot/user_id
+chmod 0705 /chroot/user_id
+chown user_id:user_id /chroot/user_id

content/inc/sec-ssh-chrootdirectory-fatal-match

@@ -0,0 +1,3 @@
+Match group sshusers
+        ForceCommand internal-sftp
+        ChrootDirectory /chroot/%u

content/inc/sec-ssh-home-chiffre-make

@@ -0,0 +1,3 @@
+# mkdir -p /home/.ssh/USER
+# chown -R USER:USER /home/.ssh/USER
+# chmod 0700 /home/.ssh/USER

deploy

@@ -144,8 +144,8 @@ hugo --gc
 status="$?"
 
 if [ "${status}" -eq 0 ]; then
-    sleep 1
-    _gz
+    #sleep 1
+    #_gz
     sleep 1
     _lftp