SSH config : question sur autorisation ou non MDP

Support Debian
#1

Je viens de tester le sshd_config d’un SSH serveur d’essai.
Je ne veux pas entrer dans la discussion des meilleurs clefs et je ne parle ici que de RSA 4096.
Là, je pense que tout le monde est d’accord :

> Authentication:

PermitRootLogin no
StrictModes yes

C’est là où je me pose des questions, à l’origine, c’est présenté ainsi :

#  Change to no to disable tunnelled clear text passwords
 #PasswordAuthentication yes

Si je laisse ainsi, à partir du client, il m’est demandé :
1/la passe phrase
puis, si elle est acceptée,
2/le mot de passe de ricardo sur le serveur.

Tout fonctionne et je trouve que ça crée une double barrière, donc mieux à mon sens.

Par contre, si je décommente
#PasswordAuthentication yes
et que je remplace ‘yes’ par ‘no’,
J’ai bien la demande de pass phrase mais elle est refusée.

J’ai souvent lu qu’il fallait pourtant choisir cette seconde formulation.
Qu’en pensez-vous ?

#2

Mais, puisque je te dis : ED25519 !
“Et, surtout pas …”
"Non, je rigole … pas taper ! " :wink:

Bizarre ton problème !
Tu as bien redémarrer le service ?

Tu as vérifié le fichier auth.log, pour lire ce qu’il te dit, quand tu te fais “jeté” ?

Tu peux choisir la double authentification, si tu en as envie ; c’est juste plus contraignant !
Sachant que ça devient de plus en plus à la mode, sur beaucoup de sites … on va finir par s’y habituer :stuck_out_tongue:

#3

Moi, ça ne me dérange pas plus que ça pour un serveur contacté en SSH. ce n’est pas tous les jours que j’ai à le faire.
Ce que je voulais savoir c’est “pourquoi” il était préférable de placer cette ligne à “no”, alors qu’elle est commentée ?

#PasswordAuthentication yes

#4

Un coup de ‘man 5 ssh_config’ nous indique :

PasswordAuthentication
Specifies whether to use password authentication. The argument to this keyword must be “yes” or “no”. The default is “yes”.

De ce qu’il faut comprendre du manpage, quand une option est indiqué par un commentaire, c’est la valeur par défaut …
d’où le fait, que tu doives modifier le fichier pour lui indiquer ‘no’ dans ce cas :wink:

#5

1er essai : avec la ligne à ‘yes’ commentée :
Connexion parfaite après demande pass phrase ET mot de passe de ricardo du serveur.
2e essai, après avoir décommenté la ligne et mis 'no’
tentative de connexion, de la même machine sans avoir modifié autre chose :
Permission denied (publickey).
et retour à l’invite.
auth.log du serveur :
date nom machine : Server listening on 0.0.0.0 port XXX
seconde ligne semblable sauf ‘::’ à la place de 0.0.0.0
Côté client, log sans rapport et pas à la même date.

Je fais quoi ?

#6

Montre moi ta config côté client, puis serveur, relatives à tes arguments Ciphers, KeyAlgorithms, et MACs.
J’ai eu ce problème de connexion impossible, sans aucun message “concluant”.
Jusqu’à comprendre que cela venait de mes choix relatifs à ces arguments-là !

Donc, si tu ne veux pas les montrer … vérifies la bonne gestion avec l’option Q de ssh, telle que :

ssh -Q cipher
ssh -Q mac
ssh -Q key

#7

ricardo nous dit :
Je fais quoi ?

Sur la machine cliente, vous faites les deux commandes suivantes

ssh-add -l

ssh -v utilisateur@serveur

et vous copier coller ce qui s’affiche.

Je dis cela car si vous utilisez des clés (vous parlez bien de passphrase), autant utiliser un agent (ssh-agent) qui va faire le boulot de négocier avec le serveur pour ces histoires d’authentification.

Une fois cela fait, vous passez au niveau supérieur en tapant

ssh-agent $SHELL
# (normalement vous donnez ici votre passphrase, ces infos sont gardées au chaud par l'agent)
ssh-add -l
# devrait afficher 4096 suivi d'une empreinte
ssh -v user@serveur
#  connexion sans mot de passe. Vous êtes le roi :smile:

Cordialement,
Regards,
Mit freundlichen Grüssen,
مع تحياتي الخالصة

F. Petitjean

Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. (R. Devos)

#8

Une seule chose à la fois : ma config serveur complète :

J’ajoute que ma spécificité vient ptet du fait que ma clef est appelée
"id_rsa-serv" pour la différencier car j’ai déjà une “id_rsa” et une “id-rsa1”, lesquelles fonctionnent.

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port XXX
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
######HostKey /etc/ssh/ssh_host_rsa-serv_key ###essai avec ssh_host_rsa-serv = infructueux### 
###HostKey /etc/ssh/ssh_host_dsa_key
###HostKey /etc/ssh/ssh_host_ecdsa_key
###HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
### PermitRootLogin without-password
PermitRootLogin no
StrictModes yes

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

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

AllowUsers ricardo
#9

Mis-à-part, cette ligne qui DOIT être à ‘no’ … je ne vois pas en quoi, cela t’empêche la connexion.

ET, ce n’est surtout pas ton histoire de nom de fichier qui change quelque chose.
À moins que tu n’aies pas de correspondance de noms de fichiers.

Ensuite, si cela ne marche pas avec cette clé, es-tu sûr de la bonne génération de la clé relative à ce fichier ?

#10

Pas beaucoup de temps en ce moment mais je vais tester cet AM à partir d’une autre machine.
Merci de l’aide.

#11

J’ai donc modifié -vieux le “authorized_keys” du serveur
Sur ma seconde machine-client, j’ai viré les deux clefs présentes
J’ai recréé un jeu de clef
J’ai “ssh-copy-id …” le .pub vers le serveur
Vérifié la connexion SSH avec ces nouvelles données = OK
Retour sur le serveur, replacé autorisation par MDP à 'no’
Restart SSH
Retour sur le client, test de connexion = OK … enfin.

la config est la même sur les deux clients, hormis le nom de la cles :
rsa vs rsa-serv
rsa.pub vs rsa-serv.pub

Le problème, c’est que sur ma machine principale, j’ai déjà un “rsa” qui pointe vers mon serveur distant et je ne veux pas y toucher.
Je suis donc bien obligé de modifier le dernier.

J’arrête là car j’ai plein d’autres occupations familiales en ce moment.
Le principal, c’est que je peux continuer mes essais avec une possibilité de connexion en ssh.

merci à tous pour l’aide.