1 votes

Rsync fichiers entre deux serveurs distants en utilisant SSH

Résumé

Je veux copier des fichiers entre 2 serveurs distants en utilisant Rsync et SSH. Le moyen que j'ai trouvé pour le faire est de créer un tunnel SSH, mais j'ai essayé avec plusieurs exemples et aucun d'entre eux n'a fonctionné.

Détails

  • J'ai 3 machines : 1 ordinateur local et 2 serveurs distants
  • Je peux me connecter en SSH aux deux serveurs distants en utilisant ma clé RSA locale.
  • Les 2 serveurs distants ne peuvent pas se parler entre eux. Le serveur distant n°1 n'a pas accès au serveur distant n°2 et vice versa.
  • Je peux utiliser Rsync sur les deux serveurs distants individuellement.

Ce que j'ai essayé

ssh -vvv -A \
-l user_remote1 \
-R localhost:50000:remote2:22 user_remote1@remote1 \
'rsync -e \
"ssh -A -o StrictHostKeyChecking=no \
-o UserKnownHostsFile=/dev/null \
-o GlobalKnownHostsFile=/dev/null \
-p 50000" \
-var /home/user_remote1/test.txt user_remote2@localhost:/home/user_remote2'

Sortie de cette commande

OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug2: resolve_canonicalize: hostname remote1 is address
debug2: ssh_connect_direct
debug1: Connecting to remote1 [remote1] port 22.
debug1: Connection established.
debug1: identity file /Users/user_local/.ssh/id_rsa type 0
debug1: identity file /Users/user_local/.ssh/id_rsa-cert type -1
debug1: identity file /Users/user_local/.ssh/id_dsa type -1
debug1: identity file /Users/user_local/.ssh/id_dsa-cert type -1
debug1: identity file /Users/user_local/.ssh/id_ecdsa type -1
debug1: identity file /Users/user_local/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/user_local/.ssh/id_ed25519 type -1
debug1: identity file /Users/user_local/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/user_local/.ssh/id_xmss type -1
debug1: identity file /Users/user_local/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0
debug1: match: OpenSSH_8.0 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to remote1:22 as 'user_remote1'
debug3: hostkeys_foreach: reading file "/Users/user_local/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/user_local/.ssh/known_hosts:4
debug3: load_hostkeys: loaded 1 keys from remote1
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes256-cbc,aes128-gcm@openssh.com,aes128-ctr,aes128-cbc
debug2: ciphers stoc: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes256-cbc,aes128-gcm@openssh.com,aes128-ctr,aes128-cbc
debug2: MACs ctos: hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512
debug2: MACs stoc: hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:6gPivXbLGMtZsqEIwH4713sH1S/p/pQfHJ8+DoTsqc8
debug3: hostkeys_foreach: reading file "/Users/user_local/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/user_local/.ssh/known_hosts:4
debug3: load_hostkeys: loaded 1 keys from remote1
debug1: Host 'remote1' is known and matches the ECDSA host key.
debug1: Found key in /Users/user_local/.ssh/known_hosts:4
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /Users/user_local/.ssh/id_rsa RSA SHA256:TRou12Aso7/pS0D7blnRJsw9YHeFmDjfPIgkrgu2l4o
debug1: Will attempt key: /Users/user_local/.ssh/id_dsa 
debug1: Will attempt key: /Users/user_local/.ssh/id_ecdsa 
debug1: Will attempt key: /Users/user_local/.ssh/id_ed25519 
debug1: Will attempt key: /Users/user_local/.ssh/id_xmss 
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/user_local/.ssh/id_rsa RSA SHA256:TRou12Aso7/pS0D7blnRJsw9YHeFmDjfPIgkrgu2l4o
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: /Users/user_local/.ssh/id_rsa RSA SHA256:TRou12Aso7/pS0D7blnRJsw9YHeFmDjfPIgkrgu2l4o
debug3: sign_and_send_pubkey: RSA SHA256:TRou12Aso7/pS0D7blnRJsw9YHeFmDjfPIgkrgu2l4o
debug3: sign_and_send_pubkey: signing using rsa-sha2-512
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to remote1 ([remote1]:22).
debug1: Remote connections from localhost:50000 forwarded to local address remote2:22
debug3: send packet: type 80
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug3: receive packet: type 4
debug1: Remote: /home/user_remote1/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: receive packet: type 4
debug1: Remote: /home/user_remote1/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: receive packet: type 81
debug1: remote forward success for: listen localhost:50000, connect remote2:22
debug1: All remote forwarding requests processed
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug1: Requesting authentication agent forwarding.
debug2: channel 0: request auth-agent-req@openssh.com confirm 0
debug3: send packet: type 98
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x20
debug2: client_session2_setup: id 0
debug1: Sending environment.
debug3: Ignored env TERM_PROGRAM
debug3: Ignored env TERM
debug3: Ignored env SHELL
debug3: Ignored env TMPDIR
debug3: Ignored env TERM_PROGRAM_VERSION
debug3: Ignored env OLDPWD
debug3: Ignored env TERM_SESSION_ID
debug3: Ignored env USER
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env PATH
debug3: Ignored env PWD
debug3: Ignored env XPC_FLAGS
debug3: Ignored env XPC_SERVICE_NAME
debug3: Ignored env HOME
debug3: Ignored env SHLVL
debug3: Ignored env LOGNAME
debug1: Sending env LC_CTYPE = UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env _
debug3: Ignored env __CF_USER_TEXT_ENCODING
debug1: Sending command: rsync -e \\
"ssh -A -o StrictHostKeyChecking=no \\
-o UserKnownHostsFile=/dev/null \\
-o GlobalKnownHostsFile=/dev/null \\
-p 50000" \\
-var /home/user_remote1/test.txt user_remote2@localhost:/home/user_remote2
debug2: channel 0: request exec confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug3: receive packet: type 90
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 4 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 50000, originator ::1 port 56418
debug2: fd 7 setting O_NONBLOCK
debug2: fd 7 setting TCP_NODELAY
debug1: connect_next: host remote2 ([remote2]:22) in progress, fd=7
debug3: fd 7 is O_NONBLOCK
debug3: fd 7 is O_NONBLOCK
debug1: channel 1: new [::1]
debug1: confirm forwarded-tcpip
debug3: channel 1: waiting for connection
debug1: channel 1: connected to remote2 port 22
debug3: send packet: type 91
debug3: receive packet: type 90
debug1: client_input_channel_open: ctype auth-agent@openssh.com rchan 5 win 65536 max 16384
debug2: fd 8 setting O_NONBLOCK
debug3: fd 8 is O_NONBLOCK
debug1: channel 2: new [authentication agent connection]
debug1: confirm auth-agent@openssh.com
debug3: send packet: type 91
debug2: channel 0: rcvd ext data 84
Warning: Permanently added '[localhost]:50000' (ECDSA) to the list of known hosts.
debug2: channel 0: written 84 to efd 6
debug3: receive packet: type 96
debug2: channel 2: rcvd eof
debug2: channel 2: output open -> drain
debug2: channel 2: obuf empty
debug2: channel 2: chan_shutdown_write (i0 o1 sock 8 wfd 8 efd -1 [closed])
debug2: channel 2: output drain -> closed
debug1: channel 2: FORCE input drain
debug2: channel 2: ibuf empty
debug2: channel 2: send eof
debug3: send packet: type 96
debug2: channel 2: input drain -> closed
debug2: channel 2: send close
debug3: send packet: type 97
debug3: channel 2: will not send data after close
debug3: receive packet: type 97
debug2: channel 2: rcvd close
debug3: channel 2: will not send data after close
debug2: channel 2: is dead
debug2: channel 2: garbage collecting
debug1: channel 2: free: authentication agent connection, nchannels 3
debug3: channel 2: status: The following connections are open:
  #0 client-session (t4 r2 i0/0 o0/0 e[write]/0 fd 4/5/6 sock -1 cc -1)
  #1 ::1 (t4 r4 i0/0 o0/0 e[closed]/0 fd 7/7/-1 sock 7 cc -1)
  #2 authentication agent connection (t4 r5 i3/0 o3/0 e[closed]/0 fd 8/8/-1 sock 8 cc -1)

