Comment utiliser Cloud-Config pour votre configuration initiale du serveur

introduction

Avec l'introduction desDigitalOcean metadata service, il est possible de commencer à configurer vos serveurs avant même de vous connecter. En bref, le service de métadonnées est un emplacement HTTP auquel votre serveur peut accéder pendant le processus de démarrage.

L’emplacement des métadonnées contiendra des données de base sur la configuration et l’environnement du serveur, telles que les adresses réseau, le nom d’hôte, etc. Lors de la configuration initiale, ces valeurs peuvent être abaissées par un programme appelécloud-init pour aider à configurer les services essentiels.

La fonctionnalité la plus puissante est que vous pouvez transmettre un script au service de métadonnées lorsque vous créez un serveur à l'aide d'un champ appeléuser-data. Ceci sera exécuté pendant le processus de démarrage initial et est très flexible, vous permettant d'accomplir tout ce que vous pouvez script.

Le type de script le plus courant à transmettre est appelé scriptcloud-config. Il s’agit d’un fichier au format YAML qui fournit des méthodes simples et lisibles pour la configuration d’éléments de configuration courants par déclaration. Il a également la possibilité d'exécuter des commandes arbitraires pour d'autres tâches.

Dans ce guide, nous nous familiariserons avec le service de métadonnées DigitalOcean et les fichierscloud-config en essayant un exemple simple. Nous allons recréer certaines des étapes décrites dans le guideinitial server setup for Ubuntu 14.04 afin de démontrer.

Buts

Afin de réussir à répliquer les étapes dans lesUbuntu 14.04 initial server setup guide, notre script devrait effectuer un certain nombre de tâches.

Le guide ci-dessus accomplit les tâches de base suivantes:

  • Changer le mot de passe de l'utilisateur root

  • Créer un nouvel utilisateur

  • Créer le mot de passe du nouvel utilisateur

  • Donner au nouvel utilisateur les privilèges root

  • (Facultatif) Modifiez le port sur lequel le démon SSH écoute.

  • (Facultatif) Restreindre la connexion SSH racine

  • (Facultatif) Autoriser explicitement notre nouvel utilisateur

Modification des objectifs pour s’adapter à l’environnement

Pour nos serveurs créés avec un fichiercloud-config, nous devrons modifier un peu nos objectifs. Toute information transmise via un fichiercloud-config est accessible à l'utilisateurany du système pendant toute la durée de vie du serveur.

Cela introduit un certain nombre de problèmes de sécurité qu'il est important de comprendre et de résoudre. Quelques points à garder à l'esprit sont:

  • Toutes les informations transmises dans voscloud-config sont accessibles à tous les utilisateurs du système. Ne placez rien de confidentiel dans vos fichierscloud-config.

  • Vous pouvez définir le mot de passe pour les utilisateurs existants, mais vous devez le transmettre en texte brut.

  • Pour les nouveaux utilisateurs, vous pouvez passer une version hachée d'un mot de passe, mais ces hachages peuvent être cassés très facilement avec du matériel moderne.

Avec ces choses à l'esprit, notre configuration doit faire tout son possible pour éviter de valider des mots de passe, sous quelque forme que ce soit, dans le fichiercloud-config. Nous pouvons ajuster nos objectifs pour répondre aux besoins spécifiques de notre environnement de déploiement.

Notre stratégie ajustée ressemblera à ceci:

  • Ne définissez aucun mot de passe et ne fournissez aucune clé SSH pour le compte root viacloud-config (toutes les clés SSH ajoutées via l'interface DigitalOcean seront toujours ajoutées comme d'habitude)

  • Créer un nouvel utilisateur

  • Définir aucun mot de passe pour le nouveau compte d'utilisateur

  • Configurer l'accès SSH pour le nouveau compte d'utilisateur

  • Donnez au nouvel utilisateur les privilèges sudo sans mot de passe pour effectuer des modifications administratives.

  • (Facultatif) Modifiez le port sur lequel le démon SSH écoute.

  • (Facultatif) Limitez la connexion SSH racine (en particulier si vous n'incluez pas de clés SSH via l'interface DigitalOcean).

  • (Facultatif) Autoriser explicitement notre nouvel utilisateur

Outre la suppression des mots de passe pour les deux comptes, le changement le plus radical ici est que le nouveau compte sera autorisé à utilisersudo sans entrer de mot de passe de compte. Cela est nécessaire car nous n'autorisons pas les connexions root et nous ne définissons pas de mot de passe pour le compte de notre nouvel utilisateur.

