SSH al router desde consola falla (con putty va bien)

Archivado
Hola buenas.
Llevo un rato perdido con esto y no se que hago mal.
La cuestión es que quiero acceder al router por SSH, y he activado dicha opción en el router, pero no me acepta la conexión.
Comentar que desde putty (en windows) va bien.

Pruebas que he hecho:
ssh admin@192.168.1.1
Connection closed by 192.168.1.1


pi@raspbmc:~$ ssh -L 8080:192.168.1.1:80 admin@192.168.1.1
Connection closed by 192.168.1.1


ssh -L 8080:192.168.1.1:80 192.168.1.36  -l admin
admin@192.168.1.36's password:
Permission denied, please try again.

(192.168.1.36 es la IP local de la maquina.)

Aquí es donde he visto la principal diferencia con el putty que al hacer login pregunta:
admin@192.168.1.1's password:
adslppp@telefonicanetpa>

Es decir que la IP en este caso es .1 y en los demás .36

En fin que no se que más probar ya.
Saludos.

A ver si es que va a ser que el putty te está haciendo una conexión telnet y no ssh....
Buenas.
No, tengo seleccionado SSH. De hecho en el router tengo desactivado telnet.
No se que falla la verdad.
Bueno, podrías comprobar las configuraciones de ssh de putty y de tu... ¿raspberry? y ver si hay diferencias significativas.
mmm.. cual es la configuración de putty?

Tambien prueba a ejecutar ssh en modo verbose para que te de mas información, ssh -vvvv
Hola.

Pongo lo que muestra en modo verbose.
Antes que nada comentar que aún no tengo claro cual seria la forma más correcta de hacer la conexión.
En este caso he optado por probar la más simple: ssh admin@192.168.1.1 -vvvv

pi@raspbmc:~$ ssh admin@192.168.1.1 -vvvv
OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22.
debug1: Connection established.
debug1: identity file /home/pi/.ssh/id_rsa type -1
debug1: identity file /home/pi/.ssh/id_rsa-cert type -1
debug1: identity file /home/pi/.ssh/id_dsa type -1
debug1: identity file /home/pi/.ssh/id_dsa-cert type -1
debug1: identity file /home/pi/.ssh/id_ecdsa type -1
debug1: identity file /home/pi/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version dropbear_0.46
debug1: no match: dropbear_0.46
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "192.168.1.1" from file "/home/pi/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa
debug2: kex_parse_kexinit: 3des-cbc
debug2: kex_parse_kexinit: 3des-cbc
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client 3des-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server 3des-cbc hmac-md5 none
debug2: dh_gen_key: priv key bits set: 191/384
debug2: bits set: 485/1024
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
Connection closed by 192.168.1.1


En putty (bueno en realidad es kitty portable, pero vamos que son iguales) la configuración la he dejado tal y como venia.
Pongo unas capturas a ver si veis algo:
Imagen

Y esta es la configuración del fichero /etc/ssh/ssh_config:

pi@raspbmc:~$ cat /etc/ssh/ssh_config

# This is the ssh client system-wide configuration file. See
# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options. For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

Host *
# ForwardAgent no
# ForwardX11 no
# ForwardX11Trusted yes
# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# GSSAPIKeyExchange no
# GSSAPITrustDNS no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# Port 22
# Protocol 2,1
# Cipher 3des
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
# MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# VisualHostKey no
# ProxyCommand ssh -q -W %h:%p gateway.example.com
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
La última línea significativa del output de ssh lleva a hilos del estilo de este:

https://groups.yahoo.com/neo/groups/ts- ... pics/21937

No se si será aplicable a tu caso.
No tendrás un ~/.ssh/config donde se defina que la conexión al host 192.168.1.1 se haga autenticando con clave RSA en vez de con usuario/password? (u otra configuración igualmente incorrecta para ese host).

Es raro que en el primer intento de conexión que pones te rechace antes siquiera de preguntar el password.

Supongo de todas formas a falta de más datos que tanto tu máquina windows como la linux estarán conectadas a la red de la misma forma, si no ya entran otras posibles variables.
jorchube escribió:La última línea significativa del output de ssh lleva a hilos del estilo de este:

https://groups.yahoo.com/neo/groups/ts- ... pics/21937

No se si será aplicable a tu caso.

Pues no se si será el mismo caso pero según parece modifican algo en el servidor y en este caso seria el router y no creo que pueda tocar mucho.
Y según veo muchos hablan de problemas en remoto pero que funciona bien en local. En mi caso es local lo que quiero y ni eso.

kornshell escribió:No tendrás un ~/.ssh/config donde se defina que la conexión al host 192.168.1.1 se haga autenticando con clave RSA en vez de con usuario/password? (u otra configuración igualmente incorrecta para ese host).

Es raro que en el primer intento de conexión que pones te rechace antes siquiera de preguntar el password.

Supongo de todas formas a falta de más datos que tanto tu máquina windows como la linux estarán conectadas a la red de la misma forma, si no ya entran otras posibles variables.

Lo he mirado y no tengo ninguna configuración en ~/.ssh/config.
Es raro si...

Las dos máquinas (windows y linux) están conectadas a la misma red si.

Creo que me voy a rendir de momento. Quizás es un fallo del router que tiene una versión vieja y desde linux por seguridad no deja conectar.

No me gusta telnet pero creo que tendré que utilizarlo.
Activaré solo por LAN y supongo que no será ningún problema de seguridad no?
Haz un ssh en modo verbose:

     -v      Verbose mode.  Causes ssh to print debugging messages about its progress.  This is helpful in debugging connection, authentication, and configuration problems.  Multiple -v options increase the verbosity.  The maximum is 3.


ssh -vvv host


Para ver hasta que paso llega en la conexión desde el lado del cliente.

Y en el router usando putty, dale un vistazo a /var/log/auth.log o /var/log/secure después del intento de conexión para ver el motivo por el que está fallando en el lado del servidor.
9 respuestas
Archivado
Volver a Software libre