Clave pública SSH

¿Qué es una clave pública SSH en el mundo cripto?

Una clave pública SSH es la parte compartible de un par de claves SSH. Permite que un servidor verifique que un usuario posee la clave privada correspondiente antes de concederle acceso remoto.

En el ámbito de las criptomonedas, las claves públicas SSH son importantes porque los operadores de nodos, validadores y minería, así como los ingenieros de infraestructura y desarrolladores, suelen utilizar SSH para acceder a los servidores que ejecutan software blockchain.

SSH significa Secure Shell, un protocolo que se utiliza para iniciar sesión de forma segura en remoto, ejecutar comandos, transferir archivos y administrar servidores.

La documentación oficial de GitHub sobre SSH explica que SSH proporciona un canal seguro a través de una red no segura.

Una clave pública SSH no es lo mismo que una clave pública de una cartera, una dirección blockchain, una frase de recuperación o una clave de firma de validador.

Es una credencial de control de acceso para ordenadores y servidores, no una clave para gastar criptoactivos on-chain.

Por lo general, una clave pública puede compartirse de forma segura, ya que no revela la clave privada.

La clave privada correspondiente debe mantenerse en secreto porque demuestra la identidad del usuario durante la autenticación SSH.

La documentación oficial de Microsoft sobre la autenticación de OpenSSH basada en claves explica que la clave pública se instala en el servidor SSH y puede compartirse sin poner en peligro la clave privada.

En pocas palabras, una clave pública SSH es un identificador de inicio de sesión en servidores que se puede compartir y que ayuda a los operadores de infraestructura cripto a acceder a máquinas sin depender de contraseñas convencionales.

Por qué son importantes las claves públicas SSH en el mundo cripto

Las claves públicas SSH son importantes en el mundo cripto porque la infraestructura blockchain suele gestionarse mediante servidores Linux o servidores en la nube a los que se accede en remoto.

Un operador de validador puede usar SSH para actualizar un cliente de consenso, revisar registros, reiniciar un servicio, renovar certificados, supervisar el uso del disco o aplicar parches al sistema operativo.

Un operador de nodo completo puede usar SSH para administrar un cliente de ejecución, configurar la red, gestionar el almacenamiento y proteger los endpoints RPC.

Un operador de minería puede usar SSH para gestionar servidores de pools, herramientas de supervisión, controladores de firmware o infraestructura que respalde las operaciones de minería.

Un desarrollador puede usar claves SSH para desplegar código, conectarse a plataformas de control de versiones o acceder a infraestructura de producción.

La guía oficial de Ethereum para ejecutar un nodo explica que ejecutar nodos y validadores requiere software, clientes, sincronización, API y configuración operativa.

Como estos servidores pueden controlar infraestructura cripto de gran valor, una seguridad de acceso deficiente puede suponer un riesgo financiero grave.

Los inicios de sesión con contraseña pueden quedar expuestos a ataques de fuerza bruta, reutilización de contraseñas, phishing, malware o divulgaciones accidentales.

La autenticación SSH basada en claves reduce la dependencia de las contraseñas mediante criptografía asimétrica.

En las operaciones cripto, una clave pública SSH bien gestionada puede ser una parte básica, pero importante, de la seguridad de la infraestructura.

Cómo funciona la autenticación SSH con clave pública

La autenticación SSH con clave pública utiliza un par compuesto por una clave pública y una clave privada que se corresponden.

La clave pública se copia en la cuenta del servidor a la que se quiere permitir el acceso.

La clave privada permanece en el ordenador local, dispositivo de hardware o gestor de claves seguro del usuario.

Cuando el usuario se conecta al servidor, el cliente SSH demuestra que posee la clave privada sin enviársela al servidor.

El servidor comprueba esa prueba con la clave pública almacenada.

Si la prueba es válida y los permisos de la cuenta son correctos, el servidor permite el inicio de sesión.

Si la clave privada no se corresponde con la clave pública almacenada, la autenticación falla.

La documentación de OpenSSH de Microsoft explica que, durante la autenticación basada en claves, el servidor SSH y el cliente comparan la clave pública del servidor con la clave privada del cliente.

Este modelo es eficaz porque la clave privada no necesita circular por la red.

También puede ser peligroso si roban la clave privada, ya que el atacante podría iniciar sesión en todos los sistemas que autoricen la clave pública correspondiente.

Clave pública frente a clave privada

Una clave pública SSH y una clave privada SSH se crean juntas como un par.

La clave pública está pensada para copiarse en servidores, cuentas de plataformas de alojamiento de código y otros sistemas que deban reconocer al usuario.

La clave privada debe permanecer en secreto en el dispositivo del usuario o en un almacenamiento seguro de claves.

El manual oficial de ssh-keygen de OpenBSD explica que ssh-keygen crea claves de autenticación para SSH y guarda la clave pública con el mismo nombre que la clave privada, seguido de la extensión .pub.

Si alguien obtiene únicamente la clave pública, por lo general no podrá iniciar sesión como el usuario.

Si alguien obtiene la clave privada y la frase de contraseña necesaria, podría iniciar sesión como el usuario en los servidores que confíen en la clave pública.

Por eso se puede compartir la clave pública, mientras que la clave privada debe protegerse como un secreto de gran valor.

