Tuneando firefox sobre ssh

Hace un tiempo hice que Firefox corra remoto sobre X. Para eso forwardeo el X por ssh (haciendo $ ssh -X blah) Y esto anda bien para correr sobre una VM. Pero cuando probé conectarme a mi linux desde mi mac no anduvo :(. Así que primero tuve que decirle como forwardear XAuthority corriendo XAUTHORITY=$HOME/.Xauthority firefox --no-remote. Pero cuando quiero conectarme a otra compu en mi red wifi anda muy lento. Así que hice algunas optimizaciones.

La primera es que cuando me conecto por ssh le paso -C para que comprima los datos, porque X manda bocha de cosas para forwardear la pantalla. Y el otro seteo que sirvió para algo fue ir a about:config en firefox y bajar el frame rate seteando layout.frame_rate en 15.

Con eso puedo usar firefox más o menos. Una cosa medio molesta es que el audio sigue saliendo por los parlantes de mi linux y no encontré fácil como forwardearlo o mutearlo, pero aunque sea así es posible usar firefox forwardeado por X por mi wifi, así que ese arreglo quedará para el futuro.

chromium en snap via ssh

Me conecto a una VM por ssh, forwardeando X (ssh -X).

Instalo el snap de chromium (sudo snap install chromium).

Lo corro, y me da este error.

$ chromium
X11 connection rejected because of wrong authentication.
[2050513:2050513:0909/155104.874445:ERROR:ozone_platform_x11.cc(240)] Missing X server or $DISPLAY
[2050513:2050513:0909/155104.874518:ERROR:env.cc(255)] The platform failed to initialize.  Exiting.
[1]+  Done                    XAUTHORITY=$HOME/.Xauthority chromium

Para arreglar el problema hay que setearle la variable de entorno de XAUTHORITY (¿por qué?).

Lo corro así y problema solucionado.

$ XAUTHORITY=$HOME/.Xauthority chromium

ssh-agent no anda en lubuntu 22.4

Este fin de semana upgradié el sistema operativo de mi notebook. Lo pasé de lubuntu 20.4 a lubuntu 22.4.1. Cuando terminé todo anduvo razonablemente bien (booteó!) pero el agente de ssh dejó de arrancar solo.

Estuve un rato googleando y no encontraba nada. Así que me puse a buscar como arranca el ssh-agent. Para eso tiré un find con un grep en mi home.

 

$ find . -type f -print0 | xargs -0 -n 1000 fgrep -n ssh-agent

 

Hice eso y encontré que en el archivo $HOME/.xsession-errors tenía este mensaje de error:

 

/etc/X11/Xsession.d/90x11-common_ssh-agent: line 9: has_option: command not found

 

¡Bingo!

Googlié el error y encontré este reporte de bug de ubuntu. Dentro de los comentarios encontré la solución.

La misma consiste en poner en el directorio /etc/X11/Xsession.d/ un archivo más para definir has_option. El archivo yo lo nombré 01x11-has_option-aure y tiene este contenido:

 

# This file is sourced by Xsession(5), not executed.
#
# workaround created by Settel
# defines "has_option" unless it is already defined
# see https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1922414
#


if type -t has_option >/dev/null; then
  return
fi


OPTIONS="$(
  if [ -r "$OPTIONFILE" ]; then
    cat "$OPTIONFILE"
  fi
  if [ -d /etc/X11/Xsession.options.d ]; then
    run-parts --list --regex '\.conf$' /etc/X11/Xsession.options.d | xargs -d '\n' cat
  fi
)"

has_option() {
  # Ensure that a later no-foo overrides an earlier foo
  if [ "$(echo "$OPTIONS" | grep -Eo "^(no-)?$1\>" | tail -n 1)" = "$1" ]; then
    return 0
  else
    return 1
  fi
}

Montando directorios por ssh

 
Me gusta contectarme a mis VMs por ssh y es bastante cómodo. Pero a veces es un garrón copiar archivos desde/hacia mis VMs. Por eso prefiero montar el disco vía ssh. Saqué cómo hacerlo de acá.

