Tag ssh - Userlinux.net

Si algo bueno tiene Mercurial es que permite la autentificación de usuarios a través de SSH. Es muy sencillo agregar un nuevo usuario a un desarrollo/repositorio: adduser y con meterlo dentro del grupo correspondiente al desarrollo llegaría. Pero ¿qué ocurre si no queremos que ese usuario haga otra cosa que no sean comandos hg?.

Conociendo la existencia de hg-ssh no ocurre demasiado, se trata de un script que hemos de referenciar en el authorized_keys del usuario que acabamos de crear de forma que todos los comandos entrantes pasen por este script. El script se encarga de parsear el comando que se pide en ejecución: si es de la familia de Mercurial lo ejecuta, en cualquier otro caso mostrará un error.

Ejemplo de authorized_keys:

command="~/hg-ssh /home/repo1 /home/repo2",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-dss AAAA...

He optado por copiar el archivo hg-ssh en el directorio home del usuario, pero se podría referenciar directamente el que trae de ejemplo la instalación de Mercurial.

Todos sufrimos con más frecuencia de lo deseado intentos de ataques por fuerza bruta en los servicios que ofrecen nuestras máquinas, es inevitable. Pero con herramientas como DenyHosts podremos controlar mucho mejor estos intentos de violación. Su instalación y posterior configuración son triviales, tan solo debemos comprobar que tenemos python instalado en el sistema y poco más:

# dpkg --list | grep python2
ii  python2.5...
# python -V
Python 2.5.2
# apt-get install denyhosts

Una vez instalado pasamos a configurar el archivo /etc/denyhosts.conf, que es el que tiene toda la chicha:

Si has reinstalado el sistema operativo en un servidor, o le has cambiado la ip, seguramente cuando vuelvas a intentar acceder a la máquina por ssh te impedirá el acceso y recibiras un mensaje como este:

Si nos gusta ver en el título de cada una de las pestañas de Gnome Terminal el host al que estamos conectados por ssh (algunos tenemos unas preferencias algo raras, lo reconozco) podemos conseguirlo mediante un pequeño tip en el .bashrc del host destino:

# Titulo de ventana para xterm
case $TERM in
    xterm*|rxvt*)
            PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}"; echo -ne "\007"'
            ;;
    screen)
            PROMPT_COMMAND='echo -ne "\033_${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}"; echo -ne "\033\\"'
            ;;
esac

Con ésto sabremos perfectamente y de un vistazo a qué servidores estamos conectados y cual es su pestaña correspondiente. Si, tengo pendiente instalar ssh-menu.

Lectura obligada para tunelizar conexiones SSH.

Es posible que el servidor SSH al que estamos intentando conectar tenga activado el uso de DNS, con lo que intentará resolver el nomber y/o IP antes de proceder al login. Si no existe ningún servidor de nombres capaz de resolver el proceso se vuelve bastante lento.

Para evitar este tipo de situaciones editamos la configuración del servidor (/etc/ssh/sshd_config en este caso) agregando una pequeña linea:

UseDNS No

Reiniciamos el servicio (/etc/init.d/ssh restart) y a vivir que son dos días.

Probando Eclipse he notado que hay varias funciones esenciales -al menos para mi- que necesitan ser activadas mediante la instalación de un plugin. Una de estas características básicas es la edición remota. Con el plugin RSE es muy sencillo.

Para instalarlo simplemente vamos a Help » Software Updates » Find and Install » Search for new features to install y en la ventana de diálogo que aparece seleccionamos New Remote Site. Le llamamos RSE y en url rellenamos lo siguiente: http://download.eclipse.org/dsdp/tm/updates/2.0/.

Lo siguiente será seleccionar los protocolos de edición remota a usar (SSH, FTP, Telnet...) y aceptar la licencia de uso. En el siguiente reinicio de Eclipse tendremos habilitada la edición remota.

Hace tiempo me venía preguntando si existiría algún archivo (dot) donde guardar la configuración de pestañas abiertas en un gnome-terminal. No es descabellado tener varias pestañas con sesiones ssh a diferentes máquinas, presumiblemente las mismas todos los días. Es una tediosa costumbre que esperaba automatizar algún día.

Y precisamente ahí es donde actúa SSHMenu. Consiste en un Applet de gnome que, configurado correctamente, abrirá n sesiones ssh en pestañas (o ventanas) gnome-terminal con una geometría determinada, todo configurable.

Siempre que instalo un sistema desde cero suelo toparme con los mismos problemas que, incauto de mi, no he documentado anteriormente por falta de tiempo, ganas, o ambas. Esta vez ha sido instalando Quanta en una Ubuntu:

# apt-get install quanta

El problema no ha sido su instalación sino configurar el Files Tree para que mostrase máquinas remotas. Recordemos que una de las principales características por las que uso Quanta es su edición remota (vía ftp, ssh...), tratando archivos y directorios como si estuvieran en local.

Al intentar abrir un archivo remoto (fish://usuario:passwd@host/var/www/index.php) ni se inmutaba, con lo que recordé que hacía falta algún componente Kio slave:

Al hilo de la anterior entrada y buscando alternativas para bloquear todos esos ataques por fuerza bruta (bruteforce) al servicio de administración remota SSH he encontrado la solución ideal -o lo que más se le aproxima-, sin descartar las anteriores.

La regla mágica hace uso de una nueva característica de Packet Filter (desde OpenBSD-3.7) llamada max-src-conn-rate. Lo que venimos a decirle a nuestro firewall es que permita todas las conexiones ssh con la salvedad de que no se sobrepasen 3 intentos en menos de 30 segundos, en dicho caso se agregará la IP del atacante a una lista llamada ssh-bruteforce, en pf.conf: