Otro de mis pequeños proyectos

Etiqueta: ssh

¿Qué cliente de FTP usas?

Esta pregunta me ha hecho hoy Mr. Client*. Reconozco que no ha sido el primero pero supongo que tampoco será el último.

Mi primera respuesta es que mi religión me lo impide. Ya no recuerdo la última vez que usé FTP por cuenta propia. En caso de necesitar FTP siempre usaré SFTP y, si tengo acceso shell, SCP. No hay nada mejor que una consola y, si es posible, una sesión SSH.

Pero realmente no querí­a hablar de FTP, sino de clientes para estos servicios. No tengo nada en contra de ellos y si los usas me parece muy bien, pero voy a explicar porque tiendo a no usarlos si es que puedo cambiarlos por comandos en la consola o por acciones que pueda controlar directamente con el teclado. ¿Raro? ¿Arcaico? ¿Friki? Ni mucho menos, eficiente.

Y si el simple hecho de mover las manos entre el teclado y el ratón hace que seas más lento, podemos incluir el hecho de que para la mayorí­a de las acciones que tengas que hacer bastarí­a con repetir la misma acción (subir un fichero, copiar una carpeta, borrar un fichero, etc).

Ahí­ van un par de las preguntas más frecuentes:

«¿Y tienes que estar todo el rato conectándote? ¿Y la contraseña?»

Para esta pregunta, la solución está en este post en el que explica como crear un par de claves que te permita acceder al servidor de forma sencilla y segura.

La respuesta es sí­, pero es que conectarme al servidor es una cosa muy sencilla. Además, para configuraciones habituales o que requieran de muchos parámetros, siempre podemos «Tunear» un poco nuestro ssh 😉

«¿Y cuando tienes que subir varios ficheros?»

El tema se pone interesante. Depende del caso, desde el más sencillo usando wildcards:

scp *.log host:/var/log

O algo más complicado:

scp {script,config}.php host:/var/www

O siempre está la opción de hacernos un mini-script que suba varios ficheros, aunque recordemos que siempre que podamos hacerlo en la misma conexión, ganaremos tiempo.

«Vale, ¿y cuando tienes que subir muchos ficheros? ¿Y carpetas?»

Para las carpetas, nada como la opción -r que permite subir ficheros de forma recursiva, incluyendo directorios.

Cuando tienes que subir muchos ficheros, automatización con un script o incluso usar un tar.gz, subir y descomprimir. Si realmente tienes que trabajar con cambios en muchos ficheros en distintos sitios, la mejor opción serí­a rsync lanzado manualmente (hasta el momento, no me he encontrado con este caso, pero bueno, será por opciones).

O puedo asegurar que si os gusta la velocidad, lo primero es aprender a no usar el ratón (que no quiere decir que no lo uséis) y luego, a automatizar los trabajos repetitivos. Conseguiréis ser más rápidos, eficientes y, como no, aprenderéis más cosas.

Que no se me enfade nadie, cada uno es libre de usar las herramientas como quiera. Sólo he dado mi propuesta que, además, vale tanto para Linux, Windows o Mac.


*: cariñosamente para el post de hoy 😉

Múltiples cuentas en github.com

Al hilo del último post sobre cómo «tunear» un poco nuestro ssh, podemos usarlo por ejemplo si tenemos varias cuentas en github.com. Cuando ocurre esto, por cada cuenta que tienes en github, tienes que añadir una clave pública; esto no es ningún problema ya que podemos crear tantas claves como queramos, pero lo que no es tan fácil es cambiar la cuenta ssh con la que debe conectarse el cliente de git a github. No es muy común, pero te puede ocurrir como a mi, que tienes tu cuenta personal y la del trabajo.

Para poder conseguir esto, supongamos que tienes estos datos:

  • Cuenta personal
    • Usuario: usuario_casa
    • Fichero de clave: ~/.ssh/casa
  • Cuenta trabajo
    • Usuario: usuario_trabajo
    • Fichero de clave: ~/.ssh/trabajo

Lo que habrí­a que hacer es tener un fichero de configuración ssh (recordemos que está en ~/.ssh/config) de la siguiente forma:

Host github
 HostName github.com
 User usuario_casa
 IdentityFile ~/.ssh/casa

Host github-trabajo
 HostName github.com
 User usuario_trabajo
 IdentityFile ~/.ssh/trabajo

La diferencia es sutil: cambia el valor que ponemos en Host (los espacios o tabulaciones son opcionales, yo los uso para dar un poco más de orden).