Para hacer eso en ubuntu hay que instalar sshfs

$ sudo apt-get install sshfs

Hacer un directorio vacío para montar el filesystem nuevo.

$ mkdir /home/johndoe/sshfs-path/

Y montar el directorio vía ssh.

$ sshfs  remoteuser@111.222.333.444:/remote/path /home/johndoe/sshfs-path/

Por último, para desmontarlo hay que correr:

$ fusermount -u /home/johndoe/sshfs-path/

Bug en VSCode

En el último año empecé a usar VSCode para programar. Lo uso de una forma extraña, ya que me conecto por ssh a la máquina virtual donde está instalado, forwardeando X11. Aparte lo instalé usando el snap. Hoy lo quise arrancar y me dio una sorpresa fea. En vez de arrancar, solo apareció un rectángulo gris. Me di cuenta que había un problema así que reporté el bug y busqué un workarround. Al final me di cienta que era porque en VSCode upgradearon a Electron 9 y tiene un problema cuando corre con forwardeo de X11 adentro de un container.

Por suerte también hay un workarround. Corrí

export QT_X11_NO_MITSHM=1

en bash antes de arrancarlo y se solucionó el problema.

Update: Si no quieren setear una variable de entorno pueden arrancar VSCode corriendo

code --no-xshm

y también workarroundea el problema.

Fingerprint del certificado

Una de las cosas más molestas de conectarse vía ssl es toda la danza de los certificados, los DNS y las autoridades certificantes. Todo sería mucho más fácil si pudiéramos basarnos en el fingerprint del certificado del server y nos cagáramos en las autoridades certificantes, como hacemos en ssh.

En python podemos hacer eso.

Por ejemplo, para obtener el sha256 del certificado de uno de mis sitios favoritos para jugar al go podemos hacer:

>>> import ssl, socket, hashlib
>>> c = ssl.wrap_socket(socket.socket(socket.AF_INET,socket.SOCK_STREAM))
>>> c.connect(("www.dragongoserver.net",443))
>>> c.do_handshake(True)
hashlib.sha256(c.getpeercert(True)).hexdigest() # da '6cc78bca1293524be3bb0d6321d129d03fd244426c8c3e2ed69f454a14491623' que es el valor del fingerprint SHA 256 del certificado que veo si entro por el navegador al momento de escribir este post.


Con eso, podemos fijarnos si el certificado es el que esperábamos e implementar TOFU ('trust on first use') si nos pinta.

Espero que nos sirva,
Aureliano.

eclipse@docker

Estuve scripteando un poquito, e hice que eclipse corra en un container de docker (base, ubuntu:trusty), con las cosas que necesito para desarrollar sandro

Primero hice un dockerfile bastante trivial:

FROM ubuntu:trusty
RUN apt-get update && apt-get install -y \
  git \
  mercurial \
  default-jdk

con su correspondiente .dockerignore

dockerfile
.dockerignore

en un directorio que nombré docker

Después hice una imagen con ese container (a la que llamé, sandro:base).

$ docker build -t sandro:base docker

Y después vino la parte complicada.

Decidí correr el eclipse en volumenes afuera del container, con la idea de que quizás sea una buena idea inyectarlo en muchos distintos y poder instalar fácilmente plug-ins y esas cosas y que siga andando todo cuando haga otros containers. Para eso hice 4 directorios:

• eclipse: donde puse un eclipse luna
• workspace: donde va el workspace del eclipse
• devel: donde pongo todo mi código
• apache-tomcat-7.0.62: acá puse un tomcat bajado de apache.org

 Usando esa estructura hice 2 scripts:

• dev.sh corre cualquier programa en un container nuevo, setupeando todo para tener un ambiente razonable para laburar.
• eclipse.sh arranca eclipse usando dev.sh

Primero les muestro eclipse.sh

#!/usr/bin/env bash 

./dev.sh $1 eclipse/eclipse -data /workspace 

