Todo sobre el protocolo de copia segura

El protocolo Secure Copy Protocol (SCP) transfiere archivos a través de una conexión SSH cifrada utilizando una sintaxis que la mayoría de los ingenieros pueden escribir de memoria. Esa simplicidad es también el problema: el protocolo subyacente de SCP se remonta al rcp de 1983, se ha distribuido con vulnerabilidades conocidas, incluyendo un fallo de inyección de comandos de 2020 y un error de escalada de privilegios de 2026, y OpenSSH ahora utiliza por defecto un método de transferencia más seguro con el mismo nombre de comando.

Publicado: abril de 2026. Actualizado: agosto de 2026. Revisado por el equipo de SSH y gestión de claves de Encryption Consulting.

¿Qué es el Protocolo de Copia Segura (SCP) y cómo funciona?

SCP es una herramienta de línea de comandos que copia archivos entre un host local y uno remoto, o entre dos hosts remotos, a través de una conexión SSH existente . Su existencia se debe a que el Protocolo de Copia Remota (RCP) original, en el que se basa, carecía por completo de cifrado. SCP toma la semántica de copia simple de RCP y le añade la autenticación y el cifrado de SSH, de modo que ningún usuario de la red puede leer ni modificar un archivo en tránsito.

Internamente, una transferencia SCP se ejecuta en dos direcciones posibles una vez que el túnel SSH está activo. El modo de sumidero envía archivos del host local al host remoto; el modo de origen descarga archivos del host remoto al host local. El modo que se ejecuta depende completamente de cómo se escribe el comando, no de ninguna opción específica: SCP simplemente inicia la transferencia correspondiente. scp El proceso se ejecuta en el extremo remoto y transmite los datos del archivo a través del canal SSH.

La estructura básica de comandos es:

scp [opciones] origen destino

Para enviar un archivo local a un host remoto:

scp file.txt user@remote_host:/home/user/

Para descargar ese mismo archivo de nuevo al directorio local actual:

scp user@remote_host:/home/user/file.txt .

Ese punto final es importante: le indica a SCP que escriba el archivo en el directorio desde donde se ejecuta el comando. -r Copiar un directorio completo de forma recursiva. Para la autenticación, el inicio de sesión con contraseña funciona, pero la autenticación con clave SSH es el estándar para cualquier proceso automatizado o repetitivo:

scp -i ~/.ssh/id_rsa file.txt user@remote_host:/home/user/

Otras banderas que vale la pena conocer: -v para obtener información detallada cuando una conexión no funciona correctamente, -P para establecer un puerto SSH distinto al predeterminado y -p para conservar las fechas de modificación de los archivos y los permisos en la copia. El error más común es olvidar los dos puntos en la ruta remota, ya que sin ellos SCP trata todo el argumento como una ruta local en lugar de una remota.

SCP vs. SFTP vs. Rsync sobre SSH: ¿Cómo se comparan?

Las tres herramientas transfieren archivos a través de un canal SSH cifrado, pero lo hacen mediante protocolos muy diferentes, y esa diferencia es precisamente la que genera sus deficiencias de seguridad y fiabilidad. SFTP surgió de la misma necesidad que abordó SCP: consulte nuestro análisis del Protocolo de Transferencia Segura de Archivos (SFTP) y sus ventajas para conocer más a fondo este protocolo.

El protocolo scp/rcp heredado funciona teniendo el local scp El cliente invoca un remoto scp proceso con indicadores no documentados (-t para fregadero, -f para origen), luego pasando rutas de archivo que el shell remoto interpreta parcialmente, incluyendo expansión de comodines. Esa participación del shell es la raíz de los fallos más conocidos de SCP. SFTP reemplaza esto por completo con un protocolo de solicitud-respuesta basado en paquetes diseñado específicamente: el cliente solicita operaciones discretas (abrir, leer, escribir, estado, renombrar) y el servidor responde, sin que intervenga la construcción de comandos de shell en ningún momento. Rsync-over-SSH adopta un tercer enfoque, utilizando SSH puramente como transporte seguro mientras que el propio protocolo de rsync maneja la comparación y transferencia reales, incluyendo codificación delta para que solo las partes modificadas de un archivo se muevan a través de la red.

