El SSH (Shell Seguro) es un protocolo cliente-servidor para conectarse y autenticarse a un servidor remoto.

La autenticación significa que el servidor remoto puede verificar que eres tú mismo no alguien más hablando por ti.

Podrías ya estar usando la autenticación SSH de Github, ¿pero sabes cómo funciona en sí? En este artículo, aprenderá qué sucede de forma interna y cómo funciona en realidad la autenticación de SSH.

A lo largo, entenderás los conceptos fundamentales de criptografía que cada desarrollador debería saber: encriptación de clave simétrica, encriptación de clave asimétrica, funciones hash criptográficas, y firmas digitales.

Algunos desarrolladores usualmente no tienen la chance de aprender y entender estos fundamentos de criptografía, pero estos conceptos te ayudarán a la larga. También, te ayudarán en estar en una mejor posición para tomar decisiones de seguridad informadas para tus aplicaciones de web en producción.

Así que vamos, abróchate los cinturones de seguridad, ¡y comencemos!

Esto es lo que cubriremos:

1. Primero, ¿por qué la Autenticación es tan importante?
2. Encriptación de Clave Simétrica
3. Encriptación de Clave Asimétrica
4. Funciones de Hash Criptográficas
5. Firmas Digitales
6. Cómo Funciona la Autenticación SSH
7. Resumiendo Todo

Primero, ¿por qué la Autenticación es tan importante?

Cuando ejecutamos git push, Github necesita verificar que la persona correcta está interactuando con Github. Imagina si un atacante podría llegar a hacer git push por ti.

Entonces todos tus repositorios estarían bajo el control del atacante. Podrían eliminar todo tu código juntamente con todo el historial de las confirmaciones.

Esto suena bastante peligroso, ¿no? Así que para verificar que eres tú el que está hablando con Github, y no un atacante, Github tiene varias formas de autenticarte.

El método más usado para autenticar con Github es la autenticación SSH.

Antes que entendamos cómo funciona la autenticación SSH internamente, necesitaremos entender los conceptos fundamentales de criptografía, a saber – encriptación de clave simétrica, encriptación de clave asimétrica, funciones de hash criptográficas, y firmas digitales.

¡Comencemos!

Encriptación de Clave Simétrica

En los tiempos antiguos, los gobernantes idearon varios métodos de comunicar mensajes militares secretos a sus comandantes del ejército.

En los métodos más primitivos, mayormente usados por los gobernantes Griegos antiguos y posiblemente luego los Romanos, involucrados usando una vara de madera cilíndrica llamado un Escítala.

Antes de una invasión militar, el gobernante tendría las dos mismas varas de madera cilíndricos exactas. Entonces le daría una escítala al comandante del ejército y mantener uno para sí mismo.

El dispositivo funcionaba al enrollar una tira de cuero alrededor de escítala. Después de hacer esto, el gobernante escribiría el mensaje por encima de la tira de cuero enrollada de forma que solo pudiera ser leído cuando estuviere enrollada de forma apropiada nuevamente.

Supón que la escítala le permitiera escribir tres letras alrededor en un circulo y cinco letras de forma recta a lo largo de su longitud. La tira de cuero enrollada con el mensaje attackfromright escrito luciría así:

       |   |   |   |   |   |
       | a | t | t | a | c |  |
     __| k | f | r | o | m |__|
    |  | r | i | g | h | t |
    |  |   |   |   |   |   |

Después de escribir el mensaje en la escítala, el gobernante desenrollaría la tira de cuero y lo enviaría al comandante del ejército. Cuando estaba desenrollada, la tira de cuero tendría el siguiente mensaje desordenado:

----------------
akrtfitrgaohcmt
----------------

Así que ahora lo ves, incluso si la tira de cuero fuera interceptada por un espía enemigo, el mensaje no tendría sentido. ¿No es fascinante? El uso inteligente de una vara de madera y una tira de cuero, ¡podría haber ayudado a algunos gobernantes antiguos ganar batallas!

Cuando la tira de cuero alcanzaba al comandante del ejército, lo envolvería con su propia escítala (que sería exactamente el mismo que el del gobernante), y luego el comandante sería capaz de entender el mensaje apropiadamente.

Esta técnica de la escítala en realidad es un ejemplo de la encriptación de clave simétrica en la práctica.

