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 ?
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.
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é:
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
C’est-à-dire de lancer la commande id sur le serveur
Pourquoi vous vous amusez à éditer les commandes et les sorties ?
D’accord, on pourrait supprimer l’option -v.
Mais ce qui coince c’est votre compréhension du problème.
Sur la machine locale seulement, sur le serveur distant vous êtes 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$
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/"
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).
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
?
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…
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 :
Dommage que tu n’aies pas répondu aux demandes de littlejohn75
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 :
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
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)
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.
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.
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.
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 )
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):
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:
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:
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 ) ?
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.
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 )
Une pagaille sans nom qui dure trois jours
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.
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. »
(pour avoir