jump to navigation

Convocatoria EDUSOL 2009 junio 19, 2009

Posted by jmanuelmeza in Debian, Educación, edusol, Linux, Personal, Psicología, software libre, Tecnología.
add a comment

Abierta la inscripción de ponencias y participantes al encuentro en línea EDUSOL 2009

Quinto Encuentro en Línea de Educación, Cultura y Software Libres, EDUSOL 2009” a celebrarse del 09 al 20 de Noviembre del 2009 en que abordaremos como tema general las “Redes Sociales“.

Durante 4 años hemos estado construyendo un espacio comunitario de reflexión académica al rededor de la educación con software libre, en el que año con año hemos sumado los discursos de personas y colectivos que luchan por causas similares en áreas como el arte o la política.

Por esta razón este año ampliamos la convocatoria de nuestro encuentro oficializando el eje de la cultura libre, entendida esta como la cultura promovida por diversos movimientos sociales basados en la libertad de distribuir, compartir y modificar obras creativas diversa índole.

Así el Quinto Encuentro en Línea de Educación, Cultura y Software Libres convoca a activistas, docentes, investigadores y fauna similar a presentar ponencia, taller, tutorial o simposio por IRC en línea sobre experiencias educativas con software libre o cultura libre.

Algunos de los ejes temáticos son: Educación: en línea y a distancia, multimedia, experiencias de uso, objetos de aprendizaje, perspectivas tecnológicas con software libre. Sociedad del conocimiento y cultura libre: proyectos colaborativos, políticas y experiencias de uso, producción y consumo en la Internet, ética y política en el software y cultura libres, construcción democrática de la sociedad. Conocimiento, libertad y educación: experiencias comunitarias con software libre y esquemas permisivos de contenidos.

Fechas Importantes

10 de Octubre. Cierre de recepción de ponencias en extenso.
24 de Octubre. Notificación de aceptación preliminar.
8 de Noviembre. Cierre de registro a participantes.

Encuentro del 09 al 20 de Noviembre del 2009.

Costo: Ninguno.

Muchas personas nos han subsidiado con su trabajo y tiempo para tener un encuentro sin costo, aprovechalo.

Vínculos importantes

Página del encuentro: http://edusol.info/es/e2009
Convocatorias: http://edusol.info/es/e2009/convocatorias
Voluntarios: http://edusol.info/es/e2009/voluntarios
Difusión: http://edusol.info/es/e2009/difusion

Agregados relevantes

Bajo el lema, porque instalar no es suficiente, tendremos un curso mixto (presencial-en línea) de dos semanas de uso básico de linux, dirigido a personas no iniciadas técnicas. Del 26 de Octubre al 5 de noviembre.

Registra tu aula de medios!
Más detalles en http://edusol.info/es/e2009/convocatorias/instalarnoessuficiente

Día de educación y cultura libre (6 de noviembre de 2009) en el que se convoca a los colectivos a organizar un par de platicas de cara a su comunidad para discutir el tema de la educación y cultura libre.

Registra tu sede en:
Más detalles en http://edusol.info/es/e2009/convocatorias/dialternivo

Dejo WordPress por una vida mejor! mayo 22, 2009

Posted by jmanuelmeza in Anime, Basketball, Basquetbol, Blogroll, Caca a windows, Cine, Debian, Educación, edusol, Equipo Ryonan, humor, Linux, Literatura, Personal, Psicología, Reflexiones, Ryonan, software libre, Tecnología, ubuntu, Ubuntu linux, Uncategorized, Ventas, Videojuegos.
3 comments

Sé que hay algunos que aún me siguen, aunque creo que son pocos, pero quería publicar la noticia sobre mi cambio de blog, dejo este en wordpres y me voy a mi dominio propio:

http://manuelmeza.org

En él encontrarán mi blog y mi CV, por favor, entren ahí, ahora escribiré solo en ese blog y este lo dejo para la posteridad!!

Saludos!

Distros de linux para máquinas viejas y no tan viejas junio 23, 2008

Posted by jmanuelmeza in Debian, Linux, software libre, ubuntu, Ubuntu linux.
Tags: , ,
7 comments

¿¿Que gallina vieja hace buen caldo??