La encriptación es un proceso en el que el mensaje origina es modificado (o codificado) de tal forma que solamente el recipiente indicado puede decodificar y ver el mensaje actual.

El mensaje original se llama texto plano, mientras que el mensaje codificado se llama texto cifrado. La encriptación convierte el texto plano a texto cifrado con la ayuda de una clave.

Para descifrar el mensaje, que sería convertir el texto cifrado a texto plano, una persona debe tener acceso a la misma llave.

Si lo comparamos a la técnica de la escítala, la escítala es la llave. El gobernantes solamente comparte la llave (escítala) con el comandante del ejército que necesita saber lo que dice el mensaje.

Así es como luce el proceso de encriptación:

El proceso de descifrado lucirá así:

Llamamos a esto encriptación de llave simétrica porque la misma llave se usa tanto para encriptar y descifrar el mensaje.

Esta llave (la escítala) se debe mantener resguardada del acceso del enemigo. Si el enemigo accede a esta llave, entonces será capaz de descifrar los mensajes.

Pero hay otro tipo de encriptación llamada encriptación de llave asimétrica. Ahora que entiendes la encriptación de llave simétrica, sigamos con la encriptación de llave asimétrica.

Encriptación de Llave Asimétrica

En la encriptación de llave simétrica, como vimos arriba, la misma llave era usada por el gobernante y el comandante del ejército para encriptar y descifrar el mensaje.

Pero en una encriptación de llave asimétrica, hay dos llaves (llamado un par de llaves). De las dos llaves, una es una llave privada y la otra es una llave pública.

La llave pública puede ser compartido con todos (el cual por eso se llama pública). Pero la llave privada tiene que mantenerse, ¡en secreto! Nunca debe ser revelado a nadie.

Lo interesante sobre la encriptación de llave asimétrica es eso, si un mensaje es encriptado con la llave pública, entonces puede ser descifrado solamente con la llave privada correspondiente. Ninguna otra llave puede descifrarlo.

Y funciona de la otra forma también. Si un mensaje es encriptado con la llave privada entonces puede ser descifrado solamente usando la llave pública correspondiente.

Las dos llaves – pública y privada – están enlazados matemáticamente uno con el otro. Mientras uno encripta, el otro descifra.

Sólo una pequeña nota, la encriptación de llave asimétrica también se le llama encriptación de llave pública. Estos dos términos son usados de forma intercambiable pero significa lo mismo.

Funciones Hash Criptográficas

Una función hash criptográfica está diseñada para tomar una entrada de cualquier longitud y producir una salida de longitud fijada. La salida de longitud fijada se le denomina valor hash.

Un ejemplo popular de una función hash criptográfica es SHA-256.

La imagen de arriba muestra el valor hash SHA-256 de la entrada "freeCodeCamp.org". Las funciones hash criptográficas tienen tres propiedades que lo hacen muy útiles (lo veremos en las próximas secciones).

Primero, es prácticamente imposible para tomar el valor hash y averiguar la entrada del valor hash.

Por ejemplo, si nos dan el valor hash c9c31315ef2257e4b7698, no hay forma de que averigüemos que la entrada a la función hash fuere "freeCodeCamp.org".

Segundo, si pasamos la misma entrada a la función hash, obtenemos el mismo valor hash como la salida.

Si pasamos "freeCodeCamp.org" nuevamente a la función hash SHA-256, obtendremos la misma salida hash como nuestra llamada previa.

Tercero, dos entradas distintas nunca comparten el mismo valor hash. Inclusive el cambio más ligero en la entrada produce una salida totalmente distinta.

Supón que si proveemos "freeCodeCamp" como entrada en vez de "freeCodeCamp.org" – obtenemos una salida totalmente distinta.

Firmas Digitales

En tus vidas diarias, podrías tener que firma varios documentos. Podrían ser documentos legales, o el boletín de calificaciones de tus hijos, o tal vez algo más.

Cuando tu firma esté presente en el documento, le transmite a la otra parte que eres tú el que está de acuerdo cualquier cosa que esté escrito en ese documento.

Luego, no puedes dar marcha atrás de lo que está escrito en el documento. ¿Correcto?

De forma similar, en el mundo digital, tenemos las firmas digitales – o podemos simplemente llamarlos firmas.

Entendamos cómo funcionan las firmas usando un ejemplo. Tenemos dos usuarios llamados "Alice" y "Bob".

