cClaude.rocks ☕ Le blog

Le protocle ssh s'appuis sur des pais de clés, pour l'utiliser ce protocole vous avez besoin d'une clé ssh bien à vous.

Pour créer votre propre clé ssh au format rsa (ce qui est demandé par exemple pour un serveur git), vous devez simplement utiliser la commande suivante :

☆☆☆

ssh-keygen -t rsa

Une astuce cependant, pour vous aider à gérer et identifier vos clés, je vous conseille fortement l’utilisation du paramètre -C. Comme valeur vous pouvez mettre votre nom d’utilisateur et le nom de la machine où la clé a été générée (où la clé privée est hébergée).

Par ailleurs, histoire d’avoir une clé assez robuste, je vous encourage à ce qu’elle soit assez longue. Cela se configure l’aide du paramètre -b. Comme valeur, je préconise 4096.

Et du coup, cela donne :

★☆☆

ssh-keygen -t rsa -b 4096 -C "${USER}@${HOSTNAME}"

Par défaut, la clé privée est stockée dans ~/.ssh/id_rsa (ce fichier vous le garder précieusement là où il est et vous ne le communiquer à personne). La clé publique associée sera alors : ~/.ssh/id_rsa.pub.

Automatisation, clé ssh par défaut.

Si vous devez créer une clé ssh depuis un script vous devrez préciser d’autre paramètres, cela donnera quelque chose comme :

☆☆☆

ssh-keygen -t rsa -b 4096 -C "your comment" -f "${HOME}/.ssh/my_id_rsa" -N ''

Là encore, je vous encourage à utiliser le champ commentaire pour identifier vos clés, comme ceci :

★★★

ssh-keygen -t rsa -b 4096 -C "${USER}@${HOSTNAME}" -f "${HOME}/.ssh/id_rsa" -N ''

Pour stoquer votre clé, il est souvent raisonnable (voire préférable) d’utiliser le nom de fichier par défaut: ~/.ssh/id_rsa' (${HOME}/.ssh/id_rsa`).

Automatisation, création d’une clé personnalisée

Pour la configuration d’un service ou tout usage très spécifique, dans ce cas c’est une bonne idée d’utiliser le champ commentaire pour identifier le nom du service, l’utilisateur et/ou le fichier relatif à cette configuration.

Par exemple :

APP_USER='testuser' # User for the application
APP_NAME='gitlab'   # Name of the application

ssh-keygen -t rsa -b 4096 -C "${APP_USER}_${APP_NAME}@${HOSTNAME}" -f "${HOME}/.ssh/${APP_USER}_${APP_NAME}_id_rsa" -N ''

Utilisation de plusieurs clés ssh

Les systèmes Linux prennent en compte généralement la clé par défaut, mais ils ignorent les autres clés. Pour résoudre cela vous devez utiliser le code suivant :

eval $( ssh-agent -s ) # Seulement une fois par session.

ssh-add [file …] # Vous pouvez enregistrer plusieurs clés à la fois

Pour voir les clés connues par votre système vous pouvez utiliser la commande suivante :

ssh-add -l

Protection de vos clés

Votre dossier .ssh doit avoir les droits d’écriture que pour votre utilisateur. Une bonne pratique est de le rendre accessible qu’à vous en lecture et écriture.

chmod 700 ~/.ssh

Votre clé privée doit rester privée. Cette configuration est acceptable, mais pas nécessaire. Votre clé publique est accessible.

chmod 600 ~/.ssh/id_rsa     # chmod u=rw,go= ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub # chmod a=r,u+w ~/.ssh/id_rsa.pub

Votre clé privée doit rester privée, mais le fichier qui contient votre clé publique peut l’être aussi.

★★★

chmod 600 ~/.ssh/id_rsa ~/.ssh/id_rsa.pub
# chmod u=rw,go= ~/.ssh/id_rsa ~/.ssh/id_rsa.pub