debug2: channel 0: rcvd ext data 38
Permission denied, please try again.
debug2: channel 0: written 38 to efd 6
debug2: channel 0: rcvd ext data 38
Permission denied, please try again.
debug2: channel 0: written 38 to efd 6
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: chan_shutdown_read (i0 o0 sock -1 wfd 4 efd 6 [write])
debug2: channel 0: input open -> closed
debug2: channel 0: rcvd ext data 229
debug3: receive packet: type 96
debug2: channel 1: rcvd eof
debug2: channel 1: output open -> drain
debug2: channel 1: obuf empty
debug2: channel 1: chan_shutdown_write (i0 o1 sock 7 wfd 7 efd -1 [closed])
debug2: channel 1: output drain -> closed
debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug3: receive packet: type 97
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: obuf_empty delayed efd 6/(229)
user_remote2@localhost: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.3]
debug2: channel 0: written 229 to efd 6
debug3: channel 0: will not send data after close
debug2: channel 0: obuf empty
debug2: channel 0: chan_shutdown_write (i3 o1 sock -1 wfd 5 efd 6 [write])
debug2: channel 0: output drain -> closed
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug3: send packet: type 97
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 2
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r2 i3/0 o3/0 e[write]/0 fd -1/-1/6 sock -1 cc -1)
  #1 ::1 (t4 r4 i0/0 o3/0 e[closed]/0 fd 7/7/-1 sock 7 cc -1)

debug2: channel 1: read<=0 rfd 7 len 0
debug2: channel 1: read failed
debug2: channel 1: chan_shutdown_read (i0 o3 sock 7 wfd 7 efd -1 [closed])
debug2: channel 1: input open -> drain
debug2: channel 1: ibuf empty
debug2: channel 1: send eof
debug3: send packet: type 96
debug2: channel 1: input drain -> closed
debug2: channel 1: send close
debug3: send packet: type 97
debug3: channel 1: will not send data after close
debug3: receive packet: type 97
debug2: channel 1: rcvd close
debug3: channel 1: will not send data after close
debug2: channel 1: is dead
debug2: channel 1: garbage collecting
debug1: channel 1: free: ::1, nchannels 1
debug3: channel 1: status: The following connections are open:
  #1 ::1 (t4 r4 i3/0 o3/0 e[closed]/0 fd 7/7/-1 sock 7 cc -1)

