Open Broadcaster Software (también conocido por su sigla OBS) es una aplicación libre y de código abierto para la grabación y transmisión de vídeo por internet (streaming), mantenida por OBS Project.
OBS comenzó como un pequeño proyecto creado por Hugh "Jim" Bailey, pero creció rápidamente con la ayuda de muchos colaboradores que trabajan para mejorar la aplicación y para difundir el conocimiento sobre la misma. En 2014, comenzó a desarrollarse una nueva versión conocida como OBS Multiplatform (más tarde renombrada OBS Studio) para soporte multiplataforma, siendo un programa más completo y con una API más potente. OBS Studio es un trabajo en progreso, ya que hasta febrero de 2016 no alcanzó la paridad de características con el OBS Classic (original). Aunque OBS Classic aun está disponible en el sitio, los desarrolladores recomiendan utilizar OBS Studio ya que OBS Classic está considerado como obsoleto. La última versión de OBS Classic es la 0.659b.
Crea escenas con múltiples tipos de fuentes de vídeo, incluyendo la pantalla de tu ordenador, videojuegos, webcams, archivos de vídeo y más.
Transmita sus producciones de vídeo en sitios como Twitch, YouTube o Facebook Live, o grabe sus vídeos localmente para compartirlos.
Características
Transmisión en directo a sitios como Twitch, YouTube, Facebook Live y muchos más, incluyendo tus propios servidores personalizados
Grabación de vídeos para guardar en tu disco duro y compartirlos con tus amigos
Captura y mezcla de vídeo/audio en tiempo real de alto rendimiento. Crea escenas formadas por múltiples fuentes incluyendo capturas de ventana, imágenes, texto, ventanas de navegador, cámaras web, tarjetas de captura y más
Configura un número ilimitado de escenas entre las que puedes cambiar sin problemas a través de transiciones personalizadas
Mezclador de audio intuitivo con filtros por fuente, como puerta de ruido, supresión de ruido y ganancia. Toma todo el control con el soporte de plugins VST
Opciones de configuración potentes y fáciles de utilizar. Añade nuevas fuentes, duplica las existentes y ajusta sus propiedades sin esfuerzo
El panel de ajustes de emisión te da acceso a una gran variedad de opciones de configuración para modificar cada aspecto de tu transmisión o grabación
La interfaz de usuario modular te permite reorganizar la interfaz exactamente como quieras. Incluso puedes abrir cada panel individual en su propia ventana
Escoge entre una variedad de diferentes transiciones personalizables para cuando cambies entre escenas o agrega tus propios archivos de vídeo stinger
Establece teclas de acceso rápido para prácticamente cualquier acción, como cambiar entre escenas, iniciar/detener transmisiones o grabaciones, silenciar fuentes de audio, pulsar para hablar y más
El Modo Estudio te permite previsualizar tus escenas y fuentes antes de mostrarlas en el directo. Ajusta tus escenas y fuentes o crea nuevas y asegúrate de que quedan perfectas antes que de tus espectadores las lleguen a ver
Obtén una visión de alto nivel de tu producción usando la Vista múltiple. Monitorea 8 escenas diferentes y cambia o transiciona a cualquiera de ellas con sólo un clic o doble clic
¡Nos complace anunciar que YouTube se ha convertido en uno de los principales patrocinadores del Proyecto OBS! Desde los primeros días del programa, una gran cantidad de nuestros usuarios han utilizado OBS para crear contenido de video específicamente para YouTube, ya sea transmitido en vivo o grabado para postproducción. Nos sentimos increíblemente honrados de tener a YouTube, la plataforma de creación de contenido más grande de Internet, como uno de nuestros patrocinadores.
YouTube es un pilar de la creatividad en la comunidad de Internet y sirve como nexo para que las personas compartan todo tipo de contenido, incluidas presentaciones en vivo, transmisiones en vivo de contenido de videojuegos, recursos educativos, reseñas de productos, sketches cómicos y mucho más. Fue pionero en una nueva generación de contenido de video en TV, computadoras y dispositivos móviles, al mismo tiempo que proporciona una plataforma que permite a cualquiera crear y hacer crecer una carrera a partir de la creación de contenido de video.
El equipo del Proyecto OBS se enorgullece de desempeñar un papel en brindar servicios a los creadores de contenido en YouTube con herramientas gratuitas y de código abierto, y está increíblemente agradecido con YouTube por apoyarnos mientras continuamos satisfaciendo esas necesidades.
Aprenda cómo descargar, instalar y usar Wget en Windows 10. Por ejemplo, con Wget podemos descargar archivos desde el CMD.
El símbolo del sistema en Windows 10 no se puede comparar con la terminal en Linux. Para compensar sus deficiencias, se pueden instalar herramientas como wget y Cygwin en Windows para obtener más del Command Prompt. Aquí se explica cómo puede instalar y usar wget en Windows 10.
1. INSTALAR WGET
Wget es una herramienta gratuita, pero descargar el archivo correcto es extrañamente complicado. Es difícil saber cuál descargar y uno de los mirrors más populares para EXE es notorio por fallar en Windows 10. Para instalar wget, descargue este archivo de Sourceforge.
Extraiga el archivo y ejecute el .EXE dentro de él. La instalación es bastante sencilla. Excepto el EULA (acuerdo de licencia de usuario final), no hay mayor problema.
Instalar Wget
2. USO DE WGET
Hay dos formas de usar Wget en Windows 10. Esta es una herramienta de línea de comandos, por lo que no tiene una GUI. Usted accede a través del Símbolo del sistema.
Para usarlo desde el símbolo del sistema, puede agregarlo como una variable de entorno o puede ir manualmente al directorio en el que se encuentra la aplicación Wget y usarlo desde allí.
El segundo método no es conveniente si tiene la intención de utilizar esta herramienta a menudo, pero vamos a detallar ambos métodos y puede elegir el que más le convenga.
2.1. EJECUTAR WGET DESDE SU UBICACIÓN DE INSTALACIÓN
Este es el método menos conveniente. Abra File Explorer y vaya a la siguiente ubicación. Habrá un archivo Wget.exe aquí. Realmente solo necesitas la ruta a este archivo. Cópialo en tu portapapeles.
C:\Program Files (x86)\GnuWin32\bin
A continuación, abra el símbolo del sistema e ingrese el siguiente comando para moverse a la ubicación anterior.
cd C:\Program Files (x86)\GnuWin32\bin
Una vez que esté en esta carpeta, puede escribir wget y usar cualquiera de sus funciones y/o parámetros.
2.2. AGREGAR VARIABLE DE ENTORNO
Para tener que moverse a la carpeta bin del donde se ubica wget.exe cada vez que desea utilizar la herramienta consume mucho tiempo. Sin embargo, si lo agrega como una variable de entorno, simplemente podrá escribir wget desde cualquier directorio y usarlo. Necesitará derechos de administrador para hacer esto.
Para agregar wget como una variable de entorno, abra el Explorador de archivos y pegue lo siguiente en la barra de direcciones.
Panel de control\Sistema y seguridad\Sistema
En la columna de la izquierda, haz clic en Configuración avanzada del sistema. En la ventana que se abre, haga clic en Variables de entorno. En la ventana Variables de entorno, seleccione ‘Path‘ en la sección en la parte superior y haga clic en Editar.
En la ventana que se abre, haga clic en Nuevo, luego haga clic en el botón Examinar. Ingresa esta ubicación:
C:\Program Files (x86)\GnuWin32\bin
Agregar variable de entorno
Haga clic en Aceptar en cada ventana para salir.
Usar wget en Windows
Ahora, cuando abra el Símbolo del sistema, puede escribir wget sin importar en qué directorio/carpeta se encuentra y podrá acceder a esta aplicación y usar sus comandos.
Tenlos por culpables, oh Dios; ¡que caigan por sus mismas intrigas! Echalos fuera por la multitud de sus transgresiones, porque se rebelan contra ti. (Salmos 5:10)
La primera vez que nos conectamos a un servidor SSH obtenemos mensajes de advertencia sobre el fingerprint similares al siguiente:
The authenticity of host '192.168.1.123 (192.168.1.123)' can't be established.ECDSA key fingerprint is SHA256:TiqZXJITgH/kUE9WoNP4TF2xkescmKxFIe33TpsQRC7.Are you sure you want to continue connecting (yes/no)?
Esta advertencia es para prevenir que nos conectemos a un servidor SSH malicioso y evitar ataques man in the middle. En lenguaje llano, la advertencia nos está preguntando si estamos seguros de conectarnos al servidor SSH que tiene el fingerprint SHA256:RiqYXJITgH/kUE9WoNP4TF2xkescmKxFIe33TpsQRC8.
¿QUÉ ES EL FINGERPRINT DE UN SERVIDOR SSH?
En el momento que se generan las claves pública y privada de un servidor SSH, se genera una huella digital única para cada una de estas llaves. Esta huella digital única es el fingerprint y su principal función es identificar de forma inequívoca un servidor.
¿QUÉ UTILIDAD TIENE EL FINGERPRINT DE UN SERVIDOR SSH?
En el momento que nos conectamos al servidor SSH se inicia un proceso autenticación. El proceso es el siguiente:
Cuando el cliente se conecta al servidor consulta el archivo ~/.ssh/known_hosts. El fichero ~/.ssh/known_hosts es una base de datos de fingerprints de los servidores SSH a los que nos hemos conectado.
Si el fingerprint del servidor SSH al que nos conectamos está almacenado en ~/.ssh/known_hosts, querrá decir que no es la primera vez que nos conectamos al servidor. Por lo tanto a priori se trata de un servidor conocido y seguro al que nos podremos conectar sin ningún tipo de problema.
En el caso que el fingerprint del servidor SSH no esté almacenado en nuestro ~/.ssh/known_hosts nos aparecerá el mensaje de advertencia que hemos visto al inicio del artículo. En este caso deberemos proceder según se indica en los puntos 4 y 5.
Si no es la primera vez que nos conectamos al servidor y nos aparece la advertencia tenemos que responder no y abortar la conexión. Si nos encontramos con esta situación pueden estar pasando 2 cosas. La primera de ellas no es peligrosa y es que el administrador del servidor haya generado un par de llaves nuevo. Si este es el caso nos podemos conectar al servidor sin ningún tipo de problema. La segunda es que estemos recibiendo un ataque del tipo man in the middle, y que el servidor al que nos estamos conectando sea un servidor malicioso que pretende robar nuestras credenciales. Una vez robadas nuestras credenciales el atacante podrá conectarse al servidor real en nombre nuestro. Si este es el caso aborten de inmediato la conexión al servidor.
Si aparece el mensaje de advertencia y es la primera vez que nos conectamos al servidor no nos debemos preocupar. Tan solo tenemos que comprobar que el fingerprint de la advertencia corresponda al fingerprint del servidor SSH. Si el fingerprint es correcto escribiremos yes, presionaremos la tecla Enter y seguidamente nos conectaremos al servidor. En el momento que nos hayamos conectado al servidor, el fingerprint del servidor se almacenará en nuestro archivo ~/.ssh/known_hosts. En el caso que el fingerprint no sea correcto debemos responder no y abortar la conexión de inmediato.
Por lo tanto queda claro que el fingerprint es una mecanismo para asegurar que nos estamos conectado al servidor al que realmente queremos conectarnos.
¿CÓMO PODEMOS SABER EL FINGERPRINT DE NUESTRO SERVIDOR SSH?
Nos dirigimos al directorio donde se almacenan las claves privadas y públicas de nuestro servidor. Para ello ejecutamos el siguiente comando en la terminal:
cd /etc/ssh
Para visualizar nuestras claves privadas ejecutamos el siguiente comando en la terminal:
El fingerprint de cada una de las llaves se almacena en los ficheros que terminan con la extensión .pub.
Si en el inicio del post consultan el mensaje de advertencia que obtengo al conectarme al servidor verán que se está usando la llave ECDSA. Por lo tanto consultaré el fingerprint de la llave ssh_host_ecdsa_key.pub ejecutado el siguiente comando en la terminal:
ssh-keygen -l -f ssh_host_ecdsa_key.pub
Cada una de los términos del comando tiene el siguiente significado:
ssh-keygen: Utilidad que uso para conseguir mi propósito. -l: Opción que indica a ssh-keygen que muestre el fingerprint. -f: Opción para poder especificar el nombre de una llave. ssh_host_ecdsa_key.pub:Nombre de la llave que quiero averiguar el fingerprint.
El resultado obtenido de ejecutar el comando es el siguiente:
El fingerprint mostrado es el mismo que el que aparece en el mensaje de advertencia de conexión al servidor. Por lo tanto nos podemos conectar al servidor sin ningún tipo de temor.
COMO VER LA FINGERPRINT DE LOS SERVIDORES A LOS QUE ME HE CONECTADO
Como hemos dicho anteriormente, el archivo ~/.ssh/known_hosts almacena la totalidad de fingerprints de los servidores a los que nos hemos conectado.
Por lo tanto para consultar la totalidad de fingerprints tan solo tenemos que ejecutar el siguiente comando en la terminal:
cat ~/.ssh/known_hosts
Procediendo de la forma que describimos en el artículo conseguiremos obtener mayor seguridad en el momento de conectarnos a servidores SSH.
ssh es quizás (en mi opinión) la mejor herramienta de comunicación que existe cuando se trata de establecer contacto con un servidor remoto Linux. Al decir remoto, me refiero que puede estar situado en el escritorio de al lado o al otro lado del mundo, en la LAN o en alguna parte de Internet. Claro, el servidor tiene que estar ejecutando el demonio o servicio sshd que normalmente funciona en el puerto 22 (ver el artículo servicios para aprender más sobre como iniciarlo). La ventaja de ssh (Secure SHell, por cierto) es que es seguro, el tráfico entre los equipos es encriptado, estable, robusto, fácil de actualizar y usar, etc. Ha tenido serios bugs como cualquier otro programa pero como buen software open source es rápidamente actualizado en cuestión de horas literalmente, cuando nuevas vulnerabilidades se le conocen, además de que tiene utilerías agregadas como scp y sftp, así como clientes excelentes tanto en Linux y Windows, en fin altamente recomendable su uso en la vida diaria de cualquier administrador o usuario Linux.
¿Si todo es tan maravilloso con ssh?, ¿Entonces cual es el problema?
Muy bien. El escenario es el siguiente para entender bien lo que sucede. El cliente se conecta (por primera vez) digamos desde un equipo Windows con un cliente ssh como puede ser putty (si no usas putty, te estás perdiendo el mejor cliente ssh del mundo) a un servidor Linux y aparece el siguiemte cuadro de diálogo: (algo similar pero en modo de texto aparecería desde una consola de texto):
- mmmmm, ¿Qué diablos es esto?, No tengo tiempo de leer eso, presionaré Si, bien ya entró.
Esto es lo que el usuario común hará al no comprender realmente lo que sucede entre el cliente y el servidor ssh. Al tratarse de un protocolo de comunicación altamente seguro y con tráfico encriptado de punto a punto, entran en juego algoritmos de encriptación. Cada servidor ssh tiene una huella digital única (fingerprint) generada al momento de la instalación. Este fingerprint identifica al servidor en específico. Traduciendo el diálogo anterior diría lo siguiente:
La llave del servidor anfitrión no está registrada en el registro. Tu
no tienes garantía que el servidor es la computadora que tu
piensas que es.
La clave fingerprint del servidor es:
1024 63:d1:48:fc:9f:7e:1e:0d:27:d1:7b:23:75:06:34:a2
Si tu confias en este host, presiona Si para añadir la clave al
cache de PuTTY y establecer la conexión.
Si quieres conectarte solo una vez, sin
añadir la clave al cache, presiona No.
Si no confias en este host, presiona Cancelar para abandonar la
conexión.
¿Comienza a quedar claro?, se nos está advirtiendo que el equipo al que queremos conectarnos puede no ser el nuestro, es decir SE TIENE QUE ESTAR SEGURO QUE AL SERVIDOR LINUX QUE ME ESTOY CONECTANDO ES REALMENTE EL MIO y esto solo se logra conociendo previamente el fingerprint del servidor y tenerlo en la Palm, en una nota, o en un papel en la cartera o en un block de notas de la computadora de la casa u otra ubicación, como sea. Si por razones de trabajo u otras, se requiere acceder a un servidor de producción de forma remota ES SUMAMENTE IMPORTANTE CONOCER EL FINGERPRINT DEL SERVIDOR para estar seguro que no me estén interceptando (en un momento se explica esto, calma).
Ok, si, si, pero ¿Como diablos se cuál es el fingerprint de mi servidor?
Ábrete una terminal en tu servidor Linux y te cambias al directorio de configuración de ssh:
#> cd /etc/ssh
#> ls -l
total 173
drwxr-xr-x 2 root root 344 Feb 18 00:18 .
drwxr-xr-x 107 root root 9088 Feb 17 22:57 ..
-rw------- 1 root root 132839 Jan 27 07:51 moduli
-rw-r--r-- 1 root root 2517 Jan 27 07:51 ssh_config
-rw------- 1 root root 668 Oct 20 21:26 ssh_host_dsa_key
-rw-r--r-- 1 root root 600 Oct 20 21:26 ssh_host_dsa_key.pub
-rw------- 1 root root 525 Oct 20 21:26 ssh_host_key
-rw-r--r-- 1 root root 329 Oct 20 21:26 ssh_host_key.pub
-rw------- 1 root root 887 Oct 20 21:26 ssh_host_rsa_key
-rw-r--r-- 1 root root 220 Oct 20 21:26 ssh_host_rsa_key.pub
-rw-r----- 1 root root 3482 Feb 18 00:18 sshd_config
Notarás que existen algunos archivos con terminación .pub, pues esta es la parte pública de las llaves de tu servidor ssh pero en forma de un fingerprint, es decir la llave pública generada por los algoritmos dsa o rsa. Generalmente, por default, ssh guarda su llave pública o fingerprint en este caso en el archivo ssh_host_key.pub, si mostramos su contenido se verá lo siguiente:
#> more ssh_host_key.pub
1024 35 161635971725059974812816613188513865727625643323552121445765023013612487474922451108
80703826701959121218181176403629257123317219888287730368486491009806579706597689031242574789
96617659498748196451487737641156043897343204483595648176422701566886723150233655375182156814
44474810364877205687200614515477060949257 root@linux
No nos dice mucho, pero si usamos la herramienta adecuada de las que vienen junto con ssh, se podrá conocer el fingerprint del servidor en un formato de una cadena de números hexadecimales:
Nótese que es el mismo fingerprint mostrado por el diálogo de PuTTY con lo que ahora si estamos seguros que es nuestro servidor. En este punto queda claro entonces que la línea anterior es la que deberás conocer previamente y apuntarla y/o traerla contigo de alguna manera para cuando te conectes remotamente a tu servidor Linux estés totalmente seguro que es el tuyo.
NOTA: ssh puede usar dos protocolos: versión 1 y versión 2. La versión 1 es totalmente obsoleta y con algunas vulnerabilidades conocidas y por lo tanto es inseguro y no aconsejable su uso, se incluye por compatibilidad, pero hay que usar el 2. Si usas el protocolo 1 entonces tu archivo de llave privada (del lado del servidor solamente) es ssh_host_key (rsa1). Si usas el protocolo 2 tus archivos de llave privada son ssh_host_rsa_key y ssh_host_dsa_key que se usan indistintamente por parte de ssh, aumentando asi el nivel de complejidad en el encriptado del tráfico. Para asegurarte que solo uses la versión 2 de ssh incluye o asegúrate de tener la siguiente línea en el archivo de configuración de ssh (/etc/ssh/sshd_config).
Protcol 2
IMPORTANTE: Obsérvese que cuando hice el ejemplo de arriba, a propósito dejé la línea de la variable Protocol como se queda por default en muchas distros y que es la siguiente:
Protcol 1,2
Aceptando ambos protocolos y en primer lugar toma el 1, como se aprecia perfectamente en el ejemplo, al observar que el fingerprint corresponde al archivo de llave privada de la versión 1. Esto es algo inaceptable en un servidor Web o de producción en alguna empresa, asi que chécalo bien si es que eres el responsable d e los sistemas Linux.
¿Y quien es Man in the middle (MiM) o el hombre intermedio?
Ahora te preguntarás, ¿Si ssh es tan seguro, entonces cual es el riesgo, o porque la necedad de tener que conocer los fingerprints de mis servidores Linux?. ssh es seguro y confiable una vez establecida la comunicación entre el cliente y el servidor, pero en la vida real no todo es tan perfecto y existe una técnica de hackeo (¿o será hacking?) llamada Man in the middle -hombre intermedio-, que consiste en que el hacker (hombre intermedio) se coloca entre dos equipos (cliente y servidor) y el también es un servidor ssh pero obviamente con otro fingerprint distinto al servidor ssh genuino. Entonces, una vez montado el ataque, es decir, lograr que el tráfico del cliente dirigido al puerto 22 del servidor real se desvié al puerto 22 del hacker, este "cachará" los paquetes en su servidor ssh y los reenviará al servidor ssh genuino y cuando este responda al cliente pasará de vuelta por el equipo del hacker, pudiendo este con una herramienta como wireshark "observar" el tráfico entre los dos y como se desencripta lo que reciba/manda para poder ser pasado por su propio servidor ssh, entonces conocerá TODO lo que circula entre los dos extremos pero desencriptado.
Se entiende ahora la importancia de no presionar "Si" de primera instancia porque si algún hacker en nuestra empresa, ciberinternet, escuela, universidad, etc. logró lo anterior, entonces cuando nos conectemos al servidor ssh la primera vez VEREMOS SU FINGERPRINT NO EL NUESTRO, y si lo conocemos previamente entonces es obvio que no es nuestro servidor y no deberemos conectarnos y por supuesto avisar inmediatamente de la situación al administrador de sistemas del lugar.
Generalmente los ataques "Man in the middle" se logran realizar cuando en la red hay switches mal configurados o no monitorizados mediante técnicas conocidas como envenenamiento arp (arp poissoning), que en pocas palabras consiste en lograr que el switch canalize o envié todos los paquetes de todos sus puertos al puerto del hacker. Es decir corrompiendo las tablas arp (la relación de la dirección IP-dirección MAC) del switch. Tal vez las siguientes imágenes clarifiquen esto:
La conclusión importante de todo esto es que SSH ES TOTALMENTE SEGURO Y CONFIABLE, EL PROBLEMA ESTÁ EN LA RELATIVA FACILIDAD PARA REALIZAR SUPLANTACIONES TIPO MAN IN THE MIDDLE, QUE NO ES PROBLEMA DE LA APLICACIÓN SSH Y LA INSEGURIDAD PRODUCIDA ES POR PARTE DEL USUARIO QUE NO VERIFICA EL FINGERPRINT QUE SEA VÁLIDO O CONOCIDO POR ÉL.
¿Cómo hago para ver los fingerprints de los servidores ssh que ya he aceptado?
En Linux, en tu cuenta que uses se genera un directorio oculto llamado .ssh dentro de el encontrarás un archivo llamado known_hosts que si ejecutas el programa ssh-agent:
$> ssh-agent -l -f known_hosts
te dará una lista de los fingerprints de los hosts a los que te has conectado, basta con eliminar el renglón del host que quieras o eliminar todo el archivo para que la siguiente vez que te conectes al servidor ssh te pregunte de nuevo que si lo aceptas o no.
En Windows con PuTTY, en el menú de la ventana de la termina que se abre hay una opción "event log" donde se observa los fingerprints del servidor al que estás conectado. Si buscas en el registro de Windows "putty" te da la siguiente llave:
Y es donde deja el registro de los fingerprints que has usado, pero no entiendo como los guarda porque deja una cadena muy larga y no se aprecia el fingerprint realmente, aunque si queda claro el servidor del que pertence, basta con que borres la clave del registro correspondiente y te volverá a preguntar la siguiente vez que te conectes.
Quiero cambiar mis archivos de fingerprint de mi servidor por otros ¿Cómo se hace eso?
Es perfectamente posible y hasta recomendable cada cierto tiempo en un servidor expuesto al Internet por ejemplo, cambiar el fingerprint de ssh. Para hacer esto usaremos nuestra ya conocida herramienta ssh-keygen: Veámoslo por pasos para dejarlo bien claro:
1er. Paso Cambiarse a /etc/ssh, no tiene que ser forzosamente aqui pero por cuestiones de organización (y por que aqui están las llaves originales) dejemos nuestras nuevas llaves aqui.
#> cd /etc/ssh
2do. Paso Asumimos que solo se trabajará con el protocolo 2, asi que debemos de generar archivos de llaves para los algoritmos dsa y rsa:
#> ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): /etc/ssh/mi_llave_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/mi_llave_rsa.
Your public key has been saved in /etc/ssh/mi_llave_rsa.pub.
The key fingerprint is:
e1:40:bb:57:ae:62:dd:bc:a2:3c:3f:35:63:d2:ab:62 root@linux
#>
Se usa la opción -t para indicar el tipo de algoritmo en este caso rsa, se detiene la ejecucción y pregunta por el nombre del archivo donde se guardará la llave privada, indiqué: /etc/ssh/mi_llave_rsa, hay que indicar la ruta completa. Y después pregunta por una contraseña (passphrase), que cuidado!!!!, NO hay que poner nada. Es una llave privada no expuesta a nadie, y ssh en llaves generadas solo para el uso de archivos del mismo servidor necesita NO tener contraseña.
Repetimos lo mismo pero ahora para generar el archivo con dsa:
#> ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa): /etc/ssh/mi_llave_dsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/mi_llave_dsa.
Your public key has been saved in /etc/ssh/mi_llave_dsa.pub.
The key fingerprint is:
01:aa:d9:9e:33:f1:ea:50:d4:be:e8:e7:dd:a2:ce:de root@linux
#>
Tenemos ya, entonces, cuatro archivos, dos con las llaves privadas y dos con las llaves públicas, que son las que se exportan al cliente al momento de aceptarse la conexión:
#> ls -l mi_llave*
-rw------- 1 root root 668 Feb 19 00:53 mi_llave_dsa
-rw-r--r-- 1 root root 602 Feb 19 00:53 mi_llave_dsa.pub
-rw------- 1 root root 883 Feb 19 00:48 mi_llave_rsa
-rw-r--r-- 1 root root 222 Feb 19 00:48 mi_llave_rsa.pub
3er. Paso Hay que reconfigurar el archivo de configuración de ssh (/etc/sshd/sshd_config) donde agregaremos la variable HostKey dos veces indicando en cada una la ruta y archivos recien creados, veamos el bloque completo de esa parte del archivo de configuración como debe quedar.
# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
#HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/mi_llave_rsa
HostKey /etc/ssh/mi_llave_dsa
Obsérvese que aparecen comentadas con un # los archivos de llaves originales, esto es normal, porque son el default.
Listo es todo, ssh recibió una nueva huella digital que lo identifique.
¿Que pasará si nos conectamos de nuevo desde Windows con el cliente PuTTY?, veamos el mensaje tan apremiante que nos manda:
Es muy distinto al del primer ejemplo. Debido a que ya se tiene almacenado en el cache del cliente la llave pública, su fingerprint, y al no concordar en este intento de conexión , ya que el servidor tiene un nuevo fingerprint, nos lo advierte. ESTO ES PRECISAMENTE O ALGO MUY SIMILAR LO QUE SE VERÍA SI HAY UN ATAQUE MAN IN THE MIDDLE, ya que previamente nos hemos estado conectando siempre a nuestro servidor sin ningún mensaje, y de repente aparece esto y si no se ha cambiado el fingerprint o nadie aviso nada, cuidado habrá que investigar. Esto es a lo que me refería cuando mencionaba mas atrás que ssh es seguro, lo que no es seguro es que alguien se nos ponga en medio y peor aun que no hagamos caso a los mensajes. En el primer párrafo dice:
La llave del servidor no concuerda con la que PuTTY tiene
guardada en su registro. Esto significa que o el
administrador ha cambiado la llave del host, o que te estás
conectando a otra computadora que pretende
ser el servidor.
Mas claro ni el agua. En fin, en este caso se puede perfectamente apreciar que el fingerprint que muestra el diálogo es el mismo que se generó cuando creamos el archivo con tipo rsa:
e1:40:bb:57:ae:62:dd:bc:a2:3c:3f:35:63:d2:ab:62
Asi que con toda seguridad procedemos a presionar Si, sabiendo que SI es nuestro servidor.
Ojalá te sirva esta ayuda y si tienes dudas, comentarios, ampliaciones del documento, etc. son bienvenidas.