Bob quiere transferir algo de dinero a la cuenta bancaria de Alice. Así que Bob le pide a Alice su información de cuenta bancaria.

Alice sabe sobre las firmas digitales y decidió usar una. Al final, entenderás por qué Alice optó por una firma digital.

Antes de que Alice pueda crear una firma digital. Alice provee a Bib su clave pública (y guarda la clave privada para sí misma).

Luego Alice crea una firma digital y lo color al final del documento.

Una firma digital se crea primero al pasar el contenido del documento a una función hash criptográfica como SHA-256. En el caso de Alice, el contenido del documento es su número de cuenta bancaria.

Una vez que obtenemos el valor hash, se encripta con la clave privada de Alice. La salida de esta encriptación es la firma el cual se coloca al final del documento.

Luego esto se lo envía a Bob por Internet.

Cuando Bob recibe este documento, verifica si la firma es válida o no.

Para verificar la firma, Bob primero descifra la firma con la clave pública de Alice. Si lo recuerdas, Alice generó la firma al encriptar el valor hash.

 plaintext                         ciphertext  
     |                                 |
     |                                 |
     |                                 |
hash value --------encrypt--------> signature

Así que, cuando Bob descifra la firma, obtendrá el valor hash que Alice calculó. Llamemos a este valor hash de Alice.

 ciphertext                         plaintext  
     |                                 |
     |                                 |
     |                                 |
signature --------decrypt--------> hash value

Luego Bob toma el número de la cuenta bancaria que esta presente en el documento y lo pasa a la función hash.

Finalmente, Bob coincide el valor hash de Alice (la firma descifrada) y el valor hash que calculó. Si ambos valores hash coinciden entonces significa que la firma es válida.

Muy bien – ¿pero por qué necesitábamos hacer todo esto? ¿Qué significa si la firma es válida?

Cuando la verificación de la firma es exitosa, prueba dos cosas.

Primero, prueba que el documento ha sido enviado por Alice solamente. Nadie más podría haber enviado este documento.

La garantía de que solamente Alice ha enviado este documento viene del hecho de que fuimos capaces de descifrar la firma usando la clave pública de Alice.

Hemos aprendido de que si algo es encriptado usando una clave privada entonces puede ser descifrado solamente usando su clave pública vinculada.

Asi que, si Bob fue capaz de descifrar la firma usando la clave pública de Alice, significa que fue descifrado utilizando la clave privada de Alice, ¿correcto?

Y solamente Alice tiene acceso a su clave privada. Esto significa que, ¡Alice es la única persona quien podría haber enviado este documento!

Segundo, prueba que el contenido del mensaje no ha sido modificado por un atacante durante la transmisión en red.

Hicimos dos cosas para verificar la firma. Desciframos la firma, y nos dio el valor hash que Alice calculó. Y también hasheamos el número de cuenta bancaria recibido.

Si el valor hash que Alice caluló y el valor hash que Bob calculó son los mismos, significa que Alice y Bob dieron exactamente la misma entrada a la función hash.

Y esto significa que el número de cuenta bancaria que Alice envió y que Bob recibió son exactamente los mismos.

Si un atacante habría cambiado el número de cuenta bancaria antes de que el documento le llegara a Bob, entonces Bob hubiera recibido un número de cuenta bancaria modificado.

Cuando Bob fuera a calcular el valor hash de este número de cuenta bancaria modificado, el valor hash hubiera sido distinto de lo que Alice había calculado.

Así que mientras coincida el valor hash de Alice (firma descifrada) y el valor hash que Bob calculó, la coincidencia fallaría. Y evitaría que Bob transfiera dinero al número de cuenta bancaria errónea.

Para concluir, cuando la firma es verificada con éxito, significa que:

1. El documento es solamente de Alice.
2. El contenido del documento no fue modificado por algún tercero.

Ahora has aprendido sobre encriptación de clave simétrica, encriptación de clave asimétrica, funciones de hash criptográficas, y firmas digitales. ¡Es genial!

Hemos construido una fundación realmente sólido. Ahora entender la autenticación SSH va a ser mucho más fácil para ti.

Cómo Funciona la Autenticación SSH

Si no has configurado la autenticación SSH con Github, entonces después de terminar este artículo puedes seguir la documentación detallada de Github sobre cómo hacerlo. Por ahora, por favor quédate hasta el final.

La cruz del proceso de configuración es que crees un par de claves pública y privada en tu computadora local. Luego subes tu clave pública a tu perfil de Github – ¡y eso es todo!