Pues en linux no aplica…

Durante estas 2 semanas en el CEXPE (laboratorio escondido en una cueva a las afueras de la ciudad de México al más puro estilo de la baticueva) probamos varias distribuciones linux para ver cuáles podían ofrecernos una solución en términos de usabilidad (entorno gráfico, programas, encontrar archivos, etc.) y velocidad.

En nuestro proyecto XOTI tenemos contemplado la donaciónde equipos mismos que se entregarán a personas que de verdad los necesiten, generalmente en comunidades rurales o con pocos recursos económicos, por lo tanto, nos dimos a la tarea de comenzar nuestras pruebas en equipos con las siguientes características:

Pentium 4

128 Mb Ram

HD 60 gigas

Tarjeta Nvidia (no se de cuantos mb ni modelo)

Conexión por ethernet a internet

CD rom y floppy disk

En realidad son equipos aún bastante buenos (excepto por la RAM) y sin embargo varias de las distros “ligeras” para “máquinas viejitas” no dieron el ancho…

Aquí presentamos una tabla con los resultados.

Distro

Basada en…

Características

Comentarios

Knoppix/Gnoppix

Debian

KDE

KDE es demasiado pesado para una pc con 128 mb en ram

Damn Small Linux

Live CD

Instalable

Blackbox

Se ve feo, sin embargo, es muy ligera aunque el software que usa es funcional es poco atractivo.

Difícil de utilizar por alguien con pocos conocimientos

Ubuntu lite

Ubuntu

gusty

Feisty

Dapper

Usa LXDE (que a su vez está basado en openbox).

Se instala a partir de un sistema base (alternate o mini) y posteriormente se utiliza un sh para terminar la instalación.

Fuxbuntu

Ubuntu

Usa fluxbox

Problemas con la ISO y con los CD. Nunca pudo arrancar.

Deli linux

Usa icewm

Difícil de instalar.

Difícil de configurar.

No arrancaron las X

Slax

Slackware

Usa KDE

Ligero en Live CD pero al usar KDE es pesado para una pc con las características antes mencionadas.

Vector linux

Versión light

Nunca pudo instalarse, problemas en la instalación, no utilizable.

Versión Starndar

Usa xfce

Instalación requiere algunos conocimientos. Pesado ya instalado, se alenta un poco

Puppy linux

Puppy

Muy ligero.

Fácil de montar y acceder a particiones

Dificultad en la instalación.

Tarda mucho en compiarse al hd

Cuando se ha instalado no logra arrancar.

Elive

Debian etch

Muy Ligero

Usa enlightenment 16 y 17

Muy ligero en live Cd

Muy ligero instalado

Fácil de instalar

Programas adecuados, ligeros (gnomeoffice)

Entorno agradable

Así es, por todos los elementos antes mencionados el ganador es Elive! Esta sí es una distro para resucitar (cual Lázaro) máquinas viejas.

Lo probé en una pentium celeron a 400 mhz con 128 en ram y también corre aceptablemente, dicen que hasta con 64 va bien, pero quien sabe.

Parece que va bien aunque tenemos algunos cuelgues con ciertas aplicaciones pero veremos si esto es pasajero.

Seguiremos informando

Saludos!

Ya estuve en el Consol 2008!! febrero 25, 2008

Posted by jmanuelmeza in Debian, Educación, edusol, Linux, Personal, Psicología, Reflexiones, ubuntu, Ubuntu linux.
Tags: , , ,
1 comment so far

Pues si lectores, ya pasó el CONSOL 2008 en la Universidad Autónoma de la Ciudad de México y fui solamente el día que tenía que presentar.

Lo que pasa es que tuve algo de trabajo y decidí solo asistir a ese día, además de que no tenía mucho $$ para gastar y pues que mejor que ir como ponente a presentar, recibir una bolsa con regalitos y hasta comida gratis :D.

El encuentro lo vi un tanto desierto, de hecho hasta la universidad estaba algo desierta, nos preguntábamos si había clases o no, a mi se me hacía que no porque no vi casi alumnos, ni en los exteriores ni en las aulas.

