miércoles, 13 de enero de 2021

No matching host key type found



Cómo solucionar el error "no matching host key type found. Their offer: ssh-dss".



Tuve que crear un script que se conectara a un host externo vía SSH. Al probar la conexión manualmente para ver que podía establecerse, me encontré con el siguiente problema:

HOST # sftp usuario@host Unable to negotiate with 1.2.3.4 port 22: no matching host key type found. Their offer: ssh-dss Connection closed

Parece que el otro extremo corre una versión antigua (muy antigua) de OpenSSH, por lo que hay que indicarle explícitamente a la última versión de OpenSSH (es decir, la versión que ejecutamos en nuestro host) que use el algortimo "ssh-dss" para establecer la conexión.

Para ello, deberemos usar una opción en el comando ssh (las opciones se añaden con el parámetro -o seguido de la opción que querramos añadir) del siguiente modo:

-oHostKeyAlgorithms=+ssh-dss

De esta forma, el comnando completo queda así:

HOST # sftp -oHostKeyAlgorithms=+ssh-dss usuario@host

Tras usar el comando ssh con el parámetro indicado, ya podremos establecer la conexión con el host en cuestión con normalidad y ya no nos saltará el mensaje de error.

Como curiosidad, si queremos averiguar qué versión de OpenSSH corre en el otro extremo, podemos usar la opción "-vvv" de ssh para ver las versiones local y remota:

debug1: Local version string SSH-2.0-OpenSSH_8.4 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2p2+sftpfilecontrol-v1.3-hpn13v12
0

miércoles, 23 de septiembre de 2020

Qué es y cómo apuntarse a Windows Insider



¿Qué es Windows Insider? ¿Cómo enrolar un ordenador al programa?



Windows Insider es una iniciativa de Microsoft destinada a los usuarios de Windows que permite a quien esté apuntado en ella probar versiones preliminares (o nuevas características) del sistema operativo Windows antes de que estas sean lanzadas al gran público. A cambio, Microsoft pide a los Insiders sus opiniones respecto a las nuevas funcionalidades de cara a mejorar el producto.

Este programa fue anunciado el 30 de septiembre de 2014 junto con Windows 10. A finales de ese mismo año, alrededor de 1,5 millones de personas ya se habían instalado la primera preview de la siguiente build de Windows 10 y ya estaban flighting.


Flighting



Flighting es un término inventado por el departamento de marketing de Microsoft usado para denominar el proceso de ejecutar las compilaciones de Windows 10 Insider Preview. Este proceso incluye:

• Configurar nuestro dispositivo en uno de los canales de Windows Insider.
• Instalar las actualizaciones preview (de vista previa) de ese canal.
• Ejecutar y probar esas compilaciones previas.


Canales



Microsoft divide el programa Insider en 5 canales, donde 2 de ellos son sólo para uso interno, es decir, solo visibles por sus empleados.

El primer canal se llama Canary, y es donde los desarrolladores de Microsoft proponen y prueban por primera vez nuevas funciones para Windows.

Una vez creada una nuva función, esta llega al canal Dev y se libera al público para que de su feedback.

Una vez testeadas en el canal Dev, las actualizaciones vuelven a un canal interno, el canal Microsoft, donde además de los desarrolladores, el resto de empleados de Microsoft pueden también probarlas.

Una vez pulidas por los programadores tras el feedback recibido desde Dev, las actualizaciones pasan del canal Microsoft al canal Beta, volviendo a ser públicas.

En última instancia, las actualizaciones llegan al canal "Release Preview", donde los Insiders reciben las próximas actualizaciones acumulativas unos días antes de su lanzamiento oficial, para acabar de pulir incompatibilidades o problemas derivados de hardware poco común.

No hace falta decir que al canal Dev llegan muchas más actualizaciones que al canal Beta, pero cuando las actualizaciones llegan al canal Beta, estas ya han sido pulidas y funcionan mejor que cuando llegaron a Dev. Por último, las Release Preview apenas recibirán builds, aunque días antes de que se lance una gran actualización se envían allí para que puedan ser probadas anticipadamente por los Insiders.


Ventajas y desventajas



