Autenticación por claves no servizo SSH

De MediaWiki
Revisión del 20:30 10 feb 2026 de Joselv (discusión | contribuciones)
(dif) ← Revisión anterior | Revisión actual (dif) | Revisión siguiente → (dif)
Ir a la navegación Ir a la búsqueda

Escenario

ste escenario ten como principal obxectivo explicar e implementar un sistema de autenticación por claves, que usando a criptografía de clave asimétrica, permita que os usuarios se autentiquen no sistema a través dunha identidade dixital.

Escenario

Ó longo deste escenario crearemos varias identidades dixitais e configuraremos o servidor ssh para permitir únicamente o acceso mediante claves criptográficas (identidades dixitais). Unha vez configurado o sistema de autenticación, veremos como un ataque de diccionario lanzado con medusa ou semellantes fracasa.

Configuración dos equipos para o escenario

Os equipos para desenvolver o escenario son:

  • Os equipos son os do escenario anterior.
  • A maiores dos equipos da figura usarei o equipo anfitrión dos contedores.
  • Os tres equipos deben poder comunicarse entre si.

Autenticación por claves

SSH permite autenticar ós usuarios facendo uso de identidades dixitais (formadas cunha parella de claves privada-pública) e os algoritmos criptográficos de clave asimétrica. O procedemento a seguir ten dous pasos:

  1. Crear a identidade dixital
  2. Copiar a clave pública no arquivo de claves autorizadas no host remoto.

Resúmese na seguinte imaxe:

Openssh e identidades dixitais

Fig. Esquema dun sistema de autenticación por claves en ssh

Crear a identidade dixital

En primeiro lugar, o usuario creará a súa identidade dixital xerando a parella de claves privada-pública. Como xa foi explicado na criptografía asimétrica, a clave privada debe manterse segura a toda costa e a pública pode distribuirse. A clave privada pode protexerse mediante o uso dunha passphrase; é dicir, que cando se use haberá que introducir a passphrase. Sinalar que cando se indica a passphrase o que se está a escribir non é visible; e no caso de esquecer a passphrase, a clave privada non se poderá usar ó non poderse descifrar; xa que o mesmo cifrado que fai seguro o sistema ssh, fai irrecuperable a clave. A solución sería abandoar a clave, xerar unha nova e instalar a nova pública nos equipos remotos.

Está claro que protexer as claves privadas cunha passphrase é o máis seguro, sen embargo o uso de claves privadas sen passphrase tamén ten a súa utilidade. Por exemplo, as claves privadas sen passphrase permiten o seu uso sen necesidade da intervención manual do usuario, o que é axeitado na execución automática de scripts.

Para crear a parella de claves empregarase o comando ssh-keygen, sendo as opcións máis salientables:

  • -t <tipo_clave> permite especificar o tipo de clave (RSA, DSA, ECDSA, etc.).
  • -b <tamaño_clave> permite especificar o tamaño de clave. Lembrar que estas claves serven únicamente para autenticar ó usuario; polo tanto, incrementar o seu tamaño non significará incrementar a carga de cpu cando se envíen datos por ssh.
  • -C “<comentario>” permite engadir un comentario á clave para poder distinguila doutras.
  • -f <nome_ficheiro> permite especificar a ruta e nome dos ficheiros das claves (é posible ter varias identidades dixitais).

A día de hoxe os tipos máis empregados son RSA e ED25519 e a forma de traballar con elas é semellante. A continuación creamos unha parella de claves, protexendo a clave privada cunha passphrase: 

$ ssh-keygen -t rsa -b 4096 -C "Identidade manuel - curso platega"