Capacidad	SCP	SFTP	Rsync a través de SSH
Modelo de transferencia	Empuje/tracción basado en carcasa	Subsistema de solicitud-respuesta	Sincronización delta a través del transporte SSH
Reanudar transferencia interrumpida	No	Sí, admite archivos parciales.	Sí, construido para ello.
Sincronización de directorios / copia incremental	No, siempre copia completa del archivo	Limitado, por sesión	Sí, fuerza nativa
Navegación remota interactiva	No	Sí (ls, cd, rm en sesión)	No
Construcción de comandos de shell en el lado remoto	Sí, solo protocolo heredado	No	No (protocolo rsync, no shell)
Valor predeterminado en OpenSSH 9.0+	scp ahora utiliza SFTP internamente.	Sí:	No aplica, herramienta separada
Mejor ajuste	Copias rápidas y automatizadas en hosts confiables y actualizados.	Transferencia segura de archivos de uso general, automatización y registro de cumplimiento.	Grandes conjuntos de datos, replicación, sincronizaciones repetidas, enlaces poco fiables

En la práctica, la mayoría de los equipos deberían usar SFTP por defecto para cualquier cosa que vaya más allá de una sola copia puntual, y recurrir a rsync cuando la carga de trabajo se trate realmente de sincronización en lugar de una entrega única.

¿Cuáles son las limitaciones de seguridad conocidas de SCP?

El protocolo SCP/RCP heredado de SCP tiene dos vulnerabilidades divulgadas y rastreadas por CVE que los equipos de seguridad deberían conocer antes de estandarizarlo para nuevas implementaciones.

CVE-2020-15778 es una vulnerabilidad de inyección de comandos en el cliente scp a través de OpenSSH 8.3p1 (puntuación CVSS 3.1: 7.4, alta). Un argumento de destino que contiene caracteres de acento grave puede interpretarse y ejecutarse como un comando de shell en el lado remoto, ya que el protocolo heredado pasa los nombres de archivo a través del shell remoto en lugar de tratarlos como datos puros. Los responsables del mantenimiento de OpenSSH han declarado que intencionalmente no validan lo que denominan "transferencias de argumentos anómalas", argumentando que una validación más estricta podría romper scripts y flujos de trabajo de larga data. Esta postura es precisamente la razón por la que la vulnerabilidad permaneció sin una solución completa en el proyecto principal durante tanto tiempo, incluso cuando varias distribuciones derivadas lanzaron sus propias mitigaciones.

CVE-2026-35385 es un problema de escalada de privilegios más reciente que afecta a OpenSSH antes de la versión 10.3 (puntuación CVSS 3.1: 7.5, alta). Cuando se descarga un archivo con scp como raíz utilizando el protocolo heredado (el -O bandera) sin pasar también -p Para preservar el modo de archivo, el archivo resultante puede instalarse con permisos setuid o setgid, un resultado que la mayoría de los administradores no esperarían ni desearían. Esto representa una verdadera vía de escalada de privilegios en cualquier sistema donde el usuario root extraiga archivos habitualmente mediante SCP. La solución se incluyó en OpenSSH 10.3p1.

Ambos problemas se remontan a la misma causa raíz: el protocolo heredado scp/rcp confía en el lado remoto más de lo que debería un protocolo de transferencia moderno, y nunca fue diseñado teniendo en cuenta el modelo de amenazas actual. Es precisamente por eso que, a partir de OpenSSH 9.0 en 2022, el scp El comando cambió para usar el protocolo SFTP internamente por defecto. Ejecutando scp en una compilación actual de OpenSSH ya no habla el protocolo heredado vulnerable a menos que alguien lo fuerce explícitamente con el -O Red Hat fue más allá en RHEL 9, declarando formalmente obsoleto el protocolo heredado scp/rcp y marcándolo para su eventual eliminación, precisamente porque, como lo expresó Red Hat, el protocolo "conlleva múltiples riesgos y problemas de seguridad que no tienen soluciones sencillas" ya que "es inherentemente confiable para sesiones autenticadas".

La conclusión práctica: si sus sistemas están en una versión actual de OpenSSH, escriba scp Hoy probablemente ya se ejecuta a través de SFTP. Si todavía estás forzando -O Para garantizar la compatibilidad con sistemas antiguos o al ejecutar versiones de OpenSSH sin parchear, se está expuesto a ambas vulnerabilidades CVE mencionadas anteriormente.