Une fois le nouvel utilisateur connecté, il sera libre de définir un mot de passe pour lui-même en toute sécurité et de modifier les privilèges sudo pour exiger un mot de passe, le cas échéant.

Avec ces objectifs ajustés à l’esprit, commençons.

Utilisation de fichiers de configuration en nuage

Un fichiercloud-config est essentiellement un fichier YAML qui comprend certaines directives. YAML est un format de sérialisation de données destiné à être très lisible par l'homme, le rendant simple à comprendre et à modifier.

Les fichiers YAML reposent sur quelques règles de formatage:

  • L'indentation avec des espaces blancs indique la structure et la relation des éléments les uns aux autres. Les éléments les plus en retrait sont les sous-éléments du premier élément avec un niveau d'indentation inférieur au-dessus d'eux.

  • Les membres de la liste peuvent être identifiés par un tiret.

  • Les entrées de tableau associatif sont créées à l'aide de deux points (:) suivis d'un espace et de la valeur.

  • Les blocs de texte sont en retrait. Pour indiquer que le bloc doit être lu tel quel, avec le formatage conservé, utilisez le caractère de canal (|) avant le bloc.

La première ligne d'un fichiercloud-config doit contenir un identifiant spécial pour que le programmecloud-init sache que le fichier est un fichiercloud-config. Cela ressemble à ceci:

#cloud-config

Cela doit être placé seul sur la toute première ligne. Le fichiercloud-config doit être fourni lors de la création du serveur. Cela peut être accompli de deux manières différentes.

N'oubliez pas que le service de métadonnées n'est disponible que dans les régions où le cloud 1.5 est déployé. De plus, la version de cloud-init nécessaire pour utiliser le champ de données utilisateur n'est actuellement disponible que dans Ubuntu 14.04 et CentOS 7, ainsi que dans les images d'application basées sur ces versions.

Via l'interface du panneau de commande, une case à cocher facultative permet d'activer les données utilisateur. Lorsque vous sélectionnez cette option, une zone de texte apparaîtra où vous pouvez coller votre fichiercloud-config:

DigitalOcean user data

Si vous utilisez l'API, l'objet JSON qui est transmis lors d'une demande de création peut utiliser un champ appeléuser_data. Par exemple, vous pouvez passer un objet JSON qui ressemble à ceci:

{
    "name": "test",
    "private_networking": true,
    "region": "nyc3",
    "size": "512mb",
    "image": "ubuntu-14-04-x64",
    "user_data":"#cloud-config
        config_data
        more_config"
    "ssh_keys":[ 12345,56789 ]
}

Ces deux méthodes fonctionnent exactement de la même manière dans la pratique, utilisez donc celle qui vous convient le mieux.

Configuration du nouveau compte d'utilisateur

La première chose à faire est de configurer notre nouveau compte utilisateur.

C'est là que la quasi-totalité du travail aura lieu. Le compte root n'a pas de mot de passe par défaut, il n'est donc pas nécessaire de «supprimer» le mot de passe.

Créer le nouvel utilisateur

Pour créer un nouvel utilisateur, nous utilisons la directiveusers. Ce sera contenir une liste de tous les nouveaux comptes que nous voulons créer. Comme nous ne créons qu'un seul compte, nous en aurons une liste. Pour suivre le guide auquel nous nous sommes liés, nous appellerons ce nouveau comptedemo.

Rappelez-vous, nous devons commencer nos fichierscloud-config avec#cloud-config uniquement sur la première ligne. Jusqu'ici, notre fichier ressemblera à ceci:

#cloud-config
users:
  - name: demo

Si nous voulions ajouter des utilisateurs supplémentaires, nous pourrions le faire en plaçant un élément en dessous et aligné horizontalement avec celui-ci, en commençant par un tiret à nouveau, comme ceci:

#cloud-config
users:
  - name: demo
  - name: second_user

Chaque tiret indique un compte utilisateur distinct sous lequel nous pouvons ajouter les détails de l’utilisateur (ce que nous allons faire dans un instant). Cependant, nous ne créons qu’un seul utilisateur, nous n’avons donc pas cette deuxième ligne dans ce guide.

Ajout de clés autorisées

Pour vous connecter à ce nouveau compte sans mot de passe, nous devrons fournir une ou plusieurs de nos clés publiques SSH. Ceux-ci seront ajoutés au fichierauthorized_keys du nouvel utilisateur dans le répertoire.ssh de son répertoire personnel.

