Siguiendo el punto de Fred en los comentarios (y en realidad leyendo el mensaje de error), me equivoqué y ssh fue conectando. Voy a dejar mi respuesta original en la parte inferior y adicionalmente responder a la pregunta de no ser capaz de conectarse a un ssh en ejecución.
Otra buena manera de diagnosticar los problemas de ssh cuando el servidor sshd rechaza las conexiones, y si el OP es correcto nada se está registrando auth.log o syslog es ejecutarlo en un puerto separado con la depuración activada (he elegido el puerto arbitrario de 44 ).
/full/path/to/sshd -p 44 -d
A continuación, puede conectarse con su cliente ssh y seguir depurando el problema:
ssh -p 44 root@x.x.x.x
Root (como Fred señaló en su respuesta) es un usuario que potencialmente puede ser restringido a través de la opción ssh PermitRootLogin en su sshd_config . También los tipos de métodos de autenticación utilizados por su sshd_config puede restringir aún más el acceso a a su anfitrión:
RSAAuthentication
PubkeyAuthentication
RhostsRSAAuthentication
HostbasedAuthentication
ChallengeResponseAuthentication
PasswordAuthentication
KerberosAuthentication
GSSAPIAuthentication
Mira la página man de sshd_config ( man 5 sshd_config ) para obtener más información sobre estas opciones. Por lo general, la mayoría de los sshds tienen RSAAuthentication , PubkeyAuthentication y a veces PasswordAuthentication . RSAAuthentication es específico para Protocol 1 y la mayoría de los anfitriones utilizan Protocol 2 que utiliza PubkeyAuthentication . Ambos se basan en root tener un archivo de claves (normalmente se encuentra en /root/.ssh/authorized_keys ), pero esta ubicación puede ser anulado por el AuthorizedKeysFile opción. Parece que PasswordAuthentication no está habilitado en su sshd.
Para la autenticación RSA y Pubkey se necesita un par de claves. Que has generado y viven en tu máquina cliente en /home/mona/.ssh/id_rsa y /home/mona/.ssh/id_rsa.pub . El público la mitad de estos dos archivos (la clave contenida en /home/mona/.ssh/id_rsa.pub) tendría que ponerla en el authorized_key archivo mencionado anteriormente.
Respuesta original, referida a un fallo en la conexión remota con el proceso sshd
Eso parece ser TCPWrappers o un firewall cerrando la conexión inicial.
Compruebe su auth.log o syslog archivos en /var/log ya que estos pueden proporcionar algunas pistas sobre lo que está bloqueando la conexión.
TCPwrappers se implementa normalmente a través de un /etc/hosts.allow y en algunos unixes un archivo adicional o sólo el /etc/hosts.deny (es decir, sin un archivo hosts.allow).
Las entradas suelen ser del tipo
<service> : <access list> : <allow|deny>
O
<service> : <access list>
dependiendo del tipo de envoltura tcp que se utilice. El formato de estos archivos se puede encontrar normalmente con la página man de hosts_access man 5 hosts_access . Es posible que tenga que añadir una entrada para permitir el acceso de su IP remota.
sshd : my.ip.address.here : allow
La mayoría de las distribuciones con un núcleo Linux tienden a utilizar iptables como el principal cortafuegos, aunque algunos utilizan ipchains . (Sé que FreeBSD utiliza ipfw que está portado desde NetBSD). Es posible que su proveedor de servicios tenga un cortafuegos o un router con un cortafuegos delante de su servicio que bloquee estas peticiones. Para saber qué cortafuegos utiliza su proveedor habrá que investigarlo.
iptables Las reglas del cortafuegos se pueden enumerar a través del iptables -nvL (que debe ejecutarse como root, o a través de sudo). el INPUT chain es el conjunto de reglas que se utiliza para permitir/rechazar las conexiones entrantes de su host. Es posible que tenga que añadir una regla para permitir las conexiones SSH entrantes:
iptables -I INPUT -p tcp --dport 22 -j ACCEPT -m comment --comment "Allow SSH connections from all hosts"
Puede que quieras hacer que sólo permita conexiones desde una IP específica:
iptables -I INPUT -s 10.10.10.10 -p tcp --dport 22 -j ACCEPT -m comment --comment "Allow SSH connections from the 10.10.10.10 host"
Si su proveedor de servicios bloquea el puerto 22, probablemente tendrá que poner el servicio en un puerto diferente (puerto 2222 es bastante popular) a través del Port en su sshd_config (que normalmente se encuentra en /etc/ssh ).