¿Quién debería ser el propietario de las claves SSH que respaldan las transferencias SCP?

La seguridad de SCP depende de la clave SSH que la autentica y, a diferencia de un certificado TLS, una clave SSH no tiene fecha de caducidad predefinida. La propiedad debe asignarse explícitamente, o las claves simplemente se acumulan. En la práctica, la propiedad del ciclo de vida se divide entre tres roles:

• Equipo de seguridad o de identidad: Es propietaria de la política de emisión, los tipos y longitudes de claves aprobadas, y el inventario central de todas las claves en uso, incluidas las claves integradas en scripts y pipelines de CI/CD.
• Propietarios del sistema o de la aplicación: poseer el authorized_keys Las entradas se alojan en sus propios servidores y son responsables de eliminar el acceso cuando finaliza un usuario, un servicio o un contrato.
• Equipos de plataforma o DevOps: Poseen claves de transferencia de archivos automatizadas utilizadas por los procesos de compilación, las tareas de copia de seguridad y las integraciones, y son responsables de limitar el alcance de cada clave al único host y comando que realmente necesita.

Si no hay una persona claramente responsable de alguno de estos roles, las claves SSH se asignan por defecto a quien las generó, lo que provoca que las organizaciones acaben con claves que nadie recuerda haber concedido y que nadie está dispuesto a eliminar.

¿Cuándo se deben rotar las claves SSH de las que depende SCP?

La rotación debe activarse mediante eventos, no solo mediante un calendario, aunque un respaldo basado en el calendario sigue siendo importante. Los desencadenantes que deberían forzar la rotación de la clave SSH para cualquier cuenta utilizada con SCP o SFTP incluyen:

1. Se establece una antigüedad máxima fija para las claves, generalmente de 90 a 180 días para las claves de usuario interactivas y menor para las cuentas de servicio con altos privilegios.
2. La baja de un empleado o contratista, o un cambio de funciones que elimina la necesidad de acceso a un host determinado.
3. Sospecha o confirmación de una vulneración de una estación de trabajo, un servidor de compilación o el propio material clave.
4. Una vulnerabilidad revelada en el cliente, servidor o biblioteca de generación de claves SSH en uso, como la CVE-2026-35385 mencionada anteriormente.
5. La migración de un sistema a una nueva infraestructura es un momento idóneo para volver a emitir claves en lugar de copiarlas.
6. Durante una revisión de acceso, se descubrió una clave que ya no corresponde a un propietario o propósito documentado.

La rotación manual en docenas o cientos de hosts es donde la mayoría de las organizaciones se rinden discretamente, lo cual es el verdadero argumento a favor de la gestión centralizada de claves SSH en lugar de una política de rotación más estricta sobre el papel.

¿Qué política de acceso debería regir los permisos de transferencia de archivos?

El acceso a la transferencia de archivos debe seguir la misma disciplina de privilegios mínimos que cualquier otro acceso de producción, con algunos controles específicos de SCP y SFTP añadidos:

• Deshabilitar la autenticación por contraseña para cuentas compatibles con SCP/SFTP y requieren autenticación basada en claves o certificados.
• Restringir por usuario y grupo con AllowUsers or AllowGroups directivas y por rango de IP de origen donde las transferencias solo se originan desde redes conocidas.
• Chroot y restringir las cuentas que solo utilizan SFTP utilizando OpenSSH ChrootDirectory y ForceCommand internal-sftpPor lo tanto, una cuenta de transferencia de archivos nunca puede abrir una consola interactiva.
• Limitar el alcance de las claves de la cuenta de servicio con command= restricción en authorized_keys Por lo tanto, una clave de automatización puede ejecutar exactamente un comando de transferencia en una sola ruta, y nada más.
• Se requiere aprobación para el nuevo acceso. en lugar de permitir la adición de claves de autoservicio a los hosts de producción, y limitar el tiempo de acceso a cualquier excepción.

Estos controles son más importantes que la elección entre SCP y SFTP en sí. Una cuenta SCP bien definida en un servidor reforzado y actualizado es más segura que una cuenta SFTP sin restricciones con una clave compartida y sin registro de actividad.

¿Cómo se genera la evidencia de auditoría para las transferencias de archivos?

