¿Puedo "ocultar" la clave privada, mientras sigo permitiendo que se use?

Se está enfocando en asegurar las claves en el lado del cliente. Le recomendaría que eche un vistazo en el lado del servidor.

En el servidor, puede limitar lo que se les permite hacer a su clave y de qué servidores se puede usar, editando el archivo authorized_keys para la cuenta de destino. Aquí hay un ejemplo de una clave con límites:

from="their.workstation.only.example.com" no-port-forwarding ssh-dss AAA....

Si lo desea, puede usar direcciones IP en lugar de un FQDN.

Para evitar que los usuarios manipulen el archivo authorized_keys, puede moverlo a una ubicación donde no tengan permiso de escritura. Seguirá funcionando mientras tengan el permiso leer . Esto se puede hacer editando sshd_config y cambiando

AuthorizedKeysFile .ssh/authorized_key

a por ejemplo

AuthorizedKeysFile /usr/local/authorized_keys/%u

El %u se reemplaza por el nombre de usuario, por lo que cuando alguien se conecta a ssh con el nombre de usuario foo , ssh buscará el archivo de claves en /usr/local/authorized_keys/foo . Mientras foo tenga acceso de lectura a ese archivo, la conexión funcionará.

Editar: En lugar de mover la clave, simplemente puedes configurar el archivo como inmutable, como esto:

sudo chattr +i /home/user/.ssh/authorized_keys

Una vez que haya configurado la limitación de IP de origen y haya asegurado el archivo de la clave contra la manipulación, no importará si la clave privada se filtra; aún no podrá utilizarse desde ningún otro sistema.

Hay muchas otras cosas que puede hacer para limitar a los usuarios cuando se conectan con las teclas. Consulte la página de manual de sshd . También ha habido algunas preguntas sobre esto en Serverfault, por ejemplo, Acceso SSH limitado para recuperación de registro .

Sugeriría tarjetas inteligentes y tokens seguros *. Estos tienen un almacenamiento que no se puede leer, solo se puede usar desde el criptoprocesador seguro. Esto significa que nadie que tenga acceso completo al token puede leer la clave privada. Lo único que el usuario puede hacer es enviar una cadena para que sea firmada o desencriptada, y recuperar el resultado.

La tarjeta inteligente / token seguro también puede generar el par de llaves en la tarjeta, asegurando que la clave nunca haya estado y pueda estar fuera de la tarjeta / token. Luego se puede extraer la clave pública para luego insertarla en las claves autorizadas.

* Los tokens USB seguros son efectivamente una tarjeta inteligente y un lector de tarjetas inteligentes, combinados en el mismo chip con el mismo nivel de seguridad.

Sugeriría una tarjeta inteligente y un lector de tarjetas inteligentes, si varios usuarios autorizados usarán el mismo terminal para conectarse al servidor SSH bajo su propia identidad.

Si cada usuario autorizado tiene su propio terminal, o se usan identidades de grupo, sugeriría usar un token PKI, que se puede colocar de forma permanente e incluso bloquear con un candado, dentro de la computadora, y luego conectarse a la computadora utilizando un cable USB interno.

No puede eliminarlo, pero podría cifrarlo, sin utilizar el hashing MD5 estándar:

cp /userdir/.ssh/id_rsa /userdir/.ssh/id_rsa.old
openssl pkcs8 -topk8 -v2 des3 -in /userdir/.ssh/id_rsa.old -out /userdir/.ssh/id_rsa
chmod 600 /userdir/.ssh/id_rsa

Si lo hace, openssl le pedirá una frase de contraseña tres veces (para desbloquear la clave privada existente, y dos veces más para una frase de contraseña para la nueva clave). Ese es el método manual, o simplemente puede utilizar keycrypt

Hay un problema bastante fundamental aquí: no puedes permitir que lean la clave en una circunstancia y luego evitar que hagan algo que no quieres que hagan.

Incluso cifrando la clave ... si tienen la contraseña para descifrar, entonces pueden hacer lo que quieran. Y si no lo hacen, no pueden usarlo en absoluto.

Ante este problema, le sugeriría que use una 'cuenta de privilegios' específica para cada usuario: asigne ese par de llaves y use sudo para permitir que se ejecuten comandos específicos como ese 'usuario de privilegio'. P.ej. %código%. Para los puntos de bonificación, también puede imponer un ssh $hostname para esa cuenta de usuario que no podrán cambiar.