Ceci est accompli avec la directivessh-authorized-keys, qui est un sous-élément d'une entréeusers. Fondamentalement, cela signifie que nous l'alignerons sur notre directivename, mais ne lui donnons pas de tiret, car ce n'est pas le début d'une nouvelle entrée utilisateur.

L'entréessh-authorized-keys prend en fait une liste de clés. Cela vous permet d'ajouter plus d'une clé publique SSH au fichier. Par exemple, si vous disposez d'une paire de clés SSH pour votre ordinateur portable, votre ordinateur de bureau et votre ordinateur au travail, vous pouvez les ajouter toutes en tant qu'éléments distincts dans la listessh-authorized-keys.

Pour obtenir le contenu de votre clé publique de votre ordinateur local, vous pouvez taper:

cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCv60WjxoM39LgPDbiW7ne3gu18q0NIVv0RE6rDLNal1quXZ3nqAlANpl5qmhDQ+GS/sOtygSG4/9aiOA4vXO54k1mHWL2irjuB9XbXr00+44vSd2q/vtXdGXhdSMTf4/XK17fjKSG/9y3yD6nml6q9XgQxx9Vf/IkaKdlK0hbC1ds0+8h83PTb9dF3L7hf3Ch/ghvj5++tWJFdFeG+VI7EDuKNA4zL8C5FdYYWFA88YAmM8ndjA5qCjZXIIeZvZ/z9Kpy6DL0QZ8T3NsxRKapEU3nyiIuEAmn8fbnosWcsovw0IS1Hz6HsjYo4bu/gA82LWt3sdRUBZ/7ZsVD3ELip [email protected]

Vous pouvez ensuite coller le contenu complet en tant qu'élément sous notre entréessh-authorized-keys. Les clés publiques SSH peuvent être affichées ouvertement, cela ne représente donc pas un risque pour la sécurité:

#cloud-config
users:
  - name: demo
    ssh-authorized-keys:
      - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCv60WjxoM39LgPDbiW7ne3gu18q0NIVv0RE6rDLNal1quXZ3nqAlANpl5qmhDQ+GS/sOtygSG4/9aiOA4vXO54k1mHWL2irjuB9XbXr00+44vSd2q/vtXdGXhdSMTf4/XK17fjKSG/9y3yD6nml6q9XgQxx9Vf/IkaKdlK0hbC1ds0+8h83PTb9dF3L7hf3Ch/ghvj5++tWJFdFeG+VI7EDuKNA4zL8C5FdYYWFA88YAmM8ndjA5qCjZXIIeZvZ/z9Kpy6DL0QZ8T3NsxRKapEU3nyiIuEAmn8fbnosWcsovw0IS1Hz6HsjYo4bu/gA82LWt3sdRUBZ/7ZsVD3ELip [email protected]

Si vous souhaitez ajouter des clés supplémentaires, vous pouvez le faire en ajoutant un autre tiret suivi de la deuxième clé publique:

#cloud-config
users:
  - name: demo
    ssh-authorized-keys:
      - key_one
      - key_two

Ajoutez les clés que vous souhaitez utiliser pour vous connecter à ce compte ici.

Configurer l'accès Sudo

L'étape suivante consiste à configurer l'accès desudo à notre nouveau compte. Pour réitérer, nous allons configurer l'accèssudoans mot de passe car nous ne définirons pas de mot de passe sur ce compte en raison des limitations de sécurité.

Pour configurer l'accès, nous allons effectuer deux étapes distinctes.

Tout d'abord, nous allons créer l'entrée que nous voulons utiliser pour le fichiersudoers. Nos modifications seront en fait écrites dans un fichier séparé dans le répertoire/etc/sudoers.d, que/etc/sudoers inclut lors de l'analyse.

L'entrée que nous devons créer n'aura pas besoin d'inclure le nom d'utilisateur, puisquecloud-init est suffisamment intelligent pour comprendre le nom du compte à partir des informations d'entrée. La directive que nous devons utiliser estsudo, qui est alignée sur nos autres directives de niveauusers.

Pour notre guide, puisque nous configurons la capacitésudo sans mot de passe, ressemblera à ceci:

#cloud-config
users:
  - name: demo
    ssh-authorized-keys:
      - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCv60WjxoM39LgPDbiW7ne3gu18q0NIVv0RE6rDLNal1quXZ3nqAlANpl5qmhDQ+GS/sOtygSG4/9aiOA4vXO54k1mHWL2irjuB9XbXr00+44vSd2q/vtXdGXhdSMTf4/XK17fjKSG/9y3yD6nml6q9XgQxx9Vf/IkaKdlK0hbC1ds0+8h83PTb9dF3L7hf3Ch/ghvj5++tWJFdFeG+VI7EDuKNA4zL8C5FdYYWFA88YAmM8ndjA5qCjZXIIeZvZ/z9Kpy6DL0QZ8T3NsxRKapEU3nyiIuEAmn8fbnosWcsovw0IS1Hz6HsjYo4bu/gA82LWt3sdRUBZ/7ZsVD3ELip [email protected]
    sudo: ['ALL=(ALL) NOPASSWD:ALL']

Cela créera un fichier dans le répertoire/etc/sudoers.d appelé90-cloud-init-users. À l'intérieur de ce fichier, l'entrée ressemblera à ceci:

demo ALL=(ALL) NOPASSWD:ALL

La deuxième chose que nous allons faire est en fait d'ajouter notre utilisateur au groupesudo. Ce n'est pas strictement nécessaire car nous avons une entrée spécifique à notre nouveau compte qui est analysée parsudo, mais cela nous donne plus de flexibilité.

Plus tard, nous pourrions souhaiter définir manuellement un mot de passe pour notre utilisateur et exiger ce mot de passe pour les commandessudo. Si notre utilisateur est déjà dans le groupesudo, tout ce que nous aurions à faire est de définir un mot de passe et de supprimer l'entrée dans le fichier90-cloud-init-users.

Pour ajouter un groupe supplémentaire, nous pouvons utiliser la directivegroups:

#cloud-config
users:
  - name: demo
    ssh-authorized-keys:
      - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCv60WjxoM39LgPDbiW7ne3gu18q0NIVv0RE6rDLNal1quXZ3nqAlANpl5qmhDQ+GS/sOtygSG4/9aiOA4vXO54k1mHWL2irjuB9XbXr00+44vSd2q/vtXdGXhdSMTf4/XK17fjKSG/9y3yD6nml6q9XgQxx9Vf/IkaKdlK0hbC1ds0+8h83PTb9dF3L7hf3Ch/ghvj5++tWJFdFeG+VI7EDuKNA4zL8C5FdYYWFA88YAmM8ndjA5qCjZXIIeZvZ/z9Kpy6DL0QZ8T3NsxRKapEU3nyiIuEAmn8fbnosWcsovw0IS1Hz6HsjYo4bu/gA82LWt3sdRUBZ/7ZsVD3ELip [email protected]
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    groups: sudo

Cela facilitera la transition vers une configuration desudo plus traditionnelle. Nous allons vous montrer comment faire cela à la fin de ce guide.

Définir l'environnement Shell

Par défaut, les utilisateurs nouvellement créés ont leur shell par défaut défini sur le shell très basique/bin/sh.

C'est un environnement beaucoup plus épuré que la plupart des gens sont habitués, nous voulons donc spécifier manuellement un environnement shellbash pour notre nouvel utilisateur.

Cela peut être accompli avec la directiveshell dans l'élément de niveauusers. Tout ce que nous avons à faire est de le pointer vers le chemin complet de l'exécutablebash:

#cloud-config
users:
  - name: demo
    ssh-authorized-keys:
      - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCv60WjxoM39LgPDbiW7ne3gu18q0NIVv0RE6rDLNal1quXZ3nqAlANpl5qmhDQ+GS/sOtygSG4/9aiOA4vXO54k1mHWL2irjuB9XbXr00+44vSd2q/vtXdGXhdSMTf4/XK17fjKSG/9y3yD6nml6q9XgQxx9Vf/IkaKdlK0hbC1ds0+8h83PTb9dF3L7hf3Ch/ghvj5++tWJFdFeG+VI7EDuKNA4zL8C5FdYYWFA88YAmM8ndjA5qCjZXIIeZvZ/z9Kpy6DL0QZ8T3NsxRKapEU3nyiIuEAmn8fbnosWcsovw0IS1Hz6HsjYo4bu/gA82LWt3sdRUBZ/7ZsVD3ELip [email protected]
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    groups: sudo
    shell: /bin/bash

Nous avons terminé notre nouvelle configuration utilisateur. Nous pouvons maintenant passer aux étapes facultatives qui verrouillent notre démon SSH.