Tanto los auditores como los equipos de respuesta a incidentes necesitan lo mismo: un registro de quién transfirió qué, desde dónde o hacia dónde, y cuándo. Esa evidencia proviene de algunos controles concretos:

• Establecer LogLevel VERBOSE En los servidores SSH que gestionan transferencias de archivos, los eventos de autenticación incluyen la huella digital de la clave específica utilizada, no solo el nombre de usuario.
• Habilita el registro del subsistema SFTP, que registra las operaciones individuales de archivos (abrir, leer, escribir, renombrar, eliminar) de una manera que el modelo basado en shell de SCP no puede igualar.
• Envíe los registros SSH y SFTP a un almacén de registros centralizado e inviolable o a un SIEM, con un período de retención que cumpla con sus obligaciones de cumplimiento (generalmente un año o más según PCI DSS y SOC 2).
• Realizar revisiones de acceso periódicas que concilien cada authorized_keys Entrada contra un propietario documentado y justificación comercial.
• Asigne el registro de transferencia de archivos y los controles de inventario de claves directamente a las familias de controles pertinentes en marcos como ISO/IEC 27001, SOC 2 y PCI DSS, de modo que la misma evidencia sirva tanto para fines de seguridad como de auditoría.

Esta es el área donde SFTP tiene una ventaja estructural sobre SCP: debido a que cada operación es una solicitud discreta y registrada en lugar de un comando de shell, los registros de auditoría de SFTP son mucho más fáciles de reconstruir a posteriori.

¿Cómo es un flujo de trabajo para la implementación de transferencias seguras de archivos?

Ya sea que optes por SCP, SFTP o rsync, el proceso de implementación de una nueva ruta de transferencia segura de archivos debe seguir la misma secuencia:

1. Confirme la versión de OpenSSH. en cada host involucrado, y parchear al menos a 10.3p1 para cerrar CVE-2026-35385, o a una versión igual o superior a 9.0, por lo que scp Utiliza por defecto el protocolo SFTP.
2. Elige la herramienta adecuada para la carga de trabajo: SFTP para transferencias automatizadas y de propósito general, rsync para sincronizaciones grandes o repetidas, y SCP únicamente para copias rápidas, manuales y puntuales en hosts de confianza y que usted controla.
3. Generar claves SSH con ámbito por sistema o servicio, utilizando tipos de clave modernos (se prefiere Ed25519, RSA de 3072 bits o superior donde no se admita Ed25519), nunca una única clave compartida entre múltiples integraciones.
4. Restringir el acceso del lado del servidor con AllowUsers/AllowGroups, SFTP con chroot cuando corresponda, y command= Restricciones en las claves de automatización.
5. Habilitar el registro detallado y enviarlo a un almacenamiento centralizado antes de que se ejecuten las primeras transferencias de producción, no después de un incidente.
6. Calendario de propiedad y rotación de documentos para cada clave creada, vinculada a los activadores anteriores.
7. Pruebe la ruta de fallo: Confirme qué sucede en caso de una transferencia interrumpida, una clave revocada o un permiso mal configurado, antes de confiar en la configuración en producción.

¿En qué se diferencian la compatibilidad con SCP y SFTP entre plataformas?

Linux, macOS y la mayoría de los sistemas Unix vienen con OpenSSH. scp y sftp Los clientes y servidores vienen integrados, por lo que la compatibilidad es constante siempre que la versión de OpenSSH esté actualizada. Windows solucionó ese problema a partir de la versión 1809 de Windows 10 (lanzada en 2018), cuando Microsoft integró el cliente y el servidor de OpenSSH directamente en el sistema operativo, lo que permitió que ambos comandos estuvieran disponibles de forma nativa desde PowerShell o la Terminal de Windows sin necesidad de herramientas de terceros como PuTTY.

Las distribuciones de Enterprise Linux han comenzado a alejar activamente a los usuarios del protocolo scp heredado. RHEL 9 declaró obsoleto el protocolo scp/rcp heredado, estableciendo por defecto las nuevas transferencias al comportamiento basado en SFTP introducido en OpenSSH 9.0 y advirtiendo que la ruta heredada eventualmente se eliminará por completo. Esta obsolescencia pone de manifiesto un problema práctico que conviene planificar: SCP y SFTP manejan los enlaces simbólicos y las rutas expandidas con tilde de manera diferente, por lo que las transferencias entre un host moderno y uno heredado que dependen de ~ Los accesos directos pueden comportarse de forma inesperada. El uso de rutas absolutas evita este problema.

