Tag ssh - Userlinux.net

Una de las infinitas opciones que nos ofrece SSH es hacer Forward Dinámico en modo de Socket para proxy de navegador (por ejemplo). Si queremos configurar "atajos" de las máquinas en el ~/.ssh/config podemos decirle también que conecte activando el DynamicForward de la siguiente forma:

$ cat ~/.ssh/config
Host atajo
        User root
        Port 122
        HostName mi-host-remoto.com
        DynamicForward 8080

Simple como el mecanismo de un botijo pero me ha costado encontrarlo en los frondosos bosques de documentación que habitan este gran servicio. Así que aquí queda el tip, una vez escrito este archivo llegará con un simple ssh atajo para establecer la conexión. Para nota sería ya combinarlo con IdentityFile, pero eso ya es más sencillo de encontrar ;).

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: