El extraño caso del SSH y el ataque de fuerza bruta

Hace poco me pasó una anécdota curiosa que me gustaría compartir con vosotros. Intentaré narrarla de la forma mas fidedigna posible.

Suena el teléfono, es un cliente con el que tengo una de esas relaciones que van mas allá de lo profesional y 'hay confianza':

Cliente> Yago ! Me están atacando !

Yago> ¿? A ti o algún equipo tuyo ?

Cliente> Perdona, estoy un poco acelerado, he encontrado unos logs de lo mas extraños relacionados con intentos de acceso vía SSH

Yago> Si es un servidor de cara a internet, es lo más normal del mundo, deberías cambiar el puerto e instalar fail2ban

Cliente> No, no, es a un equipo con un Linux que uso para administrar máquinas que está tras un router ADSL

#Interesante

Yago> Bueno, mantén la calma, seguro que todo tiene una explicación, ¿podrías enviarme alguna traza del log?

Cliente> Claro, ya mismo

Me llega a mi correo lo siguiente:

Feb  1 22:25:34 localhost sshd[11740]: Failed password for root from 173.83.251.184 port 52597 ssh2

Feb  1 22:25:36 localhost sshd[11742]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=173.83.251.184  user=root

Feb  1 22:25:38 localhost sshd[11742]: Failed password for root from 173.83.251.184 port 53937 ssh2

Feb  1 22:25:41 localhost sshd[11744]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=173.83.251.184  user=root

Feb  1 22:25:43 localhost sshd[11744]: Failed password for root from 173.83.251.184 port 55240 ssh2

Y así, un buen número de líneas con diferentes IPs cuya procedencia geográfica variaba y era de lo más variopinta (turkia, china ...)

Claramente se trata de un ataque de fuerza bruta pero ¿Como podía estar ejecutándose?

Lo primero que me vino a la cabeza son dos hipótesis: O bien era alguien en la misma red (wifi, presumiblemente) o había un 'nat' que hacía visible el puerto.

Descarto el tema de la Wifi por las IPs, si hubiera sido por ahí serian 192.168.x.x

Vamos con el tema nat:

Yago> No tendrás mapeado el puerto 22 de tu router hacia dentro ¿no?

Cliente> No ! claro que no, ya había pensado en eso

Como dicen en Aragón: 'Aragonesico que no toca, no ve'

Yago> Bueno, ve a www.whatismyip.com y la IP que te dé me la envías que quiero hacer una prueba.

Ejecuto un nmap y nada, 0 puertos a la escucha.

El cliente me asegura que su máquina es un pc de sobremesa y por ende, 'no se ha movido', también me asegura solo se conecta vía cable y no tiene interface Wifi (eso descarta que se haya podido conectar a una red insegura de forma inadvertida ...)

Le tranquilizo y le pregunto si tiene activado el acceso vía ssh para el usuario root. Me confirma que no, no está. Le pregunto por la longitud y la complejidad de la contraseña y por lo que cuenta, parece difícil de romper. 

No obstante, le envío una serie de comandos grep para buscar si otros usuarios han sido atacados y si hubo un login positivo. No parece que haya habido compromiso en el sistema.

Dos días después vuelve a sonar el teléfono:

Cliente> Yago ! otra vez ! más intentos de acceso

Como esta persona no está excesivamente lejos decido desplazarme. Ya veré de que forma le hago entender el 'pedazo favor' que le estoy haciendo cuando toque hablar 'de otros proyectos'

Una vez in situ, reviso el router, efectivamente no tiene ningún puerto mapeado, vuelvo a leer los logs y veo que los patrones de acceso suelen ser por la noche.

Le cambio la IP a ese equipo por otra de la red interna y pongo otro PC con la IP anterior, en el que ejecuto un netcat a la escucha en el puerto 22

nc -l -p 22

Y me marcho.

A la mañana siguiente llamo y pregunto

Yago> ¿Que tal? hay alguna conexión en el netcat que dejé ayer ?

Cliente> No, está como lo dejaste, voy a ver en el otro PC

tras un rato ...

Cliente> Joder ! tengo más intentos de acceso !!

Yago> ¿Cooooooooomo? en el equipo donde cambié la IP ?

Cliente> Si ! ahí están