Le pasás por parámetro la imagen que querés usar para arrancarlo, y usa como workspace el directorio workspace que les conté más arriba.

Y ahora, la posta. dev.sh

#!/usr/bin/env bash

xhost +SI:localuser:root
ID=$( docker run \
  -d --name sandro-dev -h sandro-dev \
  -e SSH_AUTH_SOCK=$SSH_AUTH_SOCK -v $(dirname $SSH_AUTH_SOCK):$(dirname $SSH_AUTH_SOCK) \
  -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix \
  -e GIT_SSH=/usr/bin/ssh \
  -v `pwd`/devel:/devel -v `pwd`/eclipse:/eclipse -v `pwd`/workspace:/workspace -v `pwd`/apache-tomcat-7.0.62:/tomcat \
  -p 127.0.0.1:8080:8080 \
  $@ )
docker wait $ID
docker rm $ID

Mejor voy línea por línea porque es un bardo

1. xhost +SI:localuser:root habilita al container a poner aplicaciones en la GUI (las apps de los containers corren como root).
2. ID=$( docker run \ arranco el container y guardo su id
3. -d --name sandro-dev -h sandro-dev \ hace que el container corra desattacheado y setea nombre y hostname a sandro-dev para hacerme la vida más fácil
4. -e SSH_AUTH_SOCK=$SSH_AUTH_SOCK -v $(dirname $SSH_AUTH_SOCK):$(dirname $SSH_AUTH_SOCK) \ setupea el forwardeo del agente de ssh. Puede resultar útil si quieren pushear código vía ssh sin usar passwords
5. -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix \ Comparte el display del desktop con el container
6. -e GIT_SSH=/usr/bin/ssh \ para que si usan eclipse con git use el agente de ssh
7. -v `pwd`/devel:/devel -v `pwd`/eclipse:/eclipse -v `pwd`/workspace:/workspace -v `pwd`/apache-tomcat-7.0.62:/tomcat \ monta todos los directorios que quedan afuera del container
8. -p 127.0.0.1:8080:8080 \ forwardea el puerto 8080 (donde va a correr el tomcat de desarrollo) a localhost. Lo bindeo a 127.0.0.1 para que no se puedan conectar desde afuera.
9. $@ ) recibe más parámetros para docker run, incluyendo los comandos para correr y el nombre de la imagen a usar
10. docker wait $ID espera a que termine de correr el container
11. docker rm $ID lo borra

Espero que les resulte útil, y espero mejoras y críticas,
Aureliano.

Tuneando eclipse

Estoy usando eclipse con pydev para desarrollar usando pyzmq en un ubuntu 12.04 en forma remota por X11 (está en una VM). Para que sea usable, hice los siguientes cambios:

• Para que use java7, toqué eclipse.ini y agregué -vm
  /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java
• Para que ande mejor pydev, fuerzo el stack de ipv4. Para eso agregué a eclipse.ini -Djava.net.preferIPv4Stack=true
• Para que ande no tan lento, fuerzo que ande con GTK2 seteando la variable de entorno SWT_GTK3=0 (mirar acá para más detalles)
• Para que ande git con el agente de ssh standard seteo la variable de entorno GIT_SSH=/usr/bin/ssh
• Para interprete correctamente el package zmq, agregué zmq a los builtins (Window->Preferences->PyDev->Interpreters->Python Interpreters->Forced Builtins)

Happy hacking,
Aureliano.

Ssh port forwarding con reconexión automática

Ayer mostré cómo forwardear puertos usando ssh. Hoy lo mejoro. Usando autossh se mantiene el tunel levantado cuando la conexión de ssh se cae haciendo una nueva. Pueden correr en el shell así:

autossh -N -L bind_cliente:port_cliente:host_server:port_server usuario@host

Happy hacking, Aureliano.

Rsync iterado, integración con EC2

Ayer hice un script para coordinar directorios con rsync. Hoy lo integré con EC2, usando boto. Así no tengo que andar buscando el nombre de dns de la instancia cada vez. Cambien las constantes que aparecen arriba y úsenlo a piaccere. Para que sea usable tienen que poner la clave para loguearse en la instancia en su agente de SSH.