En fin, la ponencia de Alejandro Miranda y Gunnar Wolf sobre el tercer encuentro en línea de educación y software libre estuvo muy bien, si alguien los conoce se ha de imaginar que fue una conversación dispersa y entre “cuates”.

Aquí este par:

alex-y-gunnar.jpg

A las 12 tocó el turno del proyecto Xoti: herramientas libres para la vida, un esfuerzo de Alejandro Miranda, José Mayorga (quien no pudo asistir) y mío (José Manuel Meza) para acercar las tecnologías a los que menos tienen por medio de la creación de documentación adecuada para iniciar a los usuarios con menos experiencia en el cómputo.

alex-y-yo.jpg

La charla fue un poco más formal, bueno, mi parte porque Alejandro todo lo hace muy ameno, inició con este sustento social del proyecto, el porqué debemos de hacer algo por poner nuestro grano de arena para “cambiar el mundo” (como el dice), una introducción de lo que es y no es el proyecto Xoti y luego tocó mi turno.

exponiendo-2.jpg

La verdad me sentí un poco nervioso a pesar de las pocas personas que asistieron,empecé a hablar un poco rápido pero creo que me di a entender, expliqué el método de producción de la documentación que seguimos, nuestros criterios y etapas de la documentación, la justificación del uso de imágenes y videotutoriales y mostré un par de ayudas ya avanzadas, la de Base de datos de openoffice y la de writer.

Mientras Gunnar jugaba con mi cámara…

gunarcarota.jpg

Todo esto lo fuimos alternando siempre con un discurso sobre la psicología educativa y el diseño adecuado de las ayudas para que quedara bien claro que no se trata de otros tutoriales de los que abundan en la red y parece que quedó bien claro puesto que un par de personas de la misma UACM se acercaron a platicar con nosotros al final de la ponencia.

Me parece que hicimos un buen papel, la verdad me han dado ganas de impulsar más el proyecto, dedicarle aún más tiempo y proponer mejores ideas, esto ya urge y necesitamos manos, en primera instancia vamos a trabajar sobre la plataforma drupal que acaba de instalar Alejandro y a perfeccionarla para que si alguien quiere sumarse se sienta como en casa.

Nadie fue a verme 😦 y pido una disculpa a Fetova y a Adam000 porque no pude ir a su ponencia el viernes 22, sí quería pero tenía trabajo y no pude hacer mas…

Por cierto, al término de nuestra ponencia fuimos a un aula en donde conocí de cerca la OLPC!! está genial el aparatito, casi mato al que lo llevaba 😀

olpc.jpg

Salí en la foto grupal del consol, en el centro, junto a Alejandro y debajo de Gunnar, espero que alguien pueda pasarme una copia… digital 😛

Saludos!!

Manual SSH: El dios de la administración remota diciembre 4, 2007

Posted by jmanuelmeza in Debian, Linux, software libre, ubuntu, Ubuntu linux.
add a comment

Y es que no se merece un titular peor. ¿Has estado alguna vez en el trabajo o en casa de y has necesitado o te has acordado de un archivo que no tienes en ese momento pero sí en tu ordenador? Existen los escritorios remotos, de hecho Ubuntu trae uno instalado por defecto, pero puede que no queramos hacer más que mandarnos un archivo o hacer algo en el ordenador remoto. Para esto -y mucho más- existe SSH, con un inmenso potencial.

SSH son las siglas de Secure SHell. Lo que te ofrece es una consola en un ordenador remoto con los privilegios que tenga la cuenta con la que conectes. Es decir, si en tu PC tienes varias cuentas, puedes conectar desde otro ordenador al tuyo con cualquiera de esas cuentas y sus respectivos privilegios, como pudiera ser la cuenta root, la de tu administrador sudo o la de un usuario normal sin poder de administración. Y todo esto con encriptación de datos.

En este tutorial os voy a mostrar algunas facetas de su uso, pero antes debéis saber que tener el servidor de SSH corriendo es de cierto riesgo, ya que si no tocáis la configuración por defecto para aumentar la seguridad a un nivel más que aceptable, puede ser un agujero para que alguien pueda entrar en vuestro sistema. Pero no os preocupéis, si seguís estos pasos es difícil que suceda, nunca imposible, pero sí difícil.

