Bonjour à tous,
Je viens vous voir car, je n’arrive pas à copier de fichier où autres à distances, il me met ceci :
ssh: connect to host 192.168.1… port 22: Connection refused
Je n’ai pourtant pas touché aux règles de parfeu et j’ai bien installer ssh server et client sur les machines … ( chose que j’ai vérifié en voyant un post simillaire ici lien
Le code d’erreur indique une connection refusé et non pas un ‘timeout’, le problème est donc que la connexion est refusé soit par une règle iptable soit par un problème d’accésibilité,.
Je pencherai pour la deuxième solution vue que tu utilise une IP privée pourrais-tu à minima nous en dire plus sur la topologie du réseau ?
Les machines sont-elles sur le même ‘network’ ?
Avec quel commande essaye tu de copier ? «scp» ?
Arrive tu a te connecter «normalement», CAD pas de copie mais une connexion shell toute bête.
@Clochette Oui les machines sont sur le même réseau, et le probléme n’a pas toujours était présent,ça fonctionner très bien “avant” et sans crier gare ce probléme est apparu …
Je n’ai pourtant pas modifié où définie de règles quelconque concernant ce port où même les autres … Petite précision qui peut potentiellement avoir son importance, j’ai également un soucis d’attribution d’IP ( voir ici ) je ne pense pas que ça soit liée mais sait t-on jamais …
@Mimoza Oui j’utilise la commande «scp» et oui, bizarrement la connexion shell fonctionne à merveille, le probléme apparaît ( à priori ) qu’avec «scp»
Soit problème de port, soit problème de clef, si tu utilises.
Donne-nous la ligne exacte et complète de ta commande, en cachant, éventuellement par des XXX .
Là je part du principe que le pc nommé “patrick” est le pc distant et que “corbo” le pc physique
" corbo@debian:~$ ssh patrick 192.XXX.X.XX "
patrick@debian:~$ ( Jusqu’ici donc rien d’anormal j’ai accès à patrick )
patrick@debian:~/Documents$ scp codes corbo@192.XXX.X.X:/home/corbo/Bureau ( et là quand je veux copier le fichier “codes” par exemple où n’importe quoi d’autres de patrick à chez corbo là ça coince )
ssh: connect to host 192.XXX.X.XX port 22: Connection refused
lost connection
Et non je n’utilise pas de clé
Ton port SSH est bien le port d’origine, le 22 ?
Tu ne l’as pas modifié ?
Oui je n’ai touché à «iptables» qu’une fois et le probléme était déjà présent …
Néanmoins si une commandes autres que celle de dessous peut te permettre de vérifier mes dires je veux bien l’exécuter . Je ne suis pas à l’abri d’une erreur .
"Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
corbo@debian:~$ "
Il me semble que tout est d’origine puisque la seul fois où je l’ai touché j’ai volontairement pas enregistrer les modifications …
Pour le pare-feu , tu es tranquille , il ne protège rien.
Lä, je suis sur une tablette et pas facile pour moi d’y 3crire.
Une commande ssh se fait comme suit
B
Putain de tablette
En user :
Scp /home/ricardo/fichierAtranmettre destinataire@192.168.0.55:/dossierDeDestinatio
scp -v codes corbo@192.XXX.X.X:/home/corbo/Bureau
Ajoute l’option «-v» pour le mode «verbose», verbeux. Tu auras surement plus de précision sur la raison du problème
Remarques :
Connexion depuis corbo vers patrick, si je comprends bien.
La syntaxe est bizarre. Normalement le premier argument est le nom ou l’adresse du serveur et le second, optionnel, est la commande à exécuter.
Connexion depuis patrick vers corbo, si je comprends bien. C’est donc sur corbo qu’il faut vérifier que le serveur SSH (sshd) tourne et écoute sur le port 22 et l’adresse LAN, et les règles iptables.
Pourquoi se connecter d’abord de corbo à patrick pour ensuite exécuter le scp sur celle-ci, au lieu d’exécuter le scp directement sur corbo ? Le sens de la connexion scp n’a rien à voir avec le sens de la copie, comme en FTP.
Ta commande semble être un non sens car tu es sur “corbo”, que tu décris comme physique et tu passes ta commande à partir de “Patrick” qui est le distant.
Pascal te l’a déjà dit d’ailleurs.
Autrement dit, tu veux aller chercher le fichier “codes” sur “corbo” pour le copier sur “Patrick”.
Pour tester qq chose qui pose problèmes, il est toujours préférable de faire au plus simple mais au plus complet en ce qui concerne les chemins.
Je te propose de rester sur ta machine physique, en tant qu’ “user” sans te connecter en ssh sur la distante. C’est-à-dire :
corbo@nom_de_la_machine:~$
Puis entrer la commande :
scp patrick@debian:/home/Documents/codes /home/corbo/Bureau
EDIT :
Suis le conseil de Pascal en donnant des noms causants à tes machines, qui n’aient surtout aucun rapport avec les noms d’utilisateurs.
Je donne mon exemple avec les noms suivants, chez moi :
ordibureau
portable
mini
test
msi
et j’ai oublié le “distant” qui s’appelle … serveur.
C’est noté merci bien, pour que ça soit plus compréhensible j’appellerai à partir de maintenant “corbo” MSI et “patrick” ASUS
Hum … Quand je rentre la commande il me dit accès refusé, [quote=“ricardo, post:12, topic:70172”]
scp patrick@debian
[/quote]
On est bien d’accord sur le faite que “ASUS” ( anciennement patrick ) reste la distante ? le @debian ne signifie t-il pas qu’il cherche un user en local ?? Si c’est le cas, il peut chercher longtemps étant donné qu’aucun user en local ne s’appelle “patrick” pas sur “MSI” en tout cas …
Autant pour moi, comme l’a souligné @ricardo je pense m’être compliqué moi même la tache
A mon avis tu ferais mieux de refaire l’exposé initial avec MSI et ASUS, ou bien avec les vraies adresses IP privées, en tout cas les commandes exactes que tu as tapées. Ce serait plus clair pour tout le monde.
/etc/ssh/sshd_configAllowUsers ricardoSi tu as une réponse de refus d’accès, il n’y a pas beaucoup de possibilités :
–Il t’est demandé un mot de passe
–les utilisateurs ne sont pas reconnus
–Si ton pare-feu est encore comme celui indiqué plus haut, il n’est pas en cause
Par contre, ce qui est étonnant, c’est que tu puisses obtenir une connexion SSH directe.
Tu confirmes que cette commande répond favorablement :
…:~$ ssh patrick@192.168.0.XX
et
…:~$ ssh corbo@192.168.0.YY
Non j’ai fait une recherche de mot clé une fois dans /etc/ssh/sshd-config mair aucun mot n’a était trouvé …
Par contre, je pense effectivement que MSI n’écoute pas le bon port, car tout les échanges n’incluant pas directement MSI fonctionne .
Je m’explique, je me suis connecté depuis MSI à ASUS, une fois sur ASUS par le biais du SSH j’ai demandé à ASUS de copier un fichier sur un 3 éme pc PACKARBELL et ça à fonctionner !
Mais quand je veux copier un fichier depuis MSI où vers MSI ça coince …
" Connexion to host 192.168.1.3 port 22 connexion refused "
Oui ça fonctionne de MSI vers ASUS ( patrick ) aucun probléme mais comme dit plus haut l’inverse impossible …
ça doit "juste être un probléme de port nais je ne savait même pas comment changer le port d’écoute avant de me renseigner alors je voie pas comment il aurait pu changer …
EDIT :
D’aprés le sshd–config oui j’écoute bien le port 22 je vous et fait un rapide copier/coller au cas où vous constateriez quelque chose …
" 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
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
Privilege Separation is turned on for security
UsePrivilegeSeparation yes"
Écoute, si tu veux qu’on puisse t’aider, il faut que tu répondes EXACTEMENT aux questions qu’on te pose.
Alors, on va procéder de façon plus détaillée.
Dans la description que tu vas nous faire, tant des machines, que des utilisateurs, tu vas les appeler comme suit :
‘machine1’ avec comme utilisateur 'toto’
IP de machine1 = 192.168.0.1
‘machine2’ avec comme utilisateur 'tata’
IP de machine2 = 192.168.0.2
À partir de machine1, donne le résultat de
ssh tata@192.168.0.2
Puis, à partir de machine2, donne le résultat de
ssh toto@192.168.0.1
À toi, bien sûr, de modifier avec les bons utilisateurs et les bonnes IP.
Ensuite, selon ces deux résultats, on passera à la suite.
“Connection refused” indique que le port de destination est fermé ou qu’un pare-feu le fait passer comme tel. Ce n’est pas un problème de compte utilisateur ou de mot de passe.
Est-ce que le processus sshd est present sur MSI, et si oui sur quel port et adresse écoute-t-il en vrai (pas dans le fichier de config). Commandes utiles (en root pour la seconde, sinon enlever ‘p’) :
ps -Af | grep ssh
netstat -ntlp | grep ssh
Pascal, s’il n’y a pas interdictions spécifiques plus bas, ce qui semble peut probable, puisque notre ami dit ne rien avoir configuré sur le pare-feu, ce dernier ne devrait pas être en cause;
D’autre part, il annonce son port comme étant le 22, ce qui n’est pas vraiment exotique et par quoi pourrait-il être fermé ?
Machine 1
MSI : Utillisateur = corbo : IP = 192.168.1.X
Machine 2 :
ASUS Utilisateur = patrick : IP = 192.168.1.X
Machine 3 :
Toshiba Utilisateur = agnes : IP = 192.168.1.X
Résultat des commandes SSH en tant que utilisateur :
De MSI [ 192.168.1.X ] vers ASUS [ 192.168.1.X ] : " Connexion SSH établie ! "
De ASUS [ 192.168.1.X ] vers MSI [ 192.168.1.X ] : " Connexion to host 192.168.1.3 port 22 connexion refused "
De ASUS [ 192.168.1.X ] vers TOSHIBA [192.168.1.X] " Connexion SSH établie ! "
De TOSHIBA [192.168.1.X ] vers ASUS [ 192.168.1.X ] " Connexion SSH établie ! "
De TOSHIBA [192.168.1.X] vers MSI [ 192.168.1.X ] " Connexion to host 192.168.1.X port 22 connexion refused "
De MSI [ 192.168.1.X ] vers TOSHIBA [192.168.1.X ] " Connexion SSH établie ! "
Voici le résultat des commandes que tu m’as demandé :
" root 684 1 0 17:21 ? 00:00:00 /usr/sbin/sshd -D
corbo 1078 1044 0 17:22 ? 00:00:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session x-session-manager
corbo 1785 1365 0 18:04 pts/0 00:00:00 grep ssh "
corbo@debian:~/$ sudo netstat -ntlp | grep ssh
tcp 0 0 0.0.0.0:2222 0.0.0.0:* LISTEN 684/sshd
tcp6 0 0 :::2222 :::* LISTEN 684/sshd
Je confirme une nouvelle fois, je n’ai pas changé de port ni configurer le pare-feu … Comme je l’ai dit précédemment j’ai touché une fois aux réglages avec livres spécifique sur le sujet à l’appuie, mais n’ai rien enregistrer de façon volontaire. De tels sorte qu’au redémarrage les règles se sont remit comme ils étaient par défaut .
Mais comme je l’ai mentionner plus haut, dans tout les cas ce probléme SSH est survenu avant que je touche au pare-feu la 1ere fois .