Le contenu de votre clé publique est un simple texte que vous pouvez copier/coller très facilement.

cat ~/.ssh/id_rsa.pub

Références

• Documentation Red Hat sur le Protocole SSH

ᦿ

Sous Linux avec systemd pour connaître votre configuration DNS vous devez utiliser la commande suivante :

systemd-resolve --status --no-pager

Ici le paramètre --no-pager est destiné à ne pas mettre en pause l’affichage à chaque fois que la page de la console a été remplie.

La commande systemd-resolve

La commande systemd-resolve s’adresse au service correspondant systemd-resolved.service. Pour ceux qui connaissent Linux depuis un petit moment, ce service remplace dnsmasq – et à noter qu’ils sont incompatibles l’un avec l’autre au sens que si vous avez les deux services sur la même machine vous risquez que la résolution DNS ne fonctionne pas.

systemd-resolve peut être utilisé pour résoudre des noms de domaine, des adresses IPv4 et IPv6, des enregistrements de ressources DNS et des services. Par défaut, la liste de paramètres spécifiée sera résolue en tant que noms d'hôtes, en récupérant leurs adresses IPv4 et IPv6.

Si les paramètres spécifiés sont formatés comme des adresses IPv4 ou IPv6, l’opération inverse est effectuée et un nom d’hôte est récupéré pour les valeurs spécifiées.

systemd-resolve www.example.org

www.example.org: 2606:2800:220:1:248:1893:25c8:1946
                 93.184.216.34

-- Information acquired via protocol DNS in 994us.
-- Data is authenticated: no

nslookup www.example.org

Server:     127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
Name:   www.example.org
Address: 93.184.216.34
Name:   www.example.org
Address: 2606:2800:220:1:248:1893:25c8:1946

host example.com

example.com has address 93.184.216.34
example.com has IPv6 address 2606:2800:220:1:248:1893:25c8:1946
example.com mail is handled by 0 .

Cependant systemd-resolve ne permet pas de sélectionner un serveur DNS alternatif pour la requête en cours.

nslookup HOTE_A_RESOUDRE SERVEUR_DNS_A_UTILISER

nslookup www.example.org 8.8.8.8

Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:   www.example.org
Address: 93.184.216.34
Name:   www.example.org
Address: 2606:2800:220:1:248:1893:25c8:1946

Les commandes de contrôle du DNS

Pour une réparation et diagnostique rapide (en mode j’ai autre chose à faire), je vous propose la séquence de commande suivante :

sudo systemd-resolve --flush-caches ; systemctl status --no-pager -l systemd-resolved.service

Pour faire un diagnostic un peu plus sérieux, voici comment obtenir quelques informations utiles :

• Identifier les DNS utilisés (par interface) :

systemd-resolve --no-pager --status

• Vous pouvez également avoir les statistiques de résolution à l’aide de :

systemd-resolve --statistics

Vous pouvez avoir besoin de réinitialiser ces statistiques, pour cela utilisez :

sudo systemd-resolve --reset-statistics

• Vérifier la configuration

La configuration est accessible via le fichier /etc/resolv.conf mais pour systemd, et particulièrement en conjonction avec une configuration réseau basée sur un DHCP, vous devez que ce fichier est un lien symbolique vers la configuration de systemd.

Typiquement, la commande :

ls -la --color /etc/resolv.conf

doit avoir comme résultat du type :

lrwxrwxrwx 1 root root 39 mars  16  2019 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Il est probablement pas une bonne idée de modifier le contenu de etc/systemd/resolved.conf surtout si votre machine doit supporter le protocole DHCP (ce qui est normalement le cas sur un réseau domestique). D’ailleurs en entreprise, cela me semble également une mauvaise idée que d’intervenir sur ce fichier. Les problématiques d’infrastructure devant être réglées au niveau de l’infrastructure.

• Pensez également à vérifier votre configuration réseau à l’aide de comme simple comme ping et traceroute (ou traceroute6).