En este punto y ya con los esquemas totalmente por los suelos decido empezar a generar conversación intrascendente mientras intento que se me ocurra algo. Lo bueno de la informática es que siempre, SIEMPRE, las cosas tienen un motivo. No es como por ejemplo la medicina donde lo mismo un día te levantas con un misterioso dolor en la cadera y puedes pasar años escuchando 'no sabemos el motivo'

Después de haber hablado del tiempo, fútbol, política, etc ...

Yago> Se están poniendo feas las cosas con tanta SOPA/Sinde y demás ¿Eh?

Cliente> Si ! empieza a dar miedo navegar, yo estoy probando uno de esos servicios de VPN 'anonimizadores' cuando me pongo a bajar algo

¡Ding! Se me enciende la bombilla

Yago> Ehm, déjame hacer una prueba, conéctate a ese servicio de VPN

Cliente> ¿Ahora?

Yago> Si, dale

Cliente> Ok, ya está

Yago> Ve a www.whatismyip.com y me pegas la IP

Cliente> Toma xx.xx.xx.xx

telnet xx.xx.xx.xx 22

Connected to xx.xx.xx.xx.

Escape character is '^]'.

SSH-2.0-OpenSSH_5.6

Misterio resuelto !

Resulta que esa persona, 'además de usar el equipo para administrar' también lo usaba para descargar cosas, accedía mediante la VPN y esta le daba una IP pública totalmente accesible sin las restricciones de su router ADSL

Lecciones aprendidas:

1- Desconfía de lo obvio, pese a que un escenario parezca claramente una cosa (pc de sobremesa, tras un router adsl, sin wifi) has de intentar despejar la mente y no caer en pensamientos del tipo ¡ Es imposible !, si hay un log que dice X, es X y es ahí donde hay que hacer 'foco'.

2- Fuera los remilgos. Probablemente si hubiera auditado el PC a fondo, revisado todos los logs y configuraciones, habría visto tanto las trazas de la conexión VPN, como los ficheros de configuración. En primera instancia me pareció demasiado intrusivo pedirle 'el root' y lanzarme a investigar y opté por no invadir su privacidad. Craso error

 

Fuente:http://www.securitybydefault.com/2012/02/el-extrano-caso-del-ssh-y-el-ataque-de.html

Servidor de torrents con Delugue-web

Os quiero colocar un magnifico tutorial,  escrito por nuestro amigo y miembro del foro  Matkiber  estoy seguro que os servirá:

“ Se trata de disponer en un solo ordenador (en mi caso un server sin entorno de escritorio) de la aplicación Deluge, usándola vía interfaz web desde cualquier otro equipo de casa (o desde fuera de casa, ejej).Puesto a funcionar en Debian Squeeze”

Accedemos al servidor:
ssh mi-servidor@192.168.1.xx (NOTA-Luego edito y pongo enlace a este otro manual, cuando lo ponga)

pasword:


Y empezamos...

El servidor está funcionando bajo debian Squeeze, y tras probar el programa de sus repositorios, he pensado que mejor instalo una versión más nueva, así que he seguido el tutorial de su web, ahí nos explica perfectamente como hacerlo añadiendo los repos de "unstable"
nano /etc/apt/sources.list
añadir

Código:

deb http://ftp.us.debian.org/debian unstable main

Tu haz lo que estimes conveniente.

Una vez añadido el repo, procedemos con

Código:

apt-get update
 
apt-get install deluge deluge-web deluged

Ahora vamos a lanzarlo (como usuario normal)

Código:

deluged
 
deluge-web

Pues ya lo tenemos, ponemos en nuestro navegador favorito la ip del servidor y el puerto de acceso, ejemplo:

Código:

http://192.168.1.43:8112/

Y accedemos, nos pedirá un pasword, por defecto es "deluge", ya lo podrás cambiar en las preferencias.



¿que conseguimos con esto? pues imagina las posibilidades, podremos añadir un torrent desde cualquier equipo de nuestra red, accediendo via navegador web, o desde cualquier lugar aun sin estar en la red local, desde fuera de casa, una vez descargado, estará a disposición de todos los equipos que tengamos compartiendo en casa, Interesante ¿no?.

Parte 2 de este tocho

A partir de ahora, cada vez que queramos usar deluge en nuestro server, solo tendremos que poner como usuario normal

Código:

deluge
 
deluge-web