debug3: send packet: type 1
debug3: fd 1 is not O_NONBLOCK
Transferred: sent 6168, received 6820 bytes, in 2.5 seconds
Bytes per second: sent 2488.0, received 2750.9
debug1: Exit status 255

J'ai fait des recherches sur plusieurs sujets connexes à partir de cette sortie, comme "rsync error : unexplained error (code 255) at io.c(226) [sender=3.1.3]", "ssh debug1 : Next authentication method : password" ou "read_passphrase : can't open /dev/tty : No such device or address", mais je n'ai rien trouvé d'utile.

Y a-t-il quelque chose d'incorrect dans la commande ou peut-être ai-je besoin d'une configuration personnalisée dans les serveurs ? Tout commentaire sera utile. Merci.

1voto

Kamil Maciorowski Points 57004

Vous utilisez ssh -A . Je comprends que tu veuilles ssh exécuté par rsync sur remote1 pour atteindre votre ssh-agent . Vous espérez obtenir une autorisation sur remote2 avec votre clé locale de cette façon. Le plan est bon.

La sortie verbeuse que vous avez publiée me dit ssh-agent travaille localement et ssh exécuté par rsync sur remote1 peut y accéder. Vous obtenez quand même Permission denied (publickey,… . La connexion SSH (tunnellisée) de remote1 a remote2 ne parvient pas à s'authentifier et se ferme ; rsync ne peut pas continuer ( rsync: connection unexpectedly closed ).

Cela suggère fortement que l'agent local ne détient pas la bonne clé. man 1 ssh-agent lit :

L'agent ne dispose initialement d'aucune clé privée. Les clés sont ajoutées en utilisant ssh-add(1) ou par ssh(1) quand AddKeysToAgent est fixé dans ssh_config(5) .

Une façon d'ajouter une clé à un projet déjà lancé. ssh-agent est avec ssh-add avant d'invoquer ssh . Puisque vous voulez utiliser la même clé que celle de votre local ssh va utiliser, AddKeysToAgent devrait également fonctionner. Vous n'avez pas besoin de modifier ssh_config vous pouvez passer l'option directement dans le fichier (local) ssh l'invocation :

ssh -A -o AddKeysToAgent=yes …

(où indique le reste de la commande que vous avez déjà).

Notez que cela nécessite ssh-agent pour fonctionner et SSH_AUTH_SOCK pour être dans l'environnement, donc ssh peut communiquer avec l'agent. Il semble que vous vous soyez déjà occupé de cette question.

Les utilisateurs qui ont un problème similaire et qui ne savent pas grand-chose sur ssh-agent et comment le faire démarrer correctement (ou ils ne sont pas sûrs de savoir si ssh-agent a été lancé correctement par son système d'exploitation, par lui-même ou autre) peut préférer la commande suivante :

ssh-agent ssh -A -o AddKeysToAgent=yes …

Elle démarre une nouvelle ssh-agent . L'agent commencera ssh dans le bon environnement, pour que les deux puissent communiquer. Il existe des scénarios où ce formulaire est particulièrement utile ( exemple ). Ici, le formulaire n'est pas obligatoire, mais il est indépendant de tout agent précédemment lancé (ou pas lancé du tout) et devrait fonctionner d'emblée, à moins qu'il n'y ait un problème avec la ou les clés. Donc, si vous n'êtes pas familier avec ssh-agent alors la dernière commande est le meilleur choix. ssh-agent commencé de cette façon se terminera après ssh sortent.

Dans le cas de l'OP, il y a quelques améliorations mineures à apporter :

  • ssh -l user_remote1 user_remote1@remote1 est redondant, il précise user_remote1 deux fois. Il existe peu de méthodes pour spécifier l'utilisateur et le serveur. L'utilisation de plus d'une méthode dans une seule invocation n'est pratiquement jamais utile (voir une cas limite où c'est utile ).

  • Je ne pense rien sur remote2 doit accéder au réseau local de ssh-agent . -A dans le ssh commande rsync (sur remote1 ) va utiliser est donc superflue. La commande fonctionnera de l'une ou l'autre façon, mais faites attention à ce que man 1 ssh États :

    Le transfert d'agent doit être activé avec prudence. Les utilisateurs ayant la possibilité de contourner les autorisations de fichiers sur l'hôte distant (pour le socket du domaine UNIX de l'agent) peuvent accéder à l'agent local via la connexion transférée. Un attaquant ne peut pas obtenir de clé de l'agent, mais il peut effectuer des opérations sur les clés qui lui permettent de s'authentifier en utilisant les identités chargées dans l'agent.

    Vous devez -A quand vous ssh du local au remote1 ; un attaquant assis sur remote1 est le risque que vous prenez. Le superflu -A lors de la connexion à remote2 est seulement une opportunité pour un attaquant assis sur remote2 .

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X