Para las organizaciones que utilizan diversas versiones de OpenSSH en entornos Linux, Windows y macOS, o dispositivos de red heredados con pilas SSH integradas antiguas, la solución práctica no consiste en seguir el comportamiento predeterminado de cada plataforma individualmente. La clave está en gestionar las claves SSH y la política de acceso de forma centralizada, de modo que el protocolo de transferencia predeterminado de cada host sea menos relevante.

¿Cómo debe responder ante unas credenciales de transferencia de archivos comprometidas?

Cuando se sospecha que una clave SSH utilizada para SCP o SFTP ha sido comprometida, la velocidad importa más que la perfección del proceso. Una secuencia de respuesta práctica:

1. Revocar inmediatamente. Retire la llave de cada authorized_keys archivarlo en el que aparece, o revocar el certificado SSH correspondiente si se emitió alguno.
2. Contienen el movimiento lateral. Compruebe si la misma clave o material de clave se ha reutilizado en otros hosts o servicios, y revoque también allí.
3. Conservar y revisar los registros. Recopile los registros SSH y SFTP que abarquen el período de exposición sospechoso para identificar qué información se accedió o se transfirió realmente.
4. Rotar las credenciales relacionadas. Cualquier clave generada en la misma estación de trabajo comprometida, o cualquier clave que un atacante pudiera haber tocado, debe considerarse sospechosa y cambiarse de clave.
5. Compruebe que haya acceso a la vegetación. Revise las claves de host y authorized_keys archivos para entradas que el propietario legítimo no agregó.
6. Notificar a las partes interesadas de acuerdo con su respuesta a incidentes y, cuando corresponda, con los requisitos de divulgación reglamentaria.
7. Realizar una revisión posterior al incidente. para identificar cómo se expuso la clave y subsanar esa deficiencia específica, ya sea una clave sin cifrar en el disco, una concesión de acceso demasiado amplia o una política de rotación inexistente.

Las organizaciones que pueden responder a la pregunta "¿qué clave, qué hosts, desde cuándo?" en cuestión de minutos tras recibir un informe son las que cuentan con un inventario real de claves SSH antes de que ocurra el incidente, no las que lo están creando durante el mismo.

Limitaciones

Más allá de los problemas de seguridad mencionados anteriormente, SCP presenta limitaciones funcionales que lo hacen inadecuado para cualquier tarea que vaya más allá de transferencias rápidas y manuales. No puede reanudar una transferencia interrumpida: si una copia falla a mitad de camino, debido a una pérdida de conexión o un fallo en la red, toda la transferencia se reinicia desde cero. No cuenta con sincronización incremental, por lo que modificar una línea en un archivo grande implica copiar el archivo completo de nuevo. Además, al carecer de las optimizaciones de transferencia delta en las que se basan herramientas como rsync, SCP consume más recursos y ancho de banda para transferencias repetidas o a gran escala. Estas deficiencias, sumadas a las limitaciones de seguridad mencionadas, explican por qué SCP se recomienda reservar para copias ocasionales y puntuales, en lugar de para sistemas de transferencia de archivos en entornos de producción.

¿Qué recomendaría Encryption Consulting?

Para nuevas implementaciones, recomendamos a los equipos usar SFTP en lugar de SCP, y rsync en lugar de SSH para cualquier tarea que implique sincronización extensa o repetida. Sin embargo, la elección del protocolo rara vez es donde reside el verdadero riesgo. En casi todos los entornos SCP o SFTP que analizamos, la vulnerabilidad real se encuentra en las claves SSH no administradas: claves sin propietario documentado, sin un calendario de rotación y sin un registro de auditoría que vincule una transferencia con una persona o un servicio.

Esa es la brecha que SSH Secure está diseñado para cerrar. Ofrece un inventario centralizado de todas las claves SSH en su entorno, rotación automatizada vinculada a los activadores descritos anteriormente y aplicación de políticas para que las claves de transferencia de archivos permanezcan limitadas al host y comando específicos que necesitan. Para los equipos que también emiten y administran certificados TLS o de firma de código, la combinación con CertSecure Manager mantiene la visibilidad del ciclo de vida de los certificados y las claves en un solo lugar, en lugar de dispersa entre varias herramientas. Y cuando las claves privadas deben residir en un entorno seguro y validado según FIPS 140-3, en lugar de en disco, HSM-as-a-Service elimina por completo ese riesgo.