Configurer et verrouiller le démon SSH (facultatif)

Les étapes suivantes peuvent être utiles pour renforcer la sécurité. Vous pouvez mettre en œuvre tout ou partie d'entre eux comme bon vous semble. Consultez le guide que nous automatisons pour obtenir plus d'informations sur ces options. Nous allons vous montrer comment implémenter chacun des éléments en utilisant deux méthodes différentes.

Toutes les modifications que nous devons apporter seront dans le fichier/etc/ssh/sshd_config. Pour réitérer, les changements que nous souhaitons apporter sont les suivants:

  • (Facultatif) Modifiez le port sur lequel le démon SSH écoute.

  • (Facultatif) Limitez la connexion SSH racine (en particulier si vous n'incluez pas de clés SSH via l'interface DigitalOcean).

  • (Facultatif) Autoriser explicitement notre nouvel utilisateur

Ces paramètres peuvent être implémentés en effectuant ces modifications dans le fichiersshd_config, respectivement:

  • Port4444

  • PermitRootLoginno

  • AllowUsersdemo

Il existe deux approches pour effectuer ces changements. La première consiste à réécrire complètement le fichier en fournissant l'intégralité du fichier de configuration dans notre fichiercloud-config. La seconde consiste à effectuer les modifications de manière stratégique à l'aide d'utilitaires de texte Linux courants.

Les deux ont leurs avantages et les deux démontrent des directives différentes encloud-config. Nous allons couvrir chacun à son tour.

Configuration du démon SSH en fournissant un nouveau fichier de configuration

La première stratégie pour apporter les modifications souhaitées consiste à réécrire complètement le fichier avec le contenu exact souhaité.

Cela nous permet d'avoir un contrôle complet sur le fichier, indépendamment de ce qui est disponible par défaut. La méthodologie est simple et il est facile d’anticiper les résultats de nos actions.

Pour écrire un nouveau fichier sur le disque, nous pouvons utiliser la directivewrite_files. Il s'agit d'une directive de premier niveau, elle doit donc être placée en dehors de la sectionusers dans laquelle nous travaillions précédemment.

Nous fournissons une liste (à nouveau représentée par un tiret pour chaque élément) des fichiers que nous voulons écrire.

#cloud-config
users:
  - name: demo
    ssh-authorized-keys:
      - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCv60WjxoM39LgPDbiW7ne3gu18q0NIVv0RE6rDLNal1quXZ3nqAlANpl5qmhDQ+GS/sOtygSG4/9aiOA4vXO54k1mHWL2irjuB9XbXr00+44vSd2q/vtXdGXhdSMTf4/XK17fjKSG/9y3yD6nml6q9XgQxx9Vf/IkaKdlK0hbC1ds0+8h83PTb9dF3L7hf3Ch/ghvj5++tWJFdFeG+VI7EDuKNA4zL8C5FdYYWFA88YAmM8ndjA5qCjZXIIeZvZ/z9Kpy6DL0QZ8T3NsxRKapEU3nyiIuEAmn8fbnosWcsovw0IS1Hz6HsjYo4bu/gA82LWt3sdRUBZ/7ZsVD3ELip [email protected]
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    groups: sudo
    shell: /bin/bash
write_files:
  - item_one
  - item_two

Dans notre cas, nous n'écrirons qu'un seul fichier. Pour chaque fichier, nous fournissons des détails sur les modifications que nous souhaitons apporter. Par exemple, les paramètres que vous pouvez utiliser sontpath,content,owner,permissions et mêmeencoding.

Par défaut, le propriétaire des fichiers créés avec cette méthode est root et les permissions sont644, ce qui est exactement ce que nous voulons. Il suffit donc de fournir les directivespath etcontent.

Lepath est juste l'emplacement dans le système de fichiers pour écrire le fichier.

Pour lescontent, nous voudrons fournir tout le contenu du fichier, à écrire tel quel. N'oubliez pas que nous pouvons utiliser le caractère de pipe (|) pour passer un bloc de texte qui conservera sa mise en forme.

Pour le contenu de notre fichiersshd_config, nous utiliserons simplement le contenu par défaut, sans commentaires (par souci de concision), avec les modifications que nous voulions apporter. La section complète pour réécrire notre fichier ressemblera à ceci:

