Modification des paramètres SSH ( surtout changement de ports et connexion avec clé)

Discuss Advanced use case
1

:fr: Français, baguette, fromage !

Mon serveur YunoHost

Matériel: Vieil ordinateur
Version de YunoHost: 4.1.8
J’ai accès à mon serveur : En SSH | Par la webadmin
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non (j’ai essayé de modifier la connexion en SSH sur un fichier test, mais j’ai été vite refroidi et remis le fichier d’origine)

Description du problème

Bonjour, j’ai déjà configuré un accès SSH pour un serveur Debian (non Yunohost) en :

  • remplaçant la connexion avec mot de passe par une connexion avec une paire de clé,
  • et aussi en changeant le port de connexion.

Pour cela, j’ai suivi scrupuleusement le tutoriel du site Korben. L’avantage est que je dispose déjà dans mon pc portable d’une paire de clé publique/privée, donc je n’ai pas à en refaire une.

MAIS, avec Yunohost, alors que je pensais être devenu un as du SSH (en fait non), toutes mes tentatives de connexion on échouées (le message d’erreur pour la paire de clé affichant quelque chose du genre too many login attempts, et pour le changement de port, impossible de me connecter tout simplement).

Question :

J’aimerais que vous me donniez votre avis sur les modifs que j’ai faites et que vous me disiez si elles sont erronées, ou si tel paramètre est obsolète, mal placé, etc.

Pour le problème de changement de port je n’arrive pas à suspecter le souci (j’ai peut-être pensé ouvrir un port alors qui ne l’était pas). Quant au problème de la connexion avec clé, je suspecte d’avoir ajouté le mauvais utilisateur au groupe autorisé à se connecter en SSH.

Dites-moi ce que vous en pensez, j’ai disséminé mes pensées via des remarques le long de ce tuto pour que vous puissiez comprendre mes suspicions.

Merci beaucoup pour votre aide, et ne vous endormez pas en lisant !

Voici les étapes suivies :

  • Connexion SSH sur le serveur via le port classique (22) et mot de passe, puis modification de la config SSH sur le serveur (avant de modifier le fichier, je fais une copie au cas où) :

ssh korben@monserveur.com

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config_original

sudo nano /etc/ssh/sshd_config

  • Changement de port en remplaçant le numéro 22 par 1234 par exemple :
Protocol 2
Port 22

devient :

Protocol 2
Port 1234
  • Relancer le serveur et se reconnecter avec le nouveau port :

/etc/init.d/ssh restart

ssh -p1234 korben@monserveur.com

Remarque 1 : déjà là, le changement de port ne fonctionnait pas, j’avais pourtant ouvert les ports sur la box et sur l’interface webadmin. Une idée ?

  • Modification des droits d’accès au dossier ssh du serveur (pour y transférer la clé) :

chmod 0700 ~/.ssh

  • Transfert de la clé publique du pc portable vers le serveur :

scp -P 1234 ~/.ssh/id_server.pub korben@monserveur.com:~/.ssh/authorized_keys

  • Remodification des droits d’accès au dossier ssh du serveur (pour le verrouiller) :

