[h]Guía básica conexión por protocolo SSH (servidor, cliente, llaves)[/h]
https://www.wifi-libre.com/img/members/3/manual_ssh_6.jpg
Las iniciales SSH significan “intérprete de órdenes seguro” (Secure SHell).
Se creó para mejorar protocolos como el **telnet **que carecen de cifrado.
Con telnet los datos (y credenciales) circulan en texto claro y es un “problemón”: Un intruso solo tiene que esnifar el trafico para recoger los credenciales y tomar el controlo de nuestro dispositivo.
Era necesario crear un protocolo “seguro”
La primera versión del **ssh **fue lanzada en 1995 por Tatu Ylönen
Hoy en día (y desde el 1999) se usa la segunda implementación que es 100% código libre: OpenSSH
[h]Conceptos básicos[/h]
Es muy simple.
[list=1]
]Por un lado tenemos al “servidor”. Es decir el dispositivo que vamos a controlar remotamente./]
]Por otro lado tenemos el “cliente”. Es decir el dispositivo que se conecta a nuestro servidor para controlarlo/]
[/list]
https://www.wifi-libre.com/img/members/3/how-does-ssh-protocol-work-920x272-SWKuhzNV.png
Una vez que se establece un “túnel” SSH, las ordenes que entro en mi consola SSH “cliente” se ejecutan en el “servidor”.
Sobre la seguridad del protocolo.
SSH permite cifrar las comunicaciones con algoritmos de cifrado robustos.
La conexión se puede hacer por contraseña simple entrada en consola (se desaconseja) o bien mediante un par de llaves (una secreta y una privada)
Este segundo método introduce una dimensión “asimétrica” en el cifrado y es la configuración la más robusta.
Si quieres saber más sobre las técnicas de cifrados empeladas por el ssh:
[list=*]
]¿Cómo funciona el SSH? by/@ hostinger/]
[/list]
[h]Las llaves (cliente)[/h]
Come dije antes es mejor optar por un sistema con llaves publicas y privadas en lugar de una identificación mediante contraseña única.
Vamos a generar llaves para el cliente
En el ejemplo uso un ordenador portátil con Kali linux
No importa el sistema operativo que tengamos instalado: openssh funciona en todos y está muy probablemente instalado.
Para configurar nuestro cliente necesitamos a openssh-client
https://www.wifi-libre.com/img/members/3/manual_ssh_1.jpg
Vamos a generar llaves con cifrado RSA (el más empleado y viene configurado por defecto) de 4096 bits.
2048 bits se considera seguro hoy en día pero nosotros somos espabilados y tenemos un pie en el futuro. 
ssh-keygen -b 4096[list=1]
]Se nos preguntará adónde queremos guardar las llaves.
Recomiendo prensar directo para dejar la ruta por defecto, es decir en un directorio escondido “.ssh” en su carpeta personal. /]
]Se nos preguntará si queremos proteger el acceso a las llaves con una contraseña.
Puede parecer redundante pero no lo es y se debe hacer. Si nuestro cliente está comprometido el servidor no estará comprometido automáticamente./]
[/list]
Una vez hecho veréis una “huella” en consola:
https://www.wifi-libre.com/img/members/3/manual_ssh_2.jpg
La llave publica se puede difundir sin problemas y podéis ver la vuestra en el fichero id_rsa.pub
cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDOdpSZCdZmXh83GLe7fFagxIwnnVfTlC2j+FVD9PblNMN3QPDs6qrliEJbpeixqeDEmF9gPgBVADa5Dj6+0OgkMfzXbQBwdKkZNd3gFX6nAwSPQhoWMc2TibvNKVEskNQCweVbxQK5M2uKSyx29nnYJJqzaJe/PmHTL/gTgILjwAU1JnZO4C3j3HGHHTV8JYmUja46w2WYNW/3Jj5QSFifEjeP0fdQQ4J4gH8htAtlqR6HUjpH3FuACuylVmssoRcdCtoQNBBG8vdMmgbXo36VP7j5hnYoYWwJHUPXxjeqaMMOcLWVucrjhChG33cNgIy3EaAk4FZqZV0hqg0nhsM4Cxm0PohMCB07ITH9Xp04V3bnB0+l6pX55Jpj1MpHIn7QoaZxbC+NiMQJYU69XvskNAm6aXhTlY1FQi5MBU3sOvOIhR7NChhNU1eGxhhh/nK+hlOkIWxnxJGtZnRDwxoZq0jZ1B0y1+h+Lpf+IrAz7Dn+lDzR75EtJLoDEc5FWSHW2G6LRzxs4NOrRS4pnH+arz+ZyxOvalc7F+z3LcYoQ74G9C6svjXrhy0tiXFuRgH37wP+lPDctv50iuUcVnp0tIPWvUxLYn33/41867pJnAIeYD7avceVQZdWnVrdCeUpgV31r9JJgghsQNW1zrSxKit+M3ebuFC1WZL4ityhPw== kcdtv@kaliiznotdead
Copiar la llave y pegar la en un fichero que guardéis en un stick USB o en vuestra cuenta mega.
La cosa es tener la llave lista y accesible para copiar en el ordenador servidor.
[h]Configuración servidor[/h]
En mi caso es un ordenador de sobre mesa con Debian stretch.
El paquete openshh-server viene instalado por defecto
Vamos a introducir en el servidor la llave publica que hemos generado en el cliente
Creamos un directorio para guardar la llave:
mkdir -p ~/.sshY la guardamos en dicho directorio con nombre “authorized_key”
https://www.wifi-libre.com/img/members/3/manual_ssh_3.jpg
Luego se puede repasar un poco el fichero de configuración “sshd_config”.
Su ruta por defecto es /etc/ssh/sshd_config
Los parámetros son comentados (no se ejecutan) con el valor por defecto.
Me explico: Abrir el fichero con un editor de texto (con rpivilegios root)
sudo leafpad /etc/ssh/sshd_configMirren por ejemplo este trozo
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
Nos dice que si queremos deshabilitar el uso de contraseñas que circulan en texto calro debemos poner “no” (por defecto es yes)
Quitamos la almohadilla delante “PasswordAuthentication” y cambianos “yes” por “no” dejando este trozo así:
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no
Podríamos modificar el puerto por defecto (es el 22) o deshabilitar la posibilidad de ejecutar el servidor X (aplicaciones gráficas) para incrementar la seguridad de nuestra conexión.
Este tema está en español y explica gran parte de los parámetros: Los Ficheros de Configuración
[h]Conexión por protocolo ssh[/h]
[list=*]
*]Desde el **servidor **debemos iniciar el servicio
sudo systemctl start ssh*]Desde el cliente nos conectamos al servidor
ssh <ip_servidor>[/list]
Y debemos entrar la contraseña que hemos elegido anteriormente para desbloquear las llaves .
¡Ya está! 
Podéis ver en la captura mi consola pasa de **kali **(cliente, prompt en rojo) a debian (servidor, prompt en verde)
https://www.wifi-libre.com/img/members/3/manual_ssh_5.jpg
Estos son los pasos a seguir para una conexión ssh sencilla en nuestra red local y generalmente son suficientes
En caso de que no funcione se debe echar un ojo a la configuración de su router. Según las interfaces y la configuración: Se debe deshabilitar una(s) regla(s) del firewall, o/y se debe activar el “port forwading” para el trafico TCP en el puerto 22 (si no hemos cambiado).
Y si usamos un firrewall personal en el cliente y/o el servidor debemos obviamente permitir el trafico ssh entre los dos puestos de trabajo.
Para concluir les recomiendo la lectura de los temas en Digital Ocean y especialmente este: SSH Essentials: Working with SSH Servers, Clients, and Keys