Commandes Linux et compétences Shell
ssh : la connexion qui gère votre infrastructure
ssh n'est pas une commodité, c'est le transport sur lequel chaque opération sur chaque serveur s'effectue, et ~/.ssh/config est un contrat avec votre futur moi à 3 heures du matin. Les alias d'hôte, les entrées IdentityFile, les cibles ProxyJump et les paramètres keepalive transforment les phrases d'indicateur mémorisées en commandes d'un seul mot. Les tunnels (-L, -R, -D) et le multiplexage ControlMaster sont ce qui transforme « un shell » en une surface de commande d'infrastructure, et les deux sont un travail de fichier de configuration, pas un travail de mémoire.
Points clés
- Mettez tout dans ~/.ssh/config : les alias d'hôte avec User, IdentityFile, IdentitiesOnly yes et ProxyJump font de 'ssh prod-web1' un mot ; une phrase d'indicateur tapée à l'identique cinq fois par jour est une entrée de configuration manquante.
- Les clés sont le seul jeu : ssh-keygen -t ed25519 -C 'role@team', moitié publique vers authorised_keys et passwordAuthentication no sur le serveur une fois que la rotation s'est avérée efficace.
- Les hôtes de saut ont été réduits en un seul indicateur : ssh -J bastion.corp internal-host ou ProxyJump bastion.corp dans le bloc Host ; les anciennes incantations ProxyCommand fonctionnent toujours et ne sont plus l'affaire de personne.
- Les tunnels sont destinés à un usage spécifique : -L 5432:db.internal:5432 pour atteindre une base de données, -D 1080 en tant que cale SOCKS via un réseau strict, -R pour exposer une boîte de développement locale, chacune liée à localhost sauf si vous l'élargissez explicitement.
- Le multiplexage ControlMaster (ControlMaster auto, ControlPath ~/.ssh/cm-%r@%h:%p, ControlPersist 10m) arrête la réexécution des poignées de main à chaque ouverture et permet un fonctionnement multi-fenêtres sur un hôte instantané.
- Keepalives conserve les sessions via NAT et les suppressions de pare-feu inactif : ServerAliveInterval 60 plus ServerAliveCountMax 3 côté client bat le mystérieux rapport "session morte au bout de 4 minutes" la plupart du temps.
- Limiter les accès dangereux : -N (pas de commande à distance) pour les transferts de port purs, -n pour les tâches par lots lisant à partir de stdin et fail2ban plus MaxAuthTries sain d'esprit afin que la force brute disparaisse dans les journaux au lieu des comptes.
- L'ordre de débogage est important : ssh -vvv révèle l'analyse de la configuration, la négociation d'authentification et les échecs de canal dans cet ordre, et un vidage de l'hôte -G répond "pourquoi a-t-il choisi cette clé et cet utilisateur" sans toucher à un serveur.
Note de terrain
J'ai désactivé une fois l'authentification par mot de passe avant que la nouvelle clé ne soit réellement dans Authorized_keys et j'ai verrouillé ma propre équipe pendant une soirée. Le rituel maintenant : deuxième session ouverte, clé fonctionnelle éprouvée et ServerAliveInterval dans la configuration pour que les suppressions NAT du bastion inactif arrêtent de tuer les sessions.
Questions fréquentes
Dans une phrase chacun : -L, -R, -D ?
-L transmet un port local vers un service distant, -R repousse un port distant vers votre machine (sachez exactement ce que vous avez exposé) et -D ouvre un proxy SOCKS dynamique via la connexion.
Ma session s'arrête après quelques minutes d'inactivité. Réparer?
Un délai d'inactivité sur un NAT ou un pare-feu est la cause habituelle : définissez ServerAliveInterval sur le client (et gardez TCPKeepAlive sain sur le serveur) ; le même correctif appartient à la configuration que vous utilisez pour les sauts de bastion du sous-sol.
Clés avec agent ssh ou sans phrase secrète ?
Agent, toujours : il conserve les clés déchiffrées par session afin que les clés conservent les phrases secrètes et que l'automatisation reste non interactive ; ForwardAgent oui sur un bastion de confiance, c'est bien et ssh-add -l vous indique ce qui est chargé avant de vous mentir.
Comment puis-je arrêter de retaper les spécifications du tunnel ?
Lignes LocalForward et RemoteForward à l'intérieur des blocs Host : 'ssh dbtunnel' fait alors tout ; une entrée par objectif maintient le fichier lisible et permet aux audits de voir exactement qui transmet quoi.
Comment Kinetikatech vous aide avec commandes linux et compétences shell
Soyons honnêtes, la plupart des équipes viennent nous voir après avoir essayé d'abord par elles-mêmes : Les commandes et habitudes de script qui décident si un administrateur exploite un serveur ou le combat : rechercher, transformer, transférer et superviser le texte et les processus avec les outils présents dans chaque installation de base. Notre service Sécurité des serveurs Linux et Gestion de serveurs existe pour que vous n'ayez pas à apprendre commandes linux et compétences shell à vos dépens : nous gérons l'installation, la supervision et les surprises de 3 h du matin.