En la infraestructura cripto, el robo de una clave privada SSH puede provocar la vulneración de un servidor, interrupciones de un validador, modificaciones de configuración, instalación de malware o robo de archivos sensibles.

La clave pública es el marcador de identidad; la clave privada es la prueba.

No subas nunca una clave privada a un servidor, aplicación de chat, sistema de tickets, repositorio público o documento compartido.

Clave pública SSH frente a clave pública de una cartera cripto

Una clave pública SSH es distinta de la clave pública de una cartera cripto.

Una clave pública SSH se utiliza para autenticar el acceso a un servidor.

Una clave pública de una cartera se utiliza en la criptografía blockchain y está relacionada con las direcciones, las firmas y la titularidad de los activos.

Una clave pública SSH no recibe criptomonedas en una blockchain.

Por lo general, una clave pública de una cartera o una dirección derivada de ella no permite iniciar sesión en un servidor mediante SSH.

Ambos conceptos utilizan criptografía de clave pública, pero pertenecen a sistemas distintos.

Confundirlos puede provocar errores graves.

Un usuario no debe pegar la frase de recuperación de una cartera en una herramienta SSH.

Un usuario no debe utilizar una clave de firma de validador como clave SSH habitual.

Las claves de acceso a la infraestructura deben mantenerse separadas de las claves de las carteras, de los validadores, de retirada y de las claves API.

Clave pública SSH frente a dirección blockchain

Una clave pública SSH no es una dirección blockchain.

Por lo general, una dirección blockchain es una representación más corta derivada de una clave pública de una cartera o de la estructura de una cuenta.

Una clave pública SSH suele ser una cadena de texto más larga que el software SSH utiliza para autenticar a un usuario o un host.

Se puede compartir una dirección blockchain para que otras personas envíen tokens o consulten la actividad on-chain.

Se puede compartir una clave pública SSH para que el administrador de un servidor conceda acceso de inicio de sesión.

Compartir una dirección blockchain puede afectar a la privacidad financiera porque otras personas pueden consultar el historial on-chain público.

Compartir una clave pública SSH suele revelar menos información financiera, aunque puede permitir identificar a una persona o un dispositivo en los registros de infraestructura.

Una dirección blockchain indica dónde se pueden enviar los activos.

Una clave pública SSH indica qué clave privada puede acceder a una cuenta de servidor.

Ambas deben manejarse con cuidado, pero se utilizan para establecer relaciones de confianza distintas.

Aspecto de una clave pública SSH

Una clave pública SSH suele ser una sola línea de texto.

A menudo empieza con un tipo de clave, como ssh-ed25519, ecdsa-sha2-nistp256 o ssh-rsa.

La parte central es un valor de clave codificado y largo.

Al final puede incluir un comentario, como el nombre de usuario, una dirección de correo electrónico, el nombre del dispositivo o una etiqueta de creación.

El comentario ayuda a las personas a identificar la clave más adelante.

El comentario, por sí solo, no proporciona seguridad.

Un archivo de clave pública suele terminar en .pub.

El archivo de la clave privada correspondiente puede tener un nombre similar, pero sin la extensión .pub.

El manual de ssh-keygen de OpenBSD explica que la clave pública se guarda en un archivo con el mismo nombre que la clave privada, seguido del sufijo .pub.

Los usuarios deben asegurarse siempre de copiar el archivo .pub y no el archivo de la clave privada.

authorized_keys

El archivo authorized_keys es el archivo habitual del servidor que contiene la lista de claves públicas SSH autorizadas para iniciar sesión como un usuario concreto.

En muchos sistemas similares a Unix, este archivo está en el directorio .ssh del usuario.

Al añadir una clave pública a authorized_keys, la clave privada correspondiente puede autenticar el acceso a esa cuenta, siempre que lo permitan los permisos y la configuración del servidor SSH.

Este archivo es muy importante porque determina quién puede iniciar sesión mediante autenticación basada en claves.

Una clave antigua olvidada en authorized_keys puede convertirse en una puerta trasera oculta.

Copiar una clave pública en la cuenta de usuario equivocada puede conceder acceso con permisos incorrectos.

El archivo authorized_keys de una cuenta root es especialmente sensible porque el acceso root permite controlar todo el servidor.

Los operadores de nodos cripto deben revisar authorized_keys periódicamente y eliminar las claves que ya no necesiten.

Siempre que sea posible, el acceso debe concederse a cuentas de usuario identificadas con sudo, en vez de permitir el inicio de sesión directo como root.

Una buena gestión de authorized_keys ayuda a limitar el alcance de los daños si roban una clave privada.

ssh-keygen

ssh-keygen es la herramienta estándar de OpenSSH para crear y gestionar pares de claves SSH.

El manual de ssh-keygen de OpenBSD indica que ssh-keygen genera, gestiona y convierte claves de autenticación para SSH.

El mismo manual señala que, si no se especifica ningún tipo de clave, ssh-keygen genera por defecto una clave Ed25519.

Ed25519 se utiliza habitualmente hoy en día porque es moderno, compacto y eficiente para muchos flujos de trabajo de autenticación SSH.

Algunos sistemas siguen admitiendo claves RSA o ECDSA por motivos de compatibilidad.

