PuTTY est un client SSH, Telnet, et de terminal emblème des utilisateurs Windows, qui s’impose comme un outil essentiel pour les professionnels de l’informatique et les particuliers souhaitant gérer leurs serveurs à distance. Développé initialement par Simon Tatham en 1998, PuTTY a su évoluer pour devenir une référence dans son domaine.

L’histoire de PuTTY

Le projet PuTTY est né de la nécessité de disposer d’un outil gratuit et fiable permettant d’accéder à des serveurs via le protocole SSH, une technologie qui assure une connexion sécurisée entre deux machines. Depuis sa création, PuTTY a gagné une réputation d’outil performant, léger et à la portée de tous.

Sa disponibilité sur différentes plateformes, notamment Windows, et sa licence open source ont contribué à son adoption massive.

Utilisation de PuTTY chez les professionnels

Les professionnels de l’informatique utilisent PuTTY pour diverses tâches critiques :

Gestion des serveurs sous Linux

PuTTY est un outil de prédilection pour accéder à des serveurs Linux via SSH. Que ce soit pour administrer un serveur, effectuer des dépannages ou exécuter des scripts, PuTTY offre une solution fiable et efficace.

Gestion des équipements réseaux

Les administrateurs réseaux utilisent également PuTTY pour configurer et gérer des matériels réseaux tels que des routeurs, des switches ou des firewalls. La prise en charge de Telnet et des connexions série en fait un outil idéal pour ces tâches.

Dépannage et résolution de problèmes

PuTTY est particulièrement utile pour le troubleshooting des serveurs et des infrastructures réseaux. Les administrateurs peuvent se connecter rapidement à un serveur ou un équipement réseau pour identifier la cause d’un dysfonctionnement, examiner les journaux système, redémarrer des services ou ajuster des configurations en cas de panne. Cette capacité à diagnostiquer et résoudre les problèmes en temps réel en fait un outil précieux dans les environnements professionnels exigeants.

Utilisation de PuTTY chez les particuliers

Pour les particuliers gérant des projets web ou explorant des services cloud, PuTTY se révèle également très utile :

Gestion d’un site Web

PuTTY permet de se connecter à un serveur web pour modifier des fichiers, mettre à jour des configurations ou déployer des sites web. Cette flexibilité est essentielle pour les webmasters souhaitant conserver un contrôle total sur leur infrastructure.

La plupart des tâches de gestion réalisées sur SysKB utilisent PuTTY. Cet outil permet une administration efficace des serveurs Linux, la supervision des infrastructures, ainsi que le déploiement et l’entretien des services critiques.

Configuration d’un VPN ou Seedbox

En tant qu’utilisateur de PuTTY, j’ai trouvé cet outil particulièrement utile pour déployer une Seedbox sur un serveur distant. Grâce à la connexion SSH, il est possible d’installer et de configurer rapidement une Seedbox avec des outils comme Swizzin, qui offre une interface intuitive et de nombreuses fonctionnalités. Si vous souhaitez découvrir un tutoriel détaillé sur l’installation d’une Seedbox avec Swizzin, consultez cet article complet sur SysKB.

Connexion complémentaire avec WinSCP

PuTTY est souvent utilisé en tandem avec WinSCP, un client FTP/SFTP qui facilite le transfert de fichiers entre une machine locale et un serveur distant. Cette synergie est particulièrement appréciée par les administrateurs, car WinSCP permet de gérer les fichiers, tandis que PuTTY offre un accès complet à la ligne de commande. Pour en savoir plus sur WinSCP et le télécharger, consultez cet article détaillé sur SysKB.

Points forts de PuTTY

• Gratuit et open source : Pas de frais cachés et une communauté active pour le support.
• Léger et rapide : Fonctionne même sur des machines avec des ressources limitées.
• Polyvalent : Supporte plusieurs protocoles, dont SSH, Telnet et rlogin.
• Personnalisable : Offre des options avancées comme les clés SSH et le tunneling.

Comment télécharger PuTTY ?

PuTTY est disponible gratuitement sur le site officiel du projet. Pour télécharger la dernière version, rendez-vous directement sur la page de téléchargement de PuTTY.

Conclusion

Que vous soyez un professionnel gérant une infrastructure complexe ou un particulier explorant des solutions de gestion de serveurs, PuTTY est un outil indispensable. Sa fiabilité, sa simplicité et son intégration avec des outils comme WinSCP en font une solution idéale pour toutes vos opérations distantes. Adoptez PuTTY aujourd’hui et simplifiez vos connexions distantes tout en renforçant la sécurité de vos échanges !

