====== ¿Qué es SSH? ======
Secure Shell (SSH) es un protocolo de red para la comunicación de datos segura, servicios de shell remotos o ejecución de comandos y otros servicios de red seguros entre dos ordenadores conectadas a través de un canal seguro sobre una red insegura: un servidor y un cliente (ejecutando un servidor SSH y programas de cliente SSH, respectivamente)
====== ¿Qué son las llaves SSH? ======
En los sistemas tipo Unix, la lista de claves autorizadas se almacena en la carpeta de inicio del usuario que puede iniciar sesión de forma remota, en el archivo ~/.ssh/authorized_keys. Este archivo solo es respetado por ssh si no se puede escribir con nada aparte del propietario y la raíz.
Cuando la clave pública está presente en un lado y la clave privada coincidente está presente en otro lado, ya no es necesario escribir la contraseña.
La clave privada también se puede buscar en lugares estándar, pero su ruta completa también se puede especificar como una configuración de línea de comandos (el modificador -i para ssh). La utilidad ssh-keygen produce las claves pública y privada, siempre en pares.
En esta practica, veremos cómo hacer lo siguiente:
* Crearemos una infraestructura clave SSH entre Ubuntu y Fedora.
* Usaremos ssh-keygen para crear un par de claves privadas / públicas para el usuario student en Ubuntu.
* Colocaremos la clave pública en el servidor de Fedora en el directorio apropiado para el usuario estudiante.
* Utilizaremos la clave privada de Ubuntu para autenticar e iniciar sesión en el servidor de Fedora como estudiante sin una contraseña.
* Utilizaremos la clave privada de Ubuntu para autenticar y ejecutar el comando contra el servidor de Fedora como estudiante sin una contraseña.
====== Creamos el directorio .ssh ======
student@ubuntu12:~$ mkdir -p .ssh
student@ubuntu12:~$ ls -ld .ssh
En mi caso el permiso es 775.
Esto es un problema porque no quiero en nadie tenga acceso en un futuro a mis llaves ssh (ssh keys)
student@ubuntu12:~$ chmod 700 .ssh
Ahora solo el usuario puede leer, escribir y ejecutar en el directorio .ssh
student@ubuntu12:~$ ls -ld .ssh
{{:sad:ubuntu:p9:01.png?400|}}
===== Creamos el par de claves =====
student@ubuntu12:~$ cd .ssh
student@ubuntu12:~/.ssh$ ssh-keygen -t rsa -b 4096
ssh-keygen es la instruccion que genera el par de claves publica y privada.
"-t" Especifica el modo de encriptación
"-b" Especifica la longitud de la clave, por defecto 2048
pulsamos 3 veces
{{:sad:ubuntu:p9:02.png?400|}}
====== Establecemos los permisos a las claves SSH ======
student@ubuntu12:~/.ssh$ ls -l
student@ubuntu12:~/.ssh$ chmod 600 *
Quermos hacer mas seguro ela acceso a las claves
student@ubuntu12:~/.ssh$ ls -l
student@ubuntu12:~/.ssh$ file id_rsa
id_rsa, es el fichero de la clave privada
student@ubuntu12:~/.ssh$ file id_rsa.pub
id_rsa.pub, es la clave pública que se coloca en otros servidores para configurar SSH de forma segura.
vamos al **fedora** y ejecutamos ifconfig -a
{{:sad:ubuntu:p9:04.png?400|}}
para ver que el openssh-serves está instalado
nos aseguramos que sshd está corriendo
[student@fedora14 ~]$ rpm -qa | grep "openssh-server"
si no esta instalado utilizamos el comando yum
----
[root@fedora14 student]# yum update openssh-server
[root@fedora14 student]# yum install openssh-server
para ver si sshd esta corriendo
[root@fedora14 student]# ps -eaf | grep sshd | grep -v grep | wc -l
si sale 0 es que no se está ejecutando
si sale 1 es que se está ejecutando, pincha en este enlace [[sad:ubuntu:p9#creamos_el_directorio_ssh1|Pincha aqui si sale 1]]
¿Por qué sshd no se está ejecutando aunque openssh-server se instaló previamente y ahora se actualiza?
[root@fedora14 student]# ls -l /etc/rc5.d/* | grep ssh
Nota:
Estamos comprobando si hay un script de inicio en el nivel de ejecución 5 para sshd. Hay que recordar que run-level 5 es el modo gráfico multiusuario donde se montan los sistemas de archivos y la red está activa.
El resultado nos muestra que solo hay un script kill, pero no un script de inicio. Todos los scripts que comienzan con una "K" son scripts de eliminación, y todos los scripts que comienzan con una "S" se consideran scripts de inicio.
Por lo tanto, si no hay un script de inicio para sshd, eso explicaría por qué sshd no se está ejecutando.
Usemos chkconfig para verificar que no haya un script de inicio para sshd.
[root@fedora14 student]# chkconfig --list | grep ssh
chkconfig: actualizaciones y consultas de información de nivel de ejecución para los servicios del sistema.
chkconfig tiene cinco funciones distintas: agregar nuevos servicios para administración, eliminar servicios de administración, enumerar la información de inicio actual para los servicios, cambiar la información de inicio de los servicios y verificar
El estado de inicio de un servicio en particular.
Los niveles de ejecución 0 a 6 no tienen un script de inicio para sshd.
Para crear los scripts de inicio para sshd
[root@fedora14 student]# chkconfig sshd --level 2345 on
[root@fedora14 student]# chkconfig --list | grep ssh
Creamos los scripts de inicio SSHD para el nivel de ejecución 2, 3, 4 y 5.
chkconfig ahora muestra que existe un script de inicio para los niveles de ejecución 2, 3, 4 y 5.
Verificar que los scripts de inicio se hayan creado usando el comando find.
[root@fedora14 student]# find /etc/rc[0-9].d/* -name "
"
find /etc/rc[0-9].d/*, Busca archivos y directorios en /etc/, que empiezan por rc y necesita un numero despues del "rc" y antes del ".d". (por ejemplo, rd2.d).
Los scripts de inicio SSHD comienzan con una "S".
-name "S*sshd*", significa búsqueda de cualquier cosa que comience con una "S" y contenga sshd después de la "S".
Ahora ya podemos comenzar el servicio
[student@fedora14 ~]$ service sshd start
Verificamos que está corriendo
[student@fedora14 ~]$ ps -eaf | grep sshd | grep -v grep
----
====== Creamos el directorio .ssh ======
[student@fedora14 ~]$ mkdir -p .ssh
[student@fedora14 ~]$ ls -ld .ssh
[student@fedora14 ~]$ chmod 700 .ssh
[student@fedora14 ~]$ ls -ld .ssh
{{:sad:ubuntu:p9:05.png?400|}}
====== Creamos el fichero de autorizacion ======
[student@fedora14 ~]$ cd .ssh
[student@fedora14 ~]$ touch authorized_keys
El fichero de autorizacion de claves contiene todos las claves publicas de los servidores en los que estará autentificado el servidor fedora
[student@fedora14 ~]$ ls -l authorized_keys
[student@fedora14 ~]$ chmod 600 authorized_keys
Le damos solo permisos al usuario
[student@fedora14 ~]$ ls -l authorized_keys
{{:sad:ubuntu:p9:06.png?400|}}
** Volvemos al ubuntu**
student@ubuntu12:/$ cd /home/student/.ssh/
student@ubuntu12:/$ scp id_rsa.pub student@192.168.153.48:/home/student/.ssh/
Reemplazamos la ip por nuestra ip del Fedora
Responder "sí"
La huella (fingerprint) RSA se agregará al archivo known_hosts del usuario.
La huella de RSA se almacena en **/home/student/.ssh/known_hosts
**
Al iniciar las siguientes sesiones de ssh, el cliente ssh identificará el nombre de host y lo buscará en el archivo **known_hosts** para encontrar la clave de host ssh previamente registrada para el servidor remoto.
{{:sad:ubuntu:p9:07.png?400|}}
Volvemos al fedora y añadimos el fichero id_rsa.com en el fichero de claves autorizadas
[student@fedora14 .ssh]$ cd /home/student/.ssh/
[student@fedora14 .ssh]$ ls -l
[student@fedora14 .ssh]$ cat id_rsa.pub >> authorized_keys
[student@fedora14 .ssh]$ cat authorized_keys
{{:sad:ubuntu:p9:08.png?400|}}
**NOTA** el la pantalla que aparece justo encima de esta nota el fichero **authorized_keys** está mal escrito, le falta la **s** (sino no funciona)
====== Testeando la conexion SSH ======
student@ubuntu12:~.ssh$ ssh -i /home/student/.ssh/id_rsa student@192.168.153.48
[student@Fedora14 ~]$ hostname
[student@Fedora14 ~]$ uptime
[student@Fedora14 ~]$ who
[student@Fedora14 ~]$ w
[student@Fedora14 ~]$ exit
volvemos al ubuntu
{{:sad:ubuntu:p9:09.png?400|}}
''**Print de pantalla que hay que entregar**''
student@ubuntu12:~.ssh$ ssh -i /home/student/.ssh/id_rsa student@192.168.153.48 "uptime"
student@ubuntu12:~.ssh$ ssh -i /home/student/.ssh/id_rsa student@192.168.153.48 "uname -a"
student@ubuntu12:~.ssh$ ssh -i /home/student/.ssh/id_rsa student@192.168.153.48 "echo \"tu nombre\""