#cloud-config
users:
  - name: demo
    ssh-authorized-keys:
      - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCv60WjxoM39LgPDbiW7ne3gu18q0NIVv0RE6rDLNal1quXZ3nqAlANpl5qmhDQ+GS/sOtygSG4/9aiOA4vXO54k1mHWL2irjuB9XbXr00+44vSd2q/vtXdGXhdSMTf4/XK17fjKSG/9y3yD6nml6q9XgQxx9Vf/IkaKdlK0hbC1ds0+8h83PTb9dF3L7hf3Ch/ghvj5++tWJFdFeG+VI7EDuKNA4zL8C5FdYYWFA88YAmM8ndjA5qCjZXIIeZvZ/z9Kpy6DL0QZ8T3NsxRKapEU3nyiIuEAmn8fbnosWcsovw0IS1Hz6HsjYo4bu/gA82LWt3sdRUBZ/7ZsVD3ELip [email protected]
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    groups: sudo
    shell: /bin/bash
write_files:
  - path: /etc/ssh/sshd_config
    content: |
         Port 4444
         Protocol 2
         HostKey /etc/ssh/ssh_host_rsa_key
         HostKey /etc/ssh/ssh_host_dsa_key
         HostKey /etc/ssh/ssh_host_ecdsa_key
         HostKey /etc/ssh/ssh_host_ed25519_key
         UsePrivilegeSeparation yes
         KeyRegenerationInterval 3600
         ServerKeyBits 1024
         SyslogFacility AUTH
         LogLevel INFO
         LoginGraceTime 120
         PermitRootLogin no
         StrictModes yes
         RSAAuthentication yes
         PubkeyAuthentication yes
         IgnoreRhosts yes
         RhostsRSAAuthentication no
         HostbasedAuthentication no
         PermitEmptyPasswords no
         ChallengeResponseAuthentication no
         X11Forwarding yes
         X11DisplayOffset 10
         PrintMotd no
         PrintLastLog yes
         TCPKeepAlive yes
         AcceptEnv LANG LC_*
         Subsystem sftp /usr/lib/openssh/sftp-server
         UsePAM yes
         AllowUsers demo

Cela remplacera complètement le contenu de/etc/ssh/sshd_config par le nouveau contenu que nous avons fourni. Il s'agit du fichiersshd_config par défaut pour Ubuntu avec uniquement les éléments mentionnés ci-dessus modifiés.

C'est une méthode pour apporter les modifications au démon SSH.

Configuration du démon SSH à l'aide de modifications ciblées

La deuxième façon de modifier le fichiersshd_config consiste à effectuer des modifications ciblées. Les systèmes Linux sont livrés avec une variété d’outils de manipulation de texte puissants que nous pouvons utiliser pour n’apporter que les changements dont nous avons besoin.

Pour exécuter des commandes arbitraires, nous utiliserons une directive appeléeruncmd, qui nous permet d'exécuter n'importe quelle commande sur le système. Chaque commande sera un élément de la liste sous la directive. Ceux-ci peuvent être donnés soit sous forme de chaînes représentant la commande entière, soit sous forme de tableau avec la commande et toutes les options sous forme d'éléments.

Nous utiliserons la commandesed, qui est faite pour les substitutions de chaînes. Bien que vous puissiez passer plusieurs opérations à une seule commandesed, nous ferons une seule opération pour chaque commandesed. Cela nous permettra de résoudre les problèmes plus facilement. Toutes nos commandessed éditeront le fichiersshd_config sur place.

Notre première commandesed changera la ligne qui configure le port d'écoute. Nous identifierons cela en recherchant une ligne commençant par «Port». Nous dirons àsed de remplacer la ligne entière (spécifiée par l'expression régulière^.*$) par notre configurationPort 4444:

#cloud-config
users:
  - name: demo
    ssh-authorized-keys:
      - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCv60WjxoM39LgPDbiW7ne3gu18q0NIVv0RE6rDLNal1quXZ3nqAlANpl5qmhDQ+GS/sOtygSG4/9aiOA4vXO54k1mHWL2irjuB9XbXr00+44vSd2q/vtXdGXhdSMTf4/XK17fjKSG/9y3yD6nml6q9XgQxx9Vf/IkaKdlK0hbC1ds0+8h83PTb9dF3L7hf3Ch/ghvj5++tWJFdFeG+VI7EDuKNA4zL8C5FdYYWFA88YAmM8ndjA5qCjZXIIeZvZ/z9Kpy6DL0QZ8T3NsxRKapEU3nyiIuEAmn8fbnosWcsovw0IS1Hz6HsjYo4bu/gA82LWt3sdRUBZ/7ZsVD3ELip [email protected]
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    groups: sudo
    shell: /bin/bash