Cet article original intitulé PuTTY : Un outil incontournable pour les professionnels et les particuliers a été publié la première sur SysKB.

Vous avez une Seedbox déployée sur un VPS dans le Cloud pour télécharger des Torrents ? Dans ce guide, découvrez comment connecter un partage situé sur votre NAS Synology à votre Seedbox. Cette astuce vous permettra d’étendre la capacité de stockage de votre Seedbox tout en réduisant vos frais d’hébergement en optant pour un VPS moins volumineux.

Pourquoi utiliser un NAS avec une Seedbox ?

Une Seedbox dans le Cloud offre plusieurs avantages :

1. Téléchargement à haut débit : Accélérez vos téléchargements sans solliciter votre ordinateur.
2. Sécurité accrue : Pas de surveillance Hadopi pour les services professionnels comme IONOS, OVH ou encore AZURE.
3. Réduction des coûts : Louez un VPS de base (à partir de 1,2 €/mois) et transférez vos fichiers directement sur un NAS.

Avec cette configuration, vous profitez de la vitesse et de la flexibilité du Cloud, tout en utilisant votre NAS pour un stockage massif à domicile.

Comment déployer une Seedbox dans le Cloud et comment rapatrier vos films sur votre NAS Synology ?

Pour déployer une Seedbox il suffit de louer un VPS chez un hébergeur et d’installer un client Torrent comme Deluge ou Transmission.

Si le sujet vous intéresse j’ai écrit un article expliquant pas à pas comment installer une Seedbox dans le Cloud pour télécharger avec un gros débit. Cela demande quelques compétences en informatique mais je détaille tout pas à pas.

Chez IONOS un petit VPS avec 80 Go d’espace disque coûte 2 à 3€ / mois seulement et vous permettra de télécharger une énorme quantité de contenu. Je vous invite à consultez les offres VPS de IONOS pour en savoir plus e bénéficier des promos du moment.

Si vous êtes gourmand en téléchargement ça peut vite être un peu juste surtout avec la démocratisation des Blu-ray en UHD avec des films à plus de 50 Go (mais c’est tellement beau).

L’astuce consiste donc à créer un partage sur votre NAS Synology puis à le monter, ou le présenter si vous préférez, sur votre VPS. Ce partage sera vu par votre VPS comme un lecteur à part entière.

Concrètement lorsque vous lancerez un téléchargement depuis votre Seedbox le fichier pourra être directement déposé sur votre NAS. Evidement le débit sera alors limité à celui dont vous disposez entre en votre Synology et votre Seedbox, mais vous pourrez lancer pleins de téléchargements, aller dormir, et retrouver vos contenus sur votre NAS sans faire d’effort.

Il est temps de mettre tout cela en place !

Si vous n’avez pas encore de NAS Synology c’est peut être le moment de vous intéresser au sujet, suivez mon guide !

Comment bien choisir votre NAS pour centraliser, protéger et partager vos données

Quelques Prérequis

1 – Ouvrir le port utilisé par SSH sur votre Box

Pour la communication en SSH entre un VPS situé dans le Cloud et votre NAS situé sur votre LAN il faut ouvrir le port adéquat sur la box de votre opérateur.

Voici ce que ça donne sur l’interface d’une Freebox Revolution.

2- Activer le service SFTP sur votre NAS Synology

Depuis votre NAS vous devez activer le service SFTP en vous rendant dans le Panneau de configuration > File Services. Cochez simplement Enable SFTP service depuis l’onglet FTP.

3- Créer un compte utilisateur dédié sur votre Synology

Je vous recommande l’utilisation un compte dédié pour connecter votre VPS / Seedbox à votre Synology. Dans cet exemple j’ai créé un compte appelé Seedbox auquel j’attribue les droits d’utilisation du rôle FTP (Ce rôle permet à l’utilisateur que l’on vient de créer d’utiliser le service SFTP)

4- Mettre en place l’authentification SSH par clé publique/privée sur le Synology

L’intérêt de l’authentification SSH avec une paire de clé est d’éviter d’avoir à taper un login et un mot de passe pour établir la connexion entre votre VPS et le NAS Synology. Ca évite ne mettre votre login et mot de passe en clair dans une commande ce qui représenterait une faille de sécurité pour votre NAS.

Je décris cette procédure à un chapitre du même nom dans mon article Synchroniser sa Seedbox vers son NAS Synology avec Rsync. Suivez donc scrupuleusement mes explications, notamment les sous-chapitres Activer la console SSH sur le NAS Synology et Permettre l’authentification par Clé SSL sur le NAS Synology.

