Comportement bizar de SCP

Support Debian
#1

Bonsoir a tous,

Je souhaite utiliser SCP pour recopier des fichiers entre 2 de mes machines. Pour cela, j’utilise la commande suivante :
scp -v -v -v -P XXX toto.toto yy@x.x.x.x:/home/toto (-v -v -v pour le debugage :wink: )

Et j’obtiens le resultat suivant :

debug1: Trying private key: /root/.ssh/identity debug3: no such identity: /root/.ssh/identity debug1: Trying private key: /root/.ssh/id_rsa debug3: no such identity: /root/.ssh/id_rsa debug1: Offering public key: /root/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-dss blen 434 debug2: input_userauth_pk_ok: fp ac:0d:c1:56:4b:c9:4e:bc:4c:1f:ed:16:45:0e:1b:38 debug3: sign_and_send_pubkey debug1: read PEM private key done: type DSA debug1: Authentication succeeded (publickey). debug2: fd 4 setting O_NONBLOCK debug2: fd 5 setting O_NONBLOCK debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug2: callback start debug2: client_session2_setup: id 0 debug1: Sending environment. debug3: Ignored env TERM debug3: Ignored env SHELL debug3: Ignored env SSH_CLIENT debug3: Ignored env SSH_TTY debug3: Ignored env USER debug3: Ignored env MAIL debug3: Ignored env PATH debug3: Ignored env PWD debug1: Sending env LANG = fr_FR.UTF-8 debug2: channel 0: request env confirm 0 debug3: Ignored env PS1 debug3: Ignored env JDK_HOME debug3: Ignored env SHLVL debug3: Ignored env HOME debug3: Ignored env LOGNAME debug3: Ignored env SSH_CONNECTION debug3: Ignored env _ debug1: Sending command: scp -v -t /home/bsm/toto debug2: channel 0: request exec confirm 1 debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_confirm: type 99 id 0 debug2: exec request accepted on channel 0

Et la commande bloque sur la derniere ligne. Malgrè qq. recherches sur le net, je ne trouve pas d’explications, d’autant plus que la connexion ssh fonctionne, elle, parfaitement.

Merci de votre aide

PS :
[]la machine tourne sous Debian 5
[]J’ai déjà tenté la desinstallation et la reinstallation de openssh-server et openssh-client
[*]Je ne sais pas si ca peut aider, mais la connexion en sftp avec filezilla bloque après l’authentification.

#2

ssh a un mécanisme qui recoupe le numéro IP avec
l’adresse mac du périphérique.
Le numéro IP ou la carte ayant changé (macchanger, IP dynamique …)
l’authentification échoue.

Réinstaller openssh ne sert à rien si le contenu de ~/.ssh est resté inchangé.

Pour réinitialiser un hôte précis
$ ssh-keygen -R hostname

Autre éventualité : mot de passe “hashage” incorrect.

Le comportement est il le même en ne spécifiant pas de mot de passe en commande ?

$ ssh toto@machine
puis renseigner le mot de passe

Alternatives à scp

mc + ssh

$ mc /#sh:toto@machine
(ou $ mc + menu F9 shell link)
le mot de passe sera demandé

à gauche le système local, à droite le distant
touche F5 pour copier depuis le réseau

konqueror/dolphin/nautilus + sftp est confortable
sftp en ligne de commande est anti-ergonomique,
pas de complétion par TAB, pas de joker *?

$ sftp toto@machine
mot de passe
< lls (ls local)
< ls (ls distant)
< pwd (pwd distant )
< lpwd (pwd local)
< get fichier ( get = obtenir, rapatrier )
< put fichier ( put = déposer)

#3

Merci de ta réponse. Par contre, j’ai essayé de reinitialiser les cles (comme tu me l’as indiqué), mais rien n’y fait. De plus, le SFTP suit le même comportement. Je commence vraiment à tourner en rond… :open_mouth:

Merci de votre aide

#4

[quote=“etxeberrizahar”]ssh a un mécanisme qui recoupe le numéro IP avec
l’adresse mac du périphérique.[/quote]
Ça sort d’où, ça ? Jamais entendu parler. L’adresse MAC de quel périphérique ?

[quote=“etxeberrizahar”]Le numéro IP ou la carte ayant changé (macchanger, IP dynamique …)
l’authentification échoue.[/quote]
D’après les logs l’authentification semble avoir réussi. Et ssh fonctionne.
Pour sftp, à quel moment ça bloque ?

#5

En fait le problème est résolu. Le problème semblait provenir du fait que lors de la connexion, le serveru ssh n’arrivait aps à réaliser un fork pour la connexion entrante. Cela venait du fait qu’un utilisateur indélicat avait modifié le fichier .bashrc de root de manière à créer un nouveau bash à chaque connexion de root.

Merci de votre aide et à bientôt

#6

J’ai parlé trop vite PascalHambourg

Mea grandem culpa

Contrairement à ce que j’ai avancé cavalièrement,
ssh n’a pas directement à voir avec l’adresse MAC.
J’ai confondu le “RSA key fingerprint” et l’adresse MAC.

scénario improbable que j’avais en tête

Un routeur qui se base sur l’adresse MAC
un macchanger en cours de route … et c’est le drame.