runcmd:
  - sed -i -e '/^Port/s/^.*$/Port 4444/' etc/ssh/sshd_config

Notre prochaine lignesed modifiera la directive «PermitRootLogin» en recherchant cette chaîne au début d'une ligne. Encore une fois, nous remplacerons toute la ligne, cette fois parPermitRootLogin no:

#cloud-config
users:
  - name: demo
    ssh-authorized-keys:
      - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCv60WjxoM39LgPDbiW7ne3gu18q0NIVv0RE6rDLNal1quXZ3nqAlANpl5qmhDQ+GS/sOtygSG4/9aiOA4vXO54k1mHWL2irjuB9XbXr00+44vSd2q/vtXdGXhdSMTf4/XK17fjKSG/9y3yD6nml6q9XgQxx9Vf/IkaKdlK0hbC1ds0+8h83PTb9dF3L7hf3Ch/ghvj5++tWJFdFeG+VI7EDuKNA4zL8C5FdYYWFA88YAmM8ndjA5qCjZXIIeZvZ/z9Kpy6DL0QZ8T3NsxRKapEU3nyiIuEAmn8fbnosWcsovw0IS1Hz6HsjYo4bu/gA82LWt3sdRUBZ/7ZsVD3ELip [email protected]
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    groups: sudo
    shell: /bin/bash
runcmd:
  - sed -i -e '/^Port/s/^.*$/Port 4444/' /etc/ssh/sshd_config
  - sed -i -e '/^PermitRootLogin/s/^.*$/PermitRootLogin no/' /etc/ssh/sshd_config

La prochaine commandesed ajoutera une ligne à la fin du fichier car il n'y a pas actuellement de directive «AllowUsers» dans le fichier. Nous faisons cela en faisant correspondre la dernière ligne (spécifiée par «$») et en ajoutant la ligne dont nous avons besoin.

Ensuite, nous devrons redémarrer le démon SSH pour que nos modifications soient propagées. Nous pouvons le faire facilement en utilisant la commande «redémarrer» de Upstart:

#cloud-config
users:
  - name: demo
    ssh-authorized-keys:
      - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCv60WjxoM39LgPDbiW7ne3gu18q0NIVv0RE6rDLNal1quXZ3nqAlANpl5qmhDQ+GS/sOtygSG4/9aiOA4vXO54k1mHWL2irjuB9XbXr00+44vSd2q/vtXdGXhdSMTf4/XK17fjKSG/9y3yD6nml6q9XgQxx9Vf/IkaKdlK0hbC1ds0+8h83PTb9dF3L7hf3Ch/ghvj5++tWJFdFeG+VI7EDuKNA4zL8C5FdYYWFA88YAmM8ndjA5qCjZXIIeZvZ/z9Kpy6DL0QZ8T3NsxRKapEU3nyiIuEAmn8fbnosWcsovw0IS1Hz6HsjYo4bu/gA82LWt3sdRUBZ/7ZsVD3ELip [email protected]
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    groups: sudo
    shell: /bin/bash
runcmd:
  - sed -i -e '/^Port/s/^.*$/Port 4444/' /etc/ssh/sshd_config
  - sed -i -e '/^PermitRootLogin/s/^.*$/PermitRootLogin no/' /etc/ssh/sshd_config
  - sed -i -e '$aAllowUsers demo' /etc/ssh/sshd_config
  - restart ssh

Cela devrait suffire à apporter les modifications nécessaires à notre fichier et à redémarrer le service.

Produit fini

Nous avons maintenant accompli tous nos objectifs ajustés en utilisant le fichiercloud-config. Vous pouvez créer votre serveur à l'aide du panneau de configuration ou utiliser l'API pour faire tourner un serveur.

Si vous choisissez d'utiliser l'API, un exemple de charge de données peut ressembler à ceci:

{"name": "your_droplet_name",
"private_networking": true,
"region": "nyc3",
"size": "512mb",
"image": "ubuntu-14-04-x64",
"user-data": "#cloud-config
users:
  - name: demo
    ssh-authorized-keys:
      - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCv60WjxoM39LgPDbiW7ne3gu18q0NIVv0RE6rDLNal1quXZ3nqAlANpl5qmhDQ+GS/sOtygSG4/9aiOA4vXO54k1mHWL2irjuB9XbXr00+44vSd2q/vtXdGXhdSMTf4/XK17fjKSG/9y3yD6nml6q9XgQxx9Vf/IkaKdlK0hbC1ds0+8h83PTb9dF3L7hf3Ch/ghvj5++tWJFdFeG+VI7EDuKNA4zL8C5FdYYWFA88YAmM8ndjA5qCjZXIIeZvZ/z9Kpy6DL0QZ8T3NsxRKapEU3nyiIuEAmn8fbnosWcsovw0IS1Hz6HsjYo4bu/gA82LWt3sdRUBZ/7ZsVD3ELip [email protected]
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    groups: sudo
    shell: /bin/bash
runcmd:
  - sed -i -e '/^Port/s/^.*$/Port 4444/' /etc/ssh/sshd_config
  - sed -i -e '/^PermitRootLogin/s/^.*$/PermitRootLogin no/' /etc/ssh/sshd_config
  - sed -i -e '$aAllowUsers demo' /etc/ssh/sshd_config
  - restart ssh"}

Dépannage

Si vous rencontrez des problèmes pour que votre fichiercloud-config fonctionne correctement, vous pouvez rechercher des indices dans les fichiers journaux.

Ceux-ci sont situés à:

  • /var/log/cloud-init.log: les journaux de processus réels pour le traitement par cloud-init des fichiers de configuration.

  • /var/log/cloud-init-output.log: Toute sortie produite par le traitement de la configuration peut être trouvée ici.

Vous pouvez généralement trouver de bonnes informations sur ce qui s'est passé en utilisantgrep pour rechercher ces fichiers.

Si vous vous trouvez dans une situation où vous ne pouvez pas vous connecter au serveur que vous avez créé en raison de problèmes de configuration, il est préférable de détruire le serveur et de recommencer. Pour le dépannage, il est parfois nécessaire de configurer temporairement un serveur de test avec un mot de passe root dans le fichiercloud-config afin que vous puissiez voir ce qui ne va pas.

Cela peut être fait en incluant quelque chose comme ceci dans voscloud-config:

#cloud-config
chpasswd:
  list: |
    root:yourpassword
  expire: False
. . .

Cela vous permettra de vous connecter à l'aide de la console DigitalOcean, qui ne repose pas sur SSH. N'oubliez pas que tous les utilisateurs de votre serveur disposeront d'un mot de passe lisible pendant toute la durée de vie de votre système. Détruisez donc ce Droplet une fois que vous avez identifié le problème. Vous pouvez ensuite démarrer un autre serveur en utilisant le fichiercloud-config corrigé.

Configuration de l'accès traditionnel à Sudo

Si vous souhaitez configurer un accèssudo plus conventionnel authentifié par mot de passe après le déploiement de votre serveur, vous pouvez facilement suivre les étapes suivantes:

Tout d'abord, vous devez définir un mot de passe pour le nouveau compte. La seule façon de faire ceciwithout ayant à entrer le mot de passe actuel (qui n'existe pas) est de passer parsudo. Vous devrez spécifier le nom de votre nouveau compte utilisateur à la fin de la commande pour ne pas définir le mot de passe root:

sudo passwd demo

Maintenant que vous avez un mot de passe pour votre compte, vérifiez que vous êtes bien dans le groupesudo. Cela peut être fait en tapant:

groups
demo sudo

Si vous n'êtes pas déjà dans le groupesudo, vous pouvez vous ajouter en tapant:

sudo usermod -a -G sudo demo

Maintenant, éditez le fichier90-cloud-init-users avec la commandevisudo, en passant le fichier comme argument:

sudo visudo -f /etc/sudoers.d/90-cloud-init-users

Mettez en commentaire ou supprimez la ligne associée à votre utilisateur:

#demo ALL=(ALL) NOPASSWD:ALL

Enregistrez et fermez le fichier. Votre compte aura maintenant besoin de votre mot de passe pour exécuter les commandessudo.

Conclusion

L'utilisation des fichierscloud-config pour terminer la configuration initiale de vos serveurs peut être facile et vous faire gagner du temps à long terme. Les fichiers sont faciles à modifier et la mise en place de différentes configurations peut vous donner une grande flexibilité pour la configuration rapide de serveurs.

En combinantcloud-config avec un système de gestion de configuration plus traditionnel après la mise en ligne de la machine, vous pouvez rapidement et facilement amener les nouvelles machines exactement dans l'état souhaité.