Ensuite revenez ici pour poursuivre !

Vous devez ensuite générer une paire de clé spécifique pour le compte Seedbox.

Depuis la session root de votre VPS générez une paire de clé SSL grâce à la commande suivante :

ssh-keygen -t rsa

Pressez 3 fois la touche Entrée pour générer la paire de clé.

Si une paire de clé a déjà été créé sur votre serveur le prompt vous propose de l’écraser. Il est évident que si vous utilisez déjà la paire de clé existante pour un autre usage, annulez l’opération et passez à l’étape suivante pour utiliser la paire existante. Une même paire de clé peut être utilisée pour plusieurs

Copiez la clé SSL sur votre NAS Synology avec la commande suivante. Remplacer IP_Synology par l’adresse de votre serveur Synology. Vous devez entrer le login et mot de passe du compte Seedbox, mais c’est la dernière fois que vous aurez besoin de vous authentifier de cette manière, ensuite tout se fera via les clés

ssh-copy-id seedbox@IP_Synology

A partir de là votre VPS et votre NAS ont établi une relation de confiance et la communication entres les 2 systèmes se fera sans authentification par login / password.

5- Installer l’outil SSHFS

Pour monter le partage du NAS sur le VPS nous allons utiliser l’outil SSHFS. Comme son nom l’indique il permet de monter un système de fichier distant via une connexion SSH.

Si votre VPS est sous Linux Debian tapez la commande pour installer SSHFS est :

apt-get update && apt-get install sshfs 

Monter un partage de votre NAS Synology sur votre VPS / Seedbox dans le Cloud

1- Création d’un partage

Il faut tout d’abord créer le partage sur votre NAS. Depuis votre NAS créez un partage, dans cet exemple je créé un partage seedbox.

Dans l’onglet permission je donne l’accès Lecture/écriture au partage à l’utilisateur seedbox. Désolé d’avoir créer un répertoire et un compte avec un nom identique … c’était volontaire pour mon usage mais ça ne rend pas le tuto très clair.

2- Monter le partage sur le VPS

Retournez sur votre VPS afin de taper la commande tant attendu, celle qui va permettre de monter le partage du NAS sur votre VPS :

sshfs -o allow_other seedbox@82.66.228.212:/seedbox /movies

Dans cette commande :

• Remplacez seedbox par le nom du compte que vous avez créé sur votre NAS
• Remplacez 82.66.228.212 par l’adresse IP de votre NAS
• Remplacez seedbox par le nom du partage que vous avez créé sur votre NAS
• Remplacez movies par le nom d’un répertoire symbolique qui sera créé sur votre VPS et qui sera associé à votre partage seedbox

Si jamais ça ne fonctionnait pas tapez la commande suivante pour avoir le détails du processus de connexion.

sshfs -odebug,sshfs_debug,loglevel=debug,allow_other seedbox@82.66.228.212:/seedbox /movies

Paramétrer le client Torrent de votre Seedbox

Maintenant que le partage du NAS est monté sur le VPS de la Seedbox vous pouvez paramétrer votre client Torrent pour qu’il utilise votre nouveau lecteur réseau.

J’utilise le client Deluge, mais le principe est le même avec Transmission ou d’autres.

Dans ce premier exemple je paramètre le client Deluge pour que les téléchargements soit directement effectués dans le partage sur le NAS. J’utile le nom du répertoire symbolique /movies pour accéder au partage distant. L’intérêt de cet exemple est que vos Torrents restent en ligne ce qui vous permet de partager vos téléchargements et gagner en ratio.

Dans ce second exemple les téléchargements sont toujours effectués dans un répertoire local de la Seebox mais les fichiers téléchargés sont ensuite déplacés dans le partage Seedbox distant via le répertoire symbolique /movies.

Conclusion

Dans ce tutoriel je vous ai décrit pas à pas comment mapper / monter un lecteur réseau d’un NAS distant sur un VPS dans le cadre de l’utilisation d’une Seedbox. L’idée est d’envoyer directement sur votre NAS les téléchargements réalisés dans le Cloud.

Bien entendu cette astuce peut trouver pleins d’autres usages, vous pouvez par exemple utiliser cette technique pour déposer des fichiers de sauvegardes de votre site web ou les logs d’un Proxy ou d’un VPN.

N’hésitez pas à me laisser vos commentaires !