Después que hemos creado nuestro par de claves pública y privada, en Ubuntu, el par de claves se almacenan dentro de la carpeta ~/.ssh.

La imagen de arriba muestra mi clave pública. Tengo esta clave pública cargada en mi perfil de Github:

Ahora, cuando ejecuto git push o cualquier otro comando que se quiera comunicar con Github, estaré autenticado usando la autenticación SSH.

SSH es un protocolo cliente-servidor. Nuestra computadora que ejecuta git push es el cliente SSH. Github es el servidor SSH.

El cliente comienza con el proceso de autenticación al solicitar nuestra clave pública que tenemos dentro de ~/.ssh.

Luego el cliente prepara un mensaje el cual tiene nuestra clave pública. Y luego el cliente genera la firma usando la clave privada correspondiente.

La clave pública y la firma se envían a Github. Al recibir este mensaje, Github hace dos cosas:

Primero, verifica si la clave pública mencionada en el mensaje se conecta a un perfil de Gihtub o no. Ya que subimos nuestra clave pública a Github, este paso se realizó con éxito.

Segundo, Github verifica la firma usando la clave pública que hemos subido.

Hemos aprendido que si la verificación de la firma termina siendo exitoso significa que solamente la persona quién está en posesión de la clave privada correspondiente podría haber enviado el mensaje.

Ya que solamente tenemos la clave privada vinculada a la clave pública cargada, esto prueba a Github que en realidad somos nosotros intentando comunicarse con Github y no un atacante.

Ahora, Github es 100% seguro que somos la persona correcta, estamos autenticados exitosamente, y a nuestro git push se le permite proceder.

Ves, se volvió fácil de entender la autenticación SSH ya que aprendiste los fundamentos.

La imagen de arriba es del cómic popular xkcd. El personaje allí (llamado Cueball) está pensando en revelar su clave privada. Espero que ahora sepas por qué está mal revelar tu clave privada.

Si revelas tu clave privada entonces alguien más puede autenticarse a Github en tu nombre. No quieres que eso suceda, ¿verdad? ;)

Así que, siempre asegúrate de mantener tu clave privada para ti mismo nada más.

Resumiendo Todo

Si has llegado hasta acá, entonces felicitaciones 🥳.

Has aprendido como funciona en realidad la autenticación SSH – cuando la firma fue verificado exitosamente por Github, le confirma a Github que somos nosotros quienes le estamos hablando, no un atacante.

A lo largo adquiriste una comprensión fundamental de la encriptación de clave simétrica, encriptación de clave asimétrica, funciones hash criptográficas y firmas digitales.

Gracias por estar conmigo en esta, espero que te vayas con algunos nuevos y valiosos aprendizajes.

Pongo ideas y recursos útiles en mi Twitter. Deberías seguirme allí. Respetaré tu tiempo.

Crea un nuevo par claves SSH

Abre una terminal y ejecuta el siguiente comando:

ssh-keygen

Verás el siguiente texto:

// Generando clave par rsa pública/privada.
// Ingresa el archivo en cual guardar la clave (/home/nombre_usuario/.ssh/id_rsa):

Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):

Presiona enter para guardar tus claves al directorio por defecto /home/nombre_usuario/.ssh

Entonces se te requerirá que escribas tu contraseña:

// Ingresa una contraseña (vacío para guardar sin contraseña):
Enter passphrase (empty for no passphrase):

Es recomendable introducir una contraseña para contar con una capa extra de seguridad. Al configurar una contraseña puedes prevenir el acceso no autorizado a tus servidores y cuentas; en el caso que alguien llegara a tener acceso a tu clave privada SSH o a tu computadora.

Luego de introducir y confirmar tu contraseña, verás lo siguiente:

// Tu identificación ha sido guardada en /home/nombre_usuario/.ssh/id_rsa.
// Tu clave pública ha sido guardada en /home/username/.ssh/id_rsa.pub.
// La huella digital (fingerprint) de tu clave es:
// SHA256:/qRoWhRcIBTw0D4KpTUyK6YepyL6RQ2CQrtWsaicCb4 username@871e129f767b
// La imagen randomart (arte aleatorio) de tu clave es:

Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:/qRoWhRcIBTw0D4KpTUyK6YepyL6RQ2CQrtWsaicCb4 username@871e129f767b
The key's randomart image is:
+---[RSA 2048]----+
| .o=+....        |
|+.*o+o .         |
|+X.=o o          |
|@.=.oo .         |
|=O ...o S        |
|o.oo . .         |
|.E+ . . . .      |
|oo . ... +       |
|=.. .o. . .      |
+----[SHA256]-----+

