Llaves SSH para Linux VPS: crear, instalar y probar acceso

Confirme el método de cuenta real, host y recuperación

Utilice esta lista de verificación para un Linux VPS que posee o está autorizado para administrar. Comience con el host, nombre de cuenta y puerto SSH realmente asignado a su servicio. No adivine un nombre de usuario de un nombre de distribución. Confirme cómo recuperaría el acceso si un cambio de autenticación falla, utilizando un método que su operador realmente ha puesto a disposición.

Mantenga una sesión autenticada existente abierta mientras prueba un nuevo método de inicio de sesión. Si aún no tiene acceso a la obra, resuelva primero los detalles de la conexión inicial. Un plan de hospedaje público o una orden de pago no es en sí mismo una cuenta de shell de trabajo; esperar los detalles de servicio reales antes de aplicar instrucciones del servidor.

Revisión de software y recursos Linux VPS

Crear la llave en el dispositivo utilizado para conectar

Ejecute el ssh-keygen en su propio dispositivo cliente, no dentro del remoto VPS. Para un cliente de OpenSSH que lo soporta, ssh-keygen -t ed25519 crea un par de teclas Ed25519 y se solicita una ubicación de archivo y contraseña. Elija un nuevo nombre de archivo si una clave existente ya está presente; no sobreescribir una clave que otro servidor todavía utiliza.

Protege la llave privada con una contraseña y almacenamiento seguro de dispositivos. Utilice el impulso interactivo en lugar de poner una contraseña en un comando que puede ser guardado en la historia de la concha. Realice un seguimiento del propósito clave y la huella dactilar de clave pública para que pueda identificar más adelante la entrada correcta al revisar o revocar el acceso.

Instalar la mitad pública para la cuenta de servidor prevista

La clave pública normalmente tiene el mismo nombre de archivo con .pub appended. Agregue esa clave pública a la ubicación de clave autorizada para la cuenta que utilizará en el VPS. Muchas instalaciones OpenSSH utilizan ~/.ssh/authorized_keys para la cuenta remota, pero la configuración eficaz del servidor puede especificar una ubicación diferente. Verifique la ubicación en lugar de asumir que cada sistema utiliza la misma política.

Cuando esté disponible, ssh-copy-id puede instalar una llave pública a través de una conexión autorizada existente. Una instalación manual debe preservar las teclas existentes y mantener cada clave pública en una línea. No reemplace todo el archivo con una única entrada nueva a menos que haya revisado deliberadamente cada soporte de acceso. La llave privada permanece en tu propio dispositivo.

Desplazar la tabla horizontalmente si es necesario.

Verifique el host y pruebe una conexión fresca

Compare la huella de host-key servidor con un valor de confianza obtenido a través de su operador u otro canal verificado antes de aceptar una nueva identidad de host. Si una huella dactilar previamente conocida cambia inesperadamente, investigue el cambio. Eliminar la entrada de los huéspedes conocidos del cliente y aceptar lo que aparece no establece que usted alcanzó el servidor correcto.

Abra una segunda terminal y conéctese con su cuenta real, host y elegido camino de tecla privada. La opción OpenSSH -i selecciona un archivo de identidad, y -p selecciona un puerto no predeterminado cuando se le ha asignado. Confirme la cuenta esperada después de iniciar sesión. Un mensaje de contraseña de clave privada desbloquea su llave local; es diferente de un aviso de contraseña de cuenta remota.

Diagnosticar el rechazo antes de cambiar la política de inicio de sesión

Si la clave es rechazada, compruebe que utilizó la cuenta correcta y que su clave pública coincide con la identidad privada seleccionada por el cliente. Revise la ubicación de archivo, propiedad y permisos autorizados. En una cuenta de OpenSSH típica, permisos restrictivos como 700 en .ssh y 600 en authorized_keys impiden que otros usuarios modifiquen los archivos de autenticación; la cuenta correcta debe poseerlos.

Inspeccione el diagnóstico del cliente y los registros de autenticación del servidor disponibles para usted. La política del servidor puede restringir los usuarios, tipos clave o combinaciones de autenticación. No amplíe los permisos para hacer un trabajo clave rechazado. Comparta un mensaje de error redactado al buscar ayuda, en lugar de una clave privada, contraseña o registro de diagnóstico sensible completo.

Cambiar la configuración de autenticación sólo después de que el acceso esté probado

Una clave de trabajo no cambia automáticamente la política de contraseña del servidor. Si tiene la intención de cambiar la configuración de autenticación, inspeccione la configuración principal de OpenSSH y los archivos incluidos que afectan a la cuenta. ContraseñaLa autenticación y la autenticación interactiva del teclado son ajustes separados, y una política de operador o bloque de Match puede cambiar el resultado efectivo.

Retrocede la configuración relevante y valide con el daemon instalado antes de aplicar cambios; sudo sshd -t es el cheque de sintaxis OpenSSH en sistemas donde se aplican ese comando y privilegio. Utilice el método de gestión de servicios documentado para su distribución. Mantenga la sesión original abierta y pruebe otra conexión clave nueva después del cambio antes de cerrarla.

Continuar con la lista de verificación de seguridad VPS

Gire el acceso y mantenga la recuperación independiente de un portátil

Dar a cada administrador su propia clave para que un cambio de acceso no requiera compartir un archivo privado. Al reemplazar un dispositivo, instale y pruebe primero la nueva clave pública, luego retire la vieja entrada de llave pública después de identificarla. Una contraseña perdida no es recuperable de la clave privada encriptada; crear un reemplazo a través de un método de acceso autorizado de trabajo.

Revisar las teclas cuando un miembro del equipo se va o se pierde un dispositivo. La eliminación de una entrada de clave pública impide futuros inicios de sesión clave a través de esa entrada, pero también revisa sesiones activas y otros métodos de acceso. Mantenga un procedimiento de recuperación aprobado con sus registros de servicio para que el acceso no dependa completamente del dispositivo que está reemplazando.

• La clave privada nunca ha sido subida o enviada a soporte.
• Una segunda conexión funciona con la cuenta e identidad prevista.
• La huella dactilar del host ha sido revisada a través de un canal de confianza.
• La recuperación y la revocación clave se documentan antes de los cambios de política.

Planifique respaldos independientes y recuperación · Validar un sitio web Nginx después de establecer acceso