A notez qu’il est déconseillé d’utiliser les outils graphiques prenant en charge le réseau en même temps que vous modifier votre configuration manuellement, c’est pourquoi ce billet n’ira pas plus loin sur ce sujet.

Juste une dernière remarque cependant, dans un environnement graphique, on s’attend généralement à ce que le WIFI soit automatiquement connecter sur les réseaux connus, et sans intervention de l’utilisateur. Dans ce cas, notez que la configuration est modifiée par les outils qui prennent en charge cette fonctionnalité.

ᦿ

Au démarrage d’un système d’exploitation comme Linux, il y a une myriade de services qui se lancent.

Et les questions auxquelles on souhaite avoir des réponses sont du genre :

• « Qu’est ce qui est long au démarrage ? »
• « Comment arrive à l’écran de connexion plus vite ? »
• Lorsque l’on rencontre un problème au démarrage : « Ou est-ce qui se passe ? »

La solution proposée par systemd

systemd-analyze

Permet d’avoir une vue générale sur le temps de démarrage de votre système d’exploitation.

Startup finished in 6.849s (firmware) + 3.836s (loader) + 4.312s (kernel) + 1min 30.342s (userspace) = 1min 45.340s
graphical.target reached after 6.247s in userspace

À noter que le résultat semble pouvoir varier considérablement entre un démarrage et un redémarrage :

# After power-on
Startup finished in 7.010s (firmware) + 3.961s (loader) + 4.120s (kernel) + 9.387s (userspace) = 24.478s
graphical.target reached after 9.363s in userspace

# After reboot
Startup finished in 7.592s (firmware) + 3.867s (loader) + 4.145s (kernel) + 1min 24.999s (userspace) = 1min 40.605s
graphical.target reached after 6.596s in userspace

Startup finished in 6.967s (firmware) + 3.889s (loader) + 4.128s (kernel) + 6.965s (userspace) = 21.950s
graphical.target reached after 6.957s in userspace

systemd-analyze --no-pager blame