El manual es algo extenso debido a que he intentado hacer que resulte bastante completo y que, como llevo haciendo en el resto de tutoriales, quiero que sepáis lo que estáis haciendo, los porqués y lo que significa cada cambio que hacéis. De esta forma tendréis criterio propio para vuestras modificaciones personales.

Instalar

En vuestros repositorios ya tenéis SSH dispuesto a instalar, así pues:

$ sudo aptitude install ssh

Una vez instalado se autoiniciará el demonio que ejecuta el servidor SSH y gestiona las solicitudes de login remoto.

Configuración: Mayor seguridad

Como decía antes no es muy inteligente usar SSH sin modificar el fichero de configuración del servidor. Vamos a modificar algunas opciones para conseguir una seguridad aceptable.

$ sudo gedit /etc/ssh/sshd_config

(nota) Si algunas de las opciones que aquí comento no aparecen en vuestro sshd_config, simplemente agregadlas. Podéis hacerlo donde queráis, aunque lo suyo es que lo hagáis al principio o al final para que sepáis cuales son las opciones que vosotros habéis agregado.

Vemos un fichero de configuración típico basado en “opción valor”. Vamos a comenzar las modificaciones por el puerto que es lo primero que vemos y una de las cosas más importantes. SSH usa por defecto el puerto 22. Esto significa que si no lo cambiamos estamos entregando a un caco que sabe la dirección de dónde vivimos (nuestra IP) también la llave del portal.

Cambiaremos el puerto para evitarlo. Esto no quita que el caco pueda intentar averiguar “el portal” si sabe cómo hacerlo pero al menos le ponemos impedimentos. También hay scripts que atacan directamente el puerto 22, por lo que el cambio de puerto es algo obligatorio. Poned el que queráis y abridlo también en el router para que podáis acceder a vuestro ordenador desde otro. Usaremos por ejemplo el 4321, podéis poner el que queráis. Así pues en el fichero de configuración:

port 4321