En función del entorno y las políticas, puede desaconsejarse el uso de algoritmos antiguos o claves cortas.

Los usuarios deben seguir las recomendaciones vigentes del sistema operativo y de OpenSSH al elegir los tipos de clave.

Al crear una clave, conviene incluir un comentario claro para poder identificarla más adelante.

En la infraestructura cripto, comentarios como validator-admin-laptop-2026 o node-maintenance-key pueden facilitar las auditorías.

Una clave que no se pueda identificar no debería seguir siendo de confianza en servidores de producción.

Frases de contraseña

Una frase de contraseña cifra o protege la clave privada cuando está almacenada.

El manual de ssh-keygen de OpenBSD explica que ssh-keygen solicita una frase de contraseña al generar claves y que no se puede recuperar una frase de contraseña perdida.

Una frase de contraseña añade protección si se copia o roba el archivo de la clave privada de un portátil.

Sin una frase de contraseña, el atacante podría utilizar inmediatamente una clave privada robada.

Con una frase de contraseña, el atacante también tendría que adivinarla o robarla.

Esto no vuelve seguros los sistemas vulnerables, pero sí mejora la protección.

Por lo general, los operadores de infraestructura cripto deberían proteger las claves privadas SSH importantes con frases de contraseña robustas.

Los sistemas automatizados pueden requerir un tratamiento especial, ya que las solicitudes de frases de contraseña sin supervisión pueden interrumpir los scripts.

Para la automatización, los equipos deberían utilizar, cuando proceda, claves restringidas, permisos limitados, restricciones de comandos, certificados de corta duración o herramientas seguras de gestión de secretos.

Una frase de contraseña no sustituye a las revisiones de acceso, el principio de mínimo privilegio ni la rotación de claves.

ssh-agent

ssh-agent es una herramienta que puede mantener en memoria claves privadas descifradas para que los usuarios no tengan que introducir una frase de contraseña en cada conexión.

La documentación de OpenSSH de Microsoft menciona ssh-agent y ssh-add como herramientas para almacenar claves privadas de forma segura en flujos de trabajo de autenticación basada en claves.

ssh-agent resulta práctico, pero también implica riesgos si el reenvío del agente o la seguridad del ordenador local son deficientes.

El reenvío del agente permite conectarse a otro servidor a través de un servidor intermedio utilizando el agente local.

Puede ser útil para los administradores, pero también puede exponer oportunidades de autenticación si el servidor intermedio se ve comprometido.

Los operadores cripto deberían evitar el reenvío innecesario del agente en la infraestructura de validadores y nodos.

Si es necesario reenviar el agente, solo debería hacerse en hosts de confianza y durante sesiones limitadas.

Una opción que suele ser mejor es conectarse directamente desde una estación de administración segura o utilizar un host bastión reforzado.

ssh-agent es útil, pero debe considerarse parte del perímetro de seguridad.

Si se compromete una estación de trabajo, pueden quedar comprometidas todas las identidades SSH cargadas en el agente.

Claves públicas SSH para nodos validadores

Los nodos validadores suelen necesitar acceso seguro al servidor porque sus operadores deben actualizar software, supervisar el tiempo de actividad, revisar registros y responder a incidentes.

Las claves públicas SSH ayudan a los validadores a evitar el inicio de sesión mediante contraseña en servidores que pueden ser objetivo de los atacantes.

Una persona que haga staking en solitario en Ethereum puede usar SSH para gestionar clientes de ejecución, clientes de consenso, clientes validadores, firewalls, agentes de supervisión y servicios del sistema.

La guía de Ethereum para ejecutar nodos explica que gestionar tu propio validador es la forma más trustless de contribuir a la red, pero requiere infraestructura y un depósito de validador.

Esa infraestructura debe protegerse cuidadosamente porque las interrupciones del validador pueden reducir las recompensas.

Un servidor validador comprometido puede provocar atestaciones omitidas, configuraciones incorrectas o interrupciones operativas.

El acceso SSH no suele permitir controlar directamente las credenciales de retirada si estas se almacenan de forma segura en otro lugar.

Sin embargo, un servidor comprometido puede seguir implicando riesgos graves por malware, robo de datos, cambios de configuración o descubrimiento de claves.

Los validadores deben mantener separadas las claves SSH de las claves de firma de validador y de las claves de retirada.

El acceso a la infraestructura nunca debe considerarse el mismo ámbito de seguridad que la custodia de activos.

Claves públicas SSH para nodos completos

Los nodos completos también se benefician de la autenticación SSH con clave pública.

Un nodo completo puede almacenar datos blockchain, exponer API locales, proporcionar servicios a carteras, validar transacciones o respaldar aplicaciones.

La guía de Ethereum para ejecutar nodos advierte de que, si se configuran incorrectamente, los endpoints RPC expuestos al público pueden quedar accesibles a través de redes locales y direcciones IP públicas.

El acceso SSH se utiliza a menudo para gestionar la configuración de estos nodos y las reglas del firewall.

Si un atacante obtiene acceso SSH a un nodo completo, puede modificar la configuración RPC, leer archivos de configuración, interrumpir el servicio o redirigir el tráfico.

Es posible que un nodo completo no almacene claves privadas de carteras, pero aun así puede ser sensible desde el punto de vista de la seguridad.