Para ponerlo en marcha, la verdad es que no tiene trabajo, y menos cuando la intención es dejarlo funcionando día y noche, pero...igual no quieres molestarte en hacerlo, y prefieres que arranque el solito desde el principio...pues bien, estás de enhorabuena, porque en su web también nos explican como hacerlo en Debian, y ciertamente resulta bastante sencillo, todo se reduce a crear dos archivos y dar permisos, voy a traducir también por aquí ese tutorial que está muy claro, y lo resumo un poco.

Pasos a hacer (como root todos)

Código:

nano /etc/default/deluge-daemon

pegamos dentro:

Código:

[code type=css]# Configuration for /etc/init.d/deluge-daemon
 
# The init.d script will only run if this variable non-empty.
DELUGED_USER=tu-usuario"             # !!!CHANGE THIS!!!!
 
# Should we run at startup?
RUN_AT_STARTUP=YES"

Nota- pon entre las comillas el nombre de tu usuario

Segundo archivo

Código:

/etc/init.d/deluge-daemon

ponemos

#!/bin/sh
### BEGIN INIT INFO
# Provides: deluge-daemon
# Required-Start: $local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Should-Start: $network
# Should-Stop: $network
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Daemonized version of deluge and webui.
# Description: Starts the deluge daemon with the user specified in
# /etc/default/deluge-daemon.
### END INIT INFO

# Author: Adolfo R. Brandes

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DESC="Deluge Daemon"
NAME1="deluged"
NAME2="deluge"
DAEMON1=/usr/bin/deluged
DAEMON1_ARGS="-d" # Consult `man deluged` for more options
DAEMON2=/usr/bin/deluge-web
DAEMON2_ARGS="" # Consult `man deluge-web` for more options
PIDFILE1=/var/run/$NAME1.pid
PIDFILE2=/var/run/$NAME2.pid
UMASK=022 # Change this to 0 if running deluged as its own user
PKGNAME=deluge-daemon
SCRIPTNAME=/etc/init.d/$PKGNAME

# Exit if the package is not installed
[ -x "$DAEMON1" -a -x "$DAEMON2" ] || exit 0

# Read configuration variable file if it is present
[ -r /etc/default/$PKGNAME ] && . /etc/default/$PKGNAME

# Load the VERBOSE setting and other rcS variables
[ -f /etc/default/rcS ] && . /etc/default/rcS

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

if [ -z "$RUN_AT_STARTUP" -o "$RUN_AT_STARTUP" != "YES" ]
then
log_warning_msg "Not starting $PKGNAME, edit /etc/default/$PKGNAME to start it."
exit 0
fi

if [ -z "$DELUGED_USER" ]
then
log_warning_msg "Not starting $PKGNAME, DELUGED_USER not set in /etc/default/$PKGNAME."
exit 0
fi

#
# Function that starts the daemon/service
#
do_start()
{
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
start-stop-daemon --start --background --quiet --pidfile $PIDFILE1 --exec $DAEMON1 \
--chuid $DELUGED_USER --user $DELUGED_USER --umask $UMASK --test > /dev/null
RETVAL1="$?"
start-stop-daemon --start --background --quiet --pidfile $PIDFILE2 --exec $DAEMON2 \
--chuid $DELUGED_USER --user $DELUGED_USER --umask $UMASK --test > /dev/null
RETVAL2="$?"
[ "$RETVAL1" = "0" -a "$RETVAL2" = "0" ] || return 1

start-stop-daemon --start --background --quiet --pidfile $PIDFILE1 --make-pidfile --exec $DAEMON1 \
--chuid $DELUGED_USER --user $DELUGED_USER --umask $UMASK -- $DAEMON1_ARGS
RETVAL1="$?"
sleep 2
start-stop-daemon --start --background --quiet --pidfile $PIDFILE2 --make-pidfile --exec $DAEMON2 \
--chuid $DELUGED_USER --user $DELUGED_USER --umask $UMASK -- $DAEMON2_ARGS
RETVAL2="$?"
[ "$RETVAL1" = "0" -a "$RETVAL2" = "0" ] || return 2
}

#
# Function that stops the daemon/service
#
do_stop()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred

start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --user $DELUGED_USER --pidfile $PIDFILE2
RETVAL2="$?"
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --user $DELUGED_USER --pidfile $PIDFILE1
RETVAL1="$?"
[ "$RETVAL1" = "2" -o "$RETVAL2" = "2" ] && return 2

rm -f $PIDFILE1 $PIDFILE2

[ "$RETVAL1" = "0" -a "$RETVAL2" = "0" ] && return 0 || return 1
}