Generating public/private rsa key pair.
Enter file in which to save the key (/home/magasix/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/magasix/.ssh/id_rsa.
Your public key has been saved in /home/magasix/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:vPZGTGjYjpbMC584LOn4nIaSu1CtaJ4mfRYjpJ2smNQ Identidade manuel - curso platega
The key's randomart image is:
+---[RSA 4096]----+
|                 |
|                 |
|       o .       |
|  ..  ..+ .      |
| =o..o =So       |
|.+=E+ * ..o      |
|=B.+ B oo.       |
|%+*.* +. ..      |
|BO=+ .   ..      |
+----[SHA256]-----+

Se facemos un listado da carpeta $HOME/.ssh veremos que aparecen dous novos arquivos, id_rsa e id_rsa.pub. Esta parella de claves criptográficas formarán a identidade dixital do usuario. Fixarse os diferentes permisos da clave privada id_rsa e a clave pública id_rsa.pub. 

$ ls -lahF .ssh/

total 24K
drwx------  2 asir asir 4,0K ene 31 13:51 ./
drwxr-x--- 24 asir asir 4,0K ene 31 13:24 ../
-rw-------  1 asir asir 3,4K ene 31 13:51 id_rsa
-rw-r--r--  1 asir asir  759 ene 31 13:51 id_rsa.pub
-rw-------  1 asir asir 2,9K ene 31 13:33 known_hosts
-rw-------  1 asir asir 2,1K ene 31 13:33 known_hosts.old

Autorizar o acceso á identidade dixital

Para poder usar esta identidade dixital hai que autorizar o seu uso no equipo remoto; para facer isto, a clave pública debe copiarse no arquivo de claves autorizadas (authorized_keys) na conta que se teña no equipo remoto onde que se quere acceder. Ollo, é moi importante salientar que é a clave pública unicamente a que debe copiarse, non a clave privada. Pode engadirse manualmente ó final do arquivo authorized_keys ou se está permitido o acceso por ssh ó equipo usar o comando ssh-copy-id: 

$ ssh-copy-id ubuntu@192.168.100.101

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/asir/.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
ubuntu@192.168.100.101's password: 

Number of key(s) added: 1

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

No equipo remoto, dentro da carpeta .ssh/ ubicada no directorio casa do usuario magasix aparece o arquivo authorized_keys coas claves públicas das identidades dixitais autorizadas para acceder por ssh como usuario magasix: 

$ ls -lhaF .ssh/

total 3,5K
drwx------ 2 ubuntu ubuntu   3 ene 31 13:15 ./
drwxr-x--- 3 ubuntu ubuntu   7 ene 31 13:33 ../
-rw------- 1 ubuntu ubuntu 759 ene 31 13:52 authorized_keys

$ cat .ssh/authorized_keys

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC7o13tTmWDkkWzC/vjdJ7sTJfJXLF+41Zu7d+En9xOVxxXAyBuOR8DiT073iVPxs6KWyy96xUM8E13Iic62Q07OMJFrpQNafAIJaRQuuHFbb++sAhnv1V9ELPSd26yn9mdnAuxuR46kT0ZEe/+oQ778OJDFcWuPgFDj9mBLScSDIoJKxdDXVJzJ7CP4b6ykZF58hycAVdeIgUCWgXkHlTvutGQFLSjWvX6wb+Lw6tPprxIbEzUz2J5nELNQ5vbMUpjvhb137W/l5bmcGlO/4tHg3wdZHOJW6XSRJVrXirB4dQlwDTdY6DnFYsGhLYkFU4wBZ0FnGtJeA8vBJDgUQKBLUuUoxgOk27LiEKJo31dwNSWs1+W85YVQqIysxOO8FIQe8dS6AMrXKXcoIFGxp4qtZm7lE+knUswnOd87S4Q1r5C1gdk3cSETL/8QraCRDCNUNpD9wvvlCe9tn4A5oDuZwjiKsTXI8yhRR6YGiLruAnNaUDuT2usgXuwMPh+N8r+nO5ZkimZL5mrvJO/qT8cEBsKApEcjV/ed4BqfKl00G1lJ1ShXCKnIFEeeEF4WUsHvh2/IGz6NxDTNVRhI+S4DAcTyhEA7YWFhexKzzrfyRapUDFW4f9yygnu+OcdvDiDRTjigx13JtOg5kqIUa5tImtDRhVucxNFhVQglQ5PuQ== Identidade manuel - curso platega

Unha vez copiada a clave pública é posible acceder usando esa identidade dixital sen necesidade de usar contrasinais: 

$ ssh ubuntu@192.168.100.101

Enter passphrase for key '/home/asir/.ssh/id_rsa': 
Last login: Sat Jan 31 13:33:16 2026 from 192.168.100.1
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

Como a clave privada está protexida cunha passphrase, o usuario será preguntado pola mesma antes de continuar e abrir a terminal no equipo remoto:

Normalmente os sistemas Linux proporcionan axentes ssh que gardan en memoria as claves para non ter que teclear a passphrase cada vez que se use a clave (durante a sesión do usuario ou por o tempo configurado). No caso de que esto non suceda podemos indicarlle ó axente que a garde. 

$ ssh-add 

Enter passphrase for /home/magasix/.ssh/id_rsa: 
Identity added: /home/magasix/.ssh/id_rsa (/home/magasix/.ssh/id_rsa)

A continuación vese a que sucede cando se conecta ó servidor remoto por segunda vez: 

$ ssh ubuntu@192.168.100.101

Last login: Sat Jan 31 13:56:33 2026 from 192.168.100.1
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

Agora, a pesar de que a clave privada está protexida por unha passphrase, non se pide a passphrase xa que o axente ssh do sistema tena en memoria.

NOTA: no caso de que non haxa un axente arrincado por defecto no sistema operativo, hai que proceder a executalo da seguinte forma: 

$ eval $(ssh-agent

Agent pid 430607

$ ssh-add -l

The agent has no identities.

$ ssh-add

Enter passphrase for /home/asir/.ssh/id_rsa: 
Identity added: /home/asir/.ssh/id_rsa (Identidade manuel - curso platega)
<pre>
 $ ssh-add -l
<pre>
4096 SHA256:vGQ+CiwNx+mxSb8m4Zcz3fBzEaZszxIZAPYb5ZEc5Pw Identidade manuel - curso platega (RSA)

Traballando con máis dunha identidade dixital

Non estamos limitados a ter unha única identidade dixital e podemos crear varias identidades dixitais (parella de claves pública-privada) e usalas según nos conveña. A modo de exemplo, no equipo remoto hai un usuario chamado asir04 con contrasinal pokemon ó que lle está permitido o acceso por ssh: 

$ ssh asir04@192.168.100.101

asir04@192.168.100.101's password: 
Last login: Sat Jan 31 16:24:14 2026 from 192.168.100.1

Crearemos unha nova identidade dixital coa clave privada sen passphrase para acceder ó equipo remoto como usuario asir04 (cando pida a passphrase prememos Intro para non protexela). Empregamos a opción -f para indicar a ubicación e o nome das novas claves (para non machacar a identidade anterior): 

$ ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_asir04 -C "id para asir04 - non protexida"

Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/asir/.ssh/id_rsa_asir04
Your public key has been saved in /home/asir/.ssh/id_rsa_asir04.pub
The key fingerprint is:
SHA256:PbpRb7MxfhVgh2CfVClBKOttG1G5ytiGC3594Ol3mHM id para asir04 - non protexida
The key's randomart image is:
+---[RSA 4096]----+
|           o++=..|
|         ...oB.o |
|          o oo=  |
|         o . . . |
|        S X o   .|
|       . * %    .|
|      . + * @ o. |
|       . = B @.E |
|        o ..=.+  |
+----[SHA256]-----+

$ ls -lhF .ssh/

total 24K
-rw------- 1 asir asir 3,4K ene 31 13:51 id_rsa
-rw------- 1 asir asir 3,4K ene 31 16:27 id_rsa_asir04
-rw-r--r-- 1 asir asir  756 ene 31 16:27 id_rsa_asir04.pub
-rw-r--r-- 1 asir asir  759 ene 31 13:51 id_rsa.pub
-rw------- 1 asir asir 2,9K ene 31 13:33 known_hosts
-rw------- 1 asir asir 2,1K ene 31 13:33 known_hosts.ol

Copiamos a identidade dixital no equipo remoto no arquivo de claves autorizadas para o usuario asir04. Fixarse que especificamos a clave pública a copiar coa opción -i e identificámonos como o usuario asir04: 

$ ssh-copy-id -i .ssh/id_rsa_asir04.pub asir04@192.168.100.101

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: ".ssh/id_rsa_asir04.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
asir04@192.168.100.101's password: 

Number of key(s) added: 1

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

Agora podemos entrar no equipo remoto como usuario ubuntu ou asir04 indicando a identidade dixital adecuada coa opción -i arquivo_clave_privada.

Como ubuntu:

$ ssh -i .ssh/id_rsa ubuntu@192.168.100.101 

Last login: Sat Jan 31 16:24:34 2026 from 192.168.100.1
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

Como asir04: 

$ ssh -i .ssh/id_rsa_asir04 asir04@192.168.100.101

Last login: Sat Jan 31 16:24:48 2026 from 192.168.100.1

Podemos engadir esta nova id. dixital ó axente: 

$ ssh-add .ssh/id_rsa_asir04

Identity added: .ssh/id_rsa_asir04 (id para asir04 - non protexida)

$ ssh-add -l

4096 SHA256:vGQ+CiwNx+mxSb8m4Zcz3fBzEaZszxIZAPYb5ZEc5Pw Identidade manuel - curso platega (RSA)
4096 SHA256:PbpRb7MxfhVgh2CfVClBKOttG1G5ytiGC3594Ol3mHM id para asir04 - non protexida (RSA)

A autenticación por claves é vaĺida non só para obter a liña de comandos senón para traballar con ssh en modo comando e scp: 

 $ ssh -i .ssh/id_rsa_asir04 asir04@192.168.100.101 ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
56: eth0@if57: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 10:66:6a:1b:3d:99 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.100.101/24 brd 192.168.100.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::1266:6aff:fe1b:3d99/64 scope link 
       valid_lft forever preferred_lft forever

$ scp -i ~/.ssh/id_rsa webmin_1.670_all.deb ubuntu@192.168.100.101:
webmin_1.670_all.deb                                        100%   21MB  20.8MB/s   00:00

Isto foi un exemplo para ver como se poden ter varias identidades dixitais e non habería ningún problema en usar a mesma identidade dixital para autenticarse no equipo remoto como usuario ubuntu e asir04.

Configurando o cliente ssh

No exemplo anterior empregamos dúas identidades dixitais para acceder ó mesmo equipo como dous usuarios diferentes. Pode suceder que teñamos que acceder a múltiples equipos por ssh posiblemente empregando diferentes usuarios, diferentes identidades dixitais, diferentes formas de autenticación, co servizo ssh correndo en diferentes portos, ... É posible configurar estos perfís na nosa conta de usuario a través do arquivo ~/.ssh/config. Por exemplo: 

$ nano .ssh/config

Host ubuntu_serverssh  
    User ubuntu
    Hostname 192.168.100.101 
    Port 22
    PubkeyAuthentication yes
    IdentityFile ~/.ssh/id_rsa
Host asir04_serverssh
        User asir04
        Hostname 192.168.100.101
        Port 22
        PubkeyAuthentication yes
        IdentityFile ~/.ssh/id_rsa_asir04
Host asir02_serverssh  
        User asir02
        Hostname 192.168.100.101
        Port 22
        PubkeyAuthentication no
Host serverdmz
        User ubuntu 
        Hostname 192.0.2.254
        Port 22000
        PubkeyAuthentication no

Creamos catro perfís coas seguintes características:

  • Perfil ubuntu_serverssh: para acceder ó equipo 192.168.100.101 como usuario ubuntu empregando autenticación por claves usando a identidade dixital id_rsa.
  • Perfil asir04_serverssh : para acceder ó equipo 192.168.100.101 como usuario asir04 empregando autenticación por claves usando a identidade dixital id_rsa_asir04.
  • Perfil asir02_medusa: para acceder ó equipo 192.168.100.129 como usuario asir02 empregando autenticación por contrasinal.
  • Perfil serverdmz: para acceder ó equipo 192.0.2.254 polo porto tcp/22000 como usuario ubuntu empregando autenticación por contrasinal.

Para usar un perfil hai que escribir ssh <perfil>: 

$  ssh ubuntu_serverssh

Last login: Sat Jan 31 16:28:45 2026 from 192.168.100.1
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

$ ssh asir04_serverssh

Last login: Sat Jan 31 16:28:52 2026 from 192.168.100.1

Co comando man ssh_config pódese acceder á documentación de axuda dos arquivos de configuración do cliente openssh.

Limitando os tipos de autenticación

Por defecto o servidor OpenSSH permite a autenticación por contrasinal e claves. En primeiro lugar trátase de autenticar ó usuario usando identidades dixitais e no caso de fallar úsase a autenticación por contrasinal. Imos conectarnos ó servidor remoto como usuario asir02 (que ten como contrasinal legolas) coa opción -v para ver as mensaxes de debugging: 

$ ssh -v asir02@192.168.100.101

OpenSSH_8.2p1 Ubuntu-4ubuntu0.11, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /home/manuel/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 192.168.100.101 [192.168.100.101] port 22.
debug1: Connection established.
debug1: identity file /home/manuel/.ssh/id_rsa type 0
debug1: identity file /home/manuel/.ssh/id_rsa-cert type -1
debug1: identity file /home/manuel/.ssh/id_dsa type -1
debug1: identity file /home/manuel/.ssh/id_dsa-cert type -1
debug1: identity file /home/manuel/.ssh/id_ecdsa type -1
debug1: identity file /home/manuel/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/manuel/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/manuel/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/manuel/.ssh/id_ed25519 type -1
debug1: identity file /home/manuel/.ssh/id_ed25519-cert type -1
debug1: identity file /home/manuel/.ssh/id_ed25519_sk type -1
debug1: identity file /home/manuel/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/manuel/.ssh/id_xmss type -1
debug1: identity file /home/manuel/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.11
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.9p1 Ubuntu-3ubuntu0.7
debug1: match: OpenSSH_8.9p1 Ubuntu-3ubuntu0.7 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.100.101:22 as 'asir02'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:t5eQQ90uVZaC5BLF1IhLRzewjgN50gqmkiCyGOWjObw
debug1: Host '192.168.100.101' is known and matches the ECDSA host key.
debug1: Found key in /home/manuel/.ssh/known_hosts:14
debug1: resetting send seqnr 3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/manuel/.ssh/id_rsa RSA SHA256:2FsTr3dYgcdlufZux2/lcqJdLcTrPL6mKX2GU9tet/8 agent
debug1: Will attempt key: id para asir04 - non protexida RSA SHA256:UQG50ML/lC8w3G+X/orDNN3ulSFwajjLol8MAB+b97A agent
debug1: Will attempt key: /home/manuel/.ssh/id_dsa 
debug1: Will attempt key: /home/manuel/.ssh/id_ecdsa 
debug1: Will attempt key: /home/manuel/.ssh/id_ecdsa_sk 
debug1: Will attempt key: /home/manuel/.ssh/id_ed25519 
debug1: Will attempt key: /home/manuel/.ssh/id_ed25519_sk 
debug1: Will attempt key: /home/manuel/.ssh/id_xmss 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com>
debug1: kex_input_ext_info: publickey-hostbound@openssh.com (unrecognised)
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/manuel/.ssh/id_rsa RSA SHA256:2FsTr3dYgcdlufZux2/lcqJdLcTrPL6mKX2GU9tet/8 agent
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: id para asir04 - non protexida RSA SHA256:UQG50ML/lC8w3G+X/orDNN3ulSFwajjLol8MAB+b97A agent
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/manuel/.ssh/id_dsa
debug1: Trying private key: /home/manuel/.ssh/id_ecdsa
debug1: Trying private key: /home/manuel/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/manuel/.ssh/id_ed25519
debug1: Trying private key: /home/manuel/.ssh/id_ed25519_sk
debug1: Trying private key: /home/manuel/.ssh/id_xmss
debug1: Next authentication method: password
asir02@192.168.100.101's password: 
debug1: Authentication succeeded (password).
Authenticated to 192.168.100.101 ([192.168.100.101]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending environment.
debug1: Sending env LANG = es_ES.UTF-8
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-105-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

  System information as of lun 29 abr 2024 18:05:26 CEST

  System load:    0.56982421875   Processes:             24
  Usage of /home: unknown         Users logged in:       0
  Memory usage:   0%              IPv4 address for eth0: 192.168.100.101
  Swap usage:     0%


Expanded Security Maintenance for Applications is not enabled.

0 updates can be applied immediately.

Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status



The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

Analizando a salida do comandos podemos sacar as seguintes conclusións:

  • Están dispoñibles á vez a autenticación por claves e por contrasinal.
  • En primeiro lugar trátase de acceder usando identidade dixitais; e se falla, inténtase coa autenticación por contrasinal.
  • Próbanse diferentes claves (identidades dixitais) que hai na carpeta ~/.ssh (ou se espera que estén)

Neste momento podemos lembrar que no apartado anterior usamos a opción -i arquivo_clave_privada para indicar a identidade dixital a usar; e vendo o anterior, podemos pensar que non era necesario xa que se proban unha por unha as identidades que coñeza o axente ssh. No servidor ssh a directiva de configuración MaxAuthTries controla o número máximo de intentos erróneos de autenticación por conexión ssh; polo tanto pode ocurrir que se proben varias identidades dixitais erróneas chegando ó valor máximo autorizado por MaxAuthTries e se aborte a conexión, sen chegar a usar a identidade dixital correcta. É aconsellable obrigar ó alumnado a usar a opción -i para que sexa consciente en cada momento do que está a facer.

Controlando a autenticación no servidor OpenSSH

A continuación revisaremos varias directivas de configuración do servidor OpenSSH que permitirán controlar a autenticación. En primeiro lugar controlaremos a autenticación do usuario root e despois aprenderemos a limitar o tipo de autenticación.

Autenticación do usuario root

A Autenticación do usuario root contrólase coa diretiva PermitRootLogin. Segundo a documentación de OpenSSH os valores que pode tomar esta directiva son:

  • Yes: usuario root pode acceder por ssh.
  • No: usuario root non pode acceder por ssh.
  • prohibit-password (without-password): usuario root pode acceder por ssh usando claves, non contrasinais.
  • forced-commands-only: usuario root pode acceder por ssh usando claves en 'modo comando'.
PermitRootLogin
Specifies whether root can log in using ssh(1).  The argument must be yes, prohibit-password, forced-commands-only, or no.  The default is prohibit-password.
If this option is set to prohibit-password (or its deprecated alias, without-password), password and keyboard-interactive authentication are disabled for root.
If this option is set to forced-commands-only, root login with public key authentication will be allowed, but only if the command option has been specified (which may be useful for taking remote backups even if root login is normally not allowed).  All other authentication methods are disabled for root.
If this option is set to no, root is not allowed to log in

A práctica recomendade é non permitir por ssh o acceso como root ou en caso de permitilo, empregar un sistema de autenticación forte como as claves dixitais.

En sshserver aínda poñendo contrasinal ó usuario root, non se pode acceder por ssh ó estar configurado PermitRootLogin no: 

$ ssh root@192.168.100.101
root@192.168.100.101's password: 
Permission denied, please try again.
root@192.168.100.101's password: 
Permission denied, please try again.
root@192.168.100.101's password: 
Permission denied (publickey,password).

Aclaración sobre forced-commands-only

Esta opción non é exactamente igual a traballar con ssh en modo comando. O que permite é o seguinte:

  • Impedir o acceso por ssh ó usuario root.
  • Asociar un comando a unha clave pública autorizada na conta do usuario root no arquivo /root/.ssh/authorized_keys
  • Permitir executar o comando asociado á clave pública se o usuario root accede por ssh usando a identidade dixital desa clave pública.

A modo de exemplo, no seguinte arquivo /root/.ssh/authorized_keys vese que o comando date está asociado a unha clave pública: 

$ cat /root/.ssh/authorized_keys

command="date" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAA1y5C...5CwwMQhon6VVKwKOA1m0pHp6+++n9OnoP9eRuw== Identidade manuel - curso platega

Cando executamos a seguinte orde dende un equipo remoto, executarase como root o comando date (o asociado á identidade dixital no arquivo authorized_keys do root): 

$ ssh root@192.168.1.240

Mon May  1 04:48:01 UTC 2023
Connection to 192.168.1.240 closed.

É unha forma de limitar o acceso a root únicamente para executar uns comandos determinados (pódense autorizar varios comandos, asociando cada comando a unha clave pública).

Tipo de autenticación

Para permitir unicamente a autenticación con claves no servidor remoto hai que editar o arquivo de configuración /etc/ssh/sshd_config: 

$ nano /etc/ssh/sshd_config 

...
PubkeyAuthentication yes
PasswordAuthentication no

$ sudo systemctl restart sshd.service

Podemos comprobar que os usuarios ubuntu e asir04 poden entrar (grazas ás súas identidades dixitais) pero o resto de usuarios non (sen identidades dixitais autorizadas).

Entrando como usuario ubuntu no servidor remoto: $ ssh asir04_serverssh 

Last login: Sat Jan 31 16:38:32 2026 from 192.168.100.1

Tratando de acceder como usuario asir02 no servidor remoto: 

$ ssh asir02@192.168.100.101
asir02@192.168.100.129: Permission denied (publickey).

Con esta configuración que permite soamente a autenticación mediante claves, os ataques de contrasinais non funcionan.

Obtenido de «https://wiki.cifprodolfoucha.es/index.php?title=Autenticación_por_claves_no_servizo_SSH&oldid=24371»