Ahora ya tienes un par de claves (privada y pública) que puedes usar para tener acceso a servidores remotos de manera segura y manejar la autenticación de programas de línea de comandos como Git.

Administra múltiples claves SSH

Aunque es considerado buena práctica tener un sólo par de claves pública-privada por dispositivo, a veces necesitas usar múltiples claves o tienes nombres para claves no-ortodoxos. Por ejemplo, podrías estar usando un par de claves SSH para trabajar en los proyectos internos de tu compañía, pero podrías estar usando una clave distinta para tener acceso a los servidores de un cliente. Además, podrías estar utilizando una clave diferente para tener acceso a tu propio servidor privado.

Administrar claves SSH puede tornarse difícil e incómodo tan pronto como necesites utilizar una segunda clave. Tradicionalmente, usarías  ssh-add para guardar tus claves en  ssh-agent, escribiendo la contraseña para cada clave. El problema es que necesitarías hacer esto cada vez que reinicies tu computadora, lo cual se vuelve tedioso rápidamente.

Una mejor solución es automatizar la adición y guardado de claves y especificar qué clave utilizar cuando se ingrese a ciertos servidores.

SSH config

Entra SSH config,  que es un archivo de configuración por-usuario para la comunicación SSH. Crea un nuevo archivo: ~/.ssh/config y ábrelo para escribir:

nano ~/.ssh/config

Administrando nombres personalizados de claves SSH

La primera cosa que vamos a resolver usando este archivo config es evitar tener que agregar nombres personalizados para las claves SSH usando ssh-add. Asumiendo que tu clave privada se llame  ~/.ssh/id_rsa, agrega lo siguiente al archivo config:

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa
  IdentitiesOnly yes

A continuación, abre otra terminal para asegurarte que  ~/.ssh/id_rsa no esté en  ssh-agent y corre el siguiente comando:

ssh-add -D

Este comando removerá todas las claves de la sesión  ssh-agent actualmente activa.

Ahora si intentas clonar un repositorio GitHub, tu archivo config usará la clave en ~/.ssh/ida_rsa.

Aquí están otros ejemplos útiles de configuración:

Host bitbucket-corporate
        HostName bitbucket.org
        User git
        IdentityFile ~/.ssh/id_rsa_corp
        IdentitiesOnly yes

Ahora puedes usar  git clone git@bitbucket-corporate:company/project.git

Host bitbucket-personal
        HostName bitbucket.org
        User git
        IdentityFile ~/.ssh/id_rsa_personal
        IdentitiesOnly yes

Ahora puedes usar  git clone git@bitbucket-personal:username/other-pi-project.git

Host myserver
        HostName ssh.username.com
        Port 1111
        IdentityFile ~/.ssh/id_rsa_personal
        IdentitiesOnly yes
        User username
        IdentitiesOnly yes

Ya puedes usar SSH para ingresar a tu servidor usando ssh myserver. Ya no necesitarás ingresar un puerto (port) y nombre de usuario cada vez que quieras ingresar a tu servidor privado.

Administración de contraseñas

La pieza final del rompecabezas es el manejo o administración de contraseñas. Se puede volver una tarea tediosa tener que ingresar una contraseña cada vez que inicializas una conexión SSH. Para evitar esta situación, podemos usar software de administración de contraseñas que viene con macOS y varias distribuciones de Linux.

Para este tutorial usaremos Keychain Access, un programa de macOS. Empecemos por agregar tu clave a Keychain Access pasando la opción -K al comando ssh-add:

ssh-add -K ~/.ssh/id_rsa_whatever

Ahora podrás ver tu clave SSH en Keychain Access:

Pero si quitas las claves de  ssh-agent con  ssh-add -D o reinicias tu computadora, esta te volverá a solicitar la contraseña y usuario cuando trates de usar SSH. Resulta que hay un obstáculo más que sortear. Abre tu archivo  config usando nano ~/.ssh/config y agrega lo siguiente:  

Host *
  AddKeysToAgent yes
  UseKeychain yes