Por ejemplo, un nodo comprometido podría proporcionar datos incorrectos a un usuario, interrumpir una aplicación o revelar detalles de la red interna.

El acceso mediante claves públicas SSH debe limitarse a los administradores que lo necesiten.

Las claves antiguas deben eliminarse cuando los contratistas, empleados, dispositivos o scripts dejen de necesitar acceso.

Un nodo completo forma parte del modelo de confianza cripto, por lo que el control de acceso al servidor es importante.

Claves públicas SSH para desarrolladores cripto

Los desarrolladores cripto utilizan claves públicas SSH para alojar código, realizar despliegues, trabajar en entornos de prueba y administrar servidores.

Las plataformas Git suelen permitir añadir claves públicas SSH para poder subir y descargar repositorios sin introducir una contraseña cada vez.

La guía oficial de GitHub para generar una clave SSH explica cómo generar una clave SSH nueva y añadirla a ssh-agent.

Esto es importante para los equipos cripto porque el código fuente, los scripts de despliegue y los repositorios de infraestructura pueden ser muy sensibles.

Una clave SSH de desarrollador comprometida puede exponer código de contratos inteligentes, pipelines de despliegue, sistemas de compilación o servidores de producción.

Los desarrolladores deberían utilizar claves SSH distintas para su trabajo personal, la infraestructura de la empresa, los sistemas de producción y los despliegues automatizados.

Deberían eliminar las claves antiguas de las plataformas de código cuando se sustituyan los dispositivos o un miembro abandone el equipo.

Deberían evitar subir claves privadas a los repositorios.

También deberían usar commits firmados u otros métodos de verificación cuando el proyecto requiera una mayor integridad del control de versiones.

Las claves SSH forman parte de la seguridad de la cadena de suministro de software, no solo facilitan el inicio de sesión en servidores.

Claves públicas SSH e infraestructura de minería

Las operaciones de minería suelen utilizar claves SSH para gestionar servidores, sistemas de supervisión, proxies, herramientas de firmware e infraestructura backend.

Aunque los dispositivos de minería utilicen sistemas de gestión independientes, los servidores que los respaldan pueden seguir dependiendo de SSH.

El robo de una clave privada SSH podría permitir a un atacante interrumpir las operaciones de minería o redirigir datos de configuración.

En la minería Proof of Work, el tiempo de inactividad puede traducirse en una pérdida directa de ingresos, ya que las máquinas siguen consumiendo energía o dejan de enviar trabajo útil.

Los operadores de minería deberían utilizar claves distintas para la supervisión, los despliegues, el acceso de emergencia y la automatización.

Deberían evitar utilizar una misma clave privada en todos los servidores de una flota de minería.

Si se compromete una clave utilizada en exceso, el alcance de los daños puede ser considerable.

El acceso debería seguir el principio de mínimo privilegio, es decir, cada clave solo debería permitir el acceso necesario para su función.

Puede que la infraestructura de minería no almacene fondos de carteras, pero aun así puede afectar a los ingresos y a la continuidad operativa.

Por tanto, la gestión de claves públicas SSH forma parte de la seguridad de las operaciones de minería.

Claves públicas SSH y servidores en la nube

Muchos nodos y validadores cripto se ejecutan en servidores privados virtuales, servidores físicos o infraestructura en la nube.

Los proveedores de servicios en la nube suelen pedir a los usuarios que suban una clave pública SSH al crear un servidor nuevo.

El proveedor instala esa clave pública para que el usuario pueda iniciar sesión de forma segura cuando se ponga en marcha el servidor.

Esto es más seguro que enviar una contraseña por correo electrónico o depender de una contraseña predeterminada.

Sin embargo, subir una clave pública no protege automáticamente todo el servidor.

La clave privada sigue teniendo que estar protegida.

El servidor sigue teniendo que recibir los parches necesarios.

Las reglas del firewall siguen teniendo que configurarse cuidadosamente.

Los puertos RPC, las API de validadores, los paneles de control y las interfaces de administración no deberían quedar expuestos salvo que el operador comprenda los riesgos.

Una clave pública SSH es una parte de la protección de un servidor en la nube, no todo el plan de seguridad.

Claves de host frente a claves de usuario

SSH utiliza tanto claves de usuario como claves de host.

Una clave de usuario autentica a la persona o al sistema que intenta iniciar sesión.

Una clave de host autentica el servidor ante el cliente.

Cuando un usuario se conecta a un servidor por primera vez, el cliente SSH puede preguntarle si confía en la huella de la clave de host del servidor.

Esta comprobación ayuda a prevenir los ataques de intermediario, en los que un atacante se hace pasar por el servidor.

La clave pública de usuario se añade a authorized_keys en el servidor.

Los clientes utilizan la clave pública de host para verificar la identidad del servidor y, tras aceptarla, suelen guardarla en known_hosts.

Los operadores cripto no deberían ignorar sin más las advertencias sobre claves de host.

Un cambio de clave de host puede ser inofensivo tras reconstruir un servidor, pero también podría indicar una interceptación o la sustitución del servidor.

Las claves de usuario controlan quién puede iniciar sesión, mientras que las claves de host ayudan a demostrar a qué servidor se está conectando el usuario.

Huella digital

Una huella digital SSH es una representación abreviada de una clave pública que se utiliza para verificarla.

