Config SSH : 2 questions et conseils

Support Debian
#1

Toujours dans mes exercices d’amélioration d’un serveur-maison, j’aimerais avoir des précisions sur ce qu’il convient de faire pour interdire à ‘root’ la connexion en SSH.
En plus du mot de passe, le serveur est muni d’un jeu de clefs RSA
Sur les points suivants, ssh_config est présenté originalement ainsi :

" Authentication:
LoginGraceTime 120
PermitRootLogin without-password ------------ (1)
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
"AuthorizedKeysFile %h/.ssh/authorized_keys

" Change to no to disable tunnelled clear text passwords
PasswordAuthentication yes ---------------------------------(2)

J’AI MODIFIÉ AINSI :

(1)
PermitRootLogin no
et j’ai commenté : PermitRootLogin without-password

(2)
Est-il préférable de mettre “no” ?

MAIS :
La connexion SSH en tant que root n’est pas refusée.
Il m’est demandé acceptation de la clef et le mot de passe de l’utilisateur.
En entrant ce MDP, bien sûr, on arrive en tant qu’utilisateur et non en tant que root.
Est-il possible d’avoir un refus plus prompt si la demande de connexion est envoyée en tant que root ?

Pour les ligne suivantes, je comprends que je dois conserver la première, mais pour les 3 autres, dois-je commenter ?

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

#2

Est-ce que tu as bien relancé le démon sshd après modification ?

Pour le point (2), je mets non aussi, une fois que je me suis assuré que la connexion par clé fonctionne.
Avec cette modification, une tentative de connexion sans clé sera directement refusée, peu importe l’utilisateur.

#3

Oui et je viens même de redémarrer les deux machines pour pouvoir tester à fond : Résultat explicite.

root@jessie-ssd:~# ssh -p XX ricardo@192.168.0.X
The authenticity of host ‘[192.168.0.X]:XX ([192.168.0.X]:XX)’ can’t be established.
ECDSA key fingerprint is ??? 64:cxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no)? no

Un rapport avec cette ligne, qu’il faudrait ptet commenter :
HostKey /etc/ssh/ssh_host_ecdsa_key

#4

Tiens, ricardo, lis ce mémo que je me suis créé !

Il part d’un prédicat de base qui est IMPORTANT :

  • utiliser QUE la version 2 du protocole
  • NE PAS permettre au compte root de se connecter
  • désactiver l’authentification par mot de passe
  • utiliser l’authentification par clés

Il est vrai, ce mémo n’explique pas comment faire ces 4 premières étapes, parce que cela doit être un prérequis qui doit être acquis, dont les réponses se trouvent très rapidement, si besoin.
Le mémo s’appesantit sur des choses plus profondes, qu’il est important d’aborder, de comprendre, et de mettre en place. :wink:

PS : j’aime tes questionnements. Il fut un temps où je me suis posé de telles questions, et j’ai cherché à comprendre et à trouver des lectures qui répondaient à mes questions. Dans le mémo, en question, tu y trouveras certaines de ses lectures en question.
Mon propos est/était d’être sûr de gérer SSH, en étant le plus sécurisé par rapport aux clés générées, aux protocoles réellement sûrs, etc…
Et, étant donné que j’ai, pour certaines raisons, des problèmes de mémoire certains, je voulais une trace écrite qui centralise mes efforts de recherche - c’est d’ailleurs carrément le but de mon blog - et, ensuite de partager toutes les traces qui sont écrites dessus.
Donc, sers-t-en, profites-en, uses-en, toi aussi :wink:

#5

Mon problème est règlé en commentant les trois lignes :

HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Et, bien sûr
connexion ‘root’ = no
connexion avec passeport = no

@PengouinPdt
À quoi sert
HostKey /etc/ssh/ssh_host_ed25519_key
C’est un autre système de clefs que RSA ?

Autre question :
UsePrivilegeSeparation sandbox
en préférant la valeur ‘sandbox’ à ‘yes’

Qu’est-ce que c’est sandbox, pourquoi cette préférence ?

#6

C’est un autre système de chiffrement, qui serait plus solide que RSA.
Si tu as deux clés, l’une RSA, l’autre ED25519, appartenant à un même hôte client, déposées sur un même serveur SSH, le serveur SSH va préférer/tenter la connexion avec le chiffrement ED25519, plutôt que RSA.

Derrière RSA, c’est du SHA1
Derrière ED25519, c’est du sha512
(si j’ai bien compris)

Bien avoir, OpenSSH > v6.5 !

Eh, beh, non, c’est justement une des deux lignes à préférer, l’autre étant à-propos du chiffrement RSA.
Celles que tu dois ABSOLUMENT commentées sont les lignes correspondant aux chiffrement DSA, ECDSA, susceptibles d’être “faillibles”

C’est une forme de cloisonnement, une protection pour SSH, appelé en français “bac à sable”.

#7

Merci pour ces précisions.

#8

Ça dépend de ce que tu appelles refusée en fait. Si tu regardes tes logs (/var/log/auth.log), tu verras des lignes de ce genre :

sshd[xxxxx]: input_userauth_request: invalid user root [preauth]
Failed password for invalid user root from xxx.xxx.xxx.xxx port xxxxx ssh2
#9

Exact !
merci.