3

I tried to setup my Arch Linux installation to be an SSH host, but here is the thing:

I can ssh localhost, it fails to login via public key and asks for username and password, but still able to login.

When I try ssh my_wan_ip it gives ssh_exchange_identification: Connection closed by remote host error. I've read all topics about this error and none helped me. By the way, just confirmed, it gives ssh: connect to host my_dyndns_hostname port 22: Connection refused from another machine (outside of my network, it has different wan ip).

I have sshd: ALL in "hosts.allow", ALL:ALL in "hosts.deny". I am able to connect to my own pc via ssh, ping my own pc, but my ssh setup seems to be the problem, it gives that annoying error when I try to ssh from wan.

/etc/ssh/ssh_config
/etc/ssh/sshd_config

And finally, here is the debug output for both sshd and ssh: (i ran ssh command and i took output to sshd debug after that):

sshd debug
ssh debug

I can edit my question according to your needs. Just ask for any more information needed. BTW I have no iptables running. I have one cable dsl modem connected to a asus wl-330gE wireless access point, they both have their firewall disabled. I configured NAT so port 22 is directed to the pc I'm having this trouble.

Any help appreciated, thanks..

DerfK
  • 19,493
  • 2
  • 38
  • 54
keremulutas
  • 171
  • 2
  • 4

2 Answers2

1

I noticed these lines in your ssh client debug output (lines 28-29):

debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/kerem/.ssh/id_dsa" as a RSA1 public key

So, may be the reason is with the keys on your client machine? Try to regenerate them this way:

ssh-keygen -t rsa
ssh-keygen -t dsa

I also would backup the old ones. Just in case.

HUB
  • 6,630
  • 3
  • 23
  • 22
  • But, this link (http://pkeck.myweb.uga.edu/ssh/) suggests not to use ssh v1, is rsa used by ssh v2? I'm also trying to accomplish that :( – keremulutas May 31 '11 at 16:22
  • I see "-t rsa1" in the article( http://www.opennet.ru/base/sec/ssh_pubkey_auth.txt.html (in Russian)) for SSHv1. Try to generate id_dsa only... – HUB May 31 '11 at 16:29
  • Oh, ok then. I wasn't aware of both -t rsa and -t rsa1 existed. I've regenerated keys again, nothing changed. – keremulutas May 31 '11 at 16:31
  • And same errors in ssh client debug output? – HUB May 31 '11 at 16:33
  • Apparently it's still looking for that ssh v1 rsa1 key: http://pastebin.com/dD4ujmdT – keremulutas May 31 '11 at 16:37
  • May be it is worth trying to generate rsa1 with "-t rsa1"? I know, it is less secure, but I would try. Only for testing purposes. – HUB May 31 '11 at 16:47
  • It gives that output, http://pastebin.com/1tU1x05Y. I don't get it. Why does it try to load every single public key as if it is RSA1 key? – keremulutas May 31 '11 at 16:54
  • Hm... I looked in my own ~/.ssh/ directory and found only .known_hosts file! I'm connecting to the ssh servers normally. May be it is worth trying to delete identiti and id_(r|d)sa?.. But it seems to me to be a silly guess. – HUB May 31 '11 at 16:59
  • It is definitely obsessed with ssh v1 keys, I left known_hosts alone, and also deleted that too, it gives this output for both situations: http://pastebin.com/qSyQE6DT. – keremulutas May 31 '11 at 17:05
  • My ssh_config: http://pastebin.com/vm7meata almost everything is commented out (default debian config) – HUB May 31 '11 at 17:22
  • I have reinstalled openssh package and it now seems to accept connections and establish a successful login somehow. Configuration is the same, and I didn't generate any keys. Thanks for answers, HUB. – keremulutas May 31 '11 at 18:12
  • I think it is worth posting your solution as an answer. Simple solution, but it worked. – HUB Jun 01 '11 at 08:42
1

The following lines can be very misleading:

debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/kerem/.ssh/id_dsa" as a RSA1 public key

Another answer suggests:

So, may be the reason is with the keys on your client machine? Try to regenerate them.

From experience, I can say that this problem can be caused by server configuration even though the messages make it look like it is strictly a client key problem. Of course, you want to check your client configuration too. But you did that and noted that nothing changed. That indicates that the problem is not the keys on your client machine (and hence the error message is misleading).

You should look at the server configuration.

For example, I found that if your user is not allowed by ssh config on the server, the ssh client gives this exact same (misleading) error message. If you are not allowing all users, check this:

sudo nano /etc/sshd_config
AllowUsers yourname@*

Also check denyhosts, but in my case the problem was AllowUsers in sshd_config and it gave this same misleading error message. Fixing the server fixed the problem without having to fix any keys on the client.

MountainX
  • 701
  • 3
  • 12
  • 25