Comienzo explicando los conceptos básicos sobre ssh en Linux.

Descripción de SSH

Por decirlo de manera sencilla, SSH nos permite conectarnos a una máquina remota de manera segura. Además de cifrar el canal de comunicación es obligatoria la autenticación.
Para esto hay dos maneras, una es mediante usuario y contraseña y la otra es mediante el uso de claves públicas y privadas.

Cuando queremos entrar con un usuario y contraseña usamos los usuarios del sistema. A nosotros nos da igual donde estén esos usuarios creados (archivos /etc/passwd, servidor LDAP…) de eso se encargará el sistema.

Cuando nos conectamos por SSH al servidor entramos con los permisos del usuario que hemos usado. Por ejemplo, si yo entro con el usuario “alvaro” (un usuario normal) mi home será /home/alvaro y sólo tendré permiso de escritura a ese directorio. Otro usuario como es root tiene acceso a todo el sistema. Por seguridad en muchos servidores el usuario root esté deshabilitado.

En resumidas cuentas, a efectos prácticos SSH es igual que usar el terminal de tu ordenador, pero esas órdenes se ejecutan en el servidor remoto.
Veamos algun ejemplo.

Al pricipio estoy en mi ordenador. Ejecutando el comando “whoami” vemos que el usuario soy y mi estoy en mi máquina. Nos podemos dar cuenta porque pone “alvaro@flanders” (flanders es el hostname de mi ordenador).
Despues ejecutamos el comando ssh usuario@servidor. Nos conectaremos con el usuario “usuario” al servidor “servidor” y luego nos pregunta por la contraseña. Si introducimos la contraseña correcta entramos al servidor. Nos muestra un texto de bienvenida y vemos que ahora no pone “alvaro@flanders” sino que pone “server” (server es el hostname del servidor, muy original sí). También ejecutando el comando whoami vemos que el usuario ahora es root y no alvaro. Ahora todo lo que escriba en ese termina se ejecutará en el servidor con los permisos de root.

Ahora que ya sabemos un poco de qué va esto del SSH vamos a instalarlo

Instalación de SSH

Tan sencillo como instalar el paquete openssh-server
sudo aptitude install openssh-server

Iniciamos el servicio ssh

/etc/init.d/ssh start

Y ya podemos conectarnos al servidor