Con esto, tenemos que cambiar la dirección con la que nos conectaremos con la cuenta de trabajo. Si por ejemplo, para añadir el repositorio remoto usamos:

git remote add origin git@github.com:usuario_trabajo/proyecto.git

Ahora deberemos poner:

git remote add origin git@github-trabajo:usuario_trabajo/proyecto.git

Es decir, ssh se encargará automáticamente de hacer el cambio por nosotros y, de esta forma, no tendremos problemas decidiendo con qué usuario debe conectar o no, está todo en el fichero de configuración 😉

«Tunear» un poco nuestro ssh

Este es un sencillo truco que a mi me descubrió hace ya un tiempo mi buen amigo Iñigo, que os abrirá (si no lo ha hecho ya) una puerta hací­a una mayor rapidez con el comando ssh. Empezaré directamente poniendo un ejemplo: supongamos que para acceder a un servidor con los siguientes parámetros (lo sé, están un poco exagerados, pero creo que se entenderá el ejemplo):

  • Dirección: punto.de.entrada.al.servidor.com
  • Usuario: miusuario
  • Puerto 12345
  • Fichero de clave: /home/user/.ssh/fichero.clave

El chorizo comando que nos hace falta es:

ssh punto.de.entrada.al.servidor.com -l miusuario -p 12345 -i /home/user/.ssh/fichero.clave

Casi nada

Bien, hay una forma de acortarlo un poco. El truco está en configurar todos estos parámetros en un fichero. Este fichero lo podemos encontrar en nuestra cuenta de usuario, concretamente en ~/.ssh/config. Este fichero por defecto viene vací­o pero, siguiendo con el ejemplo escribimos estas lí­neas en su interior:


Host miservidor
HostName punto.de.entrada.al.servidor.com
User miusuario
Port 1234
IdentityFile /home/user/.ssh/fichero.clave

Con este simple gesto, ahora podemos cambiar el comando ssh anterior por:

ssh miservidor

Casi nada la diferencia 🙂

Si investigas un poco el man de ssh_config seguro que encuentras muchas cosas de utilidad. Más adelante daré otro truco relacionado con este.

P. P: y como bien te recomendarí­a un administrador de sistemas, si encima añades el hostname a tu /etc/hosts, irá «volado»! Se ahorrará la resolución DNS

Enlaces:

Trabajando con eficiencia

Muchas veces considero que es una obsesión, pero de lo que estoy seguro es que muchas más veces gano tiempo pensando un poco y haciendo las cosas mejor y más rápidas.

El caso que voy a presentar ahora es lo que yo considero «la forma más rápida de descargarnos un dump de una base de datos». Añadamos como condición que tenemos que usar un protocolo cifrado, en este caso, SSL. Para cualquier de los dos ejemplos que voy a presentar, contamos que tenemos autentificación en el servidor remoto (ahora que sabemos cómo hacerlo).

Empecemos por el final. Cómo se nos ocurrirí­a hacerlo directamente. Básicamente los pasos serí­an estos:

# Nos conectamos al servidor
ssh user@server.com
# Realizamos el dump de la base de datos
mysqldump -u mysqluser -p mysqldb > dump.sql
# Comprimimos los datos para reducir el tamaño de los datos a trasferir
gzip dump.sql
# Volvemos a nuestro ordenador
exit
# Copiamos el fichero a nuestro ordenador
scp user@server.com:dump.sql.gz .

He hecho una prueba con una base de datos pequeña. Si únicamente contabilizamos el tiempo en realizar cada uno de estos comandos y los sumamos (es decir, no tenemos en cuenta ni el ssh inicial ni los tiempos entre comandos, incluí­do si nos vamos a tomar un café mientras hace el volcado o lo comprime), salen los siguientes tiempos:

  • mysqldump: 2.2 segundos
  • gzip: 0.5 segundos
  • scp: 12.2 segundos
  • total método 1: 14.9 segundos

Veamos ahora otra forma. ¿Y cómo es? Pues bien sencilla… ¿y si te digo que puedes agrupar todos los comandos en únicamente uno?

¿Cómo? Pues aprovechando que se pueden ejecutar comandos de forma remota con el comando ssh y que lo que devuelva ese comando, se retorna mediante la consola estándar (stdin). Además, teniendo en cuenta que también podemos llamar a gzip en lí­nea mediante una tuberí­a (denominada en inglés pipe, representada por la barra vertical: |). Si unimos todo esto, nuestro comando queda (ejecutado directamente desde nuestra máquina):

ssh user@server.com "mysqldump -u mysqluser -p mysqldb | gzip" > dump.sql.gz

