SSH - Intercambio de claves entre servidores

19 06 2008

Para intercambiar las claves, primero has de generar un par de claves en la
máquina origen (puedes hacerlo con el rsa o dsa) :

#/usr/bin/ssh-keygen -t rsa
#/usr/bin/ssh-keygen -t dsa

Esto te dejará en el $HOME/.ssh las claves generadas (una pública y la
privada)
En el nodo destino crea el fichero authorized_keys dentro del $HOME/.ssh

Y por último añades la clave pública del nodo origen en el fichero creado

[usuario@nodo_destino .ssh] ssh nodo1 cat /home/usuario/.ssh/id_rsa.pub >> authorized_keys

Con esto ya puedes hacer un ssh desde el nodo origen (donde has generado las
claves) al nodo destino con el usuario al que le habrás copiado las claves
sin que solicite el password…

Fuente: http://www.solusan.com/intercambio-de-claves-entre-servidores.html



SSH y evitar Man in the middle

10 03 2008

Supongamos que desde nuestro equipo queremos conectarnos a un Server SSH remoto y -por alguna cuestión- queremos tener plena seguridad que el server que nos pide la autenticación es quien dice ser, aquí les dejo unos simples pasos para realizarlo.

Lea el resto »



Seguridad en SSH: iptables, denyhosts, sudoers…

7 09 2007

Si se fijan en los logs generados por ssh, verán la cantidad de intentos de ataques que sufre este servicio. Existen gusanos que lanzan ataques remotos con intención de loguearse como root en nuestros sistemas y así instalar otros rootkits o hacerse con el control del mismo.

Lea el resto »



Seguridad en OpenSSH: adiós a las contraseñas

23 08 2007

Adiós… o al menos parcialmente, para aquellas personas que accedemos diariamente por SSH a una o varias máquinas en las que tenemos que introducir gigantes contraseñas para identificarnos, o para los que busquen un poco más de seguridad en sus servidores a la vez que comodidad.

Lea el resto »



Protege tu servidor SSH de ataques de fuerza bruta

26 07 2007

Si tenéis un servidor SSH corriendo y alguna vez os habéis parado a mirar los logs, habréis visto una gran cantidad de intentos de acceso no autorizados. Si estudiáis más detenidamente los logs descubriréis que la mayoría de veces son ataques basados en diccionarios o similares, por tanto a no ser que nuestros passwords sean muy débiles es difícil que consigan acceder a nuestra máquina. Pero para que arriesgarnos…vamos a ver como protegernos de estos seres malignos e indeseables que intentan entrar en nuestro sistema.

Hay varios programas/scripts que sirven para proteger nuestro servidor SSH de ataques de fuerza bruta, como por ejemplo:

* Denyhosts
* Blocksshd
* Fail2ban

Después de probarlos me quedo con Denyhosts, ya que es sencillo de instalar/configurar, apenas consume recursos y cumple su cometido de sobra. Vamos a ver como instalarnos Denyhosts en nuestra Ubuntu.

En Feisty Fawn (en Edgy creo que también) Denyhosts viene incluido en los repositorios, así que su instalación es tan sencillo como:

sudo apt-get install denyhosts

Una vez instalado debemos crear un par de archivos (si es que no existen ya), para ello nuestro colega touch nos será útil:

sudo touch /etc/hosts.allow
sudo touch /etc/hosts.deny

Con esto ya tenemos instalado denyhosts y con la configuración por defecto, para arrancarlo y pararlo manualmente haremos lo siguiente:

sudo /etc/init.d/denyhosts start
sudo /etc/init.d/denyhosts stop

La configuración de denyhosts se guarda en /etc/denyhosts.conf, vamos a ver algunas de las directivas que podemos modificar desde este archivo:

* DENY_THRESHOLD_INVALID: Número de intentos fallidos (con un usuario que no exista) necesarios para banear esa IP.
* DENY_THRESHOLD_VALID: Número de intentos fallidos (con un usuario existente) necesarios para banear esa IP.
* DENY_THRESHOLD_ROOT: Número de intentos fallidos (intentando entrar como root) necesarios para banear esa IP.
* BLOCK_SERVICE = sshd/ALL/etc… : Esta directiva indica los servicios que bloqueará a los usuarios baneados.
* DAEMON_LOG = /var/log/denyhosts : Indica el archivo en el que se guardará el log de denyhosts.

Estas son las directivas más utilizadas, aunque tiene muchas más, dentro del propio archivo /etc/denyhosts.conf viene comentado para que sirve cada una, por tanto no me alargaré más en explicarlas todas. Otro de los consejos que os daría para evitar el 90% de los intentos de acceso es cambiar el puerto en el que tenemos corriendo el servidor de ssh por uno más alto (por encima del 1024 a ser posible), eso lo hacemos modificando la directiva port en el archivo /etc/ssh/sshd_config. Para terminar os aconsejaría que no permitierais logearse por ssh como root, esto se desactiva en el mismo archivo etc/ssh/archivo sshd_config mediante la directiva “PermitRootLogin no“.

Con todo esto tendremos algo más seguro (en informática pocas veces se esta seguro de algo un 100%) nuestro servidor SSH.

Un saludo compañeros.

Fuente: http://www.elrincondetolito.com/content/view/82/31/



¿Conocías… SSHFS?

11 07 2007

