Herramientas de usuario

Herramientas del sitio


sad:ubuntu:p9

¿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

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 <Enter> 3 veces

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

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 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

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

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.

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

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

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\""
sad/ubuntu/p9.txt · Última modificación: 2019/01/04 13:18 (editor externo)