Permitir que los usuarios regulares usen SSH usando una clave privada que no pueden leer

Digamos que tengo un conjunto de máquinas (llamadas aquí máquinas de los clientes) en las que solo una pequeña lista de personas (llamada personal de soporte) puede ingresar a SSH, utilizando solo una cuenta por máquina (la cuenta de acceso de soporte).

Se supone que el personal de soporte solo debe iniciar sesión en las máquinas de los clientes utilizando claves. Además, el personal de soporte puede evolucionar, por lo que alguien que deja el personal de soporte no puede iniciar sesión en ninguna máquina del cliente. Por lo tanto, el personal tiene prohibido leer las claves privadas utilizadas para iniciar sesión en las máquinas de los clientes. Además, está prohibido modificar el authorized_keysarchivo en las máquinas de los clientes.

Para darme cuenta de esa configuración, tuve la idea de usar un proxy SSH en el que el personal de soporte iniciará sesión (con autenticación LDAP, pero ese es otro problema) y que contiene las claves privadas.

La pregunta es: ¿cómo permito que el personal de soporte utilice la clave privada SSH sin poder leerla?

Creo que tengo que hacer que un demonio se ejecute como root en la máquina proxy que acepte la solicitud de un usuario y abra una sesión SSH para ellos, pero no tengo idea de cómo hacerlo. ¿Algunas ideas?

Sugeriría un par de opciones.

1. Proteja la clave ssh y requiera el uso del lado sudode su equipo de soporte. Podrías hacer esto de forma transparente con un envoltorio. Llame al contenedor, digamos, /usr/local/bin/ssh-supporty haga que contenga algo como esto (no probado):

   #!/bin/bash
   export PATH=/usr/local/bin:/usr/bin:/bin
   export IFS=$' \t\n'
   export SUSER=ssupport
   
   # Restart if not running under sudo
   test "X$1" != 'X-S' && exec sudo -u "$SUSER" /usr/local/bin/ssh-support -S "$@"
   shift
   export SHOME="$(getent passwd "$SUSER" | cut -d: -f6)"
   
   # Extract single argument as hostname LABEL and validate that we have
   # an RSA private key for it. The target username, real hostname, port,
   # etc. can be defined in ~/.ssh/config for the user $SUSER (ssupport)
   label="$1"
   idfile="$SUSER/.ssh/id_rsa_for_$label"
   cgfile="$SUSER/.ssh/config"
   
   ok=true
   [[ "$label" =~ '/' ]] && { echo "Invalid label: $label" >&2; ok=; }
   [[ ! -s "$idfile" ]] && { echo "Missing identity file: $idfile" >&2; ok=; }
   [[ ! -s "$cgfile" ]] && { echo "Missing configuration file: $cgfile" >&2; ok=; }
   
   if test -n "$ok"
   then
       logger -t ssh-support "$SUDO_USER requested ssh to $label"
       exec ssh -i "$idfile" -F "$cgfile" "$label"
   fi
   exit 1

   Esto requeriría una entrada en el sudoersarchivo que permitiera a los usuarios del supportgrupo usar la herramienta. Este comando les permite ejecutar la ssh-supportherramienta como el ssupportusuario, que debe crear. Que no confiere ningún privilegio raíz.

   %support ALL = (ssupport) /usr/local/bin/ssh-support

   Si está satisfecho de que los usuarios de soporte no necesiten proporcionar su propia contraseña para ejecutar la herramienta (como lo solicitó la sudoinvocación dentro del script), puede modificar la sudoersdefinición de la siguiente manera:

   %support ALL = (ssupport) NOPASSWD: /usr/local/bin/ssh-support

   Suponiendo PATHcontenido /usr/local/bin/, entonces lo llamarías con ssh-support clientname. También suponiendo que había creado el ssupportusuario como /home/ssupportse crearía /home/ssupport/.ssh/id_rsa_clientnamey /home/ssupport/.ssh/id_rsa_clientname.pubcomo el par de certificados, y tienen una entrada de host en /home/ssupport/.ssh/configpara clientnameque definió el usuario, host, puerto, etc., para el equipo de destino. Probablemente deshabilitaría explícitamente el reenvío X11, el reenvío de puertos, etc. Como de costumbre, el /home/ssupport/.sshdirectorio necesitaría estar protegido con permisos 0700.

2. Proporcione a cada miembro de soporte su propia cuenta de usuario local y haga que cada persona use su propia clave ssh privada para acceder a los servidores del cliente. Cuando una persona abandona el grupo de soporte, elimina su clave ssh de los servidores del cliente. Esto significa que ya no necesita preocuparse por evitar que su personal conozca la clave ssh privada.

Lo que realmente desea hacer es utilizar SSH CA y las claves de firma utilizadas por cada persona de soporte (deben tener sus propias claves ssh, como pasaportes) y configurar los servidores de sus clientes para usarlos TrustedUserCAKeys /etc/ssh/users_ca.puben / etc / ssh / sshd_config. De esta manera, el servidor aceptará cualquier clave firmada por la clave CA (a la que tiene acceso) y podrá revocar las claves de las personas que ya no están en soporte sin siquiera tocar autorizadas_claves.

Una búsqueda rápida de "ssh ca" señaló este tutorial: https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with -ubuntu (desplácese hacia abajo hasta "Cómo configurar las claves de usuario"), aunque el tutorial menciona que Ubuntu es independiente de la distribución, pero necesita una versión nueva de OpenSSH que admita SSH CA

Otra buena entrada de blog sobre el tema es https://ef.gy/hardening-ssh (desplácese hacia abajo hasta "certificados SSH").

¡Preste especial atención en que puede firmar la clave para que sea válida por un tiempo limitado, para que caduquen automáticamente!