Donne la liste et le temps que les services mettent pour se lancer, par exemple :

          3.848s NetworkManager-wait-online.service
          1.159s dev-nvme0n1p2.device
           649ms apt-daily-upgrade.service
           627ms snapd.service
           569ms systemd-journal-flush.service
           472ms systemd-logind.service
           437ms vboxdrv.service
           382ms snap-cmake-323.mount
           381ms dev-loop0.device
           380ms snap-core-8935.mount
           328ms snap-core18-1754.mount
           316ms keyboard-setup.service
           299ms dev-loop3.device
           292ms dev-loop1.device
           292ms dev-loop2.device
           244ms upower.service
           229ms systemd-hwdb-update.service
           220ms snap-core-9066.mount
           187ms systemd-udev-trigger.service
           167ms dev-loop4.device
           146ms snap-imaginary\x2dteleprompter-5.mount
           145ms lvm2-monitor.service
           140ms snap-core18-1705.mount
           139ms snap-cmake-340.mount
           134ms systemd-resolved.service
           131ms bash-desktop-configurator.service
           122ms systemd-udevd.service
           116ms NetworkManager.service
           115ms user@1001.service
           115ms systemd-fsck@dev-disk-by\x2duuid-52fffab2\x2ffd36\x2ff509\x2da7b1\x2d1fffeb2dff56.service
           112ms systemd-timesyncd.service
           111ms ModemManager.service
           108ms gpu-manager.service
           104ms accounts-daemon.service
            94ms udisks2.service
            75ms ubuntu-system-adjustments.service
            73ms swapfile.swap
            71ms apparmor.service
            68ms networkd-dispatcher.service
            61ms networking.service
            60ms systemd-journald.service
            60ms ufw.service
            59ms systemd-modules-load.service
            59ms kmod-static-nodes.service
            59ms grub-common.service
            59ms dev-hugepages.mount
            58ms run-rpc_pipefs.mount
            58ms sys-kernel-debug.mount
            56ms systemd-tmpfiles-setup.service
            54ms systemd-remount-fs.service
            48ms bluetooth.service
            45ms rpcbind.service
            42ms rsyslog.service
            41ms avahi-daemon.service
            41ms pppd-dns.service
            34ms nvidia-persistenced.service
            33ms dev-mqueue.mount
            33ms packagekit.service
            32ms wpa_supplicant.service
            31ms systemd-rfkill.service
            29ms alsa-restore.service
            29ms thermald.service
            28ms systemd-update-utmp.service
            25ms phpsessionclean.service
            24ms lm-sensors.service
            22ms systemd-fsck@dev-disk-by\x2duuid-0F0D\x2dff1B.service
            19ms colord.service
            19ms mnt-data.mount
            19ms ssh.service
            18ms lightdm.service
            17ms speech-dispatcher.service
            17ms hddtemp.service
            17ms apport.service
            16ms binfmt-support.service
            15ms plymouth-read-write.service
            15ms snapd.seeded.service
            15ms kerneloops.service
            14ms systemd-random-seed.service
            14ms dns-clean.service
            13ms systemd-tmpfiles-setup-dev.service
            13ms sys-kernel-config.mount
            13ms blk-availability.service
            13ms systemd-tmpfiles-clean.service
            13ms systemd-sysctl.service
            12ms finalrd.service
            11ms sys-fs-fuse-connections.mount
            11ms openvpn.service
            11ms systemd-user-sessions.service
            10ms lsyncd.service
            10ms polkit.service
             9ms nfs-config.service
             7ms snapd.socket
             7ms ureadahead-stop.service
             6ms console-setup.service
             5ms dev-loop5.device
             5ms proc-sys-fs-binfmt_misc.mount
             5ms motd-news.service
             4ms dev-loop6.device
             4ms boot-efi.mount
             4ms open-iscsi.service
             3ms plymouth-quit-wait.service
             3ms vboxweb-service.service
             3ms systemd-backlight@backlight:intel_backlight.service
             3ms systemd-update-utmp-runlevel.service
             3ms rtkit-daemon.service
             2ms vboxballoonctrl-service.service
             2ms vboxautostart-service.service
             1ms setvtrgb.service

systemd-analyze critical-chain

Les différents services doivent se lancer dans un certain ordre, mais certains peuvent être lancés parallèlement…

La durée du démarrage, ne correspond alors pas à la somme des temps de lancement de ces processus. Il s’agit de la somme des temps des processus « qui sont attendus pour continuer ».

La commande systemd-analyze critical-chain [UNIT …] affiche l’arbre de la chaîne critique
pour l’unité donnée. (pour chacune des « UNIT » spécifiées ou pour la chaîne par défaut).

Cela donne pour chaque étape, après que le caractère '@' le moment de l’exécution de la tâche et le temps de démarrage après le signe '+'.

Notez que cet affichage peut être trompeur. En effet, l’initialisation d’un service peut dépendre d’un déclencheur d’activation (« trigger ») provenant de l’exécution en parallèle d’une autre unité de traitement.

graphical.target @6.247s
└─lightdm.service @6.227s +18ms
  └─systemd-user-sessions.service @6.200s +11ms
    └─remote-fs.target @6.196s
      └─remote-fs-pre.target @6.195s
        └─open-iscsi.service @6.188s +4ms
          └─network-online.target @6.185s
            └─NetworkManager-wait-online.service @2.335s +3.848s
              └─NetworkManager.service @2.198s +116ms
                └─dbus.service @2.173s
                  └─basic.target @2.170s
                    └─sockets.target @2.169s
                      └─snapd.socket @2.160s +7ms
                        └─sysinit.target @2.142s
                          └─systemd-timesyncd.service @2.027s +112ms
                            └─systemd-tmpfiles-setup.service @1.966s +56ms
                              └─local-fs.target @1.958s
                                └─mnt-data.mount @1.937s +19ms
                                  └─systemd-fsck@dev-disk-by\x2duuid-dbb7ffb2\x2dffa6\x2dffa9\x2dafa1\x2d1eafebadff56.service @1.764s +115ms
                                    └─dev-disk-by\x2duuid-dbb7ffb2\x2dffa6\x2dffa9\x2dafa1\x2d1eafebadff56.device @1.763s