chmod 0600 ~/.ssh/*

  • Mise en place d’un groupe autorisé à se connecte en ssh et ajout du user dans ce groupe :

groupadd sshusers

usermod -a -G sshusers korben

Remarque 2 : dans le tuto, il est question de l’utilisateur korben. En voulant modifier ce nom, j’ai mis admin (du serveur yunohost). Avec le recul, je pense que j’aurais dû mettre le nom d’utilisateur de mon pc portable prog-amateur_laptop puisque c’est lui qui se connecte en ssh vers mon serveur, qu’en pensez-vous ?

  • Remodification de la config SSH sur le serveur :

sudo nano /etc/ssh/sshd_config

  • Modification du paramètre Hostkey pour donner l’empreinte DSA :

HostKey /etc/ssh/ssh_host_dsa_key

  • Modification pour ne permettre qu’au groupe sshusers de se connecter en ssh :

AllowGroups ssh.main sftp.main ssh.app sftp.app admins root

devient

AllowGroups sshusers

  • Modification de la durée de connexion avant d’entrer les identifiants (on la réduit vu qu’on veut utiliser une clé) :

LoginGraceTime 120

devient

LoginGraceTime 20

  • Ajout d’un paramètre de nombre maximum d’essais avant de se faire jeter par le serveur (puisqu’on utilise une clé qui ne peut se tromper, on peut la mettre à 1) :

MaxAuthTries 1

  • Ajout d’un paramètre pour activer la connexion par clé et le chemin de cette clé :

AuthorizedKeysFile .ssh/authorized_keys

  • Désactivation de toutes les autres méthodes d’authentification :
RSAAuthentication no
UsePAM no
KerberosAuthentication no
GSSAPIAuthentication no
PasswordAuthentication no
  • Ajout d’un paramètre pour définir un quota de connexions non authentifiées simultanées :

MaxStartups 2

  • Relancer le serveur et se reconnecter :

/etc/init.d/ssh restart

ssh -p1234 korben@monserveur.com

  • Hashage du fichier known_hosts :

ssh-keygen -H -f ~/.ssh/known_hosts

Remarque 3 : le tuto ne dit pas sur quelle machine (pc portable ou serveur yunohost) faire ce hachage. Par conséquent je l’ai fait sur les deux, est-ce correct ?

2

Pour le changement de port et connexion par clé, tout est décrit comment faire ici:
https://yunohost.org/fr/security

2 Likes
3

Il comprennent rien ces jeunes en écrivant leur roman sans avoir lu la doc ^^

Je plaisante, merci beaucoup pour le lien. J’ai donc suivi le tutoriel de la doc officielle, et si j’ai pu transférer ma clé publique et augmenter la sécurité SSH, je n’arrive pas en revanche à modifier le port de connexion.

En gros, je rentre :

sudo yunohost settings set security.ssh.port -v <votre_numero_de_port_ssh>

Une ou deux secondes plus tard, ça passe à la ligne de commande suivante comme si tout s’était bien passé (j’ai même le souvenir qu’il avait dit que fail2ban a été mis à jour pour cela). Puis je me déconnecte, puis je me reconnecte avec le port proposé et ça me dit :

ssh: connect to host domaine.com port XXX: Connection refused

Du coup je retente le classique ssh admin@domaine.com (donc en port 22), et là nickel ça fonctionne.

Les ports XXX sont pourtant ouverts, à la fois dans ma box et dans yunohost.

Je revérifie donc le fichier /etc/ssh/sshd_config et m’aperçois que le port inscrit dans la config reste le port 22 (c’est-à-dire que la commande sudo yunohost settings set security.ssh.port -v XXX n’a pas modifié le fichier /etc/ssh/sshd_config).

Aurais-tu une idée stp ? Merci !

4

Oui je pense que c’ets parce que tu as modifié au préalable la config SSH, du coup YunoHost ne fait rien de peur de casser ta config personnalisée.

Du coup, tu peux faire:

sudo su
yunohost settings set security.ssh.port -v <votre_numero_de_port_ssh>
yunohost tools regenconf ssh --force
5

En fait, je suggère fortement de suivre la configuration proposée par YunoHost modulo les modifs listées dans la doc security dont j’ai donné le lien. Notamment garder une conf “marquée” comme non modifiée dans les diagnostique permet de bénéficier des mises à jour automatiquement, plusieurs personnes qui ont voulu renforcer la sécu de cette conf, ont au final fait pire que mieux et ont loupé des MAJ importantes du fichiers. Bref, si tu modifies il faudra être rigoureux ensuite sur la comparaison avec la nouvelle proposition de YunoHost (via les outils de regenconf).

Le tuto de korben semble dater de 2010 et par exemple rajouter une clé DSA semble dommage alors que justement on a fait des efforts dans yunohost pour l’enlever ^^.

Cette ligne permet à certaines apps et aux permissions SSH et SFTP dans Webadmin > Users > Manage groups and permissions de fonctionner correctement. Si tu as besoin qu’un user puisse accéder en SSH/SFTP il faut le faire via le système de permission de yunohost (idéalement).

Perso je péterais pas la maj auto du fichier juste pour ça.

Ça peut être un peu embêtant quand tu gères plusieurs serveur avec des clés différentes. Et quid si tu mets trop de temps à débloquer la clé privée ?

En fait, c’est par défaut si je dis pas de bêtises.

Ces options ne s’appliquent pas avec le protocol 2 ou sont à no par défaut.

A creuser

Conseillé dans la doc security

La valeur par défaut est 10 et c’est déjà bien à mon sens (pas de risque de couler le serveur).

1 Like
6

Merci pour ton retour très utile, tout fonctionne !!! Suivant tes conseils, j’ai arrêté de suivre le tuto de korben pour éviter un problème de config SSH et j’ai suivi la doc officielle + ton conseil pour résoudre le problème des ports.

Donc pour faire le bilan, je n’ai changé que :

  • le port (à noter que la commande yunohost tools regenconf ssh --force est incorrecte à cause de l’argument regenconf, il faut donc écrire yunohost tools regen-conf ssh --force)
  • le type de connexion (du type mot de passe à un type clé de déchiffrement avec la commande ssh-copy-id -i ~/.ssh/id_rsa.pub admin@domaine.com depuis le pc portable, puis sur le serveur sudo nano /etc/ssh/sshd_config, puis repérer l’argument PasswordAuthentication et le passer à no, et enfin lancer un systemctl restart ssh)
  • et la configuration TLS (avec sudo yunohost settings set security.nginx.compatibility -v modern puis sudo yunohost settings set security.ssh.compatibility -v modern),

le tout selon la documentation officielle (et sans faire aucune autre modif).
→ Je n’ai donc rien à craindre au niveau des mises à jours, on est d’accord ?

Encore merci.

7

Bonjour,

Dès que le fichier est modifié on perd les mises à jour automatique et comme signalé par @ljf il faut passer par regenconf pour comparé les modifications dudit fichier avec la version mise à jour. Du coup pour que ton fichier soit vu comme “non modifié” et continuer à bénéficier des mises à jour automatiques de Yunohost, il faut utiliser un hook.
Tu peux créer le fichier /etc/yunohost/hooks.d/conf_regen/04-ssh_port, que tu modifies selon ce que tu souhaites, toujours en connaissance de cause en sachant ce que tu fais:

#!/bin/bash

action=$1
pending_dir=$4
ssh_conf=$pending_dir/../ssh/etc/ssh/sshd_config

[[ "$action" == "pre" ]] || exit 0
[[ -e "$ssh_conf" ]] || exit 0

#sed -e "s/Port.*/Port ${SSH_CLIENT##* }/" \
sed -e "s/UsePAM.*/UsePAM no/" \
    -e "s/#PasswordAuthentication.*/PasswordAuthentication no/" \
    -i $ssh_conf

en l’état, il passe la valeur de UsePAM à no et celle de PasswordAuthentication à no. J’avais suivi la documentation d’Ubuntu-fr qui conseille ces 2 valeurs. Celle de Yunohost ne parle que de la seconde.

1 Like
8

Merci beaucoup @metyun. Là, ça me fait un peu flipper… si j’édite le fichier sshd_config :

  • je perds la mise à jour automatiquement entière de Yunohost ? (c’est ça que je comprends en lisant ta précédente phrase)
  • ou bien je perds la mise ça jour automatique du fichier sshd_config, le reste de Yunohost se mettant automatiquement à jour ?

Sinon, merci pour le hook, ça peut servir énormément pour ceux qui sont confiants dans le code. En ce qui me concerne, j’hésite beaucoup, je risque typiquement de tout faire capoter par manque de compétences : une erreur de syntaxe et je ne saurais probablement même pas comment trouver la faute.

9

C’est seulement la mise à jour de sshd_config qui ne sera pas fait.
Si Yunohost détecte une modification de fichier, il ne le met pas à jour. Ça oblige à être rigoureux lors des mises à jour et de vérifier à chaque fois qu’on en fait une si il y a eu des changements apportés par l’équipe de développement de Yunohost avec la commande:

yunohost tools regen-conf --dry-run --with-diff

Pour le hook c’est ce qu’il y a de mieux car Yunohost ne verra pas ta modification et continuera à appliquer les mises à jour de ce fichier. Si tu te trompes ou tu fais une erreur de syntaxe, c’est toujours réversible. Il suffit de supprimer le fichier hook et de rétablir en passant la commande:

yunohost tools regen-conf ssh

Si tu souhaites des explications sur la commande du script, tu peux toujours m’envoyer un message direct si tu le souhaites.

10

Merci beaucoup ! au moins, l’impact est moins important que si tout Yunohost devait à être figé.

Je suis tout de même tenté par ta proposition de hook. Sachant que le TLS n’est pas censé toucher /etc/ssh/sshd_config, seuls les paramètres du port et de l’authentification en mot de passe sont susceptibles d’être modifiés dans ce fichier.

  1. Du coup, qu’est-ce que tu penses de (avec XXX correspondant au numéro de port personnalisé) :
#!/bin/bash

action=$1
pending_dir=$4
ssh_conf=$pending_dir/../ssh/etc/ssh/sshd_config

[[ "$action" == "pre" ]] || exit 0
[[ -e "$ssh_conf" ]] || exit 0

#sed -e "s/Port.*/Port ${SSH_CLIENT##* }/" \
sed -e "s/Port.*/Port XXX/" \
    -e "s/#PasswordAuthentication.*/PasswordAuthentication no/" \
    -i $ssh_conf
  1. Dans l’ordre, faudrait que :
  • je remette le fichier /etc/ssh/sshd_config dans son état d’origine en lançant un :
sudo su
yunohost settings set security.ssh.port -v 22
yunohost tools regen-conf ssh --force
  • Puis faire le fameux hook dans etc/yunohost/hooks.d/conf_regen/04-ssh_port
  • Et enfin relancer le ssh avec un systemctl restart ssh

C’est bien ça ?

Merci pour ton aide.

11

Si je veux changer le port pour SSH, comment choisir un port libre ? Existe-t-il une liste de ports “occupés” quelque part ? Je connais la liste dans le webadmin (firewall, port forwarding), mais est-ce qu’il y a d’autres ports qui sont “pris” aussi?

12

Non, il faut maintenant utiliser la commande yunohost settings set security.ssh.port car celle-ci ne modifie pas que le port mais aussi la configuration fail2ban associée à ce port. Et cette commande permet toujours les mises à jour de sshd_config en automatique.

C’est vrai que le hook proposé porte à confusion de par son nom mais également parce que je l’ai posté tel quel en laissant la ligne commenté de modification de port. A vrai dire celle-ci ne sert plus à rien (ce qui commence par un # est un commentaire et n’est pas exécuté), c’est un résidu de mon ancien hook quand yunohost ne proposait pas encore la commande security.ssh.port.

Si tu suis les recommandations de la documentation Yunohost, passe la commande security.ssh.port donnée par @ljf pour modifier le port suivi du hook à utiliser :
/etc/yunohost/hooks.d/conf_regen/04-ssh_pwdauth

#!/bin/bash

action=$1
pending_dir=$4
ssh_conf=$pending_dir/../ssh/etc/ssh/sshd_config

[[ "$action" == "pre" ]] || exit 0
[[ -e "$ssh_conf" ]] || exit 0

sed -e "s/#PasswordAuthentication.*/PasswordAuthentication no/" \
    -i $ssh_conf

Tu relances ensuite un regen-conf pour prendre en compte les modifications. Tu peux vérifier après ça que PasswordAuthentication est bien passé à no.
Pour vérifier que Yunohost ne voit plus ce fichier comme modifié, tu lances la commande yunohost tools regen-conf --dry-run --with-diff ssh. Celle-ci ne devrait rien te retourner désormais.

Travaille sur un fichier original (rétabli avec l’option --force de regen-conf) et non sur un fichier sshd_config déjà modifié.

3 Likes
13

@anon78416416,
Moi j’utilise la commande sudo lsof -s TCP:LISTEN -i -n -P
Elle affiche tous les ports ouverts en écoute — c’est ce que tu veux pour SSH.
Elle n’affiche pas les ports des connexions en cours.

1 Like
14

Il faudrait mettre à jour la doc de Sécurité | Yunohost Documentation pour :

  • expliquer cette histoire des fichiers qui ne sont plus modifiés automatiquement si modifiés manuellement
    • et bien insister sur le danger d’avoir des fichiers qui ne sont plus mis à jour automatiquement
  • changer l’ordre des sections pour que la modif manuelle soit décrite après la modif automatique
    • voire proposer le script hook pour faire cette modif…
  • idéalement (peut être ?) ajouter une option dans la moulinette yunohost

Si ça tente qqn avant que j’ai le temps de faire ce que je dis, je ne serais pas vexé :angel:

15

Moi j’ai joué le rôle de cobaye donc je passe la main ^^ Traite de plaisanterie, je te remercie pour ta proposition. Si toi ou un autre peut mettre à jour la doc, ce serait sympa parce que ce n’est pas exactement comme sur un Debian classique au final (déjà que pour un utilisateur comme moi, il n’est pas évident à mettre en place un SSH classique, alors savoir qu’il existe des exceptions est un plus pour éviter les erreurs potentielles).

Je propose aussi de mettre à jour la partie SSH et la ligne de commande → section SSH et sécurité où il y est simplement mention :

Une discussion plus complète sur la sécurité de SSH peut être trouvée sur la page dédiée.

SSH et la ligne de commande est pourtant le chapitre qui me paraîtrait le plus intuitif pour configurer la connexion. Vous avez fait le choix de mettre la section SSH et sécurité à part pour une raison probablement légitime, mais à ce moment-là, je pense qu’un texte plus explicite comme ci-dessous serait plus approprié :

Si vous souhaitez administrer les ports de connexion, mettre en place une authentification par paire de clés, ou toute autre configuration avancée, un chapitre plus complet sur la sécurité de SSH peut être trouvée sur la page dédiée.

Qu’en pensez-vous ? Voilà pour ma partie relou ^^

Juste pour faire un retour sur le message de @metyun : sa proposition est la bonne, je l’ai testé et elle fonctionne, je change donc la solution vers son message. Merci à toi et à tous !

16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.