cClaude.rocks ☕ Le blog

L'informatique et les nouvelles technologies

Menu

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

Your public key can be public, what matters is that your private key is private.

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

኿


Ce billet a été édité le : 2020-05-31

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.

L’usage le plus basic de la commande est :

systemd-resolve www.example.org

qui produit un résultat du type :

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

On peut noter que le résultat est proche de ce que donne nslookup :

nslookup www.example.org

Qui retourne quelque chose comme :

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

Ou encore de host :

host example.com

Qui affiche cela :

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.

Avec nslookup c'est possible et fort simple, la syntaxe est la suivante :

nslookup HOTE_A_RESOUDRE SERVEUR_DNS_A_UTILISER

Par exemple :

nslookup www.example.org 8.8.8.8

Le rĂ©sultat est le mĂȘme, mais la rĂ©solution DNS est alors traitĂ©e par le serveur donné :

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

኿


Navigation / 2 ⋙ 61

Les anciens billets sont Ă©galement disponibles dans les archives.

â„č 2006 - 2020 | 🕾 Retour Ă  l'accueil du domaine | 🏡 Retour Ă  l'accueil du blog