Hacemos la prueba y vemos que me he contectado sin problema. Si tienes más ordenadores en tu red local prueba a conectarte desde uno de ellos.
Recuerda que los datos que debes usar son un usuario del servidor y el hostname (o dirección ip del servidor, por ejemplo

ssh usuario@192.168.1.110

Suponiendo que el usuario “usuario” existe en el servidor y que la dirección ip (local) de tu servidor es “192.168.1.110″.

Y ya está! Ha sido fácil verdad?

Notas sobre ssh-server y clonezilla

Como dije al principio, escribo este artículo a partir de este y los datos por los que te pregunta son los siguientes:

Esto la dirección de tu servidor SSH. Donde has instalado el SSH.

El usuario del servidor que usarás para conectarte a él (para almacenar la imagen del disco duro)

El directorio del servidor donde se guardará la imagen del disco duro. Recuerda que el usuario que elegiste antes tiene que tener permisos de escritura en ese directorio del servidor.

Espero que se hayan podido solucionar todas las dudas respecto a este tema. Si no, puedes preguntar por lo que no te ha quedado claro por supuesto.

Un saludo!!

Entradas relacionadas:

1. Clonando con DRBL y Clonezilla (usando multicast!) Saludos, antes de nada disculparme por la tardanza y...

Volvemos… como podemos… y con un Nukeador de fondo.

Hablamos de:

- Hurd

- Jquery

- Microfonos

Promos:

- geocastaway

- Podcast caramelizado

Música:

Entradas relacionadas:

1. GPodcast 1.5 – 5 Son multitud Ya tenemos aquí otro podcast, esta vez con dos...
2. Gpodcast 1.3 – Pegatinaas Ya estamos aquí! con un par de dias de...
3. Gpodcast 1.2 – No quiero un mac Ya hemos vuelto, gpodcast 1.2, con numerosos bugs resueltos,...

¿Qué es XMPP y por qué usar XMPP?

Es un protocolo. Como a muchos eso os dejará igual voy a tratar de explicar que es esto y te darás cuenta del por qué es necesario que sea libre.

En informática un protocolo son una serie de normas para que dos máquinas sean capaces de entenderse. Esto nos da la posibilidad de que dos (o más) máquinas (o programas dentro de una máquina) puedan compartir información, dialogar entre ellas, discutir y llegar a acuerdos, etc. Sí, las máquinas hablan entre ellas, y mucho. Son unas cotorras de tomo y lomo lo que pasa es que no nos damos cuenta. Nosotros sólo vemos el resultado de toda era “burocracia” entre máquinas. Aquellos que nos siguen desde hace bastante igual se acuerdan de la dramatización que hicimos sobre el protocolo DNS, pues esto es igual. Cuando dos máquinas conocen el protocolo son capaces de trabajar conjuntamente pero si una usa un protocolo extraño pues le costará encontrar otras máquinas con la que trabajar. Un símil entre protocolo y cerrado y abierto con la realidad sería el siguiente. Quieres aprender un idioma, vas a una academia donde te dan unas clases pero tienes la posibilidad de ir a la biblioteca pública y coger libros para aprenderlo mejor. También puedes buscar por internet e incluso preguntar a gente que gustosamente te ayudará (siempre y cuando no seas muy cansino claro ). En resumidas cuentas, nadie te pondrá trabas a que aprendas ese idioma.

En cambio, si quieres aprender un idioma pero para conocerlo tienes que entrar en una secta y no hay ningún libro ni persona fuera de esa secta que habla sobre el idioma pues lo vas a tener bastante complicado. Esto equivale a un protocolo cerrado.

Quizá te ronda por la cabeza que ¿Quién en su sano juicio querría usar un protocolo cerrado? Pues en su sano juicio supongo que muy pocos pero el problema es que los usamos sin saberlo (la ignorancia, ese gran arma de los “poderosos”). Como estamos hablando de protocolos de mensajería instantánea os voy a poner un ejemplo de este tipo que seguro que conoces: MSN Messenger. Es un protocolo cerrado y sucio. También si te hablo de uno que usa XMPP igual te suena, GTalk. Podría iniciar un flame war diciendo lo malos que son los de Microsoft y lo bien que me caen los de Google pero eso ya para otro día.

Una duda que puede surgir es que si el protocolo de MSN Messenger es cerrado, ¿Cómo hay tantos programas libres ajenos a la secta que lo “entienden”? En informática esto se llama ingeniería inversa. Consiste en capturar mensajes y volver a enviarlo. observar qué pasa y al cabo de muchas horas ir comprendiendo cómo funciona. Un símil sería como irte a china sin saber nada de chino. Con el tiempo acabarás aprendiendo el idioma (que remedio) relacionando palabras que dicen con acciones que hacen luego. Nunca aprenderás chino como si te explicaran la gramática y todo eso, pero acabarás aprendiendo lo suficiente como para manejarte. Y con el ejemplo de la secta, como un día se le ocurra cambiar cosas del idioma nos han fastidiado. Nos toca volver a hacer todo el trabajo.

Requiere de mucho más tiempo comprender un protocolo de esos que hacer un programa que use el protocolo. De ahí que sea tan importante que el protocolo sea libre, que a nadie le gusta perder el tiempo.

Todo esto de poner facilidades para que los demás te entiendan puede llevar a otra cuestión. ¿Y si no quiero que nadie sepa lo que estoy comunicando? Por ejemplo, yo no quiero que sepan lo que hablo con la gente. Me alegra que me hagas esa pregunta
Eso no forma parte del protocolo sino del canal. No voy a explicarlo porque no viene a cuento pero la solución es usar un canal seguro que en resumidas cuentas en cifrar la información. He de decir que el que un protocolo sea cerrado no es sinónimo (ni mucho menos) de seguridad. La información viaja intacta. Mientras el protocolo cerrado de microsoft es totalmente inseguro (ya que no va cifrado) el xmpp siendo libre es totalmente seguro ya que sí va cifrado. Esto lo demostramos un día cuando crackeamos nuestro wifi y sabíamos lo que hablaba por el messenger. Eso con xmpp no hubiera sido posible (cuantas referencias estoy haciendo hoy). Creo que han quedado explicados los puntos “Qué es” y “Por qué usarlo”. Pasemos a centrarnos en XMPP.

Cómo funciona XMPP

XMPP funciona a base de enviar XML. XML es una manera estándar de enviar información y que a día de hoy está hasta en la sopa aunque, de nuevo, no nos demos cuenta. Por ejemplo, el HTML (lo de las páginas web) es XML. Voy a explicar brevemente como va esto del XML (es realmente sencillo)

<cosa atributo1=valor1>Cotenido</cosa>

la palabra “cosa” se denomina tag e indica el tipo de elemento que es. El resto de campos son bastantes intuitivos. Un ejemplo real de mensaje XMPP sería el siguiente

<message from="maxpowel@wixet.com" to="prueba@wixet.com">Ey tío que pasaaaa</message>

Sobra explicarlo pero esto envía un mensaje de maxpowel@wixet.com a prueba@wixet.com con el contenido “Ey tío que pasaaa”

En XMPP existen 3 tipos de elementos diferentes: message, presence e iq
Message: Son los mensajes que se envían los usuarios entre sí.
Presence: Los eventos de presencia de usuarios. Cuando se desconectan o conectan, cuando cambian de estado, de nombre….
Iq: Sirve para enviar comandos internos. Por ejemplo para iniciar una nueva conexión, informar de errores y cosas que no tienen nada que ver con los usuarios.

Pero antes de poder conectarte te tienes que conectar, verdad? Eso se hace al principio (qué listo) y en este proceso el cliente y el servidor negocian a través del protocolo cómo se sincronizarán, el cifrado que usarán y todas esas cosas.

En el título comentaba algo de BOSH. Eso de BOSH es una pasarela para poder establecer una conexión a un servidor XMPP desde HTTP. Esto es necesario por lo siguiente.
XMPP es una conexión persistente. Se mantiene la conexión desde el principio hasta el final, y mientras se envían todos los mensajes que quieran.
HTTP es una conexión de petición y respuesta. Esto es que tu te conectas y haces una petición. El servidor responde y se termina la conexión.

Con este método haces una petición y estas a la espera de que el servidor responda y en ese momento lanzas otra. Hay otro método (polling) que consiste en enviar muchas peticiones cortitas (cada medio segundo por ejemplo) pero personalmente prefiero la primera.
Esta tarea requiere de una pequeña sincronización. Esta sincronización se hace mediante un numerito que le pasamos en cada petición y que se debe ir incrementando después de cada respuesta NO vacía, luego explico que es eso.

Siempre debemos tener una conexión abierta hacia el servidor. Podemos conectarnos al servidor de dos maneras:
Enviando una petición nuestra (por ejemplo queremos enviar un mensaje a un contacto) o escuchando (nos quedamos escuchando al servidor hasta que nos diga algo).
Sólo podemos tener dos conexiones abiertas y en caso de abrir una tercera o un numero de sincronización incrementado incorrectamente provocada que finalice la sesión (el servidor nos llama violadores y nos manda a paseo).
Voy a explicar qué es un mensaje vacío y la relación que tiene con el número de sincronización. El numerito en cuestión se llama RID y debe ser generado de manera aleatoria. Es importante tener un buen algoritmo que genere un número lo más difícil posible de precedir ya que teniendo el RID junto al SID (un numero que identifica la conexión y se crea en ese momento) alguien podría hacerse pasar por nosotros ya que si envias un SID y un RID correcto la cosa va a funcionar (al ser por HTTP el servidor no tiene manera de conocer de dónde viene la petición). Describo un ejemplo.

Inicio sesión y estoy a la escucha de un mensaje del servidor. Estoy usando una conexión.
Decido que a mi amigo “Prueba” quiero saludarle así que le escribo “Hola”. Esto genera un objeto message que se envía al servidor. En este instante estoy usando dos conexiones. Si se me ocurre enviar otra cosa el servidor nos cerrará sesión y adiós muy buenas. Lo que se debe hacer en este momento es cerrar la primera conexión, que devolverá un mensaje vacío. Entonces NO tenemos que incrementar el RID.
Nuestro amigo Prueba nos responde diciendo “Eyyyy” y el servidor nos lo hace saber, creando un message y a través de la conexión creada nos lo envía. Como dije antes, en HTTP una vez recibida la respuesta se finaliza la conexión. En este momento debemos lanzar una petición para escuchar pero como sí recibimos un mensaje incrementamos el RID. Si no lo hacemos ya sabes lo que pasa. Remarco que mensaje no es lo mismo que message. Message es un tipo de mensaje como también lo es presence o iq.

Esa es la parte complicadilla. Conceptualmente no es complejo ni mucho menos pero crear un algoritmo pues ya tiene algo de tela. Si os interesa saber más hice un plugin jQuery (en javascript) y que en apenas 200 líneas es capaz de manejar ese protocolo y facilitar manejadores de eventos. Puedes ver un poco de documentación en

1. Como configurar Google Talk en pidgin Pidgin, para el que no lo conozca, es un...

Por fin volvemos a grabar, esta vez con un 50% mas de spam sobre wixet!El sonido es algo malo, además que esta vez no estamos juntos, si no que Álvaro graba por skype, pero al menos hemos vuelto!

Hablamos de:

- NVidia abandona el desarrollo del driver xf86-video-nv

- Solaris 10 ya no es gratuito

- Bimbo ya usa ubuntu!

- Probamos la beta del starcraft II

- El protocolo XMMP

Promos:

- Gravina82

- Esencia de podcast

- La maquina de series

- La Buhardilla 2.0

Música:

Gold Fever de The Wind Whistles

Entradas relacionadas:

1. Ubuntu vs Windows 7. fight! Hace unos días, en tuxradar, realizaron un analisis entre el...
2. Ubuntu kk No, no estoy calificando a ubuntu como excremento el lenguaje...
3. Gpodcast 1.4 – Bimbo y pizza Volvemos … cada día con mas retraso, el 1.3...

En este gpodcast la segunda parte que grabamos fue brutal, invitados de lujo, música, los mejores chistes… pero lamentablemente se perdió y no hemos podido recuperarlo, a si que os traemos la primera parte, lo que pudimos recuperar. Lo sentimos mucho.

En este caso hablamos de el problema con los codecs en html5

Entradas relacionadas:

1. Gpodcast 1.5 Epílogo – Fin de temporada No! no nos hemos vuelto locos, este podcast es...
2. Gpodcast Especial #1 Tenemos un GPodcast especial, con solo dos secciones, pero...
3. GPodcast 2.8 – “GPodcast en vinagre” Casi un mes mas tarde del último GPodcast volvemos,...