Que tal.
El caso es que lo que quieres es sniffar los usernames y passwords creando un "rogue && lame" server con Bash!
Hmm... yo para SHHV1 claro, pensaria en Dsniff y sshmitm, o Ettercap. O sea, quedandote con logueos desde el exterior al interior envenenando al router y al server SSH..
Pero el caso es hacerlo como tu quieres aqui.
Lo que intentas no es muy practico, ya que intentas establecer una conexion ssh la cual hace uso de certificados y de encriptamiento y tu usas un simple script que devuelve puro texto plano, ni negocia nada de certificados ni historias.
Por mucho que te lo montes con Ssh Port Forwarding o lo que sea, tu aplicacion no tiene la habilidad de hablar y establecer la conexion cifrada. Por lo cual, es mejor como un Rogue Telnet Server.. no crees!!?? :___).
Bueno, Saludos.
/**** MODIFIKO ****/
Si no, para que estaria Ssh??!! Si se pudiese hacer lo que tu dices, ssh no serviria de nada!!
Recuerda que las 2 mociones mas importantes de ssh son:
- encyptar la sesion para evitar sniffing
- autenticar al Servidor Ssh ( mediante llaves publicas )
Ademas pues nos da una Shell ( la que intentas escupir con bash... ) y demas.
/**** MODIFIKO2 ****/
a que probé con netcat en el puerto 22 y pruebo conectarme por ssh y nada
Claro hombre!! Netcat trabaja en texto plano!!
/**** MODIFIKO3 ****/
Es que pienso yo, que para que la cosa surgiera deberias/n de usar el cliente en texto plano.
O sea, si que existe Ssh Forwarding/Tunneling para asegurar protocolos inseguros, pero no se va a usar ssh como cliente, sino el cliente de la aplicacion ( seguramente Cliente-Servidora ) insegura.
Por ello imaginemos un ssh Local Forwarding asi:
# ssh -fNL 1025:192.168.1.65:25
user@192.168.1.65Asi, si hicieramos en otro terminal ( aunque con fN pasa a segundo plano.. )
# nc localhost 1025
/* NOTA: asi por defecto se bindea a localhost. Si tuvieramos que bindear en la ifaz de Red de nuestra maquina en vez de localhost, y esa IP fuera 192.1681.64 pues seria algo asi
# ssh -fNL 192.168.1.64:1025:192.168.1.65:25
user@192.168.1.65 )
Asi tras ello podriamos hacer:
# nc 192.168.1.64 1025
*/
No esta el hilo planteado para explicar los Locals y Remote Forwardings.. por ello no explico el Remote.
Pero no esta demas visto lo visto no??
Incluso a mi me entran ganas de enredarme!!! Argghhh!!!!!!!!
Estariamos conectando con el servidor ( si es que lo hay! ) SMTP en 192.168.1.65 a traves del Tunnel Ssh.
El tunnel se establece si podemos hacer ssh a la maquina objetivo.. (
user@192.168.1.65 ).
Que pasaria si tras setear el Tunnel hacemos
# ssh -p 1025 localhost
??
Pues yo creo que nada, pues no hay un servidor Ssh en el otro extremo no??
La gracia reside en eso: en usar aplicaciones inseguras ( con sus clientes y servidores ) para hacerlas seguras en estos casos, o para saltarse reglas de filtrados en otras...
Bueno, pues me pico el enredo y ahi voy con el Remote Forwarding.
Imagina que estas en una maquina la cual no es accesible desde el exterior a su puerto 23.
La maquina del exterior se llama Humo y la maquina de dentro Lava. Pues Humo quiere acceder a Lava en el puerto 23, y tiene o ha tenido acceso a Lava y ha podido poner un Tunnel Ssh asi:
# ssh -fN -R 13337:localhost:23 user@Humo
/* Nota: se supone que en Humo hay un Server ssh corriendo y que se puede hacer ssh desde Lava a Humo */
Pues ahora, si una vez dentro Humo alguien hace un
# telnet localhost 13337
sera redireccionado a traves del tunnel ssh hacia el puerto 23 en Lava, habiendose ocurrido todo en el Tunnel Ssh y por ello pudiendose producir a pesar de las reglas de filtrado.
Se pueden hacer muchas mas cosas, pero ya me sali del tarro con esto.
Por ello no creo que podamos usar Ssh para este tipo de casos en los que estan implicadas aplicaciones inseguras ( texto plano ); sino que deberiamos de usar sus clientes inseguros :___________/
Autor
En línea