Cet article original intitulé Monter un partage de votre NAS Synology sur votre VPS / Seedbox située dans le Cloud a été publié la première sur SysKB.

Un mémo sur la mise en place du module de sécurité pam_faillock sur Debian 12. Ce module permet de verrouiller temporairement un compte utilisateur connu du système après plusieurs tentatives de connexion infructueuses via ssh.

Prérequis

• Une machine tournant sous Debian 12 (Bookworm).
• Un accès root ou des privilèges sudo.
• Une compréhension de base des fichiers PAM (Pluggable Authentication Modules).

Étape 1 : Installer les paquets nécessaires

pam_faillock est inclus dans le paquet libpam-modules, qui est installé par défaut sur Debian 12.

Étape 2 : Configurer pam_faillock

• Modifier le fichier PAM de gestion des connexions locales :
  • Éditer le fichier /etc/pam.d/common-auth :

    auth    required                        pam_faillock.so preauth
    auth    [success=1 default=ignore]      pam_unix.so nullok
    auth    [default=die]                   pam_faillock.so authfail
    auth    sufficient                      pam_faillock.so authsucc
    auth    requisite                       pam_deny.so
    auth    required                        pam_permit.so
    

  

Éditer le fichier /etc/pam.d/common-account :

account required                        pam_faillock.so

Configurer le fichier /etc/security/faillock.conf :

• deny = 3
• unlock_time = 900
• audit
• ignore_users = root
• silent

Étape 3 : Tester la configuration

• Vérifier les logs :
  • Les échecs de connexion sont enregistrés dans les journaux système :

  sudo journalctl -xe | grep pam_faillock

• Simuler des échecs de connexion :
  • Tester plusieurs fois des connexions avec un mauvais mot de passe :
    
    • Vérifier les comptes verrouillés :
      • Utilisez la commande suivante pour lister les utilisateurs verrouillés :

      sudo faillock

      

    • Pour réinitialiser les tentatives d’échec d’un utilisateur spécifique :

    sudo faillock --reset --user utilisateur

C’est un cas peu commun et qui m’a donné du fil à retordre (on parle de 3h d’essais/erreurs), c’est suffisamment barbu pour que je prenne la peine de partager l’info, en redonnant du contexte et un peu plus d’explications quand même.

Le contexte, donc

Nous sommes dans une migration de jobs qui s’exécutaient sur Jenkins à la main et qui doivent être refaits dans Gitlab-CI. Une grande partie de la facilité vient du fait que tout est basé sur Ansible, ce qui fait qu’on a finalement qu’à gérer « l’autour » de la logique des jobs, à savoir le setup de l’environnement d’exécution pour Ansible. Certains de ces jobs ciblent des serveurs sous Windows, d’autres sous Linux (Ansible fait ça très bien, via WinRM/Powershell pour Windows, SSH/Python pour Linux). Pour les Windows, un compte technique dans l’annuaire utilisé pour les environnements de préproduction fera le taf à la place de… variables utilisateurs/mots de passe fournies aux jobs à l’exécution. Pour les Linux, ça repose sur un compte dédié avec une clé SSH exploitée par Jenkins.

En temps normal personne se poserait de question, sauf que là, mon problème est que la clé est protégée par une phrase de passe, en anglais passphrase, et c’est particulièrement compliqué de travailler avec, au point que la plupart des gens recommandent de virer la phrase de la clé. Sauf que là, c’est hors de question, j’ai pas le droit d’y toucher. Au moins je peux la récupérer depuis un Vault Hashicorp privé. Et donc, mon premier symptôme, c’est ça :

debug1: Trying private key: /home/appuser/.ssh/id_rsa
debug1: read_passphrase: can\'t open /dev/tty: No such device or address

SSH, ça s’automatise bien normalement, et puis…

Le fameux tty qu’on voit, c’est l’interface qui doit permettre à l’utilisateur d’interagir, et donc de saisir la passphrase au moment souhaité, à savoir quand il doit la présenter pour la connexion. On comprend donc le problème avec un pipeline Gitlab-CI: point de TTY. Et pas la peine d’y penser, le client SSH n’a aucune autre méthode directe pour accepter ladite phrase (c’est pas comme l’installation du SDK Android où on peux suffixer < yes pour répondre automatiquement aux questions d’acceptation des licences).

