Scp @localhost

[kmchen]

Bonjour,

Ces 2 commandes fonctionnent:

scp /tmp/test kmc@127.0.0.1:/tmp/test_copied
scp -v root@unServerRemote:/tmp/test kmc@127.0.0.1:/tmp/

Mais pas celle là:

kmc@kmcs:~$ scp -v root@unServerRemote:/tmp/test kmc@127.0.0.1:/tmp/
Executing: /usr/bin/ssh ‘-x’ ‘-oClearAllForwardings=yes’ ‘-n’ ‘-v’ ‘-l’ ‘root’ ‘–’ ‘unServerRemote’ ‘scp -v’ ‘/tmp/test’ 'kmc@127.0.0.1:/tmp/'
OpenSSH_7.4p1 Debian-10+deb9u2, OpenSSL 1.0.2l 25 May 2017
debug1: Reading configuration data /home/kmc/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to unServerRemote [adr.ip.remote.server] port 22.
debug1: Connection established.
debug1: identity file /home/kmc/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/kmc/.ssh/id_rsa-cert type -1
debug1: identity file /home/kmc/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /home/kmc/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/kmc/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/kmc/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/kmc/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/kmc/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1
debug1: match: OpenSSH_6.7p1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to unServerRemote:22 as 'root’
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:w3eG1yb0N0uvsRgc/0rUxEL36LdS8BptvDy7UOqL3UI
debug1: Host ‘unServerRemote’ is known and matches the ECDSA host key.
debug1: Found key in /home/kmc/.ssh/known_hosts:2
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/kmc/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Offering DSA public key: /home/kmc/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 434
debug1: Authentication succeeded (publickey).
Authenticated to unServerRemote ([adr.ip.remote.server]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8
debug1: Sending command: scp -v /tmp/test kmc@127.0.0.1:/tmp/
Executing: program /usr/bin/ssh host 127.0.0.1, user kmc, command scp -v -t /tmp/
OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1
debug1: match: OpenSSH_6.7p1 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr umac-64-etm@openssh.com none
debug1: kex: client->server aes128-ctr umac-64-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 6a:16:c7:6d:78:0a:ef:54:b5:b7:db:1b:52:f4:25:99
debug1: read_passphrase: can’t open /dev/tty: No such device or address
Host key verification failed.
lost connection
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 3264, received 4736 bytes, in 0.2 seconds
Bytes per second: sent 15815.2, received 22947.5
debug1: Exit status 1

Je ne comprends pas (entre autre) pourquoi il va chercher l’identity file sur /root/.ssh
alors que je mentionne kmc comme utilisateur. Il n’est pas possible d’utilisateurs différents dans un scp ?

[Mimoza]

Host key verification failed.

Un soucis de clée.
Tu t’es déjà connecté sur le serveur distant avec cette machine ? (apparemment oui)
Tu lance les commandes avec quel utilisateur ?

[littlejohn75]

kmc@kmcs:~$ scp -v root@unServerRemote:/tmp/test kmc@127.0.0.1:/tmp/

Host key verification failed.

Qu’est-ce qui n’est pas clair dans ce message ?
Donner nous le retour complet de

id; echo $SSH_AUTH_SOCK
ssh -v  root@unServerRemote id

en n(oubliant pas les demandes de mot de passe ou de phrase de passe.

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

F. Petitjean
Ingénieur civil du Génie Maritime.

« L’arbre tombe toujours du côté où il penche. »
Proverbe français

« Il semble que la perfection soit atteinte, non quand il n’y a
plus rien à ajouter mais quand il n’y a plus rien à retrancher »
Saint-Exupéry -Terre des hommes , chapitre III , L’avion.

[kmchen]

Oui je me connecte régulièrement sur le serveur distant et comme je l’ai dit dans mon premier post

scp -v root@unServerRemote:/tmp/test kmc@127.0.0.1:/tmp/

fonctionne

et comme vous pouvez le voir dans cette ligne:

kmc@kmcs:~$ scp -v root@unServerRemote:/tmp/test kmc@127.0.0.1:/tmp/

j’execute en tant que kmc@kmcs

[kmchen]

Voici:

kmc@kmcs:~$ echo $SSH_AUTH_SOCK
/tmp/ssh-jzkvKTLbT1b1/agent.4361

kmc@kmcs:~$ ssh -v root@unServeurRemote.com
OpenSSH_7.4p1 Debian-10+deb9u2, OpenSSL 1.0.2l 25 May 2017
debug1: Reading configuration data /home/kmc/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to unServeurRemote.com [adr.ip.server.remote] port 22.
debug1: Connection established.
debug1: identity file /home/kmc/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/kmc/.ssh/id_rsa-cert type -1
debug1: identity file /home/kmc/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /home/kmc/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/kmc/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/kmc/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/kmc/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/kmc/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1
debug1: match: OpenSSH_6.7p1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to unServeurRemote.com:22 as 'root’
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:w3eG1yb0N0uvsRgc/0rUxEL36LdS8BptvDy7UOqL3UI
debug1: Host ‘unServeurRemote.com’ is known and matches the ECDSA host key.
debug1: Found key in /home/kmc/.ssh/known_hosts:2
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/kmc/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Offering DSA public key: /home/kmc/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 434
debug1: Authentication succeeded (publickey).
Authenticated to unServeurRemote.com ([adr.ip.server.remote]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8

serverRemote ~ >

Et là je suis sur le server.

Mais pour moi la connexion avec le serveur remote n’est pas en cause. Si vous observez attentivement le premier post que j’ai donné:

kmc@kmcs:~$ scp -v root@unServerRemote:/tmp/test kmc@127.0.0.1:/tmp/
Executing: /usr/bin/ssh ‘-x’ ‘-oClearAllForwardings=yes’ ‘-n’ ‘-v’ ‘-l’ ‘root’ ‘–’ ‘unServerRemote’ ‘scp -v’ ‘/tmp/test’ 'kmc@127.0.0.1:/tmp/'
OpenSSH_7.4p1 Debian-10+deb9u2, OpenSSL 1.0.2l 25 May 2017
debug1: Reading configuration data /home/kmc/.ssh/config
…
Authenticated to unServerRemote ([adr.ip.remote.server]:22).

Le remote server accepte l’authentification. C’est après que ça coince

Authenticated to unServerRemote ([adr.ip.remote.server]:22).
…
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1

là SSH va chercher une clé sur /root alors que j’execute en tant que kmc et demande l’accès à 127.0.0.1 en tant que kmc, simple utilisateur, et bien sûr il ne trouve pas la clé vu que kmc n’a pas accès à root

[littlejohn75]

serverRemote ~ >

Et là je suis sur le server.

Je vous vais demandé de lancer

ssh -v root@unServeurRemote.com  id

C’est-à-dire de lancer la commande id sur le serveur

debug1: Connecting to unServeurRemote.com [adr.ip.server.remote] port 22.

Pourquoi vous vous amusez à éditer les commandes et les sorties ?

Le remote server accepte l’authentification. C’est après que ça coince

D’accord, on pourrait supprimer l’option -v.
Mais ce qui coince c’est votre compréhension du problème.

là SSH va chercher une clé sur /root alors que j’execute en tant que kmc

Sur la machine locale seulement, sur le serveur distant vous êtes root

debug1: Authenticating to unServeurRemote.com:22 as ‘root’

Devoir s’authentifier comme root sur un système distant pour simplement lire un fichier /tmp/test ne me paraît pas très utile ou pertinent (pour une copie de /tmp/test )
Par contre, des commandes comme

ssh root@distant ls -l .ssh
cd /tmp
scp root@distant:.ssh/id_rsa.pub .
ls -l id_*

vous permettront de comprendre que scp n’est pas une commande privilégiée et donc cela ne peut pas remplacer chown.

fp2@debpacha:/tmp$ l authorized_keys 
4 -rw-r--r-- 1 fp2 fp2 246 janv. 31 01:33 authorized_keys
fp2@debpacha:/tmp$ sudo pwd
/tmp
fp2@debpacha:/tmp$ sudo chown root:root authorized_keys 
fp2@debpacha:/tmp$ sudo SSH_AUTH_SOCK=$SSH_AUTH_SOCK cp -p authorized_keys /root/.ssh
fp2@debpacha:/tmp$ sudo SSH_AUTH_SOCK=$SSH_AUTH_SOCK ssh localhost id
The authenticity of host 'localhost (::1)' can't be established.
ECDSA key fingerprint is SHA256:UN6vSlmphWYOvtU3Gr+JDiPro6FNTofHzG4Z7dB45rM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
uid=0(root) gid=0(root) groupes=0(root)
fp2@debpacha:/tmp$ sudo SSH_AUTH_SOCK=$SSH_AUTH_SOCK ssh root@localhost ls -l .ssh
total 8
-rw-r--r-- 1 root root 246 janv. 31 01:33 authorized_keys
-rw-r--r-- 1 root root 664 janv. 31 01:36 known_hosts
fp2@debpacha:/tmp$ ssh root@localhost ls -l .sshtotal 8
-rw-r--r-- 1 root root 246 janv. 31 01:33 authorized_keys
-rw-r--r-- 1 root root 664 janv. 31 01:36 known_hosts
fp2@debpacha:/tmp$ 

fp2@debpacha:/tmp$ scp root@localhost:.ssh/authorized_keys id_rsa.pub
authorized_keys                                100%  246   493.7KB/s   00:00    
fp2@debpacha:/tmp$ l id*
4 -rw-r--r-- 1 fp2 fp2 246 janv. 31 01:44 id_rsa.pub
fp2@debpacha:/tmp$ 

Voir aussi ma réponse à Michel

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

F. Petitjean
Ingénieur civil du Génie Maritime.

« On ne perd pas son temps en aiguisant ses outils. »
Proverbe français

[sk4hrr]

Bonjour,

Je vais pas tellement aidé à résoudre le problème, mais proposer une autre solution :

su - kmc -c "scp -v root@unServerRemote:/tmp/test /tmp/"

Je ne comprends pas (entre autre) pourquoi il va chercher l’identity file sur /root/.ssh

Sans doute parce que c’est l’utilisateur root qui lance la commande scp… Je sais pas si ça va être bien clair, mais scp ne permet pas d’utiliser l’environnement d’un utilisateur, mais simplement ces droits (d’accès SSH et sur les fichiers).

[kmchen]

Merci les gars d’essayer de déboucher le bouché que je suis. C’est vrai que je coince…

sk4hrr:
pour des raisons de simplification d’écriture d’un script je cherche à réaliser la commande équivalent à ce que vous proposez:

su - kmc -c "scp -v root@unServerRemote:/tmp/test kmc@localhost:/tmp/"
Mot de passe :
^C^Csu: Échec d’authentification

littlejohn75:
le man scp donne:
scp [[user@]host1:]file1 … [[user@]host2:]file2

Est-ce à dire que user doit être le même pour tous les hosts et que ma commande
scp root@distant kmc@localhost
s’entend
scp root@distant root@localhost
?

Pourquoi vous vous amusez à éditer les commandes et les sorties ?

Comprends pas la question

[sk4hrr]

Est-ce à dire que user doit être le même pour tous les hosts et que ma commande
scp root@distant kmc@localhost
s’entend
scp root@distant root@localhost
?

Je savais que j’étais pas clair :

1. scp : exécuté par root, c’est à dire que la connexion est initialisée par root, avec son environnement (ces fichiers de conf !)
2. kmc@localhost : les fichiers que tu copie auront les droits kmc

Je viens de voir l’option -F de scp, je sais pas si ça peut faire l’affaire, mais la description semble correspondre.

[kmchen]

comprends toujours pas. Je suis loggué sous tartampion. Lorsque je fais un

scp root@host1 kmc@host2

la commande n’est pas executée :
en tant que root sur host1, clé SSH cherchée sur localhost://root/.ssh comparée dans host1:/root/.ssh/authorized_keys
en tant que kmc sur host2, clé SSH cherchée sur localhost://home/kmc/.ssh comparée dans host2:/home/kmc/.ssh/authorized_keys?

l’option -F me parait un peu surdimensionnée pour ce que je veux faire.

Relisant le manuel l’option -i donne à penser qu’il ne peut y avoir qu’un seul et même utilisateur sur les 2 hosts. J’essaie donc de copier la localhost:/root/.ssh/id_rsa.pub dans le /root/.ssh/authorized_keys des 2 serveurs et:

kmc@kmcs:/tmp$ sudo scp -v -i /root/.ssh/id_rsa root@distant:/tmp/clonebdd.sql root@127.0.0.1:/tmp/
…
debug1: Offering RSA public key: /root/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to distant ([1.2.3.4]:22).
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
…
debug1: Enabling compatibility mode for protocol 2.0
…
debug1: read_passphrase: can’t open /dev/tty: No such device or address
Host key verification failed.
lost connection
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 2828, received 4472 bytes, in 0.2 seconds
Bytes per second: sent 13822.6, received 21858.1
debug1: Exit status 1

Je crois que je ferais pas carrière dans la piraterie…

[sk4hrr]

scp root@host1 kmc@host2

kmc@kmcs:/tmp$ sudo scp -v -i /root/.ssh/id_rsa root@distant:/tmp/clonebdd.sql

Euh… C’est quelle commande que tu veux faire fonctionner au final ?

[MicP]

sudo scp -v -i /root/.ssh/id_rsa

Si le but est de transférer une clef RSA vers une autre machine
il vaudrait mieux utiliser la commande

ssh-copy-id

---

Mais le mieux serait bien sûr de bien décrire le but que tu cherche à obtenir
car il y a confusion dès la lecture des premières lignes du premier message :

Ces 2 commandes fonctionnent:

scp /tmp/test kmc@127.0.0.1:/tmp/test_copied
scp -v root@unServerRemote:/tmp/test  kmc@127.0.0.1:/tmp/

Mais pas celle là:

kmc@kmcs:~$ scp -v root@unServerRemote:/tmp/test  kmc@127.0.0.1:/tmp/
…

---

Dommage que tu n’aies pas répondu aux demandes de littlejohn75

[kmchen]

Désolé si j’ai pas été clair. Mon but est de copier un fichier depuis un serveur distant sur une machine locale MAIS en utilisant unUser@localhost sur la cible :

scp user1@distant:/unFichier user2@localhost:/tmp/

je précise que mon /tmp/ est en chmod 777.

Première question peut-on utiliser un user différent sur la source et la cible d’un scp ?
pensant que la réponse est non je pourrais me contenter d’un:

scp root@distant:/unFichier root@localhost:/tmp/

mais mon dernier essai dans ce sens aboutit à un “Host key verification failed” sur le localhost.

Concernant les demandes de littleJohn, désolé je n’avais pas vu cette demande que voici:

kmc@kmcs:~$ ssh -v root@unServeurRemote id
OpenSSH_7.4p1 Debian-10+deb9u2, OpenSSL 1.0.2l 25 May 2017
debug1: Reading configuration data /home/kmc/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to unServeurRemote [1.2.3.4] port 22.
debug1: Connection established.
debug1: identity file /home/kmc/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/kmc/.ssh/id_rsa-cert type -1
debug1: identity file /home/kmc/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /home/kmc/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/kmc/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/kmc/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/kmc/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/kmc/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1
debug1: match: OpenSSH_6.7p1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to unServeurRemote:22 as 'root’
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:w3eG1yb0N0uvsRgc/0rUxEL36LdS8BptvDy7UOqL3UI
debug1: Host ‘unServeurRemote’ is known and matches the ECDSA host key.
debug1: Found key in /home/kmc/.ssh/known_hosts:2
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/kmc/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Offering DSA public key: /home/kmc/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 434
debug1: Authentication succeeded (publickey).
Authenticated to unServeurRemote ([1.2.3.4]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8
debug1: Sending command: id
uid=0(root) gid=0(root) groupes=0(root)
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 3212, received 2036 bytes, in 0.2 seconds
Bytes per second: sent 13629.5, received 8639.3
debug1: Exit status 0

[littlejohn75]

Pourquoi vous vous amusez à éditer les commandes et les sorties ?

Comprends pas la question

Parce que dans un message précedent nous lisons

debug1: Authentication succeeded (publickey).
Authenticated to unServeurRemote.com ([adr.ip.server.remote]:22).

Et que si je fais

fp2@debpacha:/tmp$ getent hosts  unServeurRemote.com
fp2@debpacha:/tmp$ host  unServeurRemote.com 
Host unServeurRemote.com not found: 3(NXDOMAIN)
fp2@debpacha:/tmp$ 

j’ai du mal à croire que vous vous êtes donné du mal au point que le site distant s’appelle unServeurRemote.com. N’oublions pas que pour l’authentification par ssh ou scp il y a par défaut des vérifications des noms des systèmes distants ( résolution DNS) + des clés associées aux systèmes ( fichier known_hosts dans le compte client et fichiers /etc/ssh/ssh_host_*pub sur le système distant ).

Pour en revenir à votre problème initial : [quote=“kmchen, post:8, topic:75786”]
Est-ce à dire que user doit être le même pour tous les hosts et que ma commande
scp root@distant kmc@localhost
s’entend
scp root@distant root@localhost
?
[/quote]
on va tenter de décortiquer. Au lieu de se focaliser sur la commande scp qui regroupe des fonctionnalités différentes (connexion authentification à un site distant, copie et donc autorisation d’écriture) on va revenir aux fondamentaux (comme on dit dans le monde de l’ovalie) et donc on s’intéresse à ssh .
J’attends toujours les retours de

id; hostname --fqdn
ssh root@unServeurRemote.com id
ssh root@unServeurRemote.com hostname --fqdn
ssh root@unServeurRemote.com pwd
ssh root@unServeurRemote.com ls -lApst .ssh

Libre à vous de remplacer root par un autre compte et aussi unServeurRemote.com par localhost

Si vous relisez mon message précédent (peu explicite il est vrai), vous pouvez voir que placer un fichier authorized_keys à un endroit aussi stratégique que /root/.ssh revient à pouvoir lancer des commandes privilégiées sans passer par sudo (non recommandé)

fp2@debpacha:~$ ssh root@localhost id
uid=0(root) gid=0(root) groupes=0(root)
fp2@debpacha:~$ ssh root@localhost which ifconfig
/sbin/ifconfig
fp2@debpacha:~$ which ifconfig
fp2@debpacha:~$ ssh root@localhost pwd
/root
fp2@debpacha:~$ 

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

F. Petitjean
Ingénieur civil du Génie Maritime.

« Celui qui, parti de rien, n’est arrivé nulle part n’a de merci à dire à personne !! »
Pierre Dac
Avoid the Gates of Hell. Use Linux
(Unknown source)

[kmchen]

Meri LittleJohn pour votre patience.

Je remplace systématiquement les noms et IP du serveur distant afin d’éviter de divulguer des infos qui pourraient aider à son piratage. Je ne comprends pas pourquoi ça vous surprend.

Voici les commandes que vous attendez :

kmc@kmcs:~$ ssh root@localhost id
root@localhost’s password:
Permission denied, please try again.
…
kmc@kmcs:~$ ssh root@localhost which ifconfig
root@localhost’s password:
Permission denied, please try again.
…
kmc@kmcs:~$ which ifconfig
kmc@kmcs:~$ ssh root@localhost pwd
root@localhost’s password:
…

En résumé on me demande le password root sur toutes les commandes SSH et en plus je suis rejeté même si je le donne.

Personne n’a répondu à ma question de savoir si on peut avoir un user différent pour la source et la cible d’un scp.

[littlejohn75]

kmc@kmcs:~$ ssh -v root@unServeurRemote id

debug1: Host ‘unServeurRemote’ is known and matches the ECDSA host key.
debug1: Found key in /home/kmc/.ssh/known_hosts:2

debug1: Authentications that can continue: publickey,password
debug1: Offering DSA public key: /home/kmc/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 434
debug1: Authentication succeeded (publickey).

debug1: Sending command: id
uid=0(root) gid=0(root) groupes=0(root)

Si je comprends bien, vous avez configuré le serveur distant de telle sorte que vous pouvez lancer des commandes privilégiées sur ce serveur depuis votre compte kmc@kmcs: sans même entrer de mot de passe, en utilisant la clé publique correspondant à /home/kmc/.ssh/id_dsa.
Ceci est possible car vraisemblablement sur le serveur distant un fichier /root/.ssh/authorized_keyscontient une ligne avec la clé publique id_ds.pub.

kmc@kmcs:~$ ssh root@localhost id
root@localhost’s password:
Permission denied, please try again.
…

La machine kmcs n’est donc pas configurée de cette manière, et cela peut se comprendre. D’autre part, si cela ne fonctionne pas avec une commande aussi simple que id cela ne fonctionnera avec aucune autre commande.

Désolé si j’ai pas été clair. Mon but est de copier un fichier depuis un serveur distant sur une machine locale MAIS en utilisant unUser@localhost sur la cible :

scp user1@distant:/unFichier user2@localhost:/tmp/

Vous ne pouvez pas réaliser cela en une commande scp.
Procédez en deux temps

cd /tmp
scp root@distant:/root/.ssh/authorized_keys .
ls -l authorized_keys
#  le propriétaire est le compte `kmc` qui a lancé la copie
sudo chown user2:user2 authorized_keys
# le propriétaire est un autre utilisateur (que le créateur initial par copie)

La commande chown est réservée à root.
Si vraiment vous vouliez faire en une seule ligne de commandes ce serait avec ( pour user2= root seulement )

sudo SSH_AUTH_SOCK=$SSH_AUTH_SOCK distant:/root/.ssh/authorized_keys  /path/to/dest

D’ailleurs en indiquant /root/.ssh comme répertoire de destination, vous devriez pouvoir débloquer la commande

ssh root@localhost  id

Je ne recommande pas cette manière de procéder car elle complique l’exploitation des journaux.

sudo fgrep sudo /var/log/auth.log

Vous remarquerez que pour la combinaison sudo + scp je n’ai pas précisé root@distant:... car c’est implicite

fp2@debpacha:~$ sudo SSH_AUTH_SOCK=$SSH_AUTH_SOCK id
uid=0(root) gid=0(root) groupes=0(root)
fp2@debpacha:~$ 

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

F. Petitjean
Ingénieur civil du Génie Maritime.

« Un ordinateur c’est comme un frigo : on le branche et ça marche. »
Laurent Serano Directeur informatique, réunion Délégués du Personnel 2010

[sk4hrr]

Personne n’a répondu à ma question de savoir si on peut avoir un user différent pour la source et la cible d’un scp.

La commande le permet, donc oui, mais :

on va tenter de décortiquer. Au lieu de se focaliser sur la commande scp qui regroupe des fonctionnalités différentes (connexion authentification à un site distant, copie et donc autorisation d’écriture) on va revenir aux fondamentaux (comme on dit dans le monde de l’ovalie) et donc on s’intéresse à ssh .

En gros il faut bien comprendre les différents aspects de scp avant de l’utiliser !

[kmchen]

scp root@distant:/root/.ssh/authorized_keys .

Merci beaucoup LittleJohn mais vous n’avez pas compris ma question. Transposée dans votre commande ce serait (prendre authorized_key comme fichier prête à confusion car on croit que vous faites une manip SSH):

scp root@distant:/root/.ssh/authorized_keys kmc@localhost:/tmp/

Désolé, je m’aperçois que je me suis trompé dans mon premier post, ce qui a foutu la pagaille: [quote=“kmchen, post:1, topic:75786”]
Ces 2 commandes fonctionnent:

scp /tmp/test kmc@127.0.0.1:/tmp/test_copied
scp -v root@unServerRemote:/tmp/test kmc@127.0.0.1:/tmp/
[/quote]

Non c’est:

Ces 2 commandes fonctionnent:

scp /tmp/test kmc@127.0.0.1:/tmp/test_copied
scp -v root@unServerRemote:/tmp/test /tmp/

J’aurais du d’ailleurs préciser que je lance ces commandes en tant que kmc sur localhost et que kmc a accès à /tmp/ en écriture et lecture.
Mais pour des raisons d’écriture de script je voudrais faire passer la deuxième commande scp avec un user2@localhost2 ainsi:

scp -v root@unServerRemote:/tmp/test kmc@localhost:/tmp/

et je suis surpris de ne pas trouver de solution à un problème qui me parait pourtant simple et légitime

[grandtoubab]

Salut
C’est vrai que SCP c’est pas la mer à boire
https://www.it-connect.fr/chapitres/transfert-de-fichier-via-ssh/

[littlejohn75]

Merci beaucoup LittleJohn mais vous n’avez pas compris ma question.

Combien de fois faudra-t-il vous demander de lire les suggestions et d’essayer de les comprendre.
Est-ce que ma supposition au sujet de distant:/root/.ssh/authorized_keys est correcte ? Dans l’affirmative, avez-vous lancé les commandes qui copient authorized_keys de root (système distant) sur localhost:/tmp ?
Est-ce que vous comprenez qu’un simple utilisateur peut s’il a les droits de lecture d’un fichier qui ne lui appartient pas peut par une copie s’approprier le contenu du fichier (éventuellement appartenant à un autre compte sur un site distant) par copie dans un répertoire dans lequel il a les droits d’écriture (en conservant le nom d’origine ou en choisissant un autre nom du genre Copie de MachinTruc pour faire comme windows ) ?

Personne n’a répondu à ma question de savoir si on peut avoir un user différent pour la source et la cible d’un scp.

La commande le permet, donc oui, mais :

Eh bien non ! non et non.
Va falloir apprendre à comprendre le synopsis des commandes.
Ce n’est pas parce-que ans le cas de scp le rédacteur n’a pas pris la peine de détailler

# copie d'un fichier sur un système distant 
scp [options] [ remote_user@]remote.tld:/path/to/file /path/to/dest
# copie vers un système distant
scp [options] /pat/to/file [remote_user@]remote:path/to/dest

et à tout mis dans une seule ligne d’apparence trompeuse que ce n’est pas ce qui se passe.

Transposée dans votre commande ce serait (prendre authorized_key comme fichier prête à confusion car on croit que vous faites une manip SSH):

Je vous donne un truc

fp2@debpacha:~$ dpkg-query --search /usr/bin/scp
openssh-client: /usr/bin/scp
fp2@debpacha:~$ dpkg-query --search /usr/bin/ssh
openssh-client: /usr/bin/ssh
fp2@debpacha:~$ debmany openssh-client
fp2@debpacha:~$ 

C’est le même paquet source qui fournit les deux commandes. C’est bien la peine de faire de la pédagogie (pour avoir debmany installez debian-goodies )

Désolé, je m’aperçois que je me suis trompé dans mon premier post, ce qui a foutu la pagaille:

Une pagaille sans nom qui dure trois jours

J’aurais du d’ailleurs préciser que je lance ces commandes en tant que kmc sur localhost et que kmc a accès à /tmp/ en écriture et lecture.

Ce qui est d’une banalité rare et vous ne faites que constater que la commande scp n’a que faire de ce genre de précisions triviales ( mettre user@localhost:/tmp au lieu d’un simple /tmp ) et techniquement cela va même jusqu’à une erreur (au plus une connexion ssh sous-jacente pour une commande scp). Cette erreur est une bonne chose.

je suis surpris de ne pas trouver de solution à un problème qui me parait pourtant simple et légitime

Pas si légitime que cela. Vous pouvez faire un rapport de bogue de sévérité whishlist avec si possible une rustine sur la page de manuel scp(1) contenant un synopsys plus explicite.

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

F. Petitjean
Ingénieur civil du Génie Maritime.

Linux: the operating system with a CLUE… Command Line User Environment.
– seen in a posting in comp.software.testing
« Windows est un système d’exploitation de l’homme par l’ordinateur. Linux, c’est le contraire. »