case "$1" in
start)
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME1"
do_start
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME1"
do_stop
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
restart|force-reload)
log_daemon_msg "Restarting $DESC" "$NAME1"
do_stop
case "$?" in
0|1)
do_start
case "$?" in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;; # Old process is still running
*) log_end_msg 1 ;; # Failed to start
esac
;;
*)
# Failed to stop
log_end_msg 1
;;
esac
;;
*)
echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
exit 3
;;
esac

:

NOTA_ Lo he puesto en negrita porque la etiqueta "code" le maqueta fatal

Seguimos, solo haz copipaste

Código:

chmod 755 /etc/init.d/deluge-daemon
update-rc.d deluge-daemon defaults
invoke-rc.d deluge-daemon start
mkdir -p /var/log/deluge/daemon
mkdir /var/log/deluge/web
chmod -R 755 /var/log/deluge

Atento a este dato

Código:

chown -R TU_USUARIO /var/log/deluge
nano /etc/init.d/deluge-daemon

editamos así, solo es añadir lo que está en rojo

Código:

DAEMON1=/usr/bin/deluged
DAEMON1_ARGS=-d -L warning -l /var/log/deluge/daemon/warning.log"             # Consult `man deluged` for more options
DAEMON2=/usr/bin/deluge-web
DAEMON2_ARGS=-L warning -l /var/log/deluge/web/warning.log"

Y finalmente

Código:

invoke-rc.d deluge-daemon restart
cat > /etc/logrotate.d/deluge << EOF
/var/log/deluge/*/*.log {
        weekly
        missingok
        rotate 7
        compress
        notifempty
        copytruncate
        create 600
}
EOF

Por fín está listo, si lo has hecho todo bien, cuando reinicies tendrás deluge funcionando como demonio y podrás acceder a su interfaz web del tirón.

PD- yo no tengo ningún merito en esto, solo he intentado "traducir" para usuarios noveles el metodo para ponerlo en función, y recomendar la instalación de un par de paquetes que obviaron en el tutorial, espero que te valga de ayuda...

Saludos.

Fuente:http://putodeb.com/index.php?option=com_content&view=article&id=352:servidor-de-torrents-con-delugue-web&catid=48:aplicaciones&Itemid=186

Filtrar ssh de una forma especial

ALGUIEN EN LA FISI: Por seguridad, toque antes de entrar: Tocar antes de entrar no parece presisamente una medida de seguridad sino más bien una regla de buenas costumbres. Pero entonces... ¿A qué ...

Montar directorios remotos con sshfs

Para montar acceso remoto a un directorio por sshfs ( SSH Filesystem ) primero hay que instalar el paquete sshfs .

apt-get install sshfs

Supongamos que tenemos dos maquinas en red con las ips :ç

 Máquina 1 -> 192.168.1.88  ( user )

Máquina 2 -> 192.168.1.90  ( user2)

 Deberemos comprobar que tenemos el modulo fuse cargado y con un lsmod debera salir algo parecido a esto :

 #lsmod |grep fuse
#fuse                   66430  1

Si no es así instalamos el modulo con modprobe -i fuse .
Vamos a conecatar la carpeta home del usuario de la máquina 2 ( 192.168.1.90 ) a la máquina 1 ( 192.168.1.88 ) .


Para montar la unidad creamos el directorio “compartido” en el home del usuario de la maquina 1 ( 192.168.1.88 ) :

 sshfs user@192.168.1.90:/home/user2 /home/user/directorio

La carpeta /home/user2 es la carpeta remota y la carpeta /home/user2/directorio la carpeta local.

** En este punto podemos configurar lo comentado en la entrada http://www.habitacion511.eu/index.php/autentificacion-por-ssh-con-clave-publica-y-privada-2  para evitar poner la clave cada vez que se monta la unidad y configurarlo con clave pública y privada , no es necesario para que funcione .

Con un mount veremos la unidad remota compartida :

 user2@192.168.1.90:/home/user2 on /home/user/maquina2 type fuse.sshfs (rw,nosuid,nodev,max_read=65536

Para desmontar la unidad remota podemos usar “umount directorio” .
Si quereis que se monte cada vez de arrancamos nuestra máquina podemos usar una línea como esta en el /etc/fstab (Siempre y cuando tengamos la clave pública y privada configurada  )

  sshfs#user1@192.168.1.90:/home/user1/       /home/user/maquina2      fuse defaults 0 0

Para montar el directorio con un usuario normal , tenemos que añadir el usuario a grupo fuse

 addgroup user fuse   ( necesita reinicio en debian para que funcione )

Y añadir en el fstab en las opciones de montaje  :   rw,noauto,user  y dare permisos al user al directorio chown user:user directorio .
Montamos con : mount /home/user/maquina2 , ponemos el password y arreglado .

Saludos 

Fuente:http://www.habitacion511.eu/index.php/montar-directorios-remotos-con-sshfs/

Gestión remota con Ubuntu, ssh y x11vnc

Introducción

Poder gestionar una máquina de forma remota es algo que siempre me ha llamado la atención, y cuanto mas tiempo le dedico mas me sorprende todo lo que se puede hacer, y ya no me refiero únicamente a operaciones básicas como copiar archivos utilizando Nautilus y ssh, sino a instalar aplicaciones de forma remota en el huésped, configurarlo, etc.
Pero ¿que pasa si queremos ver lo que sucede en la pantalla de la máquina huésped?, podemos recurrir a VNC.

Gestión remota

Si estamos haciendo determinadas operaciones vía ssh, y queremos lanzar una VNC para ver lo que sucede en la pantalla de la máquina huesped, podemos recurrir a x11vnc. Para ello, una vez hemos entrado en la máquina huesped vía ssh, instalaremos x11vnc, como si estuvieramos en nuestra propia máquina:

?

1	sudo apt-get install x11vnc

Una vez realiza esta operación podemos arrancar el servidor vnc, mediante el siguiente comando:

?

1	x11vnc -display :0

El problema es que nos quedamos totalmente desprotegidos en la máquina huesped, dado que otro con acceso a la red podría acceder a esta máquina. Incluso si ponemos contraseña al servidor, seguimos desprotegidos, puesto que la información viaja sin codificar.
La solución a este problema pasa por conectarse vía ssh utilizando para ello el concepto de “tunneling ssh“.
De esta manera para conectarnos a una máquina remota, por ejemplo con IP 192.168.1.100, con un usuario denominado “miusuario”, el comando a utilizar sería:

?

1	ssh -t -L 5900:localhost:5900 miusuario@192.168.1.100 'x11vnc -localhost -display :0'

Si además te encuentras fuera de la red, y esta tiene cortafuegos, primero tendrás que redireccionar el puerto hacia el equipo en cuestión, por ejemplo, pongamos que utilizas el puerto 22000, tendrías que redireccionar en el router de forma que el puerto 22000 te redireccione al IP 192.168.1.100 Puerto 22, que corresponde a la IP del ejemplo anterior y al puerto correspondiente a ssh.
Además necesitas conocer el IP del router, que lo puedes determinar utilizando el servicio www.whatismyip.com, aunque esto puede ser un problema si no hay nadie en el otro lado. Si en el router remoto tienes un IP dinámica es muy recomendable utilizar un servicio como DynDns, para resolver este problemilla. Suponiendo que la IP del router remoto es 80.30.50.100, y que has redireccionado el puerto 22000 del router al puerto 22 (ssh) de la máquina remota a la que quieres acceder (192.168.1.100), el comando a emplear en este caso sería:

?

1	ssh -t -p 22000 -L 5900:localhost:5900 miusuario@80.30.50.100 'x11vnc -localhost -display :0'

Por último sería interesante que además pusieramos una contraseña al servidor para evitar accesos no convenientes,por llamarlo de alguna manera.

Lanzar una aplicación gráfica en la máquina huesped

Si únicamente queremos lanzar una aplicación gráfica en la máquina huesped, por ejemplo, si quieramos lanzar “amule”, la cosa sería algo así:

?

1	sh miusuario@192.168.1.100 'DISPLAY=:0 amule &'

Hombre, está claro que siempre podríamos iniciar el amule para la línea de comandos desde ssh, y punto, pero cuando lo vi en ask ubuntu, me pareció algo interesante para comentar, que nunca se sabe cuando necesitaremos las cosas.

Conclusiones

Creo que con solo la gestión remota a través de ssh ya tengo más que suficiente para realizar todas las
operaciones que normalmente hago, que hasta la fecha eran copiar y pegar, pero como me he ido aficionando a esto, ahora ya me dedico a la actualización de todos los equipos de forma remota y cosas de este estilo. Pero de cualquier manera, siempre que trabajamos con un equipo con interfaz gráfica es interesante ver lo que está sucediendo al otro lado.
Más información | e-ghost, Karl J. Runge, Ask Ubuntu

Fuente;http://www.atareao.es/ubuntu/conociendo-ubuntu/gestion-remota-con-ubuntu-ssh-y-x11vnc/

Ubuntu y Android conectados vía ssh, con SSHDroid

ntroducción

Al leer hace unos días sobre SSHDroid, en Usemos Linux, se me abrió un mundo de posibilidades ante mis ojos, y no es que no sea fácil acceder a un móvil con Android desde tu PC, pero cada vez se me hace más incómodo tener que conectar por USB cualquier equipo (incluida la cámara de fotos) para sacar la información.
Lo más cómodo es siempre, dejar tu móvil o tablet cargando, al llegar a casa, pero con el wifi en funcionamiento, y mientras el chisme se carga, tu te conectas a él y sacas la información que necesitas, y aquí es donde entra SSHDroid.

SSHDroid

SSHDroid, es una aplicación a instalar en tu móvil/tablet Android, que te permitirá conectarte a él vía ssh. SSHDroid, es al fin y al cabo, un servidor ssh. Es gratuita, aunque tiene el inconveniente de la publicidad. Pero, no necesitas ser administrador para poder funcionar vía ssh.

Instalación

La instalación es tu móvil, es vía market

Uso

Una vez instalado, inicias SSHDroid, y verás la siguiente información en tu pantalla:


Aquí puedes ver la dirección del servidor y el puerto, así como el nombre del usuario:

• usuario: root
• contraseña: admin
• dirección: 192.168.2.134
• puerto: 2222

la dirección será la única variable que cambie, he puesto 192.168.2.134 que es la que utilizaré en los ejemplos, y que tendrás que modificar en función de la red. Incluso en tu misma red, si no asignaste IP estáticas a tus máquinas, tendrás que modificarlo cada vez. Esta es una razón para utilizar un firmware de terceros en tu router, como indiqué en el artículo referente a Tomato. Esta operación hace mucho más sencillo el acceso a las diferentes máquinas, puesto que al tener IP estática, el acceso siempre es a la misma dirección.

Conexión vía ssh desde el terminal

Para conectarte vía ssh desde el terminal, el comando sería:

?

1	ssh -p root@

que en mi caso, es:

?

1	ssh -p 2222 root@192.168.2.134

Te preguntará la contraseña, que recuerda que es admin, y ya está dentro de tu móvil/tablet.

Copiar al terminal un archivo utilizando scp

El comando para copiar un archivo es:

?

1	scp -P root@:

que en mi caso es:

?

1	scp -P 2222 "La Visión.pdf" root@192.168.2.134:

Igual que en el caso anterior, te preguntará la contraseña, que recuerda que es admin, y ya está copiado.

Conectarse vía sftp con Filezilla

Lo primero es añadir el sitio, para ello en el menú de Filezilla Archivo > Gestor de sitios, y verás la siguiente ventanta:

Introduces el servidor (la dirección IP, en mi caso 192.168.2.134)  , el puerto (2222), el tipo de servidor, que en el caso que nos ocupa es SFTP, el nombre del usuario (root) y la contraseña (admin), y ya lo tienes configurado, pulsas conectar y ya estás dentro.

Conectarse vía Nautilus

También podemos acceder desde Nautilus, para ello solo tenemos que introduccir la dirección donde queremos conectarnos en la barra de direcciones, con un formato como el siguiente, sftp://root@192.168.2.134:2222/, nos preguntará la contraseña (admin):

y una vez introducida, ya podremos trabajar con nuestro móvil/tablet como si fuera un directorio más de nuestro PC:

Conclusión

Como ves tienes muchas y variadas posibilidades, para acceder a tu móvil/tablet con
Vía | Usemos Linux con SSHDroid, desde tu terminal o desde Nautilus. Ciertamente ganas en comodidad, rapidez y conectividad. Te olvidas por completo de tener que conectar tu móvil a tu máquina vía usb, buscar cables, etc.
Es una alternativa más para poder pasar la información entre tus diferentes dispositivos, de una manera cómoda.
Vía | Usemos Linux
Fuente:http://www.atareao.es/ubuntu/conociendo-ubuntu/ubuntu-y-android-conectados-via-ssh-con-sshdroid/