Las huellas digitales facilitan la comparación de claves sin tener que leer una cadena larga de clave pública.

El manual de ssh-keygen de OpenBSD incluye opciones para mostrar las huellas digitales de las claves.

Al añadir una clave a un servidor, el usuario puede comparar su huella digital con una fuente de confianza para confirmar que instala la clave correcta.

Al conectarse a un servidor, el usuario puede comparar la huella digital de la clave de host con un valor fiable conocido.

Esto es importante para la infraestructura cripto, ya que una clave incorrecta puede conceder acceso a la persona equivocada o conectar al operador con el servidor equivocado.

Las huellas digitales resultan especialmente útiles en equipos en los que las claves se aprueban mediante tickets, sistemas de control de acceso o revisiones de seguridad.

El comentario de una clave pública se puede cambiar fácilmente, pero la huella digital se deriva de la propia clave.

Los operadores deberían basarse en las huellas digitales para verificar identidades, no solo en los comentarios.

Una buena verificación de huellas digitales reduce los errores al aprovisionar claves y responder a incidentes.

Rotación de claves

La rotación de claves consiste en sustituir pares de claves SSH antiguos por otros nuevos y eliminar las claves públicas antiguas de los sistemas autorizados.

La rotación es importante si se pierde un portátil, un empleado abandona la empresa, un contratista termina su trabajo, una clave puede haberse expuesto o un algoritmo queda obsoleto.

La guía de gestión de claves NIST SP 800-57 ofrece recomendaciones generales sobre la gestión de material criptográfico de claves y cuestiones relacionadas.

Los equipos cripto deberían planificar la rotación de claves antes de que se produzca una emergencia.

El equipo debería saber dónde está instalada cada clave pública.

El equipo debería saber quién es responsable de cada clave.

El equipo debería saber en qué servidores, repositorios y sistemas de despliegue confía cada clave.

Sin un inventario, las claves públicas SSH antiguas pueden seguir activas durante años.

Esto genera una superficie de ataque innecesaria.

Una buena rotación convierte las claves SSH en credenciales gestionadas, en lugar de archivos olvidados.

Inventario de claves

Un inventario de claves es un registro de claves públicas SSH, sus responsables, usos, servidores autorizados, fechas de creación y fechas de eliminación.

El informe NISTIR 7966 sobre la gestión del acceso SSH se centra en la gestión de claves de usuario SSH y explica que el acceso basado en SSH requiere procesos de aprovisionamiento, revocación y supervisión.

Esto es especialmente pertinente para las empresas cripto, los validadores y los equipos de infraestructura porque el acceso SSH puede tener muchos privilegios.

El inventario debería indicar quién puede acceder a cada servidor.

Debería explicar por qué existe ese acceso.

Debería mostrar cuándo debe caducar.

Debería registrar si la clave pertenece a una persona, un proceso de automatización, un pipeline de despliegue o una cuenta de emergencia.

Sin un inventario, nadie puede eliminar con seguridad las claves antiguas.

Si no se eliminan, las claves antiguas se convierten en accesos ocultos permanentes.

Una gestión sólida de las claves públicas SSH empieza por saber qué claves existen.

Mínimo privilegio

El principio de mínimo privilegio significa que cada clave SSH solo debe conceder el acceso necesario para su finalidad.

Una clave de supervisión no debería tener acceso root si solo necesita leer métricas.

Una clave de despliegue no debería poder retirar activos, modificar claves de validadores ni leer secretos que no guarden relación con su función.

La clave de un contratista debería caducar cuando termine el proyecto.

Siempre que sea posible, una clave de automatización debería limitarse al comando o directorio que necesita.

Utilizar una sola clave de administrador en todas partes resulta práctico, pero entraña un riesgo elevado.

Si se compromete esa clave privada, podrían quedar expuestos todos los servidores que confían en ella.

La infraestructura cripto debería tratar el acceso SSH como un sistema de control de permisos.

Los distintos roles deberían utilizar claves diferentes.

Los distintos entornos, como pruebas, preproducción y producción, deberían tener reglas de acceso distintas.

Clave pública SSH e inicio de sesión como root

El inicio de sesión como root concede acceso directo de administrador a un servidor.

El inicio de sesión SSH directo como root puede ser arriesgado porque, si lo consigue, el atacante obtiene de inmediato el control total.

Muchos operadores desactivan el inicio de sesión directo como root y utilizan una cuenta de usuario identificada con sudo.

Esto puede mejorar la trazabilidad porque permite asociar los comandos administrativos a una cuenta concreta.

También puede reducir el riesgo de ataques automatizados contra el usuario root.

En nodos cripto y servidores validadores, el acceso directo como root debe limitarse cuidadosamente.

Una cuenta de administrador identificada debería tener únicamente las claves públicas SSH necesarias para los operadores reales.

Durante las auditorías de los servidores deberían eliminarse las entradas antiguas de authorized_keys para root.

El acceso de emergencia debe documentarse y protegerse, no improvisarse.

El acceso root tiene suficiente poder para interrumpir la infraestructura blockchain, aunque no permita gastar directamente los fondos de una cartera.

Clave pública SSH e inicio de sesión con contraseña

La autenticación SSH con clave pública suele utilizarse para reducir o desactivar el inicio de sesión con contraseña.

