Autor: Joel Barrios Dueñas
Correo electrónico: darkshram en gmail punto com
Sitio de Red: https://www.alcancelibre.org/

Licencia de este documento: Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.1

© 1999-2022 Joel Barrios Dueñas. Usted es libre de copiar, distribuir y comunicar públicamente la obra y hacer obras derivadas bajo las condiciones siguientes: a) Debe reconocer y citar al autor original. b) No puede utilizar esta obra para fines comerciales (incluyendo su publicación, a través de cualquier medio, por entidades con fines de lucro). c) Si altera o transforma esta obra o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta. Al reutilizar o distribuir la obra, tiene que dejar bien claro los términos de la licencia de esta obra. Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de los derechos de autor. Los derechos derivados de usos legítimos u otras limitaciones no se ven afectados por lo anterior. Licencia completa en castellano. La información contenida en este documento y los derivados de éste se proporcionan tal cual son y los autores no asumirán responsabilidad alguna si el usuario o lector hace mal uso de éstos.

Introducción.

Utilizar firmas digitales en lugar de contraseñas a través de servicios como SSH, SCP o SFTP, resulta una técnica más segura para autenticar dichos servicios, facilitando también la operación de guiones y herramientas de respaldo que utilizan dichos protocolos.

Los procedimientos descritos en este documento asumen existe un hipotético servidor con dirección IP 192.168.100.15. Reemplace esta dirección IP por la que corresponda al servidor que se desea configurar.

Procedimientos

Procedimientos en el Servidor remoto.

Acceda como administrador al servidor remoto. Ejemplo:

ssh root@192.168.100.15

Ejecute lo siguiente para habilitar la política para SELinux denominada allow_ssh_keysign:

setsebool -P allow_ssh_keysign 1

Ejecute lo siguiente para crear el directorio ~/.ssh/ con permiso de acceso de lectura/escritura sólo para el usuario y cambiar el contexto SELinux al tipo ssh_home_t, crear el archivo ~/.ssh/authorized_keys igualmente con permiso de acceso de lectura/escritura sólo para el usuario y cambiar el contexto SELinux al tipo ssh_home_t:

mkdir -m 0700 ~/.ssh/
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
chcon -R -t ssh_home_t ~/.ssh

Salga del servidor después de haber creado el directorio y archivo descrito y de haber configurado los permisos correspondientes.

exit

Procedimientos en el sistema cliente.

Realice los siguientes procedimientos desde el sistema cliente.

Generar firmas digitales.

Genere una firma digital (firma digital pública) tipo DSA (Digital Signature Algorithm o Algoritmo de Firma digital). Puede crear una firma tipo RSA, pero es poco recomendado debido a las puertas traseras que pudiera tener la NSA de EE.UU. sobre dicha tecnología. Es importante señalar que si desea utilizar la firma digital sin contraseña, jamás se deberá establecer una durante la generación de la firma digital. Cuando el diálogo solicite una contraseña con confirmación, sólo pulse la tecla ↵ (ENTER) y continúe el procedimiento. Si asigna contraseña, está será utilizada para autenticar el certificado creado cada vez que se quiera utilizar éste.

ssh-keygen -t rsa

El procedimiento devolverá una salida similar a la siguiente:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/curso/.ssh/id_rsa): 
Created directory '/home/curso/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/curso/.ssh/id_rsa.
Your public key has been saved in /home/curso/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:/XMw94Yfo/InjXjotA0dyBCAUeW7xLRoyy7CUGaOAOL curso@curso.alcancelibre.org
The key's randomart image is:
+---[RSA 3072]----+
|+*+              |
|+o.              |
|.o.. .  o        |
|o..E. .o .  o    |
|o. o ...S. . o   |
| .+.o =.o o o    |
| .ooo* o.*.. =   |
|  .oo.o.oo=.+ .  |
|   .... ...o.o.  |
+----[SHA256]-----+

Lo anterior generará los archivos los archivos ~/.ssh/id_rsa y ~/.ssh/id_rsa.pub

Cambie de modo descendente los permisos de ~/.ssh a sólo lectura y escritura para el usuario.

chmod -R go-rwX ~/.ssh

Si utiliza openSUSE™ o SUSE™ Linux Enterprise omita el siguiente paso. Si utiliza AlmaLinux o Red Hat™ Enterprise Linux ejecute lo siguiente para garantizar los contextos del contenido del directorio ~/.ssh/ al tipo ssh_home_t:

chcon -R -t ssh_home_t ~/.ssh/

Ejecute lo siguiente para copiar automáticamente la firma digital pública dentro del archivo ~/.ssh/authorized_keys en el servidor remoto. Ejemplo:

ssh-copy-id root@192.168.100.15

La salida debe ser similar a la siguiente:

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/jbarrios/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
curso@192.168.100.15's password: 
/usr/bin/xauth:  file /home/curso/.Xauthority does not exist

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'curso@192.168.100.15'"
and check to make sure that only the key(s) you wanted were added.

Tendrá serias implicaciones de seguridad si el archivo id_dsa cae en manos equivocadas o se ve comprometido. Este archivo deberá ser considerado como altamente confidencial.

Pueden generarse diferentes firmas digitales para cada usuario que deba ingresar a través de SSH al servidor remoto. El programa ssh-copy-id se encarga de añadir automáticamente el contenido del archivo ~/.ssh/id_dsa.pub —de cada usuario que lo ejecute— al archivo ~/.ssh/authorized_keys de la firma pública correspondiente en el servidor remoto. Pueden agregarse cuantas firmas digitales en este archivo como sean necesarias. Si acaso se ve comprometida la seguridad de alguna firma digital, se debe eliminar ésta del archivo ~/.ssh/authorized_keys del servidor remoto.

Comprobaciones.

Siempre que haya omitido asignar contraseña para la llave DSA, deberá poderse acceder hacia el servidor remoto sin necesidad de autenticar con la contraseña del usuario remoto. Si fue asignada una contraseña a la clave DSA, se podrá acceder hacia el servidor remoto autenticando con la contraseña definida a la clave DSA y sin necesidad de autenticar con la contraseña del usuario remoto.