La ventaja principal de este programa es la posibilidad de ser una de las primeras personas en probar cada nueva función de Windows. Otra ventaja de Insider es que siendo miembro del programa tienes Windows gratis, pues una vez que inscritos en el programa podemos descargarnos la ISO de la última build disponible de Windows dntro del programa.

En el otro lado se encuentra la inestabilidad que puede padecer un PC al usar versiones no finales de un producto, con culegues ocasionales y problemas varios.


Cómo apuntarse a Windows Insider



Para apuntarse a Windows Insider, hace falta un ordenador con Windows 10.

Ir a Inicio, botón derecho y clic en configuración:


Una vez allí, ir a Actualización y seguridad y luego a Programa Windows Insider:


A continuación, clicar el botón "Comenzar" y acto seguido, vincular una cuenta:


Nos registramos en el programa Windows Insider y aceptamos las condiciones de uso:


Y por último, elegimos el canal que queramos probar.


A partir de este momento, ya recibiremos las actualizaciones lanzadas desde el canal seleccionado.


Fuentes:

https://insider.windows.com/es-es/
0

miércoles, 16 de septiembre de 2020

Rutas estáticas persistentes en SLES



Cómo crear (y eliminar) rutas estáticas persistentes en un SUSE Linux Enterprise Server.



Si añadimos una ruta estática a un SUSE Linux Enterprise Server con el comando ip route add y reiniciamos la máquina después, comprobaremos que las rutas añadidas de esta manera se pierden tras un reinicio, es decir, son temporales.

Para añadir rutas estáticas persistentes a un SLES, es decir, rutas que se mantengan en el sistema operativo tras reiniciar la máquina, deberemos editar dos archivos: /etc/sysconfig/network/routes y /etc/sysconfig/network/ifroute-* y añadirlas en uno de ellos.


Archivos



La tabla de rutas persistentes de un SUSE Linux Enterprise Server se encuentra en el archivo:

/etc/sysconfig/network/routes

Adicionalmente, se pueden añadir rutas a un adpatador específico editando un archivo del tipo:

/etc/sysconfig/network/ifroute-*

Es decir, si tenemos un adaptador llamado eth0 configurado en el archivo ifcfg-eth0, podemos crear rutas estáticas que afecten solamente a este adaptador editando el archivo:

/etc/sysconfig/network/ifroute-eth0


Añadir ruta estática



Las entradas en los archivos de configuración de enrutamiento pueden seguir uno de estos 3 patrones:

DESTINO GATEWAY MÁSCARA INTERFAZ
DESTINO GATEWAY PREFIJO INTERFAZ
DESTINO/PREFIJO GATEWAY INTERFAZ

Para omitir el GATEWAY, MÁSCARA o PREFIJO escribir - (guión).

El destino siempre se escribe en la primera columna. Este puede ser tanto un host como una red, así como un FQDN que la máquina sepa resolver (por ejemplo, host.dominio.com).

La segunda columna contiene el gateway (desde donde se enviará el tráfico al destino).
La palabra clave default, por su parte, indica que la ruta usa la puerta de enlace predeterminada.

La tercera columna está obsoleta; solía contener la máscara de red IPv4 del destino, del tipo máscara (por ejemplo 255.255.255.0) o prefijo (/24). Hoy en día se usa una combinación de host o red con su prefijo directamente en la primera columna. Por ejemplo, 192.168.0.0/16 para IPv4 o fc00::/ 7 para IPv6.

Por último, la cuarta columna nos indica la interfaz a usar.


Mostrar rutas



Hay dos formas de visualizar las rutas estáticas persistentes de un sistema: por comando o por archivo.

Podemos usar el comando ip route show para ver las rutas estáticas configuradas en un sistema:

HOST# ip route show default via 192.168.4.1 dev eth0 192.168.4.0/24 dev eth0 proto kernel scope link src 192.168.4.2 192.168.7.0/24 dev eth1 proto kernel scope link src 192.168.7.2

(Recordar que el comando ip route sustituye el antiguo comando netstat -nr).

De otro modo, podemos mirar el contenido de uno de los archivos mencionados anteriormente:

HOST# cat /etc/sysconfig/network/routes 192.168.4.0 192.168.4.1 255.255.255.0 eth0 192.168.7.0 192.168.7.1 255.255.255.0 eth1

Sea cual sea el método elegido, deberíamos ver las mismas rutas.


Eliminar ruta estática



Para eliminar alguna ruta, basta simplemente con borrarla del archivo en cuestión.


Fuentes:

https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-network.html#sec-network-man...
https://www.novell.com/documentation/suse91/suselinux-adminguide/html/ch14s05.html
0

miércoles, 9 de septiembre de 2020

Especificar IP de origen desde proxy NGINX



Cómo enviar peticiones desde una IP de origen concreta en un proxy inverso NGINX.



Puede que tengamos un servidor web que solo acepte conexiones de un determinado rango IP y que tengamos un NGINX por delante actuando de reverse proxy que no disponga de una IP de ese rango o que sí disponga de ella, pero no la use a la hora de enviar tráfico a dicho servidor, por lo que los paquetes no lleguen desde el NGINX al servidor final.

Para solucionar este problema, podemos asignar una IP secundaria a nuestro NGINX y especificar que para ese servidor, usaremos esa IP secundaria como origen a la hora de enviarle tráfico.

Para especificar desde qué IP se envía tráfico hacia un servidor web final, podemos usar la directiva proxy_bind antes de proxy_pass en el bloque location dentro del bloque server de un dominio:

server { server_name dominio1.com; ... location /app1/ { proxy_bind 127.0.0.1; proxy_pass http://example.com/app1/; } } server { server_name dominio2.com; ... location /app2/ { proxy_bind 127.0.0.2; proxy_pass http://example.com/app2/; } }

La dirección IP también se puede especificar con una variable, p.e $server_addr.

Primero declaramos la variable y su valor:

set $server_addr "127.0.0.1";

A partir de aquí, ya la podemos usar dentro de la directiva proxy_bind de cuantos dominios queramos:

server { server_name dominio3.com; ... location /app3/ { proxy_bind $server_addr; proxy_pass http://example.com/app3/; } } server { server_name dominio4.com; ... location /app4/ { proxy_bind $server_addr; proxy_pass http://example.com/app4/; } } ...

De esta forma, podemos usar dicha variable en varios dominios y si algún día cambiamos la IP desde la que se origina el tráfico, no hará falta ir línea por línea cambiando su valor sino que podremos cambiarla una sola vez en la declaración de la variable.


Fuentes:

https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/
0

miércoles, 2 de septiembre de 2020

Acceder a Google Drive desde el escritorio



Cómo acceder a Google Drive desde nuestro explorador de Windows, Mac o Linux.



Google Drive es un servicio de alojamiento de archivos en la nube creado por Google en 2012. Este servicio nos permite disponer de hasta 15 GB por cuenta para guardar fotos, documentos, copias de seguridad, etc. alojados en servidores de Google sin gasto alguno.

Para disfrutar de Google Drive, deberemos usar una cuenta de gmail o vincular una cuenta de correo electrónico existente con Google. Una vez hecho esto, ya podremos usar Google Drive desde el navegador web y/o desde la aplicación de escritorio.

Para acceder a Google Drive desde el escritorio de nuestro ordenador como si de una carpeta más del sistema se tratara, deberemos descargar "Backp and Sync" (Copia de seguridad y sincronización) desde:

https://www.google.com/intl/es-419_ALL/drive/download/backup-and-sync/

Al inicio de la instalación, el programa nos pide iniciar sesión a nuestra cuenta Google:



Luego debemos elegir si queremos maneter sincronizadas las carpetas de fotos, vídeos y documentos de nuestro sistema operativo o si queremos mantener Google Drive como una carpeta independiente:



A continuación, y muy importante, debemos marcar "sincronizar mi unidad con este ordenador". Si no lo marcamos, no veremos los cambios que hagamos en nuestro PC en el Drive ni viceversa.



Una vez hecho esto, ya podremos acceder a nuestros archivos contenidos en el Drive como si de una carpeta más del ordenador se tratase:



Solo recordar que el límite de espacio del plan gratuito para este servicio es 15 GB.
0

miércoles, 26 de agosto de 2020

Incrementar tamaño de / en EC2 Linux



Cómo incrementar el tamaño de la partición raíz ( / ) de un EC2 Linux en Amazon Web Services.



Si tenemos una instancia Linux en AWS, puede pasarnos que nos quedemos sin espacio en el disco principal de la máquina y no tengamos más remedio que ampliar el número de GB del disco.

Antes de ampliar la partición raíz, debemos averiguar en qué disco está situada la partición:

ip-10-250-4-103:/home/ec2-user # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 18M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/xvda1 99G 60G 35G 64% / tmpfs 799M 0 799M 0% /run/user/1000

Listamos los discos del sistema con el comando lsblk y encontramos el disco xvda:

ip-10-250-4-103:/home/ec2-user # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 100G 0 disk └─xvda1 202:1 0 100G 0 part /

Ahora ampliamos el espacio del disco xvda desde la consola de AWS.

Volvemos a lanzar el comando lsblk y vemos como xvda ha subido de tamaño:

ip-10-250-4-103:/home/ec2-user # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 250G 0 disk └─xvda1 202:1 0 100G 0 part /

Llegados a este punto, tenemos un disco ampliado, pero la partición raíz sigue igual:

ip-10-250-4-103:/home/ec2-user # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 18M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/xvda1 99G 60G 35G 64% / tmpfs 799M 0 799M 0% /run/user/1000

Ampliamos la partición /dev/xvda1:

ip-10-250-4-103:/home/ec2-user # sudo growpart /dev/xvda 1 CHANGED: partition=1 start=2048 old: size=209713119 end=209715167 new: size=524285919,end=524287967

Comprobamos que haya cogido el nuevo espacio asignado:

ip-10-250-4-103:/home/ec2-user # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 250G 0 disk └─xvda1 202:1 0 250G 0 part /


EXT4



Si el disco está particionado con EXT4, usamos resize2fs para acabar de ampliar la partición raíz:

ip-10-250-4-103:/home/ec2-user # sudo resize2fs /dev/xvda1 resize2fs 1.42.11 (09-Jul-2014) Filesystem at /dev/xvda1 is mounted on /; on-line resizing required old_desc_blocks = 7, new_desc_blocks = 16 The filesystem on /dev/xvda1 is now 65535739 blocks long.

Vemos como la partición raíz ya ve el nuevo espacio en disco:

ip-10-250-4-103:/home/ec2-user # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 18M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/xvda1 246G 60G 177G 26% / tmpfs 799M 0 799M 0% /run/user/1000


XFS



Si ampliamos una partición no EXT4 usando el comando resize2fs veremos el siguiente error en pantalla:

ip-10-250-4-94:/home/ec2-user # sudo resize2fs /dev/xvda2 resize2fs 1.43.8 (1-Jan-2018) resize2fs: Bad magic number in super-block while trying to open /dev/xvda2 Couldn't find valid filesystem superblock.

Buscamos el tipo de partición del sistema operativo:

ip-10-250-4-94:/home/ec2-user # df -Th Filesystem Type Size Used Avail Use% Mounted on devtmpfs devtmpfs 3.9G 0 3.9G 0% /dev tmpfs tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs tmpfs 3.9G 375M 3.6G 10% /run tmpfs tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/xvda2 xfs 100G 58G 42G 58% / /dev/xvda1 xfs 297M 90M 208M 31% /boot tmpfs tmpfs 797M 0 797M 0% /run/user/1000

Vemos que es XFS. Usamos xfs_growfs para ampliar nuestra partición raíz:

ip-10-250-4-94:/home/ec2-user # sudo xfs_growfs -d / meta-data=/dev/xvda2 isize=512 agcount=42, agsize=636096 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=0 spinodes=0 rmapbt=0 = reflink=0 data = bsize=4096 blocks=26137339, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 data blocks changed from 26137339 to 65458939

Ahora ya vemos el nuevo espacio en la partición raíz:

ip-10-250-4-94:/home/ec2-user # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 375M 3.6G 10% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/xvda2 250G 58G 192G 24% / /dev/xvda1 297M 90M 208M 31% /boot tmpfs 797M 0 797M 0% /run/user/1000


Fuentes:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html
0