La documentación de OpenSSH de Microsoft señala que la autenticación con nombre de usuario y contraseña puede ser vulnerable a intrusiones por fuerza bruta cuando los sistemas operan en distintos dominios o entornos en la nube.

Los servidores expuestos a Internet pueden recibir constantemente intentos automatizados de adivinar contraseñas.

La autenticación basada en claves puede dificultar estos ataques porque el atacante necesita la clave privada, no solo adivinar una contraseña.

Sin embargo, la autenticación basada en claves no es infalible.

Si se roba la clave privada, no está cifrada o se reutiliza en todas partes, el riesgo es grave.

Una configuración adecuada suele combinar claves SSH, la desactivación del inicio de sesión con contraseña, la prohibición del inicio de sesión directo como root, reglas de firewall, gestión de actualizaciones y supervisión.

Algunos equipos también utilizan VPN, hosts bastión, claves respaldadas por hardware o SSH basado en certificados.

La infraestructura cripto debe aplicar una defensa por capas porque los atacantes pueden intentar acceder tanto con contraseñas como con claves.

Desactivar el inicio de sesión con contraseña puede ser útil, pero sigue siendo esencial gestionar el ciclo de vida de las claves.

Claves SSH respaldadas por hardware

Las claves SSH respaldadas por hardware almacenan el material de la clave privada en un autenticador de hardware o dispositivo de seguridad.

Esto puede reducir la posibilidad de que el malware simplemente copie un archivo de clave privada de un portátil.

OpenSSH moderno admite tipos de clave de seguridad como ecdsa-sk y ed25519-sk en entornos compatibles con los autenticadores correspondientes.

El manual de ssh-keygen de OpenBSD incluye tipos de claves de seguridad entre las opciones de generación de claves admitidas.

Las claves SSH respaldadas por hardware pueden ser útiles para los administradores de infraestructura cripto porque el acceso a los servidores puede ser muy sensible.

También pueden requerir planificación operativa, ya que la pérdida de un dispositivo obliga a recuperarlo y sustituir la clave.

Los equipos deberían mantener procedimientos de acceso de emergencia que no dependan de la clave de hardware de una sola persona.

Las claves de hardware son más eficaces cuando se combinan con un buen inventario, la separación de roles y la eliminación de claves públicas antiguas.

No protegen frente a todos los ataques, como los comandos maliciosos ejecutados tras un inicio de sesión legítimo.

Lo mejor es entenderlas como un control sólido dentro de un sistema de seguridad más amplio.

Certificados SSH

Los certificados SSH son claves públicas SSH firmadas que permiten gestionar el acceso de forma más centralizada y limitarlo en el tiempo.

En lugar de copiar la clave pública de cada usuario a todos los servidores, un servidor puede confiar en una autoridad de certificación y aceptar los certificados de usuario que esta firme.

El manual de ssh-keygen de OpenBSD incluye compatibilidad con la firma de identidades de certificados mediante una clave de autoridad de certificación.

Los certificados SSH pueden ayudar a los equipos cripto más grandes a gestionar el acceso de forma más ordenada.

Permiten conceder acceso de corta duración a ingenieros, contratistas, personal de respuesta a emergencias o procesos automatizados.

Pueden reducir el problema de las entradas olvidadas en authorized_keys.

Es necesario proteger cuidadosamente la clave de la autoridad de certificación.

Si se compromete esa clave, los atacantes podrían emitir certificados de acceso de confianza.

Los equipos pequeños pueden utilizar archivos authorized_keys básicos, mientras que los grandes quizá se beneficien del acceso basado en certificados.

El diseño más adecuado depende del tamaño del equipo, la escala de la infraestructura y el grado de madurez de la seguridad.

Claves públicas SSH y automatización

La automatización suele utilizar claves SSH para despliegues, copias de seguridad, supervisión, transferencias de archivos y operaciones entre servidores.

El acceso SSH automatizado puede ser muy potente porque puede funcionar sin que una persona introduzca una frase de contraseña cada vez.

Por eso, las claves de automatización entrañan un riesgo elevado si no están restringidas.

Una clave de automatización no debería reutilizarse en tareas que no guarden relación entre sí.

Si solo necesita ejecutar un comando, no debería permitir el acceso a un shell interactivo.

No debería seguir activa cuando se retire el proceso de automatización.

Los equipos cripto deben extremar las precauciones con la automatización conectada a validadores, nodos, alertas de supervisión y scripts de despliegue.

Una clave de despliegue comprometida puede instalar software malicioso o modificar la configuración de muchas máquinas.

Una clave restringida puede limitar los daños si se compromete un componente.

La automatización hace que la gestión de claves sea más importante, no menos.

Buenas prácticas de seguridad para claves públicas SSH

Utiliza un tipo de clave moderno compatible con tu sistema operativo y tu infraestructura.

Cuando sea viable, protege las claves privadas con frases de contraseña robustas.

Utiliza claves diferentes para distintos roles, dispositivos y entornos.

Elimina las claves públicas antiguas de los archivos authorized_keys y de las cuentas de plataformas de alojamiento de código.

Desactiva el inicio de sesión con contraseña en los servidores expuestos a Internet cuando exista un plan de recuperación seguro basado en claves.