À force de chercher et de torturer mes termes de recherche, je finis par tomber sur cet article. Fait intéressant, il mentionne des options/variables d’Ansible pour manipuler justement les clés et éviter de fournir la phrase à chaque fois. Mais le problème, c’est que pour ansible_ssh_prompt, on doit indiquer l’intitulé de la question à laquelle on doit répondre par la passphrase et qu’il va devoir « capturer ». Question qui n’est jamais posée puisque pas de TTY pour ça. Ce n’est donc toujours pas exploitable, mais une réponse suivante sur la même page me mets sur la voie.

Cette ligne m’intrigue particulièrement:

- echo "$SSH_PRIVATE_KEY" |tr -d '\r' | DISPLAY=None SSH_ASKPASS=~/.ssh/tmp ssh-add -

La documentation d’ssh-add va répondre à mes questions:

DISPLAY, SSH_ASKPASS et SSH_ASKPASS_REQUIRE
    Si ssh-add a besoin d'une phrase secrète, il la lira sur le terminal actif s'il a été lancé dans un terminal. Si ssh-add n'a aucun terminal associé alors que DISPLAY et SSH_ASKPASS sont défi‐
    nies, il exécutera le programme spécifié par SSH_ASKPASS (par défaut « ssh-askpass ») et ouvrira une fenêtre X11 pour lire la phrase secrète. Cela s’avère particulièrement utile lors de l'appel
    de ssh-add depuis un fichier .xsession ou un script similaire.

Je tente donc la solution, mais fait face à un nouveau message d’erreur:

ssh_askpass: exec(/home/appuser/.ssh/.print_ssh_password): Exec format error

Là, ça m’a pris beaucoup moins de temps, et la solution finale était tout près, il manque le shebang au script que je fournis (.print_ssh_password). Au passage, et contrairement à la majorité des posts que j’ai pu lire sur le sujet, j’utilise une base python-alpine pour le job et pas Debian/Ubuntu, ce n’est donc pas bash qui est aux commandes, et donc il faut adapter un chouia la séquence, mais ça a donné ça :

script:
  - echo "[SSH]Initialisation Clé"
  - |
    mkdir ~/.ssh && chmod 700 ~/.ssh
    echo -ne '#!/bin/sh\necho $passphrase' > ~/.ssh/.print_ssh_password
    chmod 700 ~/.ssh/.print_ssh_password
    eval $(ssh-agent)
    echo "$key" | tr -d '\r' | DISPLAY="None" SSH_ASKPASS=~/.ssh/.print_ssh_password ssh-add -
  - echo "[INFO] Ping du serveur"
  - ansible linux_server -m ping -i inventories/$ANSIBLE_INVENTORY -vvvvvv

Ouais, la brochette de v à la fin permet d’avoir le moindre bout de message d’erreur, franchement abusez-en pendant une telle opération c’est super pratique.

Donc, qu’est-ce qu’on a fait ? En amont, via Vault, on récupère la clé privée dans la variable key et sa passphrase dans la variable passphrase, rien de très original là-dedans. En passant, comme cette récupération se fait pendant l’exécution du job, job qui se lance dans un runner Kubernetes, il n’y a pas de stockage persistant de ces variables. On crée le dossier .ssh avec les bonnes permissions à la racine du dossier utilisateur de l’image, et on y place un petit script dont le seul rôle est d’afficher le contenu de la variable passphrase. On démarre le ssh-agent, puis on traite le contenu de la variable key (pour virer d’éventuels retours chariot à la Windows), avant de l’envoyer à ssh-add (le tiret à la fin permet de dire qu’on lui envoie la clé directement, sans passer par un fichier), à qui on précise les variables DISPLAY et SSH_ASKPASS pour éviter de chercher à poser la question à un humain, la réponse étant directement fournie par le script.

Le résultat est sans appel:

linux_server | SUCCESS => {
    "ansible_facts": {
        "discovered_python_interpreter": "/usr/bin/python"
    },
    "changed": false,
    "invocation": {
        "module_args": {
            "data": "pong"
        }
    },
    "ping": "pong"
}

« Ça serait pas arrivé avec Kubernetes »

C’est vrai quoi, une API finalement c’est mieux pour faire tout ça non ?

J’avais envie de troller un peu, mais plus sérieusement, étant donné qu’il y a aussi un annuaire pour gérer les connexions utilisateurs sous Linux, je suis surpris que la méthode repose sur ce genre de mécanisme avec un compte local et une clé SSH et pas un compte technique de la même nature que pour les Windows, ce qui aurait simplifié le processus tout en harmonisant les configurations.

En tout cas, j’étais soulagé et heureux d’avoir pu trouver la solution et continuer mes migrations. Et vous, vos connexions SSH dans Gitlab-CI, vous les gérez comment ?