Si no está seguro de en qué situación se encuentra su organización actualmente, nuestro equipo de Servicios de Asesoramiento en Cifrado puede realizar una evaluación específica de su inventario de claves SSH y controles de acceso para la transferencia de archivos, y proporcionarle un plan de remediación priorizado, no solo una lista de hallazgos.

Conclusión

SCP aún tiene cabida para una copia rápida, manual y puntual entre dos hosts de confianza. Pero para cualquier tarea automatizada, repetida o sujeta a revisión de cumplimiento, SFTP es la opción mejor diseñada, y ya es lo que un sistema moderno utiliza. scp El comando se ejecuta de forma predeterminada. Rsync-over-SSH toma el control cuando la tarea consiste en sincronizar conjuntos de datos grandes o que cambian con frecuencia, en lugar de entregar un solo archivo.

Sin embargo, nada de eso importa mucho si las claves SSH que respaldan la transferencia no tienen propietario, ni calendario de rotación, ni registro de auditoría. Configurar correctamente el protocolo lleva una tarde. Lo que realmente garantiza la seguridad de las transferencias de archivos a lo largo del tiempo es la correcta gestión del ciclo de vida de las claves SSH, y es ahí donde la mayoría de las organizaciones aún tienen importantes deficiencias que subsanar.

Preguntas frecuentes

¿Seguirá siendo seguro usar SCP en 2026?
En una compilación actual y parcheada de OpenSSH, se ejecuta scp es razonablemente seguro porque ahora usa el protocolo SFTP por defecto, no el vulnerable protocolo heredado scp/rcp. El riesgo regresa si se fuerza el -O Indicador de compatibilidad, o si el host está ejecutando una versión de OpenSSH sin parchear afectada por CVE-2020-15778 o CVE-2026-35385.

¿Cuál es la diferencia real entre SCP y SFTP?
El protocolo heredado de SCP construye y ejecuta comandos de shell en el host remoto para copiar archivos. SFTP es un protocolo dedicado basado en paquetes, donde el cliente solicita operaciones de archivo específicas y el servidor responde, sin necesidad de construir comandos de shell remotos. Esta diferencia arquitectónica explica por qué SFTP admite la reanudación de transferencias, la navegación interactiva y un registro más preciso, mientras que SCP no.

¿Por qué era importante la vulnerabilidad CVE-2020-15778 para los usuarios de SCP?
Se demostró que una ruta de destino manipulada con fines maliciosos, utilizando caracteres de acento grave, podía ejecutarse como un comando en el servidor remoto durante una transferencia SCP con protocolo heredado. Los responsables del mantenimiento de OpenSSH optaron por no añadir una validación estricta, alegando problemas de compatibilidad, lo que explica en parte por qué la industria modificó el comportamiento predeterminado en lugar de solucionar la vulnerabilidad de forma permanente.

¿Debería cambiar todos mis flujos de trabajo de SCP a SFTP?
Para cualquier tarea automatizada, relacionada con el cumplimiento normativo o repetitiva, sí. Para una copia manual puntual entre dos hosts de confianza y actualizados, SCP, que se ejecuta sobre el protocolo SFTP predeterminado, funciona correctamente. En ambos casos, la prioridad principal es gestionar la clave SSH de la transferencia, no solo elegir el protocolo.

¿Rsync utiliza SSH de la misma manera que SCP?
Rsync suele funcionar sobre un protocolo SSH para el cifrado y la autenticación, al igual que SCP y SFTP, pero la lógica de comparación y transferencia de archivos se basa en el protocolo propio de rsync. Esto es lo que le confiere a rsync la eficiencia de la transferencia diferencial y la capacidad de reanudar operaciones, características que SCP no ofrece.

Referencias

• Notas de la versión 9.0 de OpenSSH, OpenSSH.org
• CVE-2020-15778Base de datos nacional de vulnerabilidad
• Aviso CVE-2026-35385Base de datos de asesoramiento de GitHub
• Desuso de OpenSSH SCP en RHEL 9, Sombrero rojo
• Páginas del manual de OpenSSH (scp, sftp), OpenSSH.org