Con esto, cuando sea que uses ssh la computadora buscará automáticamente las claves en Keychain Access. Si encuentra una, ya no se te solicitará una contraseña cada que uses SSH. Las claves también se agregan automáticamente a ssh-agent cada vez que reinicias tu computadora.

¡Ahora que sabes lo básico de crear nuevas claves SSH y administrar varias, sal a ponerlo en práctica!

Traducido del artículo - The ultimate guide to ssh setting up ssh keys

¿Qué es RSync?

Rsync es más rápido que herramientas como Secure Copy Protocol (SCP). Utiliza el algoritmo de transferencia delta que minimiza la transferencia de datos al copiar solo las secciones de un archivo que se han actualizado.

Algunas de las características adicionales de Rsync incluyen:

• Admite la copia de enlaces, dispositivos, propietarios, grupos y permisos
• No requiere privilegios de superusuario
• Transferencias de archivos mediante pipelines para minimizar los costes de latencia

Solo puedes transferir archivos de local a remoto o de remoto a local. Rsync no admite transferencias de archivos remotas a remotas.

¿Cómo funciona RSync?

Ahora que sabe qué es Rsync, veamos cómo trabajar con él.

Rsync funciona de manera similar a otras herramientas de administración de servidores remotos como SSH y SCP.

Esta es la sintaxis básica de Rsync:

rsync [options] source [destination]

Esta es la sintaxis para transferir un archivo desde el sistema local a un servidor remoto. También se denomina operación "push".

rsync local_file_path user@remote-host:remote_file_path

Esta es la explicación de cómo transferir un archivo desde un servidor remoto al sistema local, también llamada operación "pull".

rsync user@remote-host:remote_file_path local_file_path

Nota: cuando trabaje con sistemas remotos, asegúrese de tener acceso SSH al sistema remoto. Rsync establece la conexión mediante SSH para permitir la transferencia de archivos.

¿Cómo usar Indicadores en RSync?

Rsync te permite agregar opciones adicionales a través de indicadores de línea de comandos. Veamos algunos indicadores útiles.

Recursivo

Si agrega la opción -r, RSync ejecutará una transferencia de archivos recursiva. Esto es útil cuando se trabaja con directorios. Aquí hay un ejemplo:

rsync -r user@remote-host:remote_directory/ local_directory

Archivo

El indicador -a se usa para conservar los enlaces simbólicos mientras se transfieren archivos. El indicador de archivo también conserva los archivos especiales y de dispositivo, las horas de modificación y los permisos del directorio de origen.

El indicador archivo también sincroniza archivos de forma recursiva, por lo que se usa más que el indicador recursivo. Así es como se usa:

rsync -a user@remote-host:remote_directory/ local_directory

Compresión

También puedescomprimir archivos usando el indicador -z. La compresión de archivos puedes reducir la carga de la red y acelerar la transferencia de archivos.

rsync -az user@remote-host:remote_directory/ local_directory

Progreso

Para transferencias de archivos grandes, es útil conocer el progreso de la operación. Puedes utilizar el indicador -P para conocer el progreso de la transferencia de archivos. Con Rsync, también puedes reanudar las transferencias de archivos si se interrumpen.

rsync -aP user@remote-host:remote_directory/ local_directory

Verboso

Finalmente, el comando verboso nos ayuda  a comprender cada paso de la transferencia de archivos. Puedes usar el indicador -v para esto.

rsync -av user@remote-host:remote_directory/ local_directory

También puedes usar el comando de ayuda con RSync para obtener una lista de todas las opciones y indicadores.

rsync --help

Conclusión

Rsync simplifica todo el proceso de transferencia de archivos al ofrecer una herramienta robusta, versátil y flexible en comparación con alternativas como SCP.

RSync es ideal para operaciones de mantenimiento, copias de seguridad y operaciones generales de archivos entre máquinas locales y remotas.

Referencias

• https://www.digitalocean.com/community/tutorials/how-to-use-rsync-to-sync-local-and-remote-directories-on-a-vps
• https://linux.die.net/man/1/rsync
• https://www.geeksforgeeks.org/rsync-command-in-linux-with-examples/

Soy Manish y escribo sobre Ciberseguridad, Inteligencia Artificial y DevOps. Si te gustó este artículo, puedes encontrar mi blog aquí.

Traducido del artículo de Manish Shivanandhan - RSync Examples – Rsync Options and How to Copy Files Over SSH