Quelques pistes d’optimisations

Ces pistes sont à prendre comme des exemples, ce sont des problèmes identifiés sur mes machines, vous n’avez probablement pas les même optimisations à faire…

Ici, il s’agit plus d’illustrer une méthode que d’expliquer les cas exposés.

La table des partitions /etc/fstab

Un temps un peu long sur le montage des disques m’a fait regarder ma table des partitions.

cat /etc/fstab

Ce fichier contenait une ligne qui m’était inconnue :

/dev/disk/by-id/mmc-SC32G_0x3ce424fc-part1 /mnt/mmc-SC32G_0x3ce424fc-part1 auto nosuid,nodev,nofail,x-gvfs-show 0 0

Hors l’entrée /dev/disk/by-id/mmc-SC32G_0x3ce424fc-part1 n’existe pas sur ce système.

Cela se vérifie avec un simple :

ls -la /dev/disk/by-id/mmc-SC32G_0x3ce424fc-part1

J’ai donc mis cette ligne en commentaire en ajoutant le signe # en début de celle-ci.

Cela ressemble à un démontage de clé USB qui s’est mal passé (mais je n’ai pas vraiment creusé la question, puisqu’il s’agit d’une machine de développement et par conséquent le système d’exploitation est souvent mal mené)

Le service zeitgeist

Dans mon cas, c’est le traitement lié à l’utilisateur qui était lent. Du coup la commande suivante semblait adaptée :

systemd-analyze --user blame

Et j’ai eu le résultat suivant :

           465ms zeitgeist-fts.service
           230ms gvfs-goa-volume-monitor.service
           167ms zeitgeist.service
            26ms gvfs-gphoto2-volume-monitor.service
            24ms gvfs-mtp-volume-monitor.service
            22ms gvfs-udisks2-volume-monitor.service
             8ms gvfs-afc-volume-monitor.service
             8ms at-spi-dbus-bus.service
             7ms gvfs-daemon.service
             6ms obex.service
             6ms dbus.socket
             3ms gvfs-metadata.service

A priori, rien d’affolant, mais bon constatant que c’était le service zeitgeist-fts.service qui était le plus long à traité j’ai fait quelques recherches sur lui.

Au passage j’ai découvert le fichier : ~/.local/share/zeitgeist/activity.sqlite qui était d’une taille sympathique (80 584 704 octets - quand même) et qu’il est possible d’explorer à l’aide de :

sqlitebrowser ~/.local/share/zeitgeist/activity.sqlite

Par curiosité, je vous invite à faire un « browse table » sur la vue (« Views »)  : event_view…

Bref, ayant lu que le dossier pouvait être supprimé sans problème, eh bien :

rm -fr ~/.local/share/zeitgeist

Et on arrête la machine, pour la démarrer à nouveau (histoire d’avoir toujours la même référence)

Et là :

# after power-on and after removing ~/.local/share/zeitgeist directory
Startup finished in 6.967s (firmware) + 3.889s (loader) + 4.128s (kernel) + 6.965s (userspace) = 21.950s
graphical.target reached after 6.957s in userspace

À comparer avec le démarrage précédent :

# after power-on
Startup finished in 7.592s (firmware) + 3.867s (loader) + 4.145s (kernel) + 1min 24.999s (userspace) = 1min 40.605s
graphical.target reached after 6.596s in userspace

Références

• Manuel de systemd-analyze sur freedesktop.org,
• What zeitgeist is sur askubuntu.com,
• Page wikipédia de Zeitgeist

ᦿ