Gestión de claves SSH

Ser dueño de un servidor de correo debería significar ser dueño de su puerta. En un servidor de cripta.to, el acceso por shell (SSH) es independiente del inicio de sesión de su buzón, y usted decide quién tiene llave. Por defecto son dos partes — usted y nuestro equipo de soporte —, pero puede reducirlo a usted solo, en cualquier momento, desde el panel de control.

Este artículo explica exactamente quién puede iniciar sesión, cómo añadir su propia clave y cómo retirar nuestro acceso cuando quiera que la máquina responda únicamente ante usted.

Dos tipos de clave

Hay dos formas independientes de tener acceso por shell a su servidor:

  • La clave de soporte de cripta.to. Por defecto colocamos en la máquina nuestra propia clave de administración (remote-admin@cripta.to). Existe para que nuestro equipo pueda entrar a diagnosticar problemas y echar una mano cuando algo va mal. Está activa salvo que usted la desactive.
  • Sus propias claves. Puede autorizar sus claves públicas SSH para iniciar sesión como root. Son enteramente suyas; nosotros nunca vemos la mitad privada.

Ambas son independientes. Desactivar la nuestra no toca las suyas, y añadir las suyas no exige desactivar la nuestra. Usted elige la combinación con la que se sienta cómodo.

Añadir su propia clave

Desde el panel de control, abra la pantalla de claves SSH de un servidor en funcionamiento y pegue una clave pública SSH (el nombre es opcional). Queda autorizada para iniciar sesión como root. Conviene saber algunas cosas:

  • De su equipo solo sale la clave pública. La mitad privada se queda con usted. Quien le pida una clave privada está equivocado o tiene malas intenciones.
  • Los cambios se aplican en unos 15 minutos. Su servidor comprueba si hay novedades de forma periódica, no instantánea, así que dele unos minutos para que surtan efecto.
  • Puede eliminar una clave cuando quiera, y verá la huella digital de cada una para confirmar cuál es cuál.

Si todavía no tiene un par de claves, cripta.to dispone de un generador de claves SSH que crea uno localmente en su navegador: no se transmite nada. Una vez añadida su clave, consulte Conectarse a su servidor de correo por SSH para ver las instrucciones paso a paso en macOS, Windows y Linux.

Desactivar nuestro acceso

Cuando quiera que el servidor sea accesible para usted y para nadie más, desactive el acceso de soporte. Desde el panel de control, abra el menú de acciones del servidor () y elija Desactivar el acceso de soporte. Esto retira de la máquina la clave de administración de cripta.to, con lo que nuestro equipo ya no puede iniciar sesión. Como cualquier cambio de acceso, se aplica en la siguiente comprobación programada: hasta unos 15 minutos.

Puede volver a activarlo con un clic cuando quiera de nuevo nuestra ayuda. Es un interruptor, no una puerta de una sola dirección.

La única regla: añada antes su propia clave

Hay una consecuencia importante que conviene tener clara. El acceso de soporte y sus propias claves son las únicas dos vías de entrada. Si desactiva la nuestra y no ha añadido una clave propia, nadie podrá entrar por SSH al servidor, usted incluido.

Así que el orden seguro es siempre:

  1. Añada su propia clave SSH.
  2. Confirme que puede iniciar sesión con ella.
  3. Solo entonces, desactive el acceso de soporte.

En un servidor BYO (asistido) — uno que funciona en su propia cuenta de alojamiento — no nos limitamos a avisarle: no retiramos nuestra clave hasta que haya demostrado que puede entrar. Cuando elige Desactivar el acceso de soporte, el panel de control le lleva antes a verificarlo. Usted añade su clave, nosotros dejamos un token de un solo uso en el servidor y usted nos lo lee de vuelta por SSH para demostrar que el acceso funciona. Solo entonces se ejecuta la desactivación. Es la misma comprobación que hacemos antes de entregarle un servidor cuando cancela, y existe porque, en una máquina que por lo demás no controlamos, retirar nuestra clave sin un acceso que funcione es irreversible.

En un servidor gestionado (en la cuenta de alojamiento de cripta.to), el panel de control le avisa pero le deja continuar, porque quedarse fuera siempre tiene arreglo: basta con volver a activar el acceso de soporte desde el panel para restaurar una vía de entrada. Si en un servidor asistido desactiva la nuestra sin una clave propia y aun así consigue perder el acceso, la consola de su proveedor de alojamiento es el último recurso.

Perder su única clave en un servidor que ya tiene el acceso de soporte desactivado es el único estado realmente irrecuperable: trate su clave privada en consecuencia, manténgala respaldada y protéjala con una frase de contraseña.

Por qué está construido así

El acceso de soporte viene activado por defecto porque la mayoría de la gente quiere tener ayuda disponible cuando un servidor de correo se porta mal, y desactivarlo por defecto dejaría tirado a cualquiera que se topase con un problema el primer día. Pero es suyo y puede revocarlo, precisamente porque «usted es dueño del servidor» debería ser literalmente cierto.

El estado final es sencillo y honesto: la lista de quién puede iniciar sesión contiene exactamente las claves que usted ha decidido. Conserve la nuestra como red de seguridad, o desactívela y quédese usted con la única llave. En cualquier caso, la puerta es suya.

  • #seguridad
  • #ssh
  • #propiedad