Hace unos días os preparé un tutorial bastante completo sobre el poderoso SSH y os anuncié que a lo largo de la semana os presentaría un par de utilidades complementarias muy prácticas. SSHFS es una de ellas. Gracias a esta aplicación podréis tener una carpeta en un PC remoto y trabajar con/en ella como si fuera local, con transparencia total y la seguridad que ofrece SSH al estar usándose por debajo.

Como siempre en esta sección está al alcance de tu aptitude/apt-get:

$ sudo aptitude install sshfs

SSHFS necesita el módulo “fuse” para poder funcionar, por lo que tendréis que ejecutarlo siempre. Para que no lo tengáis que hacer a mano y lo cargue el sistema automáticamente (y para comprobar si ya lo cargáis o no), abrid el fichero /etc/modules y comprobad si está:

$ sudo gedit /etc/modules

Si está, no tenéis que hacer nada más, cerrad gedit. Los que no lo tengáis simplemente agregad “fuse” al final del fichero por ejemplo, guardáis y cerráis gedit.

Los que lo hayáis metido ahora tenéis dos opciones para cargar fuse, reiniciar y que se cargue automáticamente mediante el archivo modules o cargarlo manualmente hasta que reiniciéis. Supongo que preferís la segunda opción:

$ sudo modprobe fuse

Hecho esto el último requerimiento que necesitamos es tener el servidor SSH funcionando. Los que no lo tengáis podes seguir este manual para hacerlo y enteraros de qué es y para qué sirve.

En cuanto a configuración tan sólo tenéis que agregar vuestra cuenta al grupo que tiene acceso a fuse:

$ sudo usermod -G fuse -a tu_cuenta

Os aconsejo que ahora reiniciéis el entorno gráfico (Ctrl+Alt+Backspace) para tener la certeza de que se aplique vuestra adicción al agregado grupo, en caso contrario es muy probable que os dé un error de permisos si seguís adelante.

En el fondo ya está todo. Tenéis todo listo para montar la carpeta remota en vuestra carpeta local. Vamos a probarlo. Cread una carpeta donde queráis. Para que os sirva de ejemplo voy a crear la carpeta “pepino” en “/home/ceec/”. Tan sólo teneíes que cambiar “ceec” por vuestra cuenta en los siguientes pasos.

$ mkdir /home/ceec/pepino

La carpeta “pepino” va a ser el punto de montaje de la carpeta remota. Es decir, cuando acceda a “pepino” voy a acceder a la carpeta del otro ordenador. En principio para montarla tan sólo tenéis que hacer esto:

$ sshfs ceec@192.168.1.4:/home/ceec /home/ceec/pepino/

Los que ya sabéis cómo funciona SSH no os habréis sorprendido, los que no tranquilos, es fácil de entender:

* sshfs es el comando que va a realizar el montaje remoto
* ceec es la cuenta a la que tenéis acceso en el equipo remoto. En mi caso es el portátil y se llama también ceec, como en el equipo de sobremesa.
* 192.168.1.4 es la ip del portátil en la red local. Puede usarse perfectamente una IP pública (la de internet) para acceder desde el trabajo a casa por ejemplo.
* /home/ceec es la carpeta del ordenador remoto que quiero montar en…
* /home/ceec/pepino/ que es la carpeta del equipo que tengo delante.

Supongo que ya lo habéis entendido bien. Pero hay un pequeño problema. Si no habéis sido previsores funcionará sin problema ya que SSH y por consiguiente SSHFS usan el puerto 22 por defecto. Si no habéis seguido el manual de SSH donde os recomendaba entre otras cosas que cambiarais el puerto os habrá funcionado. Los que sí me hicieran caso, no les habrá funcionado porque el puerto que usáis en SSH no es el 22.

Para indicarle a SSHFS qué puerto hay que usar es igual que en SSH, es decir:

$ sshfs -p 8448 ceec@192.168.1.4:/home/ceec /home/ceec/pepino/

Siendo 8448 el puerto del ordenador remoto. Ahora no debería daros ningún problema. Id a la carpeta que hayáis montado (en el ejemplo /home/ceec/pepino/), entrad y veréis que aparecerán todo lo que tuviérais en la carpeta que le hayáis indicado del equipo remoto (en el ejemplo /home/ceec).

A partir de este momento, todo lo que borréis, añadáis, modifiquéis… de esa carpeta, lo haréis también de la carpeta del otro ordenador.

Tan sólo queda un detalle por enseñaros. Una vez montada la carpeta… ¿cómo se desmonta?

$ fusermount -u /home/ceec/pepino

Listo. Es un buen método para tener algo de vuestro ordenador siempre accesible, o bien para trabajar directamente sobre tus archivos remotos, o bien para compartir lo que queráis a modo de FTP casero o algo parecido. Hay otras alternativas como SFTP y SAMBA, pero hay un punto a favor muy bueno para usar SSHFS, su facilidad de instalación, configuración, uso y, sobre todo, su seguridad ya que toda la información que viaje de un equipo al otro estará encriptada.

Práctico, ¿verdad? ;)



Manual SSH: El Dios de la administración remota

11 07 2007

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

Buscar 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. Escribir 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:

Tomar 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 podes 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.

Fuente: http://tuxpepino.wordpress.com/2007/05/11/ssh-el-dios-de-la-administracion-remota/