One place for hosting & domains

      Comment utiliser SSH pour se connecter à un serveur distant


      Introduction

      L’un des outils essentiels à maîtriser en tant qu’administrateur système est le SSH.

      SSH, ou Secure Shell, est un protocole utilisé pour se connecter en toute sécurité à des systèmes distants. C’est le moyen le plus courant d’accéder à des serveurs Linux distants.

      Dans ce guide, nous verrons comment utiliser SSH pour se connecter à un système distant.

      Syntaxe de base

      Pour se connecter à un système distant utilisant SSH, nous utiliserons la commande ssh.  La forme la plus élémentaire de la commande est :

      Le remote_host dans cet exemple est l'adresse IP ou le nom de domaine auquel vous essayez de vous connecter.

      Cette commande suppose que votre nom d'utilisateur sur le système distant est le même que votre nom d'utilisateur sur votre système local.

      Si votre nom d'utilisateur est différent sur le système distant, vous pouvez le spécifier en utilisant cette syntaxe :

      • ssh remote_username@remote_host

      Une fois que vous vous êtes connecté au serveur, il peut vous être demandé de vérifier votre identité en fournissant un mot de passe. Plus tard, nous verrons comment générer des clés à utiliser à la place des mots de passe.

      Pour quitter la session ssh et revenir dans votre session shell locale, tapez :

      SSH fonctionne en connectant un programme client à un serveur ssh, appelé sshd.

      Dans la section précédente, ssh était le programme client. Le serveur ssh fonctionne déjà sur le remote_host que nous avons spécifié.

      Sur votre serveur, le sshd devrait déjà fonctionner. Si ce n'est pas le cas, vous devrez peut-être accéder à votre serveur via une console Web ou une console série locale.

      Le processus nécessaire pour démarrer un serveur ssh dépend de la distribution de Linux que vous utilisez.

      Sur Ubuntu, vous pouvez démarrer le serveur ssh en tapant :

      Cela devrait démarrer le serveur sshd et vous pourrez alors vous connecter à distance.

      Lorsque vous modifiez la configuration de SSH, vous modifiez les paramètres du serveur sshd.

      Dans Ubuntu, le fichier de configuration principal de sshd se trouve à /etc/ssh/sshd_config.

      Sauvegardez la version actuelle de ce fichier avant de l'éditer :

      • sudo cp /etc/ssh/sshd_config{,.bak}

      Ouvrez-le avec un éditeur de texte :

      • sudo nano /etc/ssh/sshd_config

      Il est préférable de laisser de côté la plupart des options de ce dossier. Cependant, il y en a quelques-uns que vous voudrez peut-être examiner :

      /etc/ssh/sshd_config

      Port 22
      

      La déclaration de port précise sur quel port le serveur sshd écoutera les connexions. Par défaut, il s'agit de 22. Vous devriez probablement ne pas toucher à ce paramètre, à moins que vous n'ayez des raisons spécifiques de faire autrement. Si vous **changez de port, nous vous montrerons comment vous connecter au nouveau port par la suite.

      /etc/ssh/sshd_config

      HostKey /etc/ssh/ssh_host_rsa_key
      HostKey /etc/ssh/ssh_host_dsa_key
      HostKey /etc/ssh/ssh_host_ecdsa_key
      

      Les déclarations de clés d'hôtes précisent où chercher les clés d'hôtes globales. Nous discuterons plus tard de ce qu'est une clé d'hôte.

      /etc/ssh/sshd_config

      SyslogFacility AUTH
      LogLevel INFO
      

      Ces deux éléments indiquent le niveau connexion qui devrait avoir lieu.

      Si vous avez des difficultés avec SSH, augmenter le nombre de connexions peut être un bon moyen de découvrir quel est le problème.

      /etc/ssh/sshd_config

      LoginGraceTime 120
      PermitRootLogin yes
      StrictModes yes
      

      Ces paramètres précisent certaines des informations de connexion.

      LoginGraceTime précise combien de secondes pour maintenir la connexion active sans se connecter avec succès.

      Il peut être judicieux de fixer ce temps juste un peu plus élevé que le temps qu'il vous faut pour vous connecter normalement.

      PermitRootLogin sélectionne si le root user est autorisé à se connecter.

      Dans la plupart des cas, il faut passer à no lorsque vous avez créé un compte d'utilisateur qui a accès à des privilèges élevés (via su ou sudo) et peut se connecter via ssh.

      strictModes est un garde de sécurité qui refusera une tentative de connexion si les fichiers d'authentification sont lisibles par tous.

      Cela permet d'éviter les tentatives de connexion lorsque les fichiers de configuration ne sont pas sécurisés.

      /etc/ssh/sshd_config

      X11Forwarding yes
      X11DisplayOffset 10
      

      Ces paramètres configurent une capacité appelée X11 Forwarding. Cela vous permet de visualiser l'environnement graphique (GUI) d'un système distant sur le système local.

      Cette option doit être activée sur le serveur et donnée avec le client SSH lors de la connexion avec l'option -X.

      Après avoir effectué vos modifications, enregistrez et fermez le fichier en tapant CTRL+X et Y, puis ENTER.

      Si vous avez modifié des paramètres dans /etc/ssh/sshd_config, veillez à recharger votre serveur sshd afin de mettre en œuvre vos modifications :

      • sudo systemctl reload ssh

      Vous devez tester vos changements de manière approfondie pour vous assurer qu'ils fonctionnent comme prévu.

      Il peut être judicieux d'avoir quelques séances actives lorsque vous effectuez des changements. Cela vous permettra de revenir sur la configuration si nécessaire.

      S'il est utile de pouvoir se connecter à un système à distance à l'aide de mots de passe, il est bien plus judicieux de mettre en place une authentification par clé.

      L'authentification par clé fonctionne en créant une paire de clés : une clé privée et une clé publique.

      La clé privée se trouve sur la machine du client et est sécurisée et gardée secrète.

      La clé publique peut être donnée à n'importe qui ou placée sur n'importe quel serveur auquel vous souhaitez accéder.

      Lorsque vous tentez de vous connecter à l'aide d'une paire de clés, le serveur utilise la clé publique pour créer un message pour l'ordinateur client qui ne peut être lu qu'avec la clé privée.

      L'ordinateur client renvoie alors la réponse appropriée au serveur et celui-ci saura que le client est légitime.

      Tout ce processus se fait automatiquement après l'installation des clés.

      Les clés SSH doivent être générées sur l'ordinateur duquel vous souhaitez vous connecter**. Il s'agit généralement de votre machine locale.

      Entrez ce qui suit dans la ligne de commande :

      Appuyez sur la touche Entrée pour accepter les valeurs par défaut. Vos clés seront créées à l'adresse ~/.ssh/id_rsa.pub et ~/.ssh/id_rsa.

      Passez dans le répertoire .ssh en tapant :

      Regardez les autorisations des fichiers :

      Output

      -rw-r--r-- 1 demo demo 807 Sep 9 22:15 authorized_keys -rw------- 1 demo demo 1679 Sep 9 23:13 id_rsa -rw-r--r-- 1 demo demo 396 Sep 9 23:13 id_rsa.pub

      Comme vous pouvez le voir, le fichier id_rsa est lisible et accessible en écriture uniquement au propriétaire.  C'est pour cela qu'il doit être gardé secret.

      Le fichier id_rsa.pub, cependant, peut être partagé et dispose de permissions appropriées pour cette activité.

      Si vous avez actuellement un accès par mot de passe à un serveur, vous pouvez y copier votre clé publique en émettant cette commande :

      Cela permettra de démarrer une session SSH. Après que vous ayez entré votre mot de passe, il copiera votre clé publique dans le fichier des clés autorisées du serveur, ce qui vous permettra de vous connecter sans mot de passe la prochaine fois.

      Options côté client

      Il existe un certain nombre d'indicateurs optionnels que vous pouvez sélectionner lorsque vous vous connectez via SSH.

      Certains d'entre eux peuvent être nécessaires pour correspondre aux paramètres de la configuration sshd de l'hôte distant.

      Par exemple, si vous avez changé le numéro de port dans votre sshd, vous devrez faire correspondre ce port côté client en tapant :

      • ssh -p port_number remote_host

      Si vous ne souhaitez exécuter qu'une seule commande sur un système distant, vous pouvez la spécifier après l'hôte comme cela :

      • ssh remote_host command_to_run

      Vous vous connecterez à la machine distante, vous vous authentifierez, et la commande sera exécutée.

      Comme nous l'avons déjà dit, si la transmission X11 est activée sur les deux ordinateurs, vous pouvez accéder à cette fonctionnalité en tapant :

      Si vous disposez des outils appropriés sur votre ordinateur, les programmes de l'environnement graphique que vous utilisez sur le système distant ouvriront désormais leur fenêtre sur votre système local.

      Désactiver l'authentification par mot de passe

      Si vous avez créé des clés SSH, vous pouvez renforcer la sécurité de votre serveur en désactivant l'authentification uniquement par mot de passe. En dehors de la console, la seule façon de se connecter à votre serveur est d'utiliser la clé privée qui se couple avec la clé publique que vous avez installée sur le serveur.

      Avertissement : Avant de procéder à cette étape, assurez-vous que vous avez installé une clé publique pour votre serveur. Sinon, vous serez bloqué à l'extérieur !

      En tant que root ou utilisateur avec des privilèges sudo, ouvrez le fichier de configuration sshd :

      • sudo nano /etc/ssh/sshd_config

      Localisez la ligne qui indique Password Authenticationet la décommenter en supprimant le premier #. Vous pouvez alors changer sa valeur à no :

      /etc/ssh/sshd_config

      PasswordAuthentication no
      

      Deux autres paramètres qui ne devraient pas avoir à être modifiés (à condition que vous n'ayez pas modifié ce fichier auparavant) sont PubkeyAuthentification et ChallengeResponseAuthentification. Elles sont définies par défaut et doivent se lire comme suit :

      /etc/ssh/sshd_config

      PubkeyAuthentication yes
      ChallengeResponseAuthentication no
      

      Après avoir effectué vos modifications, enregistrez et fermez le fichier.

      Vous pouvez maintenant recharger le démon SSH :

      • sudo systemctl reload ssh

      L'authentification par mot de passe devrait maintenant être désactivée, et votre serveur ne devrait être accessible que via l'authentification par clé SSH.

      Conclusion

      Apprendre à s'orienter au sein de SSH en vaut la peine, ne serait-ce que parce c'est un processus de routine.

      Au fur et à mesure que vous utiliserez les différentes options, vous découvrirez des fonctionnalités plus avancées qui peuvent vous faciliter la vie. SSH est resté populaire parce qu'il est sûr, léger et utile dans diverses situations.



      Source link

      Comment utiliser Systemctl pour gérer les services et les unités de Systemd


      Introduction

      systemd est un gestionnaire de systèmes d’initialisation et de systèmes qui est devenu la nouvelle norme pour les distributions de Linux. Étant largement adopté, cela vaut la peine de se familiariser avec systemd car l’administration de serveurs vous sera considérablement plus facile. En apprendre davantage sur les outils et les démons qui composent systemd vous permettra de mieux apprécier la puissance, la flexibilité et les capacités qu’il vous offre ou, tout du moins, de travailler avec un minimum de tracas.

      Au cours de ce guide, nous allons discuter de la commande systemctl, qui est l’outil de gestion essentiel pour contrôler le système d’initialisation. Nous allons voir de quelle la manière vous pouvez gérer les services, vérifier les états, modifier les états du système et travailler avec les fichiers de configuration.

      Notez que, bien que systemd soit devenu le système d’initialisation par défaut de nombreuses distributions Linux, il n’est pas universellement implémenté sur toutes les distributions. Si au cours de ce tutoriel votre terminal déclenche l’erreur bash: systemctl is not installed, il est alors probable que votre machine ait installé un système d’initialisation.

      Gestion de service

      L’objectif fondamental d’un système d’initialisation est d’initialiser les composants qui doivent être démarrés une fois que le noyau Linux est lancé (traditionnellement connus sous le nom de composants « userland »). De plus, le système d’initialisation vous permet de gérer à tout moment les services et les démons du serveur alors que le système est en marche. Dans cette optique, nous allons commencer par certaines des opérations de base de gestion de service.

      Dans systemd, la cible de la plupart des actions sont des « unités », c’est-à-dire des ressources que systemd sait gérer. Les unités sont classées par le type de ressources qu’elles représentent. Leur configuration se fait avec des fichiers que l’on appelle des « fichiers de l’unité ». Vous pouvez déduire le type de chaque unité à l’aide du suffixe qui se trouve à la fin du fichier.

      Pour les tâches de gestion de service, l’unité cible correspondra aux unités de service pour lesquelles les fichiers de l’unité se terminent par le suffixe .service. Cependant, en réalité, pour la plupart des commandes de gestion de service, vous n’avez pas nécessairement besoin du suffixe .service. En effet, systemd est assez intelligent pour savoir que, lorsque vous utilisez les commandes de gestion de service, vous souhaitez probablement travailler sur un service.

      Démarrage et arrêt des services

      Si vous souhaitez démarrer un service systemd en exécutant les instructions qui se trouvent dans le fichier de l’unité du service, utilisez la commande start. Si vous opérez comme un non-root user, vous devrez utiliser sudo car cela affectera l’état du système d’exploitation :

      • sudo systemctl start application.service

      Comme nous l’avons précédemment mentionné, étant donné que systemd sait qu’il doit rechercher les fichiers *.service pour les commandes de gestion de service, il vous suffirait de saisir la commande de la manière suivante :

      • sudo systemctl start application

      Même si, à des fins d’administration générale, vous pouvez utiliser le format ci-dessus, nous allons utiliser le suffixe .service pour le reste des commandes par soucis de clarté afin de définir clairement la cible sur laquelle nous travaillons.

      Pour arrêter un service en cours d’exécution, vous pouvez plutôt utiliser la commande stop :

      • sudo systemctl stop application.service

      Redémarrage et rechargement

      Pour redémarrer un service en cours d’exécution, vous pouvez utiliser la commande restart :

      • sudo systemctl restart application.service

      Si l’application en question est en capacité de recharger ses fichiers de configuration (sans redémarrage), vous pouvez lancer la commande reload pour initier ce processus :

      • sudo systemctl reload application.service

      Si vous ne savez pas si le service intègre la fonctionnalité qui lui permet de recharger sa configuration, vous pouvez lancer la commande reload-or-restart Si disponible, vous rechargerez la configuration en place. Sinon, le service redémarrera pour récupérer la nouvelle configuration :

      • sudo systemctl reload-or-restart application.service

      Activation et désactivation des services

      Les commandes ci-dessus vous seront utiles pour démarrer ou arrêter des services pendant la session en cours. Vous devez les activer pour demander à systemd de lancer automatiquement les services au démarrage.

      Pour lancer un service au démarrage, utilisez la commande enable :

      • sudo systemctl enable application.service

      Cela créera un lien symbolique à partir de la copie du fichier de service du système (généralement dans /lib/systemd/system ou /etc/systemd/system) à l’emplacement du disque où systemd cherche les fichiers de démarrage automatique (généralement /etc/systemd/system/some_target.target.wants. Nous verrons ce qu’est une cible plus tard dans ce guide).

      Pour désactiver le démarrage automatique d’un service, vous pouvez saisir :

      • sudo systemctl disable application.service

      Cela supprimera le lien symbolique indiquant que le service doit être démarré automatiquement.

      N’oubliez pas que l’activation du service ne le déclenche pas pendant la session en cours. Si vous souhaitez démarrer le service et, dans le même temps, l’activer au démarrage, vous devez lancer à la fois la commande start et la commande enable.

      Vérification de l’état des services

      Pour vérifier l’état d’un service sur votre système, vous pouvez utiliser la commande status :

      • systemctl status application.service

      Vous pourrez ainsi consulter l’état des services, la hiérarchie des groupes et les premières lignes du journal.

      Par exemple, lorsque vous souhaitez vérifier l’état d’un serveur Nginx, le résultat peut s’afficher comme suit :

      Output

      ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago Main PID: 495 (nginx) CGroup: /system.slice/nginx.service ├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr; └─496 nginx: worker process Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server... Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server.

      Cela vous donne un bon aperçu de l’état actuel de l’application, vous signalant tout problème et toute action à mettre en œuvre.

      Certaines méthodes vous permettent également de contrôler des états spécifiques. Par exemple, si vous souhaitez vérifier si une unité est actuellement active (en cours d’exécution), vous pouvez utiliser la commande is-active :

      • systemctl is-active application.service

      Cela renverra l’état actuel de l’unité, qui est généralement active ou inactive. Si elle est active, le code de sortie affichera « 0 », ce qui simplifie l’analyse dans les scripts shell.

      Pour voir si l’unité est activée, vous pouvez utiliser la commande is-enabled :

      • systemctl is-enabled application.service

      Vous pourrez ainsi voir si le service est enabled ou disabled et le code de sortie sera à nouveau configuré sur « 0 » ou « 1 » en fonction de la réponse à la question de la commande.

      Une troisième vérification consiste à voir si l’état de l’unité indique un échec. Cela indique qu’un problème est survenu au démarrage de l’unité en question :

      • systemctl is-failed application.service

      Cela reverra active si l’exécution se fait correctement ou failed si une erreur survient. Si l’unité est intentionnellement arrêtée, elle peut renvoyer unknown ou inactive. Le statut de sortie « 0 » indique qu’une défaillance est survenue. Le statut de sortie « 1 » indique tout autre statut.

      Présentation générale des états du système

      Jusqu’à présent, les commandes nous ont permis de gérer des services uniques, mais pas vraiment de consulter l’état actuel du système. Il existe un certain nombre de commandes systemctl qui vous donnent ces informations.

      Liste des unités en cours d’utilisation

      Pour avoir une liste de toutes les unités actives que systemd reconnaît, nous pouvons utiliser la commande list-units :

      Cela affichera une liste de toutes les unités considérées comme actives par systemd sur le système. La sortie finale ressemblera à peu près à ceci :

      Output

      UNIT LOAD ACTIVE SUB DESCRIPTION atd.service loaded active running ATD daemon avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack dbus.service loaded active running D-Bus System Message Bus dcron.service loaded active running Periodic Command Scheduler dkms.service loaded active exited Dynamic Kernel Modules System getty@tty1.service loaded active running Getty on tty1 . . .

      La sortie affiche les colonnes suivantes :

      • UNIT : le nom de l'unité systemd
      • LOAD : si la configuration de l'unité a été analysée par systemd. La configuration des unités chargées est gardée en mémoire.
      • ACTIVE : un état résumé indiquant si l'unité est active. Il s'agit généralement d'une méthode assez simple d'établir si l'unité a bien démarré ou pas.
      • SUB : il s'agit d'un état de niveau inférieur qui donne des informations plus détaillées sur l'unité. Il varie souvent en fonction du type, de l'état et du mode de fonctionnement réel de l'unité.
      • DESCRIPTION : une courte description textuelle de ce que l'unité est/fait.

      Étant donné que la commande list-units affiche uniquement les unités actives par défaut, toutes les entrées ci-dessus afficheront loaded dans la colonne LOAD et active dans la colonne ACTIVE. Cet affichage correspond en réalité au comportement par défaut de systemctl lorsque vous l'appelez sans commandes supplémentaires. Vous verrez donc la même chose se produire si vous appelez systemctl sans arguments :

      Nous pouvons instruire systemctl de générer des informations différentes en ajoutant des balises supplémentaires. Par exemple, pour consulter toutes les unités que systemd a chargées (ou tente de charger), qu'elles soient actuellement actives ou pas, vous pouvez utiliser la balise --all comme suit :

      • systemctl list-units --all

      Cela affichera toute unité que systemd a chargée ou tenté de charger, quel que soit l'état actuel du système. Certaines unités deviennent inactives après leur exécution et il se peut que certaines autres, celles que systemd a tenté de charger, restent introuvables sur le disque.

      Vous pouvez filtrer ces résultats en utilisant d'autres balises. Par exemple, nous pouvons utiliser la balise --state= pour indiquer les états LOAD, ACTIVE ou SUB que nous souhaitons consulter. Nous allons devoir garder la balise --all pour que systemctl permette l'affichage des unités inactives :

      • systemctl list-units --all --state=inactive

      Un autre filtre est couramment utilisé, le filtre --type=. Nous pouvons indiquer à systemctl d'afficher uniquement le type d'unités qui nous intéresse. Par exemple, pour consulter uniquement les unités de service actives, nous pouvons utiliser :

      • systemctl list-units --type=service

      Liste de tous les fichiers de l'unité

      La commande list-units affiche uniquement les unités que systemd a tentées d'analyser et de charger en mémoire. Étant donné que systemd lira uniquement les unités dont il pense avoir besoin, les unités disponibles sur le système ne seront pas nécessairement toutes répertoriées. Pour voir tous les fichiers de l'unité disponibles au sein des chemins de systemd, notamment ceux que systemd n'a pas tenté de charger, vous pouvez utiliser la commande list-unit-files à la place :

      • systemctl list-unit-files

      Les unités sont des représentations des ressources dont systemd a connaissance. Étant donné que systemd n'a pas nécessairement lu toutes les définitions de l'unité dans cet écran, seules les informations concernant les fichiers en eux-mêmes sont présentées. La sortie a deux colonnes : le fichier de l'unité et l'état.

      Output

      UNIT FILE STATE proc-sys-fs-binfmt_misc.automount static dev-hugepages.mount static dev-mqueue.mount static proc-fs-nfsd.mount static proc-sys-fs-binfmt_misc.mount static sys-fs-fuse-connections.mount static sys-kernel-config.mount static sys-kernel-debug.mount static tmp.mount static var-lib-nfs-rpc_pipefs.mount static org.cups.cupsd.path enabled . . .

      L'état indiquera généralement enabled, disabled, static ou masked. Dans ce contexte, static signifie que le fichier de l'unité ne contient pas de section install, qui sert à activer une unité. De ce fait, ces unités ne peuvent pas être activées. Habituellement, cela signifie que soit l'unité effectue une action unique, soit elle est uniquement utilisée qu'en tant que dépendance d'une autre unité et ne doit pas être exécutée seule.

      Nous allons voir dans un moment ce que masked signifie.

      Gestion de l'unité

      Jusque-là, nous avons travaillé avec les services et affiché des informations sur l'unité et sur les fichiers de l'unité dont systemd a connaissance. Cependant, en utilisant d'autres commandes, nous pouvons trouver des informations plus spécifiques sur les unités.

      Affichage du fichier de l'unité

      Pour afficher le fichier de l'unité que systemd a chargé sur son système, vous pouvez utiliser la commande cat qui a été ajoutée dans la version 209 de systemd). Par exemple, pour voir le fichier de l'unité de démon de planification atd, nous pourrions saisir :

      • systemctl cat atd.service

      Output

      [Unit] Description=ATD daemon [Service] Type=forking ExecStart=/usr/bin/atd [Install] WantedBy=multi-user.target

      On obtient ainsi le fichier de l'unité tel que reconnu par le processus systemd en cours d'exécution. Cela peut s'avérer important si vous avez récemment modifié des fichiers de l'unité ou si vous écrasez certaines options dans un fragment du fichier de l'unité (nous allons couvrir cela plus tard).

      Affichage des dépendances

      Pour voir une arborescence des dépendances de l'unité, vous pouvez utiliser la commande list-dependencies :

      • systemctl list-dependencies sshd.service

      Cela affichera une cartographie hiérarchisée des dépendances qui doivent être traitées afin de démarrer l'unité concernée. Dans ce contexte, les dépendances incluent les unités qui sont soit requises ou souhaitées par les unités au-dessus.

      Output

      sshd.service ├─system.slice └─basic.target ├─microcode.service ├─rhel-autorelabel-mark.service ├─rhel-autorelabel.service ├─rhel-configure.service ├─rhel-dmesg.service ├─rhel-loadmodules.service ├─paths.target ├─slices.target . . .

      Les dépendances récursives s'affichent uniquement pour .target, qui indique les états du système. Pour lister de manière récursive toutes les dépendances, ajoutez la balise --all.

      Pour afficher les dépendances inverses (les unités qui dépendent de l'unité spécifiée), vous pouvez ajouter la balise --reverse à la commande. D'autres balises vous seront utiles : --before et --after. Vous pouvez les utiliser pour afficher les unités qui dépendent de l'unité spécifiée qui a démarré avant et après elles, respectivement.

      Vérification des propriétés de l'unité

      Pour consulter les propriétés de niveau inférieur d'une unité, vous pouvez utiliser la commande show. Elle affichera une liste de propriétés configurées pour l'unité spécifiée en utilisant un format key=value :

      • systemctl show sshd.service

      Output

      Id=sshd.service Names=sshd.service Requires=basic.target Wants=system.slice WantedBy=multi-user.target Conflicts=shutdown.target Before=shutdown.target multi-user.target After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice Description=OpenSSH server daemon . . .

      Pour afficher une seule propriété, vous pouvez faire utiliser la balise -p accompagnée du nom de la propriété. Par exemple, pour voir les conflits que l'unité sshd.service a, vous pouvez saisir :

      • systemctl show sshd.service -p Conflicts

      Output

      Conflicts=shutdown.target

      Masquage et affichage des unités

      Dans la section Gestion de service, nous avons vu de quelle manière arrêter ou désactiver un service, mais systemd a également la possibilité de marquer une unité comme étant totalement impossible à démarrer, automatiquement ou manuellement, en la reliant à /dev/null. On dit alors que l'on « masque » l'unité, et il est possible de le faire avec la commande mask :

      • sudo systemctl mask nginx.service

      Tant qu'elle est masquée, tout démarrage automatique ou manuel du service Nginx est impossible.

      Si vous vérifiez la list-unit-files, vous verrez que le service est maintenant répertorié comme étant masqué :

      • systemctl list-unit-files

      Output

      . . . kmod-static-nodes.service static ldconfig.service static mandb.service static messagebus.service static nginx.service masked quotaon.service static rc-local.service static rdisc.service disabled rescue.service static . . .

      Si vous tentez de lancer le service, vous verrez s'afficher le message suivant :

      • sudo systemctl start nginx.service

      Output

      Failed to start nginx.service: Unit nginx.service is masked.

      Pour afficher une unité et rendre son utilisation à nouveau possible, utilisez la commande unmask :

      • sudo systemctl unmask nginx.service

      Cela renverra l'unité à l'état précédent, ce qui lui permettra son démarrage ou son activation.

      Modification des fichiers de l'unité

      Bien que ce tutoriel ne traite pas du format spécifique des fichiers de l'unité, systemctl met à votre disposition des mécanismes intégrés d'édition et de modification des fichiers de l'unité pour vous permettre de faire des réglages. Cette fonctionnalité a été ajoutée dans la version 218 de systemd.

      Par défaut, la commande edit ouvrira le fragment de code du fichier de l'unité concerné :

      • sudo systemctl edit nginx.service

      Il s'agira d'un fichier vierge qui pourra être utilisé pour remplacer ou ajouter des directives à la définition de l'unité. Un répertoire sera créé dans le répertoire /etc/systemd/systemd qui contient le nom de l'unité avec un .d annexé. Par exemple, pour le nginx.service, un répertoire appelé nginx.service.d sera créé.

      Au sein de ce répertoire, un fragment de code appelé override.conf sera créé. Une fois l'unité chargée, systemd fusionnera, en mémoire, le fragment de code de remplacement avec le fichier de l'unité dans son intégralité. Les directives du fragment de code auront la priorité sur celles qui se trouvent dans le fichier de l'unité d'origine.

      Si vous souhaitez modifier l'intégralité du fichier de l'unité au lieu de créer un fragment de code, vous pouvez passer la balise --full.

      • sudo systemctl edit --full nginx.service

      Cela chargera le fichier de l'unité actuelle dans l'éditeur dans lequel vous pouvez le modifier. Lorsque l'éditeur se ferme, le fichier modifié sera écrit dans /etc/systemd/system, ce qui aura la priorité sur la définition de l'unité du système (qui se trouve généralement dans /lib/systemd/system).

      Pour supprimer tous les ajouts que vous avez effectués, vous pouvez supprimer soit le répertoire de configuration de l'unité .d ou le fichier de service modifié de /etc/systemd/system. Par exemple, pour supprimer un fragment de code, nous pourrions saisir :

      • sudo rm -r /etc/systemd/system/nginx.service.d

      Pour supprimer un fichier complet de l'unité modifié, il faudrait entrer :

      • sudo rm /etc/systemd/system/nginx.service

      Après avoir supprimé le fichier ou le répertoire, vous devez recharger le processus systemd pour qu'il ne tente plus de référencer ces fichiers et réutilise les copies du système. Vous pouvez le faire en tapant :

      • sudo systemctl daemon-reload

      Réglage de l'état du système (niveau d'exécution) avec des cibles

      Les cibles sont des fichiers spéciaux de l'unité qui décrivent un état ou un point de synchronisation du système. Comme avec les autres unités, les fichiers qui définissent des cibles peuvent être identifiés par leur suffixe, dans ce cas .target. Seules, les cibles ne font pas grand-chose, mais elles permettent de regrouper d'autres unités ensemble.

      Vous pouvez les utiliser pour mettre le système dans certains états, tout comme les autres systèmes d'initialisation utilisent les niveaux d'exécution. Elles servent de référence lorsque certaines fonctions sont disponibles. Elles vous permettent ainsi de spécifier l'état souhaité au lieu d'avoir à spécifier les unités individuellement pour produire cet état.

      Par exemple, il existe un swap.target qui est utilisé pour indiquer que le swap est prêt à être utilisé. Les unités qui font partie de ce processus peuvent se synchroniser avec cette cible en indiquant dans leur configuration qu'elles sont WantedBy= ou RequiredBy= le swap.target. Les unités qui nécessitent la disponibilité d'un swap peuvent spécifier cette condition en utilisant les spécifications Wants=, Requires=, et After= pour indiquer la nature de leur relation.

      Obtention et configuration de la cible par défaut

      Le processus systemd a une cible par défaut qu'il utilise au lancement du système. En satisfaisant la cascade des dépendances de cette cible unique, le système est amené à l'état souhaité. Pour trouver la cible par défaut de votre système, saisissez :

      Output

      multi-user.target

      Au besoin, pour configurer une autre cible par défaut, vous pouvez utiliser le set-default. Par exemple, si vous avez installé un bureau graphique et que vous souhaitez que le système s'y lance par défaut, vous pouvez modifier votre cible par défaut en conséquence :

      • sudo systemctl set-default graphical.target

      Liste des cibles disponibles

      Vous pouvez obtenir une liste des cibles disponibles sur votre système en saisissant :

      • systemctl list-unit-files --type=target

      Contrairement aux niveaux d'exécution, plusieurs cibles peuvent être actives à la fois. Une cible active indique que systemd a tenté de lancer toutes les unités liées à la cible et n'a pas encore réessayé de les détruire. Pour voir toutes les cibles actives, entrez :

      • systemctl list-units --type=target

      Isolation des cibles

      Il est possible de lancer toutes les unités associées à une cible et d'arrêter toutes celles qui ne font pas partie de l'arborescence de dépendance. La commande dont nous avons besoin pour cela s'appelle, comme il se doit, isolate. Le processus est similaire à celui qui permet de changer le niveau d'exécution sur les autres systèmes d'initialisation.

      Par exemple, si vous opérez dans un environnement graphique dans lequel graphical.target est active, vous pouvez arrêter le système graphique et mettre le système dans un état de ligne de commande multi-utilisateur en isolant le multi-user.target. Étant donné que graphical.target dépend de multi-user.target, mais pas l'inverse, toutes les unités graphiques seront arrêtées.

      Il est conseillé de consulter les dépendances de la cible que vous isolez avant d'effectuer cette procédure afin de s'assurer de ne pas arrêter les services essentiels :

      • systemctl list-dependencies multi-user.target

      Une fois satisfait des unités qui seront restées actives, vous pouvez isoler la cible en saisissant le texte suivant :

      • sudo systemctl isolate multi-user.target

      Utilisation de raccourcis pour les événements importants

      Il existe des cibles définies pour les événements importants comme la mise à l'arrêt ou le redémarrage. Cependant, systemctl intègre également quelques raccourcis qui ajoutent quelques fonctionnalités supplémentaires.

      Par exemple, pour mettre le système en mode sauvetage (utilisateur unique), vous pouvez utiliser la commande rescue au lieu de isolate rescue.target :

      Cela permettra d'avoir une fonctionnalité supplémentaire qui avertira tous les utilisateurs connectés de l'événement.

      Pour arrêter le système, vous pouvez utiliser la commande halt :

      Pour lancer un arrêt complet, vous pouvez utiliser la commande poweroff :

      Vous pouvez déclencher un redémarrage avec la commande reboot :

      Ces fonctionnalités avertiront les utilisateurs que l'événement est en cours, ce qui ne se fera pas en exécutant ou isolant uniquement la cible. Notez que la plupart des machines relieront les commandes les plus courtes et les plus classiques de ces opérations afin qu'elles fonctionnent correctement avec systemd.

      Par exemple, pour redémarrer le système, vous pouvez généralement taper :

      Conclusion

      Maintenant, vous devriez vous être familiarisé avec certaines des capacités de base de la commande systemctl qui vous permettent d'interagir avec votre instance systemd et de la contrôler. L'utilitaire systemctl sera votre principal point d'interaction pour gérer l'état des services et l'état du système.

      Bien que systemctl fonctionne principalement avec le processus de base systemd, il existe d'autres composants de l'écosystème systemd qui sont contrôlés par d'autres utilitaires . D'autres capacités, comme la gestion des journaux et les sessions utilisateur, sont traitées par des démons et des utilitaires de gestion distincts (journald/journalctl et (logind/loginctl respectivement). Prenez le temps de vous familiariser avec les autres outils et démons pour que la gestion soit plus facile.



      Source link

      Comment utiliser SFTP pour transférer des fichiers en toute sécurité avec un serveur distant


      Introduction

      FTP, ou « File Transfer Protocol » (protocole de transfert de fichiers) était une méthode non cryptée populaire utilisée pour transérer des fichiers entre deux systèmes distants.

      SFTP, qui signifie SSH File Transfer Protocol (protocole de transfert de fichiers SSH ou protocole de transfert de fichiers sécurisé) est un protocole distinct intégrant SSH, qui fonctionne de manière similaire mais via une connexion sécurisée. Il présente l’avantage de pouvoir tirer parti d’une connexion sécurisée pour transférer des fichiers et traverser le système de fichiers à la fois sur le système local et sur le système distant.

      Dans la plupart des cas, il est préférable d’utiliser le SFTP au lieu du FTP, en raison de ses fonctionnalités de sécurité sous-jacentes et de sa capacité à se greffer sur une connexion SSH. FTP est un protocole non sécurisé qui ne doit être utilisé que dans certains cas ou sur des réseaux de confiance.

      Bien que le SFTP soit intégré à de nombreux outils graphiques, ce guide vous expliquera de quelle manière l’utiliser via son interface de ligne de commande interactive.

      SFTP utilise le protocole SSH par défaut pour s’authentifier et établir une connexion sécurisée. Pour cette raison, les mêmes méthodes d’authentification que celles présentes dans SSH sont mises à disposition.

      Bien que les mots de passe soient faciles à utiliser et configurés par défaut, nous vous recommandons de créer des clés SSH et de transférer votre clé publique à tous les systèmes auxquels vous devez accéder. Cette méthode est bien plus sécurisée et vous permet de gagner du temps sur le long terme.

      Veuillez vous reporter à ce guide pour configurer des clés SSH et accéder ainsi à votre serveur, si vous ne l’avez pas encore fait.

      Si vous arrivez à vous connecter à la machine en utilisant SSH, cela signifie que vous avez rempli toutes les conditions requises pour gérer les fichiers à l’aide de SFTP. Testez l’accès à SSH à l’aide de la commande suivante :

      • ssh sammy@your_server_ip_or_remote_hostname

      Si cela fonctionne, ressortez en saisissant :

      Désormais, nous pouvons établir une session SFTP en émettant la commande suivante :

      • sftp sammy@your_server_ip_or_remote_hostname

      Votre connexion au système distant sera établie et votre invite se transformera en une invite SFTP.

      Si vous travaillez sur un port SSH personnalisé (et non pas sur le port 22 par défaut), vous pouvez alors ouvrir une session SFTP de la manière suivante  :

      • sftp -oPort=custom_port sammy@your_server_ip_or_remote_hostname

      Ceci établira votre connexion au système distant via le port que vous avez spécifié.

      Obtenir de l'aide dans SFTP

      La commande la plus utile que vous devez apprendre à utiliser en premier est la commande d'aide. Elle vous permet d'accéder à un résumé de l'aide de SFTP. Vous pouvez l'appeler en saisissant l'une ou l'autre des options suivantes dans l'invite :

      ou

      Une liste des commandes disponibles s'affichera :

      Output

      Available commands: bye Quit sftp cd path Change remote directory to 'path' chgrp grp path Change group of file 'path' to 'grp' chmod mode path Change permissions of file 'path' to 'mode' chown own path Change owner of file 'path' to 'own' df [-hi] [path] Display statistics for current directory or filesystem containing 'path' exit Quit sftp get [-Ppr] remote [local] Download file help Display this help text lcd path Change local directory to 'path' . . .

      Nous allons explorer certaines des commandes que vous allez aborder dans les sections suivantes.

      Un certain nombre de commandes qui fonctionnement de la même manière que leurs homologues shell nous permettent de naviguer dans la hiérarchie de fichiers du système distant.

      Tout d'abord, cherchons à savoir dans quel répertoire du système distant nous nous trouvons actuellement. Tout comme dans une session shell type, nous pouvons saisir ce qui suit pour obtenir le répertoire actuel :

      Output

      Remote working directory: /home/demouser

      Nous pouvons consulter le contenu du répertoire actuel du système distant à l'aide d'une autre commande commune :

      Output

      Summary.txt info.html temp.txt testDirectory

      Notez que les commandes de l'interface SFTP ne sont pas similaires aux commandes shell normales et ne sont pas aussi riches en fonctionnalités. Elles permettent cependant d'implémenter certaines des balises optionnelles les plus importantes :

      Output

      drwxr-xr-x 5 demouser demouser 4096 Aug 13 15:11 . drwxr-xr-x 3 root root 4096 Aug 13 15:02 .. -rw------- 1 demouser demouser 5 Aug 13 15:04 .bash_history -rw-r--r-- 1 demouser demouser 220 Aug 13 15:02 .bash_logout -rw-r--r-- 1 demouser demouser 3486 Aug 13 15:02 .bashrc drwx------ 2 demouser demouser 4096 Aug 13 15:04 .cache -rw-r--r-- 1 demouser demouser 675 Aug 13 15:02 .profile . . .

      Pour accéder à un autre répertoire, nous pouvons lancer la commande suivante :

      Maintenant que nous pouvons traverser le système de fichiers distant, qu'en est-il si nous devons accéder à notre système de fichiers local ? Nous pouvons diriger les commandes vers le système de fichiers local en les faisant précéder d'un l pour local.

      Toutes les commandes abordées jusqu'à maintenant disposent d'équivalents en local. Nous pouvons imprimer le répertoire de travail local :

      Output

      Local working directory: /Users/demouser

      Nous pouvons lister le contenu du répertoire actuel sur la machine locale :

      Output

      Desktop local.txt test.html Documents analysis.rtf zebra.html

      Nous pouvons également changer le répertoire avec lequel nous souhaitons interagir sur le système local :

      Transférer des fichiers avec SFTP

      L'utilité de la navigation dans les systèmes de fichiers distants et locaux reste limitée si nous ne pouvons pas transférer des fichiers entre les deux.

      Transférer des fichiers distants vers le système local

      Pour télécharger des fichiers à partir de notre hébergement local, vous pouvez passer la commande suivante :

      Output

      Fetching /home/demouser/remoteFile to remoteFile /home/demouser/remoteFile 100% 37KB 36.8KB/s 00:01

      Comme vous pouvez le voir, par défaut, la commande get télécharge un fichier distant vers un fichier qui porte le même nom sur le système de fichiers local.

      Nous pouvons copier le fichier distant en utilisant un autre nom, en spécifiant le nom par la suite :

      La commande get prend également en charge quelques balises d'option. Par exemple, nous pouvons copier un répertoire et l'intégralité de son contenu en spécifiant l'option récursive suivante :

      Nous pouvons dire au SFTP de maintenir les autorisations et les temps d'accès appropriés en utilisant la balise -P ou -p :

      Transférer des fichiers locaux vers le système distant

      Il est tout aussi facile de transférer des fichiers vers le système distant en utilisant la commande qui s'appelle, à juste titre, « put » :

      Output

      Uploading localFile to /home/demouser/localFile localFile 100% 7607 7.4KB/s 00:00

      Les mêmes balises que celles qui fonctionnent avec get s'appliquent à put. Donc, si vous souhaitez copier un répertoire local entier, vous pouvez lancer la commande suivante :

      Remarque: il existe actuellement un bogue dans les versions d'OpenSSH intégrant les versions actuelles d'Ubuntu (au moins 14.04 à 15.10), ce qui empêche la commande ci-dessus de fonctionner correctement. Une fois la commande ci-dessus lancée pour transférer le contenu vers un serveur en utilisant la version avec bogue d'OpenSSH, l'erreur suivante apparaîtra : Couldn't canonicalise: No such file or directory (Impossible à canonicaliser : pas de fichier ou de répertoire de ce type).

      Pour résoudre ce problème, créez le répertoire de destination tout d'abord du côté distant en saisissant mkdir localDirectory. Ensuite, la commande ci-dessus devrait s'exécuter sans erreur.

      La commande df est un outil pratique, communément utilisé pour télécharger et envoyer des fichiers. Elle fonctionne de la même manière que la version avec ligne de commande. Grâce à elle, vous pouvez vérifier si vous disposez d'assez d'espace pour procéder aux transferts que vous souhaitez effectuer :

      Output

      Size Used Avail (root) %Capacity 19.9GB 1016MB 17.9GB 18.9GB 4%

      Notez qu'il n'existe pas de variation locale de cette commande, mais nous pouvons contourner cela en émettant la commande ! .

      La commande ! nous amène dans un shell local, où nous pouvons exécuter toute commande disponible sur notre système local. Nous pouvons vérifier l'utilisation du disque en saisissant :

      et puis

      Output

      Filesystem Size Used Avail Capacity Mounted on /dev/disk0s2 595Gi 52Gi 544Gi 9% / devfs 181Ki 181Ki 0Bi 100% /dev map -hosts 0Bi 0Bi 0Bi 100% /net map auto_home 0Bi 0Bi 0Bi 100% /home

      Toute autre commande locale fonctionnera comme prévu. Pour revenir à votre session SFTP, saisissez :

      Maintenant, vous devriez voir apparaître l'invite SFTP.

      Manipulations simples de fichiers avec SFTP

      SFTP vous permet d'effectuer le type de maintenance de base sur les fichiers qui vous est utile lorsque vous travaillez avec des hiérarchies de fichiers.

      Par exemple, vous pouvez modifier le propriétaire d'un fichier sur le système distant en utilisant :

      À la différence de la commande chmod du système, vous remarquerez que la commande SFTP n'accepte pas les noms d'utilisateur, mais utilise des UID à la place. Malheureusement, il n'existe aucun moyen facile de connaître l'UID correspondant à partir de l'interface SFTP.

      Vous pourriez contourner le problème avec :

      • get /etc/passwd
      • !less passwd

      Output

      root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/bin/sh man:x:6:12:man:/var/cache/man:/bin/sh . . .

      Notez qu'au lieu d'utiliser la commande ! proprement dite, nous l'avons utilisée comme préfixe pour une commande shell locale. Cette méthode fonctionne pour exécuter toute commande disponible sur notre machine locale, et aurait pu être utilisée avec la commande df locale que nous avons abordée précédemment.

      L'UID se trouvera dans la troisième colonne du fichier, délimitée par des deux-points.

      De la même façon, nous pouvons modifier le propriétaire de groupe d'un fichier en utilisant :

      Encore une fois, il n'existe aucun moyen facile d'obtenir une liste des groupes du système distant. Nous pouvons le faire avec la commande suivante :

      • get /etc/group
      • !less group

      Output

      root:x:0: daemon:x:1: bin:x:2: sys:x:3: adm:x:4: tty:x:5: disk:x:6: lp:x:7: . . .

      La troisième colonne contient l'ID du groupe associé au nom de la première colonne. C'est ce que nous voulons.

      Heureusement, la commande chmod fonctionne comme prévu sur le système de fichiers distant :

      Output

      Changing mode on /home/demouser/publicFile

      Il n'existe aucune commande pour manipuler les autorisations des fichiers locaux, mais vous pouvez configurer l'umask local de manière à ce que tous les fichiers copiés sur le système local disposent des autorisations correspondantes.

      Pour cela, vous pouvez utiliser la commande lumask :

      Output

      Local umask: 022

      Maintenant, tous les fichiers réguliers téléchargés (sous réserve que la balise -p ne soit pas utilisée) auront 644 autorisations.

      SFTP vous permet de créer des répertoires sur des systèmes locaux et distants avec lmkdir et mkdir, respectivement. Ces commandes fonctionnent comme prévu.

      Le reste des commandes de fichier cible uniquement le système de fichiers distant :

      Ces commandes répliquent le comportement de base des versions shell. Si vous devez effectuer ces actions sur le système de fichiers local, n'oubliez pas que vous pouvez vous connecter à un shell en lançant la commande suivante :

      Ou exécutez une seule commande sur le système local en faisant précédant la commande d'un ! comme suit :

      Une fois que vous en aurez terminé avec votre session SFTP, utilisez exit ou bye pour mettre fin à la connexion.

      Conclusion

      Bien que SFTP soit un outil simple, il est très utile pour gérer des serveurs et transférer des fichiers entre eux.

      Par exemple, vous pouvez utiliser SFTP pour permettre à certains utilisateurs de transférer des fichiers sans accès SSH. Pour de plus amples informations sur ce processus, veuillez consulter notre tutoriel How To Enable SFTP Without Shell Access (Comment activer le SFTP sans accès au shell).

      Si vous avez l'habitude d'utiliser FTP ou SCP pour effectuer vos transferts, SFTP est un bon compromis pour pouvoir tirer parti des avantages que les deux ont à offrir. Bien qu'il ne soit pas adapté à toute situation, c'est un outil flexible à avoir dans votre répertoire.



      Source link