#!/usr/bin/env python

import subprocess
import sys
import time
import boto
import getpass

AKI = "AKIVAUNACCESSKEY"
USER = "ubuntu"
INAME = "INSTANCENAME"
TARGET = "TARGET_DIR"
SOURCE = "SOURCE_DIR"

def main():
    sak = getpass.getpass("Enter secret access key:")
    ec2 = boto.connect_ec2( AKI, sak )
    dns_name = ec2.get_only_instances(filters={"tag:Name":INAME})[0].dns_name
    while True:
        try:
            subprocess.check_call([
                "rsync",
                "-z",
                "-r",
                "--delete",
                "--exclude=*.pyc",
                "--exclude=*.log",
                SOURCE,
                "%s@%s:%s" % (USER, dns_name, TARGET)
            ])
            print ".",
            sys.stdout.flush()
            time.sleep(1)
        except subprocess.CalledProcessError, e:
            if e.returncode in [10,11,12,14,22,23,24,30,35]: # See http://wpkg.org/Rsync_exit_codes
                print "R",
                sys.stdout.flush()
            else:
                raise

if __name__ == '__main__':
    main()

Espero que les sirva,
Aureliano.

Ssh port forwarding

Cada día que uso ssh me gusta más. Acá dejo anotado como forwardear un puerto al que me puedo conectar desde el server, para poder conectarme desde el cliente:

ssh -L bind_cliente:port_cliente:host_server:port_server usuario@host

Happy hacking,
Aureliano.

Conectandome a mi VM nateada

Para laburar, me gusta tener los ambientes de los proyectos en los que laburo separados en VMs. Eso hace que pueda desarrollar simultáneamente proyectos con requerimientos incompatibles (un caso clásico es ver una versión vieja del mismo proyecto). Setupear todo suele no ser fácil. En particular, manejar el networking entre host y guest puede ser complicado. Por default, en VirtualBox, no es posible conectarse por tcp al guest si el mismo tiene la red configurada como NAT.
Después de googlear un rato, descubrí como hacer para poner reglas del tipo "el puerto 2222 del host es el 22 de mi_vm, y solo es accesible desde el host". Es así:

$ VBoxManage modifyvm "mi_vm" --natpf1 "ssh,tcp,127.0.0.1,2222,,22"

Si quisieran sacar la regla hay que hacer:

$ VBoxManage modifyvm "mi_vm" --natpf1 delete "ssh"

Si quieren ver que reglas de forwarding tiene su VM, pueden hacer:

$ VBoxManage showvminfo "mi_vm" | grep NIC

Para más detalles pueden mirar en la sección 6.3.1 del manual de VirtualBox.

Happy hacking!

Hacer un pem con clave a partir de uno sin clave

Tengo un .pem sin clave que me sirve para acceder a un server y me parece demasiado inseguro. Entonces corro:

openssl rsa -des -in orig.pem -out con-clave.pem 

Me pide la clave y en con-clave.pem tengo el .pem con clave, así que puedo borrar el otro (pero lo pruebo antes por las dudas).

Happy hacking,
Aureliano

¿Cómo cierro conexiones nesteadas de ssh?

Cuando una conexión de ssh se caga, para poder seguir usando la terminal hay que hacer: ENTER ~. ENTER y la conexión de ssh se corta.

El problema es que no sé como hacer para hacer algo similar para una conexión nesteada.

Desde mi workstation me ssheo al host A y desde el host A al B.

Las conexiones quedan así:

W ----ssh-----> A ------ssh-----> B

Y por algún motivo se caga la conexión entre A y B, todo el quilombo queda así:

W ----ssh-----> A --ssh(cagó)---> B

Para romper la conexión entre A y B hay que hacer: ENTER ~~. ENTER

El ñuflo extra es para escapar el ~ de la primera conexión y que le llegue a la segunda.

Happy hacking!