Evita iniciar sesión directamente como root por SSH, salvo que haya un motivo sólido y se apliquen controles adicionales.

Aplica el principio de mínimo privilegio a las claves de usuarios y de automatización.

Mantén un inventario de claves, responsables, finalidades y fechas de caducidad.

Verifica las huellas digitales de las claves de host en lugar de aceptar las advertencias sin comprobarlas.

No guardes nunca claves privadas en repositorios públicos, chats compartidos, capturas de pantalla o carpetas en la nube sin un cifrado robusto y control de acceso.

Errores habituales con las claves públicas SSH

Un error habitual es copiar la clave privada en lugar de la clave pública.

Otro es utilizar la misma clave SSH para todos los servidores y roles.

Un tercer error es dejar claves públicas antiguas en authorized_keys después de que una persona o un dispositivo deje de necesitar acceso.

Un cuarto error es no proteger con una frase de contraseña una clave privada importante almacenada en un portátil.

Un quinto error es activar el reenvío del agente en todas partes sin comprender el riesgo.

Un sexto error es confiar en solicitudes de verificación de claves de host desconocidas sin comprobar las huellas digitales.

Un séptimo error es conceder acceso completo al shell a claves de automatización que solo necesitan ejecutar un comando limitado.

Un octavo error es confundir las claves públicas SSH con las claves públicas de carteras cripto.

Un noveno error es guardar secretos de validadores, claves de carteras y claves SSH juntos en el mismo servidor mal protegido.

Un décimo error es suponer que una clave pública, por sí sola, basta para proteger un servidor blockchain de producción.

Ventajas de las claves públicas SSH

La primera ventaja de las claves públicas SSH es que ofrecen un inicio de sesión remoto más seguro que el acceso basado únicamente en contraseñas sencillas.

La segunda es que reducen la exposición a intentos de adivinar contraseñas mediante fuerza bruta.

La tercera es que facilitan el control de acceso en servidores que requieren administración periódica.

La cuarta es que son compatibles con los flujos de trabajo de desarrollo, los sistemas de control de versiones, las herramientas de despliegue y los servidores en la nube.

La quinta es que permiten utilizar frases de contraseña, agentes, claves de hardware o certificados para mejorar la gestión.

La sexta es que facilitan las auditorías cuando cada persona y cada rol tienen una clave distinta.

La séptima es que, si se gestionan correctamente, hacen más seguras las operaciones de infraestructura cripto.

Estas ventajas son mayores cuando las claves públicas se inventarían, revisan y rotan, y se eliminan cuando dejan de ser necesarias.

Crear una clave pública SSH es sencillo, pero gestionarla adecuadamente es una responsabilidad continua.

Para los equipos cripto, la ventaja no es solo la comodidad, sino también la reducción del riesgo operativo.

Riesgos y limitaciones de las claves públicas SSH

El primer riesgo es el robo de la clave privada.

Si un atacante roba una clave privada sin protección, la clave pública correspondiente puede convertirse en una vía de acceso a los servidores.

El segundo riesgo es la proliferación de claves.

Se produce cuando las claves públicas se copian en muchos sistemas y nadie sabe en cuáles son de confianza.

El tercer riesgo es el acceso obsoleto.

Se produce cuando las claves públicas antiguas siguen autorizadas después de que una persona, dispositivo o proceso de automatización deje de necesitar acceso.

El cuarto riesgo es el exceso de privilegios.

Una clave con acceso root puede causar muchos más daños que una clave limitada a una tarea concreta.

El quinto riesgo es la escasa seguridad de las estaciones de trabajo.

Un servidor seguro aún puede verse comprometido mediante el robo de una clave de un portátil de administrador infectado.

El sexto riesgo es que las personas confundan las claves SSH con las claves de carteras, las claves API y las claves de validadores.

Las claves públicas SSH son útiles, pero deben gestionarse como credenciales privilegiadas.

Cómo evaluar una configuración de claves públicas SSH

Empieza por confirmar que cada clave pública autorizada tiene un responsable conocido.

Después, confirma que cada clave tiene una finalidad clara.

Comprueba si cada clave sigue siendo necesaria.

Comprueba si la clave privada está protegida mediante una frase de contraseña, un dispositivo de hardware o un gestor seguro de claves.

Comprueba si la clave tiene más acceso a servidores del que necesita.

Comprueba si el inicio de sesión como root está desactivado o sometido a controles estrictos.

Comprueba si el inicio de sesión con contraseña está desactivado cuando proceda.

Comprueba si se verifican las huellas digitales de las claves de host y se investigan las advertencias de known_hosts.

Comprueba si se eliminan las claves antiguas cuando cambia el personal, se sustituyen dispositivos o se modifican los procesos de automatización.

Una configuración SSH adecuada permite explicar, auditar y revocar el acceso con rapidez.

Claves públicas SSH y respuesta a incidentes

Si una clave privada SSH puede haberse visto comprometida, debe eliminarse la clave pública correspondiente de todos los servidores y servicios que confíen en ella.

El usuario debería generar un par de claves nuevo en un dispositivo limpio.

Se deberían revisar los servidores afectados para detectar inicios de sesión no autorizados, archivos modificados, usuarios nuevos, archivos authorized_keys alterados, malware y servicios inesperados.

