[[public:heberger_ses_services|< Retour à l'index]]

====== Administration des serveurs ======

Il s'agit ici principalement de renforcer la sécurité, et éviter une pollution des journaux par des tentatives d'attaque nombreuses mais primitives.

  * connaitre/prédire: savoir ce que l'on a et quelles sont les éléments les plus ciblés
  * prévenir: empêcher ou réduire les sources des attaques (ex. pare feu sur IP connues, VPN...)
  * détecter: auditer et lire les journaux, différencier le bruit des attaques sérieuses, mettre en place des alertes, détecter les compromissions (rootkits)
  * répondre: avoir un plan pour agir en cas d'attaque réussie, mettre en place des défenses (fail2ban). Réduire la fréquence d'accès n'est pas suffisant dans le long terme
  * récupérer: pouvoir se relever en cas d'attaque (backups, et tests de restaurations)


====== SSH: la brique de base de l'administration ======

C'est l'outil de base pour administrer interactivement son serveur, le mettre à jour et l'auditer.
Un introduction détaillée se trouve chez [[https://openclassrooms.com/fr/courses/43538-reprenez-le-controle-a-laide-de-linux/41773-la-connexion-securisee-a-distance-avec-ssh|openclassrooms]].

Le principe est celui d'une paire de clé indissociables:
  * une clé privée que vous ne devez jamais diffuser
  * une clé publique, associée, que vous pouvez diffuser librement
  * l'usage de la paire de clé peut être lui-même protégé par un "passphrase". C'est **fortement recommendé** afin d'éviter une usurpation d'identité triviale en cas de vol de vos clés! C'est encore plus conseillé si votre PC peut être volé et que son disque dur n'est pas crypté.
  * il est possible d'utiliser un "agent SSH" pour la durée d'une session qui se souviendra de cette passphrase (sous unix, avec la commande ''ssh-add'', sous windows avec ''pageant'' [[http://www.isc.cnrs.fr/informatique/ssh/putty/sshISC-Putty.html|par exemple]]).

===== Création d'une paire de clé =====

:!: Si votre poste est sous windows, on recommande l'application  [[doc:formations:hebergement:serveur:ssh:mobaxterm|MobaXterm]].

Pour créer une paire de clés asymétriques (coté client, celui qui va se connecter), on peut utiliser la commande suivante:

  ssh-keygen -t rsa -b 4096 -a 100
  # n'écrasez SURTOUT PAS une clé existante si ce n'est pas ce que vous voulez faire!
  # saisissez une "passphrase" non triviale pour protéger la paire de clé (c'est très important!)

:!: rappel: ne diffusez pas votre clé privée, elle est ... privée! Seuls les ''*.pub'' doivent habituellement être envoyés (sauf rares cas où vous générez des clés pour vos clients par exemple).

Note: les cryptages DSA and RSA de 1024 bits ou moins sont désormais réputés "obsolètes". Vous pouvez vérifier le type de clés que vous utilisez avec ce petit script: 
  for k in ~/.ssh/id_*; do ssh-keygen -l -f "$k"; done | uniq
  
===== Ajout de sa clé publique sur un compte distant =====

Le principe est d'avoir sa clé **publique** ajoutée dans le fichier ''~/.ssh/authorized_keys'' de l'utilisateur sur le serveur distant. 

:!: attention chez Scaleway: les fichiers ''authorized_keys'' pour l'utilisateur ''root'' se font systématiquement écraser au démarrage, par les clés préconfugurées sur leur site (une très bonne idée en cas d'erreur de manipulation)! Il faut ajouter sa clé soit directement dans [[https://cloud.scaleway.com/#/credentials|l'interface en-ligne]] de scaleway, soit sur le serveur dans le fichier spécial ''.ssh/instance_keys'' puis lancer la commande d'incorporation ''scw-fetch-ssh-keys %%--%%upgrade''.

En temps normal, si l'on peut se logguer sur le compte distant (par exemple via un compte administrateur, ou via un accès root par login et mot de passe), on peut utiliser la commande suivante:

  ssh-copy-id untel@mon.serveur.com

Si l'on dispose déjà d'un compte root sur un serveur distant, on peut ajouter sa clé publique directement depuis son poste local en une seule commande:
  
  srv='mon.serveur.com'
  usr='untel'
  cat ~/.ssh/id_rsa.pub | ssh root@$srv "sudo -H -u $usr bash -c 'cat >> /home/$usr/.ssh/authorized_keys'"

L'autre approche est de copier sa clé publique vers le serveur, de s'y logguer, puis de l'ajouter en éditant avec ''vi'' ou ''nano'' le fichier ''authorized_keys'' de l'utilisateur ciblé (attention de ne pas écraser les clés qui s'y trouvent déjà!)


====== Options du serveur SSH ======

On le configure principalement dans le fichier ''/etc/ssh/sshd_config'' du serveur sur lequel on se connecte.

:!: Pensez à redémarrer le serveur SSH après les modifications, avec ''service sshd restart''.


==== Port non standard ====

Il est utile de configurer le service SSH sur un port non standard (22), afin d'en réduire la visibilité ainsi que la pollution des logs faces aux attaques "brute force" (innombrables!). 

  Port 12345

:!: Chez Scaleway, on peut judicieusement utiliser les [[https://www.scaleway.com/en/docs/how-to-activate-a-stateful-cloud-firewall/|"stateful cloud firewall"]] pour conserver SSH en port 22 sur le serveur et bénéficier d'un port standard, mais en le masquant et en le faisant correspondre à un port différent en extérieur (ex: 22123 extérieur, connecté au 22 intérieur). On bénéficie alors du meilleur des deux mondes.

==== Brider SSH en IPv4 ====

Pour brider l'accès SSH en IPv4 (et non IPv4+IPv6):
  AddressFamily inet

L'intérêt est de ne pas laisser passer des accès par IPv6 quand on bride IPv4 ;)


==== Refus volontaire des identifications par mot de passe ====

Il est recommandable d'interdire les identifications par mot de passe, au profit d'une clé SSH publique: c'est plus rapide, automatisable, et cela évite de devoir gérer ou noter des mots de passes solides et qui ne sont pas eux-mêmes réutilisés partout.

:!: vérifiez bien que vous avez déjà la possibilité de vous logguer via vos clés sur le serveur avant d'interdir l'accès par mot de passe au niveau du serveur. Toujours dans ''/etc/ssh/sshd_config'',

  PasswordAuthentication no
  PubkeyAuthentication yes

Si vous voulez pouvoir vous identifier en root directement:
  PermitRootLogin prohibit-password

__Note:__ si l'on utilise plutôt ''PermitRootLogin no'', alors il ne sera pas possible de se logguer en root. Il faudra alors passer par un utilisateur, et qui pourra faire un ''sudo'' (ou ''su -''). Certains préfèrent cet ajout de sécurité, parfois un peu lourd dans la réalité. C'est utile pour se protéger un peu contre l'usage de clés SSH sans "passphrase" (cf. ci-avant), puisqu'alors il faut se connecter en SSH sur l'utilisateur, puis taper son mot de passe pour basculer en root via ''sudo''.


==== Restreindre les utilisateurs qui peuvent accéder en SSH ====

Par exemple pour trois utilisateurs:

  AllowUsers root martin paul


==== Restreindre l'origine des connexions ====

{{anchor:ssh_restrict_ips}}

Vous pouvez aussi restreindre l'accès à un compte directement dans le fichier ''authorized_keys'' de celui-ci. Par exemple pour ne permettre l'accès à un compte que depuis une IP particulière (répétez la ligne si vous voulez plusieurs IPs):

  from="11.22.33.44", ssh-rsa AAAAB3AyNChQx...0H1tl jeremie@silex

S'il s'agit d'autoriser non pas sur les clés mais sur la base d'une ou plusieurs IP ou intervalles d'IP, vous pouvez recourir à l'ancienne méthode:
  * ajouter une ligne telle que ''sshd: 11.22.33.44/32, 192.168.1.0/24''dans ''/etc/hosts.allow '',
  * et ''sshd: ALL'' dans le fichier ''/etc/hosts.deny''
Notez la priorité! On s'en doute, ce mécanisme s'applique à d'autres protocoles (dont ''ALL'', attention!)

==== Configurer des option selon l'utilisateur ====

Par exemple pour une configuration spécifique à git sur ''gitolite@mondomaine.com'' (cf [[doc:formations:hebergement:service:gitolite|gitolite]]):

<code>
Host mondomaine.com
  Match User gitoite
  ForwardAgent no
  ForwardX11 no
  RequestTTY no
</code>

Autoriser un "forward X11" permet d'exporter un affichage graphique vers un client SSH, à la condition que le serveur source dispose d'un serveur X. Faites un ''export DISPLAY=$(echo $SSH_CLIENT|cut -f1 -d\ ):0.0'' côté serveur, après avoir fait un ''xhost +'' coté client. Il est cependant probablement plus facile et efficace d'utiliser [[doc:formations:hebergement:serveur:vnc|TigerVNC]].

==== Restreindre les commandes appelables ====

Vous pouvez aussi restreindre les commandes possibles apres la validation d'un accès SSH sur un compte, par exemple:

  command="/usr/local/bin/monbackup.sh", ssh-rsa AAAAB3AyNChQx...0H1tl jeremie@silex
  
Ici, le script ''/usr/local/bin/monbackup.sh'' sera exécuté lors de la connexion SSH. Ce script peut profiter de la variable "$SSH_ORIGINAL_COMMAND" qui contient la commande passée par l'appelant, qui peut donc servir de paramétrage. C'est utilisé par exemple pour ce [[doc:formations:hebergement:serveur:sauvegarder:exemple|système de backup]].

Notez qu'on peut combiner les deux restrictions précédentes, par exemple si vous avez dans ''/home/toto/.ssh/authorized_keys'' la ligne suivante,

  from="11.22.33.44", command="/bin/date;hostname", ssh-rsa AAAAB3AyNChQx...0H1tl jeremie@silex

Alors seul un utilisateur de 11.22.33.44 dont la clé est celle ci-dessus pourra faire un ssh vers le serveur et vers ce compte, mais le résultat sera toujours l'équivalent d'avoir lancé les commandes ''date;hostname'' sur le serveur.

{{anchor:ssh_tunnels}}

==== Restreindre aux tunnels ssh ====

=== Généralité sur les tunnels ===

Un tunnel SSH permet de créer localement un service d'écoute sur un port, qui redirige la communication vers un serveur distant et un autre port, tout en la cryptant. C'est quelque part une forme très légère et réduite de [[doc:formations:hebergement:service:wireguard|VPN]] pour un service spécifique:

Par exemple si l'on veut ouvrir localement un service distant VNC (bureau virtuel à distance), on exécute localement cette commande:

  ssh vnc@tiger.server.com -L 5901:127.0.0.1:5901

=== Tunnels SSH inverse ===

On peut aussi créer des tunnels SSH inverses. Leur rôle est d'ouvrir sur le serveur distant un tunnel qui "redescend" vers le poste qui a ouvert le tunnel, ce qui permet d'ignorer les contraintes du réseau local, tant qu'il permet d'utiliser SSH. On n'a pas à se soucier d'adresses, de NAT ou de reconfiguration du gateway ou de la DMZ.

Pour se faire on crée un compte SSH ''usertssh'' que l'on bride à cette seule action, et on le paramètre dans le ''/etc/ssh/sshd_config'' du serveur;

<code>
Match User usertssh
  AllowAgentForwarding no
  PermitOpen localhost:65432
  ForceCommand echo "Ce compte est limité à du tunnel SSH."
</code>

On peut vérifier la contrainte en essayant de se logguer interactivement depuis son poste (une fois ajouté dans le ''.ssh/authorized_keys'' de ''usertssh''):

  #ssh usertssh@myserver.com
  Ce compte est limité à du tunnel SSH. Connection to myserver.com closed.

On va utiliser ici ''autossh'' à la place de SSH, car c'est un outil pratique qui relance automatiquement le tunnel s'il tombe:

  # depuis le poste client
  sudo apt-get install openssh-server autossh
  autossh -fN -M 3986 -R 65432:localhost:22 usertssh@myserver.com

Cela ouvrira sur le serveur un accès "local" SSH sur le port 65432. Quand on est loggué sur le serveur on peut l'utiliser pour redescendre vers la machine qui a ouvert ce tunnel, tout simplement (et on ressortira ici sur le port 22).

Loggué sur le serveur et avec sa clé publique dans le ''.ssh/authorized_hosts'' de l'utilisateur sur le poste qui a ouvert le tunnel sur le serveur:

  # depuis le serveur
  ssh root@localhost -p 65432

{{anchor:ssh_client_config}}
====== Options du coté "client" ======

Avec Windows, voyez les options des "sessions" de putty ou de [[doc:formations:hebergement:serveur:ssh:mobaxterm]].

Sur un poste client de type unix, on gagne beaucoup à configurer des alias/raccourcis dans ''~/.ssh/config''. Attention à vérifier que votre dossier ''~/.ssh'' n'est pas lisible par les autres utilisateurs du système sinon il sera ignoré (''chmod -R go-rwx ~/.ssh'').

<code>
Host srv files.tecrd.com alias1
  Hostname 51.15.239.195
  #Hostname files.tecrd.com
  User untel
</code>

Ainsi ''ssh srv'' fera en fait un ''ssh untel@files.tecrd.com'', à moins d'avoir explicité n'importe laquelle de ces valeurs par défaut, ex. ''ssh jeremie@srv''.

Le fichier ''.ssh/config'' permet beaucoup de choses, qui facilitent grandement l'usage d'autres outils tels que ''git'', ''scp'' ou ''rsync''.

Par exemple pour git qui utilise SSH sur un port non standard (22123 au lieu du 22 par défaut):

  ssh jeremie@tecrd.com
  > port 22: Connection refused

  ssh jeremie@tecrd.com -p 22123
  > ok

Pour éviter de devoir à chaque fois spécifier comment on se connecte à un serveur (nom d'utilisateur, port, options particulières), on peut se créer ou bien ajouter des paragraphes au fichier ''~/.ssh/config'' sous cette forme:

<code>
Host git tecrd.com
	# ce paragraphe ne s'appliquera que pour un accès via l'utilisateur "gitolite" !
	Match User gitolite
	Hostname tecrd.com
	Port 22123
        #
	# vous pouvez meme spécifier une clé SSH particulière à utiliser, ex.
        # IdentityFile ~/.ssh/cle_secondaire
        # C'est comme d'avoir passé: -i ~/.ssh/cle_secondaire''
        #
	# quelques options ssh désactivées pour éliminer des warnings sinon affichés par gitolite:
	ForwardAgent no
	ForwardX11 no
	RequestTTY no

Host tecrd.com tecrd
	Hostname tecrd.com
	User jeremie
	Port 22123
	ForwardAgent yes
	ForwardX11 yes
        # Ces deux lignes garantissent que votre session ssh n'expirera pas. C'est pratique mais
        # evidemment moins sécurisé si l'on oublie de fermer ses sessions sur un poste qui ne
        # serait pas physiquement sécurisé.
	TCPKeepAlive yes
	ServerAliveInterval 60
</code>

Désormais, si vous faites un accès ''ssh'' aux hosts sus-nommés/aliasés, il prendra par défaut les valeurs trouvées dans ce fichier de configuration.

Ici par exemple, en l'absence d'info contradictoire explicite sur la ligne de commande, il utilisera le port 22123 nécessaire: plus besoin de le spécifier à chaque fois dans ''ssh'', ''scp'', ''rsync'', ''git'' ...

Et donc:

  * ''ssh tecrd'' ou ''ssh tecrd.com'' sera équivalent à ''ssh -p 22009 jeremie@tecrd.com -o <options...>''
  * mais ''ssh git'' ou bien ''ssh gitolite@tecrd.com'' va utiliser le premier paragraphe, et donc aussi l'utilisateur ''gitolite'' (ce qui est requis pour git)
  * mais rien n'empeche de faire ''ssh toto@service.valorhiz.com''. Puisque l'on spécifie explicitement l'utilisateur, il se sera pas écrasé avec ''User jeremie'', et n'utilisera que les autres définitions par défaut.

====== Partage de session SSH ======

[[https://github.com/elisescu/tty-share|tty-share]] est un outil sympa qui permet de partager un shell avec d'autres (au sens de co-rédacteur!), y compris via un navigateur web.

La version la moins invasive tourne dans un docker ainsi:

  docker run -it elisescu/tty-share --public

:!: Attention aux problèmes évidents de sécurité, mais c'est un bel outil pour demander de l'aide !

====== Restriction d'usage d'un compte SSH ======

De nouveau du côté serveur.

===== SFTP =====

Il est possible de configurer ''/etc/ssh/sshd_config'' pour limiter l'usage de certains comptes à certaines opérations, par exemple pour n'autoriser que ''sftp'' à l'utilisateur ''partage'':

<code>
Subsystem sftp internal-sftp

Match User partage
  ChrootDirectory /home/partage_sftp
  X11Forwarding no
  AllowTcpForwarding no
  ForceCommand internal-sftp
</code>

Il faut aussi un peu d'administration initiale:

  mkdir -p /home/partage_sftp/depo    # création de la zone d'échange de fichiers par SFTP
  chown root:root /home/partage_sftp  # propriétaires obligatoires
  chmod 755 /home/partage_sftp        # et droit nécessaires
  chown root:partage /home/partage_sftp/depot
  chmod 775 /home/partage_sftp/depot

Ainsi, un utilisateur externe dont la clé SSH publique se trouve dans ''/home/partage/.ssh/authorized_keys'' pourra faire un SFTP vers ce compte, et se retrouvera bridé absolument dans le dossier ''/home/partage_sftp/''. Il lui sera ainsi impossible de modifier le ''/home/partage/.ssh''. 
Pour écrire, il faut (!?) un sous-dossier, ici ''/home/partage_sftp/depot'' (qui apparaîtra comme ''dépot'' à la racine de l'arborescence vue sous SFTP).


===== Usage de rssh (SFTP, RSYNC) =====

Il est vaguement possible mais complexe de faire pareil pour [[https://unix.stackexchange.com/questions/278489/how-to-make-ssh-account-capabele-to-only-sshfs-and-rsync|rsync]], qui est un protocole de tranfert de fichier bien plus efficace (il ne copie que ce qui a changé), ainsi que ''sshfs'' (un montage local transparent d'un dossier distant). Voir par exemple aussi ce [[https://www.marcus-povey.co.uk/2015/04/09/cross-server-ssh-rsync-backups-done-more-securely/|chroot jail]] (en anglais).

Il existe aussi un outil qui commence à être "ancien" mais qui est facile d'emploi: ''rssh'' (restricted secure shell). C'est acceptable pour des utilisateurs bien intentionnés (il vaut mieux éviter si c'est un accès publique général -- c'est rarement le cas tout de même). C'est surtout utile pour faire des backups du système.

Sur le serveur, on va créer un utilisateur ''rsyncer'' dédié aux transferts:

  apt install rssh
  useradd -m -d /home/rsyncer -s /usr/bin/rssh rsyncer

Puis on ajoute au fichier ''/home/rsyncer/.ssh/authorized_keys'' les clés SSH publiques des comptes qui pourront utiliser ce protocole (pensez toujours au ''chown -R rsyncer:rsyncer /home/rsyncer/.ssh; chmod -R go-rwx /home/rsyncer/.ssh'')

Si vous essayez de vous y connecter depuis l'extérieur avec un ''ssh rsyncer@monserveur.com'' vous devriez avoir une erreur du type ''This account is restricted by rssh.''. C'est bon signe.

Il faut en effet maintenant configurer les types d'actions autorisées, en éditant le fichier ''/etc/rssh.conf'' sur le serveur. Par exemple on peut retirer les commentaires devant ces entrées:

  allowsftp
  allowrsync

:!: N'utilisez pas ''allowscp'' qui a une faille de sécurité non réglée.