Un poco más abajo buscad la opción “Protocol” debe estar a valor 2, si no es así (valor 1 ó 2,1 ponedla. Hay dos versiones de protocolo SSH. La primera está ya en desuso y tiene varias vulnerabilidades. Así debéis dejarlo en vuestra configuración:

Protocol 2

Buscad la sección “Authentication”. Sus dos primeras opciones son también importantes. La primera es el número de segundos que tendrá el usuario remoto para hacer login en tu máquina. Poned ese valor a pocos segundos, no tardamos mucho en hacer login si sabemos la cuenta y la password. De esta forma evitamos ciertos scripts que se aprovechan de ese tiempo. El valor típico en términos de seguridad es 30, aunque podéis poned incluso menos si estáis más conformes.

LoginGraceTime 30

Justo debajo tenéis otras de las opciones más importantes, PermitRootLogin. Si antes usé la metáfora del caco y el portal, esta opción viene a ser que le digáis también en qué planta del bloque de pisos vivís y qué puerta, faltándole sólo la llave. Con esto lo que insinúo es que si sabe por qué puerto entrar, tan sólo le queda averiguar dos datos: el nombre de una cuenta y su contraseña.

Si tenemos esta opción habilitada (yes) el caco ya tiene la mitad del trabajo hecho, pues el usuario “root” existe en todas las máquinas GNU/Linux, tan sólo le queda averiguar la contraseña. Por eso es más que recomendable deshabilitar esta opción. No os preocupéis los que tenéis en mente usar SSH para hacer un uso administrativo, podéis hacerlo con vuestra cuenta y sudo sin problema alguno. Así pues…

PermitRootLogin no

También podéis señalar con el dedo las cuentas que tienen permitido el uso SSH (AllowUsers). Pongamos un ejemplo, que es como mejor se entienden las cosas: Supongamos que tienes un amigo con el que quieres compartir algo vía SSH y además tiene un hermano que es un enreda y en el que no confías por si te la puede liar. Llamaremos a las cuentas “amigo” y “pesado” respectivamente. Para restringir el uso de SSH a tu amigo y a tu propia cuenta (llamémosla “pepino”) podemos indicárselo mediante configuración. Incluso podemos indicar también que tu amigo sólo se pueda conectar a tu ordenador desde el suyo, sabiendo su IP (supongamos que es 83.45.258.21). Pondríamos en la configuración:

AllowUsers pepino amigo@83.45.258.21

De esta forma tú podrías usar tu cuenta (pepino) para conectar a tu equipo desde cualquier lugar, tu amigo podría hacerlo sólo desde su ordenador (si tiene esa IP) y tu hermano no podría conectar a tu máquina vía SSH, si no tiene tu cuenta.

Otra opción interesante es el número de intentos que tiene el usuario remoto para hacer login (MaxAuthTries). Como comenté antes, quien intente conectar debe acordarse de su login y password, por lo que es tontería darle un número grande de intentos. En principio con dos son más que suficientes. Si al segundo intento no lo ha conseguido se cortará la conexión SSH. Siempre se puede volver a conectar y reintentarlo, pero así nos quitamos de encima ciertos scripts que intentan encontrar el login por fuerza bruta a base de ensayo y error.

MaxAuthTries 2

Por último hay otra opción que define el número máximo de usuarios conectados simultáneamente a tu máquina. Esto ha de adaptarse a tus propias necesidades. Si estamos hablando de un ordenador personal donde sólo vas a conectar tú, pues lo lógico sería que como mucho hubiera una. Si estamos hablando de un ordenador que hará las veces de servidor compartiendo una carpeta a varias máquinas, deberás decidir cuántos son. Cuanto tengas claro el número indícalo en la opción siguiente en lugar de la ‘X’:

MaxStartups X

Ya podéis guardar y cerrar gedit. Con esto tenéis un servidor SSH bastante seguro. Como comenté antes nunca es 100% seguro pero a priori podéis estar bien tranquilos. Sólo resta reiniciar el propio servidor SSH para que tome los cambios que hemos efectuado en su configuración. Escribid en consola:

$ sudo /etc/init.d/ssh restart

Un último consejo. Como habéis visto podemos poner trabas al caco en cuanto a nuestra dirección y puerta, pero ¿podemos ponerle problemas con la llave? La llave se entiende que es la contraseña. Y la respuesta es afirmativa. Podéis hacerlo pero vosotros mismos. Poned claves en condiciones a vuestras cuentas. Usad como poco 5 ó 6 caracteres y a ser posible que se entremezclen mayúsculas, minúsculas y números, por ejemplo: entr3TuXeSyp3p1n0s.

Es un ejemplo exagerado, enrevesado a la hora de escribir e incómodo para meterlo en sudo cada dos por tres, pero intentad que sea del estilo y procurad que no sea algo tan simple como vuestro nombre, el de vuestra mascota, vuestra fecha de nacimiento, grupo favorito, etc.

Uso de SSH en consola
  • Conectar

Ahora que tenemos SSH bien seguro es hora de que veais para qué sirve. Parto de que tenéis dos equipos, el que tenéis delante y al que queréis conectar. Obviamente debéis tener una cuenta en el segundo para poder entrar. La forma de conectar por defecto es la siguiente:

$ ssh tu_cuenta@ip_del_ordenador_remoto

Esto sería si no hubiéramos cambiado el puerto, ya que intentaría conectar por el puerto 22 que es el puerto por defecto del cliente. Podéis cambiarlo si queréis para que conecte por defecto por el puerto que le digáis en lugar del 22 editando el fichero /etc/ssh/ssh_config. Descomentáis (si está comentada) la opción “Port” y en lugar de “22″ ponéis el que queráis.

La otra opción, que es lo más normal, es simplemente indicarle en la línea de conexión qué puerto ha de usar:

$ ssh -p puerto tu_cuenta@ip_del_ordenador_remoto

Para que lo veais más claro os voy a poner un ejemplo. Mi portátil está en la ip 192.168.1.4 y el puerto SSH que tengo para el mismo es el 4884. La cuenta que voy a usar para conectarme es “pepino”, así que para conectar desde mi PC de sobremesa al portatil sería:

$ ssh -p 4884 pepino@192.168.1.4

Tras esto me pedirá la contraseña:

pepino@192.168.1.4's password:

La introducimos y tras un texto de “bienvenida” veremos que nuestro prompt ha cambiado a “nombre_cuenta@nombre_manquina”. Mi portatil se llama salamandra, así pues mi prompt es:

pepino@salamandra:~$

A partir de este instante tu consola está controlando el equipo remoto. Estarás en el home de tu cuenta en la máquina remota. ¿Qué podemos hacer?

  • Copiar ficheros

Seguramente es lo primero que se os ha pasado por la cabeza a algunos. Efectivamente podemos copiar ficheros fácilmente desde el ordenador remoto al que estamos usando en este momento, y es fácil (es una sóla línea):

$ scp ruta/archivo cuenta_en_ordenador_presente@ip_ordenador_presente:ruta/fichero

Complicado a priori, ¿verdad? En el fondo no lo es, una vez sabéis qué es cada cosa. ruta/fichero es el lugar donde está el archivo a copiar en la primera aparición, y el lugar donde se va a copiar en la segunda. cuenta_en_ordenador_presente es la cuenta que estáis usando (u otra) en el ordenador que tenéis delante (no el remoto). La ip_ordenador_presente es precisamente la ip de vuestro ordenador. Pero como siempre mejor con un ejemplo.

Supongamos que quiero copiarme un fichero llamado pepino.jpg que está en el escritorio de la cuenta “pepino” del portátil (el ordenador remoto) y quiero copiármelo en el home de la cuenta “tux” de mi ordenador presente, cuya ip es 192.168.1.6. Ya que estoy quiero aprovechar y cambiarle el nombre. Quiero que se llame pepinaceo.jpg en lugar de pepino.jpg. Escribiremos en el SSH (es una sóla línea):

$ scp /home/pepino/Desktop/pepino.jpg tux@192.168.1.6:/home/tux/pepinaceo.jpg

¿No funciona? ¿Sabes por qué? El puerto, recordad que lo cambiamos y aquí también tenemos que indicárselo. En el ordenador de sobremesa tengo abierto el puerto 8448, así pues (es una sóla línea):

$ scp -p 8448 /home/pepino/Desktop/pepino.jpg tux@192.168.1.6:/home/tux/pepinaceo.jpg

Nos pedirá la contraseña de la cuenta “tux” en el ordenador que tenemos delante y copiará el archivo:

pepino@192.168.1.4's password:
pepinaceo.png 100% 292KB 291.7KB/s 00:00

Y si ya estuvieramos en el escritorio (prompt: pepino@salamandra:~/Desktop$) no habría que poner toda la ruta si no queremos ya que tomaría la ruta relativa a la actual:

$ scp -P 8448 pepino.jpg tux@192.168.1.6:/home/tux/pepinaceo.jpg

(Nota) Ojo con la ‘P’ que en este caso debe ser mayúscula.

Otra gracia del asunto es que no tienes por qué copiarlo a tu equipo actual. Si tienes acceso a otro ordenador más, puedes copiar algo de uno al otro del mismo modo, es decir, teniendo login en ambos y sabiendo su IP. Por otro lado si lo que queremos copiar es una carpeta, basta con añadirle el parámetro ‘-r’ para que copie todo su contenido (r=recursivo).

  • Otros usos

Básicamente cualquiera que se os pase por la cabeza. Daros cuenta que para un sistema GNU/Linux el interfaz no lo es todo, de hecho es prácticamente una aplicación que está corriendo bajo el propio sistema operativo, por lo que podéis administrar perfectamente vuestro equipo desde una consola y con acceso remoto vía SSH. Dentro de una conexión SSH, podéis reiniciarlo:

pepino@salamandra:~$ sudo reboot
Broadcast message from pepino@salamandra
(/dev/pts/1) at 23:45 …
The system is going down for reboot NOW!

O apagarlo:

pepino@salamandra:~$ sudo halt
Broadcast message from pepino@salamandra
(/dev/pts/1) at 23:51 …
The system is going down for halt NOW!

O usar cualquier otra aplicación de texto, como podría ser una que os presenté hace poco y que os podría venir muy bien en este caso: links. De esta forma si queréis podeís navegar en la consola y descargaros algo en vuestra máquina estando en otra.

El abanico de posibilidades es realmente inmenso.

SSH en Nautilus

Lo cierto es que si lo que queremos es simplemente copiar archivos o ver el contenido de alguno de ellos que están en otra máquina, podemos usar nautilus que siempre será más amigable para algunos que a través de consola.

No hay mucho cambio al respecto. Alt+F2 y escribid dentro “nautilus”. Se os abrirá el navegador de archivos. Nautilus tiene dos formas de mostrarte dónde estás dentro de la jerarquía de directorios. Una es a través de botones donde cada carpeta es un botón que puedes pulsar para volver atrás:

Y otra que te indica la ruta en modo texto:

Para cambiar de un modo al otro pinchad en el icono que está a la izquierda del todo que es un folio escrito y un lápiz. Nos quedaremos en el segundo modo y en la caja de texto de “Lugar:” escribiremos la orden de conexión:

ssh://tu_cuenta@ip_pc_remoto

Siguiendo con los ejemplos anteriores:

ssh://pepino@192.168.1.4

Esto sería si el puerto es el que está por defecto, como nosotros lo cambiamos tenemos que indicárselo con “:puerto” tras la ip. En nuestro ejemplo:

ssh://pepino@192.168.1.4:4884

Ahora nos pedirá la contraseña de la cuenta. Tenomos estas tres opciones:

Tomad la decisión que queráis. Personalmente yo soy de los prefieren tomarse la molestia de introducir la clave en cuestiones tan importantes como es la seguridad de SSH.

Tras esto nos colocará en la raíz de la máquina remota. Si lo que queríamos era que nos dejara en una carpeta determinada se lo podemos indicar en la línea de conexión. Por ejemplo en el escritorio de nuestra cuenta:

ssh://pepino@192.168.1.4:4884/home/pepino/Desktop/

Ahora podéis copiar archivos y carpetas con total comodidad desde vuestro escritorio GNOME.

Ejecutar aplicaciones gráficas remotamente

Otra cosa muy práctica que podemos hacer gracias a SSH es ejecutar una aplicación que no tenemos en el equipo actual pero sí en el remoto y trabajar allí. Es decir, puedes mirarlo como un servidor de trabajo gráfico. Si aún no queda claro os pongo otro ejemplo:

Mientras estábais fuera de casa el pesado de tu hermano se ha hecho con tu ordenador porque tiene que hacer algo y si no “se lo dice a mamá“. Sin embargo tú también tienes cosas que hacer en él. No hay problema. Te pones en el equipo de tu hermano y abres la aplicación que necesites de tu propio ordenador en el PC de tu hermano.

Práctico, ¿verdad? Pues es muy sencillo, basta con añadir un argumento más (-X) y el nombre de la aplicación que queremos usar. Por ejemplo imaginemos que queremos jugar a Doom en DOSBox, y en el ordenador de tu hermano no tenemos ninguna de las dos cosas. Podemos instalar DOSBox, copiar la carpeta de Doom, montarla y jugar. O también podemos ejecutar directamente DOSBox remotamente y montar el juego que ya tenemos en nuestro equipo:

$ ssh -X -p 4884 pepino@192.168.1.4 dosbox

Ahora tan sólo resta montar la carpeta como ya os mostré. Podéis introducir la ruta de vuestro PC pues en el fondo es en vuestro PC donde se está ejecutando todo.

Cambiar el mensaje de bienvenida

Ya saliendo de la parte práctica, he querido hacer esta pequeña sección dentro del manual para los fanáticos de la personalización como yo. Si recordáis cuando os expliqué la conexión por consola, os comenté que tras introducir la clave nos daba una especie de texto de bienvenida. Este texto de bienvenida es modificable y puedes poner lo que quieras. Este es el de mi equipo de sobremesa:

Para hacerlo es simple. Tienes que editar (con privilegios de administrador) el archivo /var/run/motd y escribir dentro lo que quieras que aparezca cuando alguien se conecte. Es decir:

$ sudo gedit /var/run/motd

Lo modificamos a nuestro gusto, guardamos y cerramos gedit.

Artículos complementarios

Espero que después de todo el ladrillo os haya resultado práctico e interesante, pues sin duda SSH lo es.

Este post está integramente compiado de: tuxpepino.

Si lo copié tal cual es porque me interesa mucho aprender de el y también algunas personas cercanas a mi.