ssh bien configuré et sécure

“Pentesting Guide
“In this guide, I will: Quickly introduce the SSH protocol and implementations.Expose some common configuration mistakes then showcase some attacks on the protocol & implementations.Present some SSH pentesting blue team tools.” https://community.turgensec.com/ssh-hacking-guide/

• Upgrade your SSH keys! https://blog.g3rt.nl/upgrade-your-ssh-keys.html
• Secure your SSH access https://infosec-handbook.eu/blog/wss1-basic-hardening/
  • allow only whitelisted IP addresses to connect
  • use a non-root account for access and disable root
  • use keys instead of passwords
  • only use modern algorithms
  • enable 2FA for SSH
  • back up your configuration
  • (use dedicated hardware to store your keys)

Pour provisioning et orchestration sans agent installé sur les serveurs cibles avec un lanage yaml et Template Jinja, permet également de faire des migrations

Outil idempotence, si on lance deux fois le cahier de jeux :

• la première fois : faire la modification sur servuer pour application de celle-ci
• la seconde fois : verifie la configuration et affiche le ok ou la différence

Un module Ansible environ 15 lignes en python (snippets) qui sera installé à coté du playbook dans ./library dans le cas de choes trop complexe avec ansible que l'on pourrait faire en python.

Dans Ansible :

• Le rôle : sert à packager les actions (idempotentes) et les fichiers statiques et variables par défaut dont on a besoin
  • La commande ansible-galaxy init <mon_role_voulu> crée le squelette, la structure du role

ref : https://invidio.us/watch?v=jePp5ZP1n14&autoplay=0&continue=0&dark_mode=true&listen=0&local=1&loop=0&nojs=0&player_style=youtube&quality=dash&thin_mode=false à partir de 29 min 30 sec

• On peut installer plusieurs rôles groupés dans un fichier requirements.yml puis faire un commande pour rendre disponible et in installer tous ces roles d'un coup ansible-galaxy install -r requirements.yml

• Les notes de Jaxom
• Vidéo :
  • Conférence "Rodez en libre". "Découverte de Ansible" proposé par Alexis Couronne
  • Ansible hors des sentiers battus (Aurélien Maury), avec configuration ssh persitente lors de la négocitation avec serveur pendant le chargement du playbook Ansible
  • FOSDEM18 - Zero Downtime Deployment with Ansible
• Blog :
  • Introduction aux Ansible Content Collections
  • Ansible - Une erreur bête qui peut faire perdre du temps

Depuis un dossier, par exemple, host

puis les rôles, avec des sous-dossiers, créés avec ansible galaxy pour chaque rôle

playbook est le fichier passé en paramètre pour point d'entrée pour apllique l'ensemble de la recette, ici pour exmple avec 2 types de recettes

1. les hosts du groupe web qui se connecte via ssh
   1. via utilisateurs root
   2. applique les deux rôles web et common
2. Les hosts du groupe database
   1. Via utilisateur root
   2. applique common et database

Pour concevoir une tache à l'inétrieur d'un rôle, oou plusieurs taches

1. Intallation de vim
   1. le module utilisé pour installé vim est ici apt
   2. L'état désiré du paquet installé, ici latest, dernière version
   3. update case, précision avant d'installer, faire un apt-get update pour mise à jour
2. Idem pour git qui ne nécessite plus update puisqu'il a été réalisé à la tâche précédente

Dans le cas d'installer beaucoup de package on peut utiliser un boucle pour alléger le nombre de taches

Il s'agit de passer un liste de packages à installer avec état latest et update avant d'installer

Pour le boucle, par exemple ici pour installation, depuis un with_item.yml

- name : Installation de logiciels pour communs
  apt:
    name={{ item }}
    state=latest
    update-case=yes
  with_items:
   - vim
   - git

ou

- name : Installation de logiciels pour communs
  apt:
     name="{{ item }}"
     state=latest
    update-case=yes
  with_items:
   - vim
   - git

En gros, objet ou strings

Ou alors j'ai fait un erreur 🤔

Il y a name: "{{ item.name }}" dans la doc https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html?highlight=loop#standard-loops

Dérivé de la question ci-dessus,

state=present semble plus dans la logique d'idempotence que state=latest, et, de plus, si on veut assurer que le systeme soit à jour il faut l'assurer par un autre mecanisme (typiquement unattended-upgrades dans le monde APT)

Une discussion en cours apparait mener à des distinctions plus claires entre latest et present

https://github.com/ansible/ansible-lint/pull/568

Merci Samuel pour ton aide

Depuis le système de contrôle (depuis lequel on lance ansible) ssh-keygen -o && scp ~/.ssh/id_rsa.pub user@mamachine_cible:~/.ssh/authorized_keys avec l'IP de la machine plutôt que son nom

sécu des clés, en gros le choix des 'Digital Signature Algorithm' et compatibilité (je dois regarder du coup ecdsa et ansible https://docs.ansible.com/ansible/latest/modules/openssh_keypair_module.html)

il faudra vérifier que cela ne casse pas des compatibilités (https://tools.ietf.org/html/rfc4251) entre différents systèmes et aussi des raisonnements sur la robustesse https://www.ssh.com/ssh/keygen