# Scp @localhost **URL:** \ **Category:** Support Debian\ **Created:** [Janvier 30, 2018, 11:30 UTC](https://www.debian-fr.org/t/scp-localhost/75786 "2018-01-30T11:30:20Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![kmchen](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/k/3d9bf3/32.png) [@kmchen](https://www.debian-fr.org/u/kmchen)\ **Post date:** [Janvier 30, 2018, 11:30 UTC](https://www.debian-fr.org/t/scp-localhost/75786/1 "2018-01-30T11:30:21Z")
Bonjour, Ces 2 commandes fonctionnent: > scp /tmp/test [kmc@127.0.0.1](mailto:kmc@127.0.0.1):/tmp/test\_copied > scp -v root@unServerRemote:/tmp/test [kmc@127.0.0.1](mailto:kmc@127.0.0.1):/tmp/ Mais pas celle là: > kmc@kmcs:~$ scp -v root@unServerRemote:/tmp/test [kmc@127.0.0.1](mailto: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](mailto:curve25519-sha256@libssh.org) > debug1: kex: host key algorithm: ecdsa-sha2-nistp256 > debug1: kex: server-\>client cipher: [chacha20-poly1305@openssh.com](mailto:chacha20-poly1305@openssh.com) MAC: compression: none > debug1: kex: client-\>server cipher: [chacha20-poly1305@openssh.com](mailto: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](mailto: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](mailto: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](mailto: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](mailto:umac-64-etm@openssh.com) none > debug1: kex: client-\>server aes128-ctr [umac-64-etm@openssh.com](mailto: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 ? ---
**Author:** ![Mimoza](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mimoza/32/3858_2.png) [@Mimoza](https://www.debian-fr.org/u/Mimoza)\ **Post date:** [Janvier 30, 2018, 11:39 UTC](https://www.debian-fr.org/t/scp-localhost/75786/2 "2018-01-30T11:39:11Z")
> [@](#): > > 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 ? ---
**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\ **Post date:** [Janvier 30, 2018, 11:45 UTC](https://www.debian-fr.org/t/scp-localhost/75786/3 "2018-01-30T11:45:59Z")
> [@](#): > > kmc@kmcs:~$ scp -v root@unServerRemote:/tmp/test [kmc@127.0.0.1](mailto: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 ```auto 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. ---
**Author:** ![kmchen](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/k/3d9bf3/32.png) [@kmchen](https://www.debian-fr.org/u/kmchen)\ **Post date:** [Janvier 30, 2018, 6:26 UTC](https://www.debian-fr.org/t/scp-localhost/75786/4 "2018-01-30T18:26:28Z")
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](mailto: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](mailto:kmc@127.0.0.1):/tmp/ j’execute en tant que kmc@kmcs ---
**Author:** ![kmchen](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/k/3d9bf3/32.png) [@kmchen](https://www.debian-fr.org/u/kmchen)\ **Post date:** [Janvier 30, 2018, 6:52 UTC](https://www.debian-fr.org/t/scp-localhost/75786/5 "2018-01-30T18:52:35Z")
Voici: > kmc@kmcs:~$ echo $SSH\_AUTH\_SOCK > /tmp/ssh-jzkvKTLbT1b1/agent.4361 > kmc@kmcs:~$ ssh -v [root@unServeurRemote.com](mailto: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](http://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](http://unServeurRemote.com:22) as 'root’ > debug1: SSH2\_MSG\_KEXINIT sent > debug1: SSH2\_MSG\_KEXINIT received > debug1: kex: algorithm: [curve25519-sha256@libssh.org](mailto:curve25519-sha256@libssh.org) > debug1: kex: host key algorithm: ecdsa-sha2-nistp256 > debug1: kex: server-\>client cipher: [chacha20-poly1305@openssh.com](mailto:chacha20-poly1305@openssh.com) MAC: compression: none > debug1: kex: client-\>server cipher: [chacha20-poly1305@openssh.com](mailto: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](http://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](http://unServeurRemote.com) ([adr.ip.server.remote]:22). > debug1: channel 0: new [client-session] > debug1: Requesting [no-more-sessions@openssh.com](mailto: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](mailto: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 ---
**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\ **Post date:** [Janvier 31, 2018, 12:50 UTC](https://www.debian-fr.org/t/scp-localhost/75786/6 "2018-01-31T00:50:56Z")
> [@](#): > > serverRemote ~ \> > > Et là je suis sur le server. Je vous vais demandé de lancer ```auto ssh -v root@unServeurRemote.com id ``` C’est-à-dire de lancer la commande `id` sur le serveur > [@](#): > > debug1: Connecting to [unServeurRemote.com](http://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](http://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 ```auto 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`. ```auto 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$ ``` ```auto 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](https://www.debian-fr.org/t/exercice-ssh-et-sudo/71247) ## 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 ---
**Author:** ![sk4hrr](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/7bcc69/32.png) [@sk4hrr](https://www.debian-fr.org/u/sk4hrr)\ **Post date:** [Janvier 31, 2018, 8:01 UTC](https://www.debian-fr.org/t/scp-localhost/75786/7 "2018-01-31T08:01:25Z")
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). ---
**Author:** ![kmchen](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/k/3d9bf3/32.png) [@kmchen](https://www.debian-fr.org/u/kmchen)\ **Post date:** [Janvier 31, 2018, 10:33 UTC](https://www.debian-fr.org/t/scp-localhost/75786/8 "2018-01-31T10:33:15Z")
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 ---
**Author:** ![sk4hrr](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/7bcc69/32.png) [@sk4hrr](https://www.debian-fr.org/u/sk4hrr)\ **Post date:** [Janvier 31, 2018, 11:55 UTC](https://www.debian-fr.org/t/scp-localhost/75786/9 "2018-01-31T11:55:55Z")
> [@](#): > > 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. ---
**Author:** ![kmchen](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/k/3d9bf3/32.png) [@kmchen](https://www.debian-fr.org/u/kmchen)\ **Post date:** [Janvier 31, 2018, 6:51 UTC](https://www.debian-fr.org/t/scp-localhost/75786/10 "2018-01-31T18:51:51Z")
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](mailto: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…😇 ---
**Author:** ![sk4hrr](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/7bcc69/32.png) [@sk4hrr](https://www.debian-fr.org/u/sk4hrr)\ **Post date:** [Février 1, 2018, 7:52 UTC](https://www.debian-fr.org/t/scp-localhost/75786/11 "2018-02-01T07:52:13Z")
> [@](#): > > 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 ? ---
**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\ **Post date:** [Février 1, 2018, 8:10 UTC](https://www.debian-fr.org/t/scp-localhost/75786/12 "2018-02-01T08:10:26Z")
> [@](#): > > 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 ```auto 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: > > ```auto > 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à: > > ```auto > 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** ---
**Author:** ![kmchen](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/k/3d9bf3/32.png) [@kmchen](https://www.debian-fr.org/u/kmchen)\ **Post date:** [Février 1, 2018, 2:14 UTC](https://www.debian-fr.org/t/scp-localhost/75786/13 "2018-02-01T14:14:37Z")
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](mailto:curve25519-sha256@libssh.org) > debug1: kex: host key algorithm: ecdsa-sha2-nistp256 > debug1: kex: server-\>client cipher: [chacha20-poly1305@openssh.com](mailto:chacha20-poly1305@openssh.com) MAC: compression: none > debug1: kex: client-\>server cipher: [chacha20-poly1305@openssh.com](mailto: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](mailto: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](mailto: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 ---
**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\ **Post date:** [Février 1, 2018, 3:10 UTC](https://www.debian-fr.org/t/scp-localhost/75786/14 "2018-02-01T15:10:51Z")
> [@](#): > > 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](http://unServeurRemote.com) ([adr.ip.server.remote]:22). Et que si je fais ```auto 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 ```auto 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é) ```auto 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) ---
**Author:** ![kmchen](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/k/3d9bf3/32.png) [@kmchen](https://www.debian-fr.org/u/kmchen)\ **Post date:** [Février 1, 2018, 4:38 UTC](https://www.debian-fr.org/t/scp-localhost/75786/15 "2018-02-01T16:38:17Z")
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. ---
**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\ **Post date:** [Février 2, 2018, 12:27 UTC](https://www.debian-fr.org/t/scp-localhost/75786/16 "2018-02-02T00:27:22Z")
> [@](#): > > 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_keys`contient 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 ```auto 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 ) ```auto 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 ```auto ssh root@localhost id ``` Je ne recommande pas cette manière de procéder car elle complique l’exploitation des journaux. ```auto 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 ```auto 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 ---
**Author:** ![sk4hrr](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/7bcc69/32.png) [@sk4hrr](https://www.debian-fr.org/u/sk4hrr)\ **Post date:** [Février 2, 2018, 7:39 UTC](https://www.debian-fr.org/t/scp-localhost/75786/17 "2018-02-02T07:39:22Z")
> [@](#): > > 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 ! ---
**Author:** ![kmchen](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/k/3d9bf3/32.png) [@kmchen](https://www.debian-fr.org/u/kmchen)\ **Post date:** [Février 2, 2018, 8:39 UTC](https://www.debian-fr.org/t/scp-localhost/75786/18 "2018-02-02T08:39:24Z")
> [@](#): > > 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](mailto:kmc@127.0.0.1):/tmp/test\_copied scp -v root@unServerRemote:/tmp/test [kmc@127.0.0.1](mailto:kmc@127.0.0.1):/tmp/ [/quote] Non c’est: > Ces 2 commandes fonctionnent: > scp /tmp/test [kmc@127.0.0.1](mailto: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 ---
**Author:** ![grandtoubab](https://www.debian-fr.org/user_avatar/www.debian-fr.org/grandtoubab/32/4505_2.png) [@grandtoubab](https://www.debian-fr.org/u/grandtoubab)\ **Post date:** [Février 2, 2018, 9:26 UTC](https://www.debian-fr.org/t/scp-localhost/75786/19 "2018-02-02T09:26:53Z")
Salut C’est vrai que SCP c’est pas la mer à boire [https://www.it-connect.fr/chapitres/transfert-de-fichier-via-ssh/](https://www.it-connect.fr/chapitres/transfert-de-fichier-via-ssh/) ---
**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\ **Post date:** [Février 2, 2018, 11:38 UTC](https://www.debian-fr.org/t/scp-localhost/75786/20 "2018-02-02T11:38:13Z")
> [@](#): > > 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 ```auto # 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 ```auto 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. » [Page suivante](https://www.debian-fr.org/t/scp-localhost/75786.md?page=2)