Si medimos el tiempo que le cuesta a este comando obtenemos para el método 2: 12.0 segundos

La diferencia puede parecer muy pequeña vista así­, pero estamos hablando que es casi un 20% más rápido. Si este proceso (con el primer método) hubiese durado 4 horas (sí­, os aseguro que se puede dar el caso), en algo más de 3 horas lo habrí­ais terminado. Estos datos son muy variables, hay que tener en cuenta muchas cosas, pero que hagáis las pruebas que hagáis, en igualdad de condiciones, este nuevo método es mucho más rápido.

Y os aseguro que si hacéis la prueba con un proceso largo, en el que tendrí­ais que esperar que terminase cada paso para iniciar el siguiente comando, ganaréis mucho tiempo sobre todo entre comando y comando.

La próxima vez que os toque algo como esto, usad este método y tomaros el café (o la comida) que os podréis tomar gracias a no tener que esperar, a mi salud.

Pensad un poco, esto es sólo un ejemplo, ¡hay muchas más opciones!

Usar pares de claves para acceder a los servidores de forma sencilla, cómoda y… segura

Este post se lo dedico a Luis que, con razón, siempre me pide que explique las cosas 🙂

Cuando te tienes que mover mucho entre servidores, uno de los principales problemas es tener que introducir el contraseña del usuario en el servidor al que te conectas. Este proceso se puede evitar de forma sencilla mediante partes de claves y ssh. Esto no te evita tener que usar una contraseña, pero será únicamente una y tienes que elegirla lo más robusta posible (para este post, la contraseña que tú elijas viene representada por AQUITUCONTRASEÑA).

Los pasos son los siguientes.

Crear el par de claves.

$ ssh-keygen -t dsa -f ~/.ssh/id_dsa
Generating public/private dsa key pair.
Enter passphrase (empty for no passphrase): AQUITUCONTRASEÑA
Enter same passphrase again: AQUITUCONTRASEÑA
Your identification has been saved in ~/.ssh/id_dsa.
Your public key has been saved in ~/.ssh/id_dsa.pub.
The key fingerprint is:
60:92:6a:6e:48:b1:1a:2d:ae:51:9b:04:8a:9f:4c:6d tatai@localhost

Esto genera dos ficheros: ~/.ssh/id_dsa y ~/.ssh/id_dsa.pub que son la clave privada y la clave pública respectivamente.

Ahora tenemos que copiar la clave pública en el servidor remoto (podremos copiar la clave en tantos servidores como nos haga falta). Para ello, teniendo en cuenta que queremos acceder a server.com con el usuario user, usamos el siguiente comando:

$ ssh-copy-id -i ~/.ssh/id_dsa user@server.com

Tras este comando, el sistema pedirá (por última vez) la contraseña del servidor para ese usuario.

Una vez tengas estos dos pasos hechos, verás como si intentas realizar una conexión ssh al servidor:

$ ssh user@server.com

Entrarás directamente, sin que te pida contraseña.

No sólo podrás realizar sesiones ssh (o ejecución de comandos mediante ssh), sino que también podrás usar scp, sftp, etc… y sin tener que introducir la contraseña.

Por último, comentar un par de cosas con respecto a todo este proceso. Lo primero es que se necesita un denominado agente de sesión ssh que se encarga de cachear las claves. Este agente se puede llamar mediante el comando ssh-agent. Por defecto, los gestores gráficos (gdm, kdm, etc) lo instancian al arrancar y por eso, mientras uses tu máquina y usuario en el entorno gráfico, no tendrás que llamarlo, pero en el caso de que te conectes a tu máquina, en general, no tendrás este agente ni tendrás clave autentificada. En este caso, tendrás que ejecutar los siguientes comandos:

$ ssh-agent bash
$ ssh-add ~/.ssh/id_dsa
Enter passphrase for ~/.ssh/id_dsa: AQUITUCONTRASEÑA

El primero de los comandos abre una consola bash con el agente de sesión ssh y con el segundo, añadimos la clave anteriormente creada de modo que el sistema nos considera autentificado.

Y ya para finalizar, comentar que puedes disponer de varios pares de claves, cada uno con su correspondiente contraseña, método de encriptación (rsa o dsa), número de bits, etc. Tan sólo es necesario cambiar el nombre del fichero que se usa. Se recomienda crearlos todos bajo el directorio .ssh en nuestra cuenta.

Update (2010-02-04): gracias a Mariotux que me ha avisado que tení­a mal algunas llamadas ( s/rsa/dsa/g :p)