Hay un par de respuestas diferentes que involucran un script de envoltura para ssh invocado a través de sudo o setuid-ejecutable (para alguna cuenta no root de propósito especial ). Como dice nkms , pasar todos los argumentos a ssh le permite al usuario hacer cosas arbitrarias con las teclas ssh que estamos tratando de proteger. El otro extremo que se les ocurrió es permitir solo un nombre de host.

El OP dice que los administradores deben poder cargar cosas.

Podría tener dos envoltorios diferentes de args fijos a ssh. Uno para un shell de inicio de sesión, otro para scp. No hay argumentos proporcionados por el usuario que no sean el nombre de host (y el nombre de archivo para cargar).

O un script de contenedor que se utiliza getoptpara analizar opciones muy limitadas y conectar cosas a un comando ssh mayormente fijo. Ignorar (o error) en opciones no reconocidas sería el camino a seguir.

No intente filtrar las opciones ssh "peligrosas", solo escriba un contenedor que pueda hacer dos cosas: inicio de sesión interactivo o subir un archivo (nombres de archivo locales y remotos). Supongo que todavía necesitas desinfectar allí.

En realidad, todavía es fácil equivocarse. Debe encontrar una manera de evitar que el usuario entregue el archivo que contiene las teclas ssh como el archivo local. Entonces todavía estás tratando de pensar en todo lo que necesita ser rechazado, en lugar de comenzar a no permitir nada. Sería un comienzo para asegurarse de que los nombres de los archivos no contengan ninguno @o :.

Si configura un servidor proxy SSH, puede organizar que el shell (in /etc/passwd) de los usuarios de su personal no esté configurado en un shell como bash, sino en un script simple que no permita el acceso al shell. En su lugar, pediría un nombre de host de destino ( read target), entonces exec ssh "support@$target".

Tenga en cuenta que el uso de un proxy como este podría dificultar el uso de herramientas como la scptransferencia de archivos a / desde las máquinas del cliente. ¡Esto puede ser un problema o una ventaja!

Su personal de soporte siempre se conecta a través de esa máquina proxy, y solo desde ella, para que los clientes simplemente puedan autenticar la máquina proxy utilizando la autenticación basada en host .

Digamos que la máquina proxy es supporters.pcy usted brinda soporte acustomer.pc

customer.pc tendrá HostbasedAuthentication yes in /etc/ssh/ssd_config, supporters.pc en la lista /etc/ssh/shosts.equivy su clave pública en /etc/ssh/ssh_known_hosts.

Cuando su personal de soporte inicie sesión en [email protected] y realice ssh customer.pc, generará ssh-keysign (8) (que debe configurarse), que manejará la firma de la clave con el archivo que no puede leer y proporcionar pruebas a supporters.pc de que la conexión realmente proviene de supporters.pc . Como customer.pc confía en supporters.pc , su miembro del personal se conecta como soporte .

Use un contenedor binario

Para este caso de uso en particular (vea la nota importante a continuación), una posibilidad es crear un usuario (digamos support-ssh) específicamente para estas conexiones SSH salientes, luego instalar un pequeño contenedor binario que se ejecute /usr/bin/ssh.

• No copie + chmod el sshbinario en sí, porque no recordará volver a copiarlo cada vez que aplique actualizaciones de seguridad.
• Y no lo use rootcomo el usuario más privilegiado, por razones en las que confío son obvias.

Esta es una alternativa funcionalmente equivalente al uso sudopara elevar los privilegios al de la support-sshcuenta con las siguientes compensaciones:

• Esto es más pequeño y delgado que sudo, por lo que hay menos riesgo de que el error de configuración se abra más de lo previsto.
• Es su responsabilidad codificarlo correctamente; solo haga esto si es extremadamente cuidadoso y (idealmente) tiene experiencia en codificación crítica para la seguridad.
• Se puede adaptar para que sea más específico que sudo(pero cuanto más código escriba, más necesitará auditar por seguridad).

El contenedor binario debe establecerse HOMEen el support-sshdirectorio de inicio del usuario, de modo que sshrecoja la ssh_configclave apropiada y privada. Pero el usuario que invoca no debe poder leer ~support-ssh/.ssh/ni sus contenidos.

El contenedor podría ser tan simple como:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(int argc, char **argv)
{
    setenv("HOME", "/home/support-ssh", 1);
    /* allow only a single, non-option argument */
    if (argc!=2 || *argv[1]=='-') {
        fprintf(stderr, "Usage: %s <hostname>", argv[0]);
        exit(EXIT_FAILURE);
    }
    execv("/usr/bin/ssh", argv);
    return EXIT_FAILURE;
}

Es posible que desee ser más restrictivo y verificar que el argumento argv[1]esté en un conjunto de nombres de host permitidos. O menos restrictivo, y permite (un subconjunto de) argumentos de opción. Es posible que desee sustituir por completo las variables de entorno (pero mantener las importantes tales como TERM, LC_*, etc.); Tenga en cuenta que LD_LIBRARY_PATHy LD_PRELOADson particularmente peligrosos.

Se podría proporcionar un programa contenedor similar scpsi fuera necesario.

Una nota sobre aplicabilidad

Esta respuesta aborda las circunstancias específicas de la pregunta, donde los usuarios están obligados contractualmente a seguir los procedimientos, y existen sanciones (por ejemplo, despido) por violarlos. Supone que desea evitar que los empleados copien casualmente claves privadas, en lugar de evitar que un atacante determinado obtenga acceso no autorizado.

Considero que la seguridad se logra a través de defensas técnicas y no técnicas, y que el equilibrio logrado aquí o mediante el uso sudoes apropiado para la situación presentada.