Il ne s’agit pas de me faire confiance mais de comprendre les implications.
Si ton mot de passe root est “toto”, je comprends que tu désactives le login root.
PermitRootLogin ne prend pas que les valeurs “yes” et “no”, on peut aussi spécifier avec la valeur “without-password” que le login root ne peut se faire qu’avec l’authentification par clé, qu’on protégera si besoin par une passphrase robuste.
J’ai bien percuté mais malheureusement, en faisant au plus simple : “permitrootlogin yes”, c’est toujours le même refus 
Connection closed by 192.168.0.4
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7]
à demain 
Avant de tester avec rsync, vérifie déjà qu’une connexion SSH “normale” fonctionne :
Ça sera probablement plus facile à déboguer comme ça qu’avec rsync.
En effet,il y a un loup dans l’acceptation de la clef :
Je me logue en root donc le pass est bon
j’envoie ma commande avec … root@192.168.0.4 …
il me demande le pass root, je le tape … il est refusé 
(c’est pourtant bien le même)
Je passe à ton test :
ssh root@192.168.0.4
The authenticity of host '192.168.0.4 (192.168.0.4)' can't be established.
RSA key fingerprint is xxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no)? yes
il me demande confirmation du pass
Warning: Permanently added '192.168.0.4' (RSA) to the list of known hosts.
root@192.168.0.4's password:
Puis reconfirmation, et là
Permission denied, please try again.
Je dois sortir et je reviens bientôt.
Je vais tenter de commenter les lignes de clefs qui sont habituellement pour ricardo ???
Non, le compte ricardo n’a rien à voir, vu que tu essayes de te connecter sur root ça ne peut concerner que /etc/ssh/sshd_config ou bien /root/.ssh/ (sur le serveur 192.168.0.4)
Question con, mais sait-on jamais : les mots de passe root sur les deux machines sont identiques, aucun risque que tu inverses les deux ?
Sinon, tu utilises un fichier de config sur ta machine cliente (celle sur laquelle tu tapes les commandes rsync/ssh, le fichier c’est /root/.ssh/config puisque tu fais ça aussi à partir du compte root) ?
Non, le compte ricardo n’a rien à voir, vu que tu essayes de te connecter sur root ça ne peut concerner que /etc/ssh/sshd_config ou bien /root/.ssh/ (sur le serveur 192.168.0.4)
Question con, mais sait-on jamais : les mots de passe root sur les deux machines sont identiques, aucun risque que tu inverses les deux ?
Sinon, tu utilises un fichier de config sur ta machine cliente (celle sur laquelle tu tapes les commandes rsync/ssh, le fichier c’est /root/.ssh/config puisque tu fais ça aussi à partir du compte root) ?[/quote]
Au niveau des pass, impossible de confondre, ils sont bien différents et d’ailleurs, quand je commence par me connecter en root, je le tape et j’arrive à # c’est donc que le pass est le bon.
Sinon, ce que j’ai fait :
placé le permitlogin root à “yes” dans les deux machines pour l’instant.
machine1 = serveur ssh ? - 192.168.0.4, celle qui sert à entrer les commandes ???
donc, sur cette machine, /root/.ssh ne comporte qu’un seul fichier : “known_hosts”, dans lequel il y a plusieurs séries de clefs, suite certainement à mes essais successifs.
Je les commente et je retente ou quoi ?
EDIT :
J’ai fait mais même refus 
Par contre, toujours en parlant de machine1 (serveur ssh ?), dans le fichier
/etc/ssh/ssh_config (ne pas confondre avec sshd_config)
j’ai été interpellé par des commentaire nombreux, dont :
[quote]Host *
ForwardAgent no
ForwardX11 no
ForwardX11Trusted yes
RhostsRSAAuthentication no
[b]# RSAAuthentication yes
PasswordAuthentication yes[/b][/quote]
Ne seraient-ils pas à décommenter ?
Salut,
[code]:~# cat /etc/ssh/sshd_config
Package generated configuration file
See the sshd_config(5) manpage for details
What ports, IPs and protocols we listen for
Port 22
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_dsa_key
#Privilege Separation is turned on for security
On active la séparation des privilèges
UsePrivilegeSeparation yes
Lifetime and size of ephemeral version 1 server key
Durée de vie et taille de la clé
KeyRegenerationInterval 3600
#ServerKeyBits 16384
#ServerKeyBits 32768
Logging
Pour syslog
SyslogFacility AUTH
LogLevel INFO
Authentication:
LoginGraceTime 2
Cette option permet d’autoriser ou non une connection au serveur openSSH avec le login root.
Les valeurs possibles sont donc yes pour autoriser l’accés au compte root par SSH, no (par défaut) pour la refuser et without-password pour
autoriser l’accés au compte root uniquement par clé (et non par identification par mot de passe).
Il est fortement conseillé pour des raison de sécurité d’interdire la connection au serveur openSSH avec le login root,
et en tout cas au moin via mot de passe afin d’éviter les attaques par la force brute via SSH.
PermitRootLogin yes
PermitRootLogin without-password
#StrictModes yes
Ignore l’authentification RhostsRSA
RSAAuthentication yes
Autoriser ou non la connexion par clé publique. Par défaut, cette option est sur « yes ».
PubkeyAuthentication yes
Indique le chemin vers le fichier cntenant les clés autorisée pour l’authentification par clé publique.
AuthorizedKeysFile %h/.ssh/authorized_keys
AuthorizedKeysFile /root/.ssh/authorized_keys
AuthorizedKeysFile /root/.ssh/authorized_keys2
AuthorizedKeysFile /root/.ssh/authorized_keys3
Don’t read the user’s ~/.rhosts and ~/.shosts files
Ignore les fichiers ~/.rhosts et ~/.shosts
IgnoreRhosts yes
For this to work you will also need host keys in /etc/ssh_known_hosts
Ignore l’authentification RhostsRSA
RhostsRSAAuthentication no
similar for protocol version 2
#HostbasedAuthentication no
Uncomment if you don’t trust ~/.ssh/known_hosts for RhostsRSAAuthentication
A décommenter sur on ne veut pas se fier au fichier ~/.ssh/known_hosts pour RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
To enable empty passwords, change to yes (NOT RECOMMENDED)
Empêche la connexion des utilisateurs qui n’ont pas de mot de passe (PAS RECOMMANDE)
#Cette option permet d’autoriser ou non des connexion avec un couple identifiant/mot de passe MAIS en autorisant que le mot de passe soit vide.
#Ceci est une aberration du point de vue sécurité.
#Par défaut, cette option est sur « no ».
PermitEmptyPasswords no
Change to yes to enable challenge-response passwords (beware issues with
some PAM modules and threads)
Activer les mots de passes par Challenge / Réponse
ChallengeResponseAuthentication no
Change to no to disable tunnelled clear text passwords
Permet de supprimer l’authentification par mot de passe et n’utiliser que l’authentification par clé partagée
Cette option permet d’autoriser ou non des connexion avec un couple identifiant/mot de passe.
Il est plus sûr d’autoriser l’accès à la machine uniquement aux utilisateurs avec des clés SSH placées dans le fichier ~/.ssh/authorized_keys.
Si c’est ce que vous voulez, positionnez cette option à « no ».
PasswordAuthentication no
Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
Activer la redirection X11
X11Forwarding yes
X11DisplayOffset 10
Aficher le message du jour (Message Of the Day)
PrintMotd yes
Afficher la date et heure de la dernière connexion
PrintLastLog yes
Maintient la connexion TCP
TCPKeepAlive yes
#UseLogin no
Cette option permet de limiter le nombre de connexion : le 10 représente le nombre de connexions acceptées sans qu’un utilisateur ait réussi à s’identifier,
#si cela passe au dessus de 10, il y a 30 % de chances que les suivantes soient bloquées, ça augmente linéairement jusqu’à complétement bloquer les connexions à 60 %.
MaxStartups 10:30:60
Cette option permet de limiter le nombre de de tentative d’authentification : ici, 3.
MaxAuthTries 3
#Banner /etc/issue.net
Allow client to pass locale environment variables
Permet à un client de passer des variables locales d’environnement
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
AllowGroups adm sshusers wheel mon-user root
AllowUsers mon-user @91.x.x.x
AllowUsers root @91.x.x.x
DenyUsers invite
DenyGroups stagiaire
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
Compression yes
:~#
[/code]
Bon, reprenons, histoire de voir si j’ai bien tout compris (ça m’embrouille ces machines 1/2 qu’on sait plus laquelle est laquelle 
)…
- Tu es assis devant la machine 192.168.0.4 (qu’on va appeler 0.4), celle sur laquelle est connecté le disque externe
- Tu te connectes en SSH sur la machine 192.168.1.2 (qu’on va appeler 1.2)
- À partir de ta session SSH, tu veux sauvegarder le contenu de 1.2 en te connectant en retour sur root@0.4 en SSH (même si c’est automatisé par rsync plus tard, mais on n’en est pas là)
Si je me plante pas, les fichiers/dossiers à vérifier sont :
- sur 0.4 : /etc/ssh/sshd_config, /root/.ssh/
- sur 1.2 : /root/.ssh/
Sur 1.2 à priori ça devrait déjà être bon, puisque tu peux de connecter sans souci sur ricardo@0.4. Peut-être tout de même vérifier /root/.ssh/config si tu l’utilises.
Sur 0.4, dans /root/.ssh il faut vérifier plusieurs choses :
- que les droits sont corrects (root:root 600)
- éventuellement le fichier authorized_keys
Toujours sur 0.4, dans /etc/ssh/sshd_config pour pouvoir te connecter en root avec un mot de passe (on verra après si tu veux installer une clé) :
- PermitRootLogin yes
- PasswordAuthentication yes
- vérifier également que tu n’as pas de AllowUsers / AllowGroups / DenyUsers / DenyGroups (ou sinon il faut mettre root explicitement dans AllowUsers et l’enlever de DenyUsers s’il y est)
[quote]Bon, reprenons, histoire de voir si j’ai bien tout compris (ça m’embrouille ces machines 1/2 qu’on sait plus laquelle est laquelle )…
- Tu es assis devant la machine 192.168.0.4 (qu’on va appeler 0.4), celle sur laquelle est connecté le disque externe
- Tu te connectes en SSH sur la machine 192.168.1.2 (qu’on va appeler 1.2)
- À partir de ta session SSH, tu veux sauvegarder le contenu de 1.2 en te connectant en retour sur root@0.4 en SSH (même si c’est automatisé par rsync plus tard, mais on n’en est pas là)[/quote]
Donc, OK avec tout en dehors du 0 à la place du 1 : 192.168.0.2
Cela étant dit, je répondrai à la suite après vérif.
[quote]Si je me plante pas, les fichiers/dossiers à vérifier sont :
- sur 0.4 : /etc/ssh/sshd_config, /root/.ssh/[/quote]
Première chose qui m’interpelle, sur 04, /root/.ssh me semble bien pauvre comparé à son homologue /ricardo
04# ls -al /root/.ssh
total 12
drwx------ 2 root root 4096 déc. 29 2009 .
drwxr-xr-x 28 root root 4096 avril 30 00:55 ..
-rw-r--r-- 1 root root 2657 mai 21 11:56 known_hosts
???
EDIT :
idem sur 0.2, pas plus locace
EDIT2 :
[quote]Sur 1.2 à priori ça devrait déjà être bon, puisque tu peux de connecter sans souci sur ricardo@0.4. Peut-être tout de même vérifier /root/.ssh/config si tu l’utilises.[/quote]Cette dernire phrase veut-elle dire que le fichier serait “à créer” ?
Ok, noté… Dans ton premier message c’est bien 1.2 qui est marqué d’où mon erreur.
[quote=“ricardo”]Première chose qui m’interpelle, sur 04, /root/.ssh me semble bien pauvre comparé à son homologue /ricardo
[…]
idem sur 0.2, pas plus locace[/quote]
C’est plutôt bon signe en fait, ça veut dire que t’as pas de config bizarre. 
D’après ce que tu dis, le seul truc éventuellement à faire c’est un chmod -R g-rwx,o-rwx /root/.ssh (efface les droits pour le groupe et pour les autres sans toucher aux droits du propriétaire) sur tes deux machines.
Et du coup, aller s’occuper du /etc/ssh/sshd_config sur la machine 0.4.
Pas nécessairement. Moi je m’en sers beaucoup pour pouvoir faire des “alias” qui sont plus simples à retenir (j’ai une clé différente par machine, des noms d’utilisateur qui sont jamais les mêmes, idem pour les ports… j’ai pas envie d’encombrer ma mémoire avec ces détails) : ssh machine1 c’est vachement mieux que ssh -i ~/.ssh/machine1 user2@machine2.domaine2.fr -p 98765 etc etc.
Mais s’il n’existe pas chez toi vaut mieux laisser tel quel, c’est pas le moment de rajouter de la complexité… C’est plus sage d’attendre que le reste marche.
Pas mieux, j’ai chmodé comme indiqué mais premier test de pass = rejeté ; 2eme, il y a une attente qui laisse à supposer que le pass a été pris en considération puis retour à l’invite avec ce msg
( en bleu, autre dossier de réception où je suis sûr qu’il y a de la place et qui se trouve sur le DD direct, sans montage) :
[quote]02# rsync -av --del --exclude-from=/home/ricardo/exclure /home root@192.168.0.4:/home/sauve-serv
root@192.168.0.4’s password:
Permission denied, please try again.
root@192.168.0.4’s password:
Connection closed by 192.168.0.4
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7]
[/quote]
???
Quelques indication sup, concernant 02
Quelques lignes commentés ???
[quote]/etc/ssh/sshd_config de 02
.
.
.
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
#IgnoreUserKnownH0osts yes
.
.
.
Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes
.
.
.
utilisateurs autorises
AllowUsers ricardo
AllowUsers xxx
AllowUsers yyy
[/quote]
Ne conviendrait-il pas d’ajouter ‘root’ aux utilisateurs autorisés ?
A priori tu n’as pas besoin de toucher à 0.2, lui ça fonctionne déjà. C’est le serveur SSH sur 0.4 qui est mal configuré.
[quote=“syam”]Toujours sur 0.4, dans /etc/ssh/sshd_config pour pouvoir te connecter en root avec un mot de passe (on verra après si tu veux installer une clé) :
- PermitRootLogin yes
- PasswordAuthentication yes
- vérifier également que tu n’as pas de AllowUsers / AllowGroups / DenyUsers / DenyGroups (ou sinon il faut mettre root explicitement dans AllowUsers et l’enlever de DenyUsers s’il y est)[/quote]
Et, je répète, essaye de tester d’abord avec ssh root@192.168.0.4 plutôt que rsync, c’est plus facile à diagnostiquer (en tous cas pour moi… il suffit de rajouter l’option -v à SSH pour avoir des indications de débogage).
Il y avait en effet ‘ricardo’ comme allow users
Aucun deny
J’ai donc rajouté ‘root’
pour le reste, c’était déjà fait.
Le résultat semble sympa, non ?
Après une demande d’acceptation de la clef RSA :
[code]04:~ $ root@192.168.0.4’s password:
Linux sid-sda8 3.2.0-2-amd64 #1 SMP Sat May 12 23:08:28 UTC 2012 x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon May 21 15:02:08 2012[/code]
EDIT :
Et je me retrouve logué en tant que ‘root’ 
EDIT2 :
Ça mouline 
Y’a pu K mettre tout ça au propre sur une fiche et à bien mettre au chaud le N° du présent fil.
Merci encore et à la prochaine
Petite remarque tout de même… Maintenant que ça fonctionne par mot de passe, tu voudras peut-être mettre en place une authentification par clé puis désactiver la connexion par mot de passe (c’est quand même vachement plus sécurisant). Mais bon ça je pense que tu sais déjà faire.
J’utilise ça déjà mais je ne crois pas que ce soit à quoi tu penses :
http://www.debian-fr.org/utilisation-de-clefs-et-raccourcis-dans-ssh-t5472.html
J’ai aussi des clefs de reconnaissance, longues d’un wagon de caractères, dans ~/.ssh/known_hosts
Mais je suis preneur de sécu supplémentaire car tu m’as filé le virus de la paranoïa 
Explique !
[quote=“ricardo”]J’utilise ça déjà mais je ne crois pas que ce soit à quoi tu penses :
http://www.debian-fr.org/utilisation-de-clefs-et-raccourcis-dans-ssh-t5472.html[/quote]
Si si c’est bien de ça que je parlais.
Là root@0.2 n’a pas de clé privée dans son /root/.ssh/ (fichiers iddsa / iddsa.pub ou bien idrsa / idrsa.pub), et root@0.4 n’a pas de clé publique dans son /root/.ssh/authorized_keys donc ça te force à te connecter par mot de passe (d’où le fait qu’il t’a probablement fallu mettre PasswordAuthentication yes dans /etc/ssh/sshd_config sur 0.4 alors qu’il devrait être à no pour forcer les connexions par clé et interdire les connexions par mot de passe simple).
Enfin si tes SSH ne sont accessibles que sur ton LAN et pas depuis internet, ça a probablement moins d’importance.
En effet, seulement les clefs à rallonge dont je parle plus haut mais rien d’autre dans 02 /root/.ssh/ et idem pour 04
Que dois-je donc faire, mettre “PasswordAuthentication” à no sur les deux machines ?
générer des clefs ?
Explique !