OpenSSH Server
Sumario
Escenario
O principal obxectivo deste escenario é revisar e familiarizarse co funcionamento dun sistema SSH, tanto na parte servidor como no cliente. Instalaremos o servidor openssh-server nunha máquina Ubuntu Server e faremos probas de conexión dende clientes ssh para probar os mecanismos de autenticación do server grazas ó uso da súa clave pública. Ademáis, este escenario supón o comezo do estudo e revisión dos arquivos de configuración máis importantes tanto da parte servidor como da cliente, así como dos principais comandos ssh.
Escenario
Ó longo do escenario realizaremos as seguintes accións:
- Actualizar a listaxe de paquetes no equipo correndo Ubuntu Server e instalar a última versión de openssh-server.
- Unha vez rematada a instalación, verificar que o servidor ssh está escoitando peticións no porto por defecto.
- Facer un listado dos arquivos de configuración do servidor ssh e localizar as claves públicas e privadas dos distintos algoritmos criptográficos.
- Explicar a misión do arquivo arquivo known_hosts.
- Conectarse dende o cliente Linux, verificando que se pide aceptar a clave pública e que unha vez aceptada, aparecerá no arquivo known_hosts do usuario.
- Conectarse novamente dende o cliente Linux, verificando que esta vez non se solicita aceptar a clave pública.
- Rexenerar as claves privada-pública que usa o servidor openssh-server.
- Comprobar que sucede cando o cliente detecta un erro na autenticación do server e como xestionar esta situación.
Configuración do server
Contedores LXC
NOTA: para este escenario é posible empregar o contedor admin2 dos escenarios anteriores directamente, tendo en conta que ten configurada a IP.2 en vez da .11. Poño as instruccións para preparar o escenario de xeito manual por dúas razóns: a primeira porque é interesante que o alumnado faga todo o proceso se nunca traballou a instalación e configuración de ssh e a segunda para que comparedes, o que é unha configuración a man fronte os despregamentos automatizado dos escenarios anteriores.
Con Ubuntu 22.04 Para montar o equipo Server do Escenario 4C nun contedor LXC teremos en conta os seguintes puntos:
Imaxe a usar Linux Ubuntu 22.04. Perfil da máquina: lan
O contedor estará directamente conectado á rede lan xestionada por LXC/incus.
Ten conexión co anfitrión e cos demais contedores conectados a esa rede.
Sairá a Internet a través da interface lan que exerce de switch-router-nat.
Non é directamente accesible dende fóra do equipo anfitrión.
Con este perfil podemos facer que todo o alumnado simule unha rede local coas mesmas IPs e poida facer a práctica seguindo as mesmas indicacións. A rede lan e o perfil lan xa foron creados en temas anteriores:
$ incus launch images:ubuntu/jammy/cloud server-ssh -p LAN Launching server-ssh $ incus ls -c n,4,s,P,S,l
+------------+-----------------------+---------+-------------+-----------+----------------------+ | NAME | IPV4 | STATE | PROFILES | SNAPSHOTS | LAST USED AT | +------------+-----------------------+---------+-------------+-----------+----------------------+ | admin2 | | STOPPED | LAN | 0 | 2026/01/31 09:13 CET | +------------+-----------------------+---------+-------------+-----------+----------------------+ | fw | | STOPPED | WAN-LAN-DMZ | 0 | 2026/01/31 11:59 CET | +------------+-----------------------+---------+-------------+-----------+----------------------+ | server | | STOPPED | DMZ | 0 | 2026/01/31 09:13 CET | +------------+-----------------------+---------+-------------+-----------+----------------------+ | server-ssh | 192.168.100.29 (eth0) | RUNNING | LAN | 0 | 2026/01/31 12:06 CET | +------------+-----------------------+---------+-------------+-----------+----------------------+
Configuración de rede do contedor: A IP que ten o contedor neste momento é por dhcp e procederemos a configurala de forma estática. Ó estar na rede lan o server debera ter unha configuración válida para a esa rede; e no exemplo, a configuración escollida é: Interface de rede: eth0 IP do server: 192.168.100.11/255.255.255.0 Default gateway: 192.168.100.1 (IP asignada á interface lan creada con lxc network en escenarios do tema Contedores LXC/LXD) Servidores DNS: 8.8.8.8 e 8.8.4.4
Para configurar o server hai que editar o arquivo /etc/network/interfaces.
$ incus shell server-ssh # nano /etc/netplan/50-cloud-init.yaml
network:
version: 2
ethernets:
eth0:
addresses:
- 192.168.100.11/24
nameservers:
addresses:
- 8.8.8.8
- 8.8.4.4
search: []
routes:
- to: default
via: 192.168.100.1
# netplan apply # 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
14: eth0@if15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:16:3e:8a:15:74 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.100.11/24 brd 192.168.100.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::216:3eff:fe8a:1574/64 scope link
valid_lft forever preferred_lft forever
# ip route
default via 192.168.100.1 dev eth0 proto static 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.10
Instalación de opensss server:
# apt update # apt install openssh-server
Permitir as conexións haberá que poñer a directiva PasswordAuthentication a yes:
# nano /etc/ssh/sshd_config
... # Change to no to disable tunnelled clear text passwords PasswordAuthentication yes ...
# systemctl restart sshd.service # ss -lntp
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1053,fd=3))
LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=303,fd=13))
LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=1053,fd=4))
Asignar un contrasinal ó usuario ubuntu que ven na imaxe:
# passwd ubuntu
Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully
Nos contedores LXC/incus o usuario root ven activado e podemos usalo para executar os comandos ou usar o usuario administrador ubuntu elevando privilexios con sudo (nos apuntamentos normalmente aparecerán desta última forma).
En Virtualbox
No caso de empregar Virtualbox para realizar o escenario 4C, o server corre nunha máquina virtual coas seguintes características:
- Sistema Operativo Ubuntu Server 22.04.
- Memoria RAM: a partir de 512 MBytes
- Rede: un único adaptador de rede configurado en modo ponte (bridge). IMPORTANTE: debe ter unha configuración de rede válida para a rede da túa casa/centro.
- Configurar a rede en modo estático seguindo as indicacións dadas no apartado anterior, tendo especial coidado no nome da interface que pode non ser eth0.
Para instalar o servidor openssh e verificar que o servizo está levantado execútanse os seguintes comandos:
$ sudo apt update $ sudo apt install openssh-server $ sudo ss -ltnp
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1053,fd=3))
LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=303,fd=13))
LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=1053,fd=4))
Instalación de OpenSSH Server
Aínda que existen diferentes implementacións tanto de clientes como de servidores ssh, a máis empregada é OpenSSH, de feito a súa implementación do cliente ssh xa ben instalada na maioría das distribucións de Linux.
No caso de querer instalalo habería que executar os seguintes comandos:
$ sudo apt update $ sudo apt install openssh-server
Unha vez rematada a instalación, verifícase que o servizo ssh está correndo e listo para aceptar conexións no porto por defecto tcp/22:
$ sudo ss -lntp
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users ("sshd",pid=1053,fd=3))
LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users ("systemd-resolve",pid=303,fd=13))
LISTEN 0 128 [::]:22 [::]:* users ("sshd",pid=1053,fd=4))
Arquivos de configuración do servidor openssh
Os arquivos de configuración e claves criptográficas do servidor openssh-server están ubicados en /etc/ssh
$ ls -lhF /etc/ssh
total 48K -rw-r--r-- 1 root root 494K Apr 11 2025 moduli -rw-r--r-- 1 root root 1.7K Apr 11 2025 ssh_config drwxr-xr-x 2 root root 2 Apr 11 2025 ssh_config.d/ -rw-r--r-- 1 root root 3.2K Apr 11 2025 sshd_config drwxr-xr-x 2 root root 2 Apr 11 2025 sshd_config.d/ -rw------- 1 root root 505 Jan 31 11:06 ssh_host_ecdsa_key -rw-r--r-- 1 root root 177 Jan 31 11:06 ssh_host_ecdsa_key.pub -rw------- 1 root root 411 Jan 31 11:06 ssh_host_ed25519_key -rw-r--r-- 1 root root 97 Jan 31 11:06 ssh_host_ed25519_key.pub -rw------- 1 root root 2.6K Jan 31 11:06 ssh_host_rsa_key -rw-r--r-- 1 root root 569 Jan 31 11:06 ssh_host_rsa_key.pub -rw-r--r-- 1 root root 342 Dec 7 2020 ssh_import_id
Destacan os seguintes arquivos:
- ssh_config
- é o arquivo onde están as directivas de configuración do cliente openssh. Aínda que teñen nomes parecidos os arquivos de configuración é importante non confundir o arquivo de configuración do cliente co do servidor.
- sshd_config
- é o arquivo onde están as directivas de configuración do servidor openssh-server que controlan o seu funcionamento. Por exemplo, permiten configurar o porto/s onde se pon á espera de conexións o servidor ssh, se o usuario root pode iniciar ou non sesión por ssh, etc.
- sshd_config.d/
- directorio onde é posible engadir arquivos de configuración para o servidor openssh-server
- Arquivos de claves privada e pública
- do servidor para diferentes algoritmos de cifrado.
- Os seguintes arquivos son as parellas de claves privada-pública:
- Claves para ECDSA: ssh_host_ecdsa_key e ssh_host_ecdsa_key.pub.
- Claves para ED25519: ssh_host_ed25519_key e ssh_host_ed25519_key.pub.
- Claves para RSA: ssh_host_rsa_key e ssh_host_rsa_key.pub.
En relación ás claves fixarse en que:
- Todas as claves públicas dos diferentes algoritmos de cifrado rematan o seu nome en .pub e que calquera usuario pode acceder a elas (permisos rw-r--r-- ou 644). Lembrar que as claves públicas están pensadas para distribuirse.
- Todas as claves privadas son accesibles únicamente polo propietario root (permisos rw------- ou 600). A razón destes permisos tan restritivos nas claves privadas é a necesidade de mantelas protexidas; xa que se alguén puidese copialas, podería suplantar a identidade do equipo.
Inicio de sesión e autenticación do servidor
SSH usa un sistema criptográfico híbrido, onde a criptografía de clave asimétrica úsase para o intercambio seguro dunha clave simétrica de sesión, que permite un maior rendemento. Aínda que existen diferencias no funcionamento entre as versións 1 e 2 de ssh, o funcionamento xeral pode verse no seguinte esquema:
Inicio de sesión SSH
Fig. Establecemento dunha sesión SSH
A primeira vez que un cliente ssh establece unha conexión ó servidor aparece unha mensaxe indicando que non se recoñece a identidade do mesmo. O que sucede é que o servidor envía a súa clave pública e o equipo cliente non ten constancia dela. Unha vez aceptada esa clave pública a conexión segue o seu camiño e o usuario debe autenticarse.
NOTA ACLARATORIA#1. Para que apareza a mensaxe indicando que non se recoñece a identidade do mesmo ten que ser a primeira vez que nos conectamos por ssh. No caso de que xa nos conectásemos con anterioridade, podemos renomear ou borrar no equipo cliente o arquivo $HOME/.ssh/known_hosts.
Para borrar no cliente Linux o arquivo known_hosts:
$ rm .ssh/known_hosts
NOTA ACLARATORIA#2. Se os intentos de conexión por ssh demóranse moito (ata uns 20 segundos), podedes probar a editar o arquivo de configuración e engadir a seguinte directiva: UseDNS no. Nalgunhas distribucións o valor por defecto é yes e o que fai é que o servidor faga unha resolución dns inversa antes de solicitar o contrasinal, ralentizando todo o proceso. Co valor a 'no', non se fai a resolución dns inversa e a petición do contrasinal é casi instantánea: $ sudo nano /etc/ssh/sshd_config
... UseDNS no ... ubuntu@server-ssh:~$ sudo systemctl restart sshd.service
Efectuamos unha primeira conexión ó servidor ssh dende o cliente e aparece o aviso para aceptar a clave pública do servidor:
$ ssh ubuntu@192.168.100.11
The authenticity of host '192.168.100.11 (192.168.100.11)' can't be established. ED25519 key fingerprint is SHA256:RoXjODU9USCL4g6F9DU8RFQDCPb4QLC8BdhrxnegNb0. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.100.11' (ED25519) to the list of known hosts. ubuntu@192.168.100.11's password: Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 6.14.0-37-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/pro 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.
O equipo cliente garda as claves públicas dos servidores ós que se conecta no arquivo .ssh/known_hosts dentro do directorio casa do usuario que lanzou a conexión:
Arquivo known_hosts
Fig. Identificación do servidor mediante a súa clave pública e o arquivo known_hosts
Ó revisar o contido do arquivo known_hosts atopámonos con:
$ cat .ssh/known_hosts
|1|5i/66XvBclbTK++bstjQJe9+kXg=|x8KqqZvqfyboLyC6mFcm5iQNhS4= ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGme5EOVsOvOYGmwUlzl4nWtR+x8DdGEgdN6aIfLez2f |1|+VWsdhcnMIRjRyAdhfcYdWqhRQw=|ev2hYNM6qnOlfNfGLeNf/qcWUU0= ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCwca4/njS0gXFbnZqhFWDdqAPAVH/njFT0m4aOJnL3xLMdAKFBffSWzX0QyhSIo0SZHqnSSd2uDaeL5CBCUbWnJzknT5A4hlOsBlpZl36kAu6UrVZT7fSuhPNbk/On8qB2hW0Rd7xKd22vCgBTR2rjjEq4kRPDvBJPLF30rowKlgfqZ24z0gt4b+jGfRzU+5Z05nOzxgzMAIYi1aZyl1Y4qYiTQiHN5eWevd9y9OKV8mpmzJSNFV37io0M5jXP/n6nCmdMi6JecqZcs1zYLmsHWxTzX0CjPSHFwNnB+AEKPesOyX5cMwuCKMbJAT/RGHs/wuCYfMei6IWK1rDJF0i91g1ncahZZN4ns8GcuU0v5TVgnWZFnJ8AeFn5hPZ5rGfJ0/0FnzfGc2wrkgq9p5mmfSrs9+rdtpiRr0SQ0PPNLaOhWmqP4Qjm0aELf+ro7Aktxt1WxNcHdxDJ8f8uSp3o5QqEluPBEcznN8Fq0itSZJTxTM0niF6MGXLW6itoT0M= |1|OvO5z7+x6qYmy8nRScf55mH7aoo=|46ZEEbRDM1TZV3HWB3PKTHl60RQ= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHSznEhoYjp0Mhbei9yyMMU43Qei+5Qs8nwCBxR4A2uxaGuVRCz3Eh5hq6flJ/k6sbKL5S/QJkoCp0L9AHA0Evg=
Pódese comparar a clave pública gardada no arquivo known_hosts do cliente coa clave pública ECDSA do servidor e ver que se trata da mesma clave pública:
$ cat /etc/ssh/ssh_host_ed25519_key.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGme5EOVsOvOYGmwUlzl4nWtR+x8DdGEgdN6aIfLez2f root@server-ssh
Gardar as claves públicas permite que en conexións posteriores:
- Se a clave enviada polo equipo remoto coincide coa clave pública gardada en known_hosts non aparecerá a mensaxe de advertencia e o usuario verá que debe autenticarse para poder iniciar a sesión no equipo remoto. É dicir, o servidor autenticouse correctamente fronte ó cliente e continúa o proceso de establecemento da sesión ssh.
- Se a clave enviada polo equipo remoto é diferente á clave pública gardada en known_hosts aparecerá unha mensaxe de erro e abortarase a conexión. Hai un erro de autenticación e o cliente non confía no equipo remoto, xa que podemos estar ante un intento de suplantanción da identidade do servidor remoto.
Podemos probar a conectarnos novamente ó servidor e veremos que xa non aparece a mensaxe, xa que a identidade do server é coñecida ó estar a súa clave pública no known_host:
$ ssh ubuntu@192.168.100.11
ubuntu@192.168.100.11's password: Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 6.14.0-37-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/pro Last login: Sat Jan 31 11:18:50 2026 from 192.168.100.1
A continuación imos provocar un erro de autenticación do servidor, facendo que a clave pública enviada polo servidor non coincida coa clave pública anteriormente aceptada e gardada en known_hosts. Unha forma sinxela de facelo e rexenerar as claves do server; polo que, en primeiro lugar borramos as claves en uso:
$ sudo rm /etc/ssh/ssh_host*
$ sudo ls -lhF /etc/ssh
total 39K -rw-r--r-- 1 root root 494K Apr 11 2025 moduli -rw-r--r-- 1 root root 1.7K Apr 11 2025 ssh_config drwxr-xr-x 2 root root 2 Apr 11 2025 ssh_config.d/ -rw-r--r-- 1 root root 3.2K Apr 11 2025 sshd_config drwxr-xr-x 2 root root 2 Apr 11 2025 sshd_config.d/ -rw-r--r-- 1 root root 342 Dec 7 2020 ssh_import_id
E despois xeramos outras nova coa utilidade ssh-keygen:
$ sudo apt install man $ man ssh-keygen
-A For each of the key types (rsa1, rsa, dsa, ecdsa and ed25519) for which host keys do not exist, generate the host keys with the default key file path, an empty passphrase, default bits for the key type, and default comment. This is used by system administration scripts to generate new host keys.
$ sudo ssh-keygen -A
ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519 $ ls -lhF /etc/ssh <pre> total 51K -rw-r--r-- 1 root root 494K Apr 11 2025 moduli -rw-r--r-- 1 root root 1.7K Apr 11 2025 ssh_config drwxr-xr-x 2 root root 2 Apr 11 2025 ssh_config.d/ -rw-r--r-- 1 root root 3.2K Apr 11 2025 sshd_config drwxr-xr-x 2 root root 2 Apr 11 2025 sshd_config.d/ -rw------- 1 root root 1.4K Jan 31 11:23 ssh_host_dsa_key -rw-r--r-- 1 root root 605 Jan 31 11:23 ssh_host_dsa_key.pub -rw------- 1 root root 505 Jan 31 11:23 ssh_host_ecdsa_key -rw-r--r-- 1 root root 177 Jan 31 11:23 ssh_host_ecdsa_key.pub -rw------- 1 root root 411 Jan 31 11:23 ssh_host_ed25519_key -rw-r--r-- 1 root root 97 Jan 31 11:23 ssh_host_ed25519_key.pub -rw------- 1 root root 2.6K Jan 31 11:23 ssh_host_rsa_key -rw-r--r-- 1 root root 569 Jan 31 11:23 ssh_host_rsa_key.pub -rw-r--r-- 1 root root 342 Dec 7 2020 ssh_import_id
Ó rexenerar as claves, hai unha discrepancia entre a clave pública que emprega agora o servidor para autenticarse fronte ó cliente e a clave que o identifica gardada no arquivo known_hosts do cliente:
$ cat /etc/ssh/ssh_host_ed25519_key.pub ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH9fiQxIEWSehD72yebiEXIG7Mz7AmYIfZ0J2kbHW2DE root@server-ssh $ cat .ssh/known_hosts
|1|5i/66XvBclbTK++bstjQJe9+kXg=|x8KqqZvqfyboLyC6mFcm5iQNhS4= ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGme5EOVsOvOYGmwUlzl4nWtR+x8DdGEgdN6aIfLez2f ...
Isto tradúcese nun erro ó tratar de establecer a conexión:
$ ssh ubuntu@192.168.100.11
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ED25519 key sent by the remote host is SHA256:A7AN8NRsLTxKCKu7N1wd2Rj/gIw3zbzx615B5OttuSk. Please contact your system administrator. Add correct host key in /home/asir/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /home/asir/.ssh/known_hosts:3 remove with: ssh-keygen -f '/home/asir/.ssh/known_hosts' -R '192.168.100.11' Host key for 192.168.100.11 has changed and you have requested strict checking. Host key verification failed.
Na mensaxe de erro indícase que pode ser que alguén esté a suplantar a identidade do server ou que a clave cambiou. Tamén indícanos como facer para eliminar a clave vella do arquivo known_hosts, executando no cliente a utilidade ssh-keygen coa opción –R para eliminar as claves almacenadas no known_hosts asociadas a un equipo:
$ ssh-keygen -f '/home/asir/.ssh/known_hosts' -R '192.168.100.11'
# Host 192.168.100.11 found: line 1 # Host 192.168.100.11 found: line 2 # Host 192.168.100.11 found: line 3 /home/asir/.ssh/known_hosts updated. Original contents retained as /home/asir/.ssh/known_hosts.old
Unha vez eliminada a clave vella, o cliente pode conectarse ó servidor como se fose a primeira vez:
$ ssh ubuntu@192.168.100.11
The authenticity of host '192.168.100.11 (192.168.100.11)' can't be established. ED25519 key fingerprint is SHA256:A7AN8NRsLTxKCKu7N1wd2Rj/gIw3zbzx615B5OttuSk. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.100.11' (ED25519) to the list of known hosts. ubuntu@192.168.100.11's password: Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 6.14.0-37-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/pro Last login: Sat Jan 31 11:22:22 2026 from 192.168.100.1
Acceso dende Microsoft Windows -- Documentación adicional
PuTTY é un dos clientes ssh para Microsoft Windows máis coñecidos. Na páxina web de descargar podemos descargar o programiña e outras utilidades para traballar con ssh, entre as que destacan:
- PuTTY
- cliente ssh/telnet.
- PSCP
- cliente scp (secure-copy).
- PSFTP
- cliente sftp (ftp seguro).
- PuTTYgen
- utlidade para xerar claves de tipo RSA e DSA.
Igual que co cliente ssh en Linux, ó acceder por primeira vez con putty aparece a mensaxe relativa á clave pública do servidor:
Preparando a conexión dende PuTTY
Fig. Configurando a conexión ssh en PuTTY
Inicio de sesión SSH en PuTTY
Fig. Mensaxe indicando que a clave pública proporcionada polo servidor non é recoñecida
Conexión establecida usando PuTTY
O cliente putty garda as claves públicas dos servidores ós que se conecta nunha entrada do rexistro:
Keys no rexistro de Windows
Fig. Clave pública do servidor gardada no rexistro de Windows.
Igual que antes, cambiar as claves no servidor provocará un erro de autenticación. No caso do cliente putty, aparecerá unha mensaxe de erro e a opción de actualizar a clave pública do servidor. Tamén é posible eliminar a clave directamente no rexistro:
Mensaxe de erro nas claves en PuTTY
Fig. Mensaxe de erro ó non coincidir a clave pública enviada polo servidor remoto e a clave pública gardada no rexistro.
Acceso ó servidor ssh por PuTTY
Fig. Unha vez actualizada a clave e autenticados correctamente, iníciase a sesión no equipo remoto