Los operadores de validadores y nodos también deberían comprobar la configuración del cliente, las reglas del firewall, la exposición RPC, las alertas de supervisión y los registros del servicio.

Si se compromete un servidor validador de producción, el operador debería valorar si pudieron quedar expuestas las claves de firma del validador, los archivos de protección contra slashing o el material relacionado con retiradas.

Una clave SSH comprometida no es solo un problema de inicio de sesión.

Puede convertirse en un incidente que afecte a toda la infraestructura.

Los equipos deberían disponer de un procedimiento escrito para revocar claves SSH antes de que se produzca una emergencia.

El inventario de claves agiliza la respuesta a incidentes porque permite saber dónde hay que eliminar la clave pública.

Cuanto antes se revoque una clave comprometida, menor será el posible periodo de exposición a daños.

Preguntas frecuentes

¿Qué es una clave pública SSH?

Una clave pública SSH es la parte compartible de un par de claves SSH que un servidor utiliza para verificar que el usuario posee la clave privada correspondiente.

¿Es seguro compartir una clave pública SSH?

Sí, por lo general es seguro compartir una clave pública SSH, pero la clave privada correspondiente debe mantenerse en secreto.

¿Es una clave pública SSH lo mismo que la clave pública de una cartera cripto?

No. Una clave pública SSH se utiliza para autenticar el acceso a un servidor, mientras que la clave pública de una cartera cripto se utiliza para generar firmas blockchain y direcciones.

¿Por qué utilizan claves públicas SSH los validadores cripto?

Los validadores cripto utilizan claves públicas SSH para acceder de forma segura a servidores remotos que ejecutan software de validadores, nodos, supervisión y mantenimiento.

¿Qué es authorized_keys?

authorized_keys es un archivo del servidor que contiene la lista de claves públicas SSH autorizadas para iniciar sesión en una cuenta de usuario concreta.

¿Qué ocurre si roban mi clave privada SSH?

Si roban tu clave privada SSH, un atacante podría iniciar sesión en los servidores donde esté autorizada la clave pública correspondiente, especialmente si la clave privada no tiene una frase de contraseña robusta ni protección de hardware.

¿Debería utilizar una sola clave SSH para todos mis servidores cripto?

No. Utilizar claves SSH diferentes para distintos roles, dispositivos y entornos reduce los daños si se compromete una de ellas.

¿Una clave pública SSH controla mis fondos cripto?

No. Una clave pública SSH no controla directamente los fondos cripto, pero puede controlar el acceso a servidores que respaldan la infraestructura cripto.

¿Puedo eliminar una clave pública SSH?

Sí. Al eliminar una clave pública SSH de authorized_keys o de una cuenta de servicio, se revoca el acceso de la clave privada correspondiente a ese sistema.

¿Cuál es el mejor tipo de clave SSH?

El tipo más adecuado depende del entorno, pero OpenSSH moderno suele admitir Ed25519 y opciones de claves de seguridad. Por motivos de compatibilidad, puede ser necesario utilizar otros tipos de clave admitidos.

Conclusión

Una clave pública SSH es una credencial de autenticación que se puede compartir y que se utiliza para conceder acceso a un servidor a quien posea la clave privada correspondiente.

En el mundo cripto, las claves públicas SSH son importantes porque los validadores, los nodos completos, la infraestructura de minería, los servidores en la nube, los pipelines de despliegue y los sistemas de desarrollo suelen depender del acceso SSH.

Una clave pública SSH no es una clave pública de una cartera, una dirección blockchain, una frase de recuperación, una clave de firma de validador ni una credencial de retirada.

Forma parte del control de acceso a la infraestructura, no de la titularidad directa de activos on-chain.

Sin embargo, una gestión deficiente de las claves SSH puede crear riesgos cripto graves, ya que un servidor comprometido puede interrumpir validadores, exponer configuraciones de nodos, alterar despliegues o debilitar los sistemas de supervisión.

Entre las buenas prácticas para las claves públicas SSH se incluyen proteger las claves privadas, utilizar frases de contraseña o claves respaldadas por hardware, limitar el acceso root, desactivar el inicio de sesión con contraseña cuando sea seguro, mantener un inventario de claves, rotarlas y eliminar los accesos antiguos.

Los equipos también deberían mantener separadas las claves de usuarios, las de automatización, las de validadores, las de carteras y las claves API.

La clave pública puede compartirse para configurar el acceso, pero la clave privada nunca debe compartirse ni subirse a ningún sitio.

Para los principiantes, una clave pública SSH se entiende mejor como una identidad pública para iniciar sesión en un servidor.

Para los operadores cripto avanzados, es una credencial privilegiada de infraestructura que debe gestionarse mediante políticas, supervisión, mínimo privilegio y respuesta a incidentes.

En el contexto del glosario cripto, SSH Public Key significa la mitad pública de un par de claves de autenticación SSH que se utiliza para autorizar el acceso remoto seguro a sistemas que pueden ejecutar o respaldar infraestructura blockchain.

La idea clave es que las claves públicas SSH mejoran la seguridad de la infraestructura cripto si se gestionan correctamente, pero pueden convertirse en vías de acceso peligrosas si roban las claves privadas, se olvidan claves públicas antiguas o los permisos son demasiado amplios.