Problem with SSH and router
 

Hello,

First my system configuration. I have WiFi router at home and connected two computers running ubuntu linux connected to it. One connected through WiFi, second through LAN. So what is the problem: I can't SSH from Gnome terminal to any machine. Be it local computer on the same router or be it distant computer. SSH session hangs just after successful login. I've read a lot about it and it should be related to DNS, MTU or whatever, but not in my case ! PuTTY client works without problem to local or to distant PC. SSH session from Gnome terminal works also just fine if.... I connect two comupers directly by not using router. So it seems SSH installation is ok, configuration is ok, but somehow router is not ok. I looked at packet sniffer of router itself and I see that packets successfully go from one computer to router and then to other computer and returns back. Firewall working ok. And its not about packet forwarding because I have the same problem if I try to SSH to router itself.
So the question. What theoretically might be wrong with router packet management ? Why PuTTY and Gnome terminal SSH packets differs ? What is the difference ? Where should I search for some sollution ?
I ran SSH in debug mode, but it was no so informative. It successfully logins and hangs on this line:

Any ideas are wellcome. Thanks in advance !

Hmm, if you can ssh in but THEN it hangs, perhaps ssh is working but something else it not, e.g. shell?

OR

perhaps you have TWO connections on your laptop (wireless AND wired) -try with just one (I had that issue once a while ago)

OR perhaps connect using different protocol version:

-1 Forces ssh to try protocol version 1 only.
-2 Forces ssh to try protocol version 2 only.
-4 Forces ssh to use IPv4 addresses only.
-6 Forces ssh to use IPv6 addresses only.

Which version of ssh are you using? Perhaps force it to use v2 instead of v3 or such like (see man ssh) :)


Not sure how putty differs to ssh I'm afraid

That's all I can think of right now. (Oh, and check sshd sever logs on a machine you're trying to ssh into) Do you have any IPtables rules???


HTH

Might be a long shot, but; I read this post https://lists.ubuntu.com/archives/ub...ne/003321.html they were hanging on the same error message, it turned out to be their wifi driver "wl" , there is a link to the fix https://lists.ubuntu.com/archives/ub...ne/003339.html good luck

Hi,

Thanks for replies. Everything would be nice, but not in my case. Suppose next situation:

1. From Gnome terminal ssh xx.xx.xx.xx -p 22 -l username
2. SSH hangs
3. Do not touch anything in computer from which I used ssh
4. Disconnect both computers from router
5. Connect them together with each other (cross cable)
6. Make the same in Gnome terminal ssh xx.xx.xx.xx -p 22 -l username
7. Everything works like a charm, but conditions are exactly the same

I think router makes something to the packets, but I have no idea what.

does your router have a firewall that might be blocking port 22? If it does you could temporarily disable the firewall to test ssh.

Firewall is allowing port 22 and the good proof is that PuTTY works through router without any problems.

Alpha, putty provides an event log: on the window bar, right click, and select "event log". This provides details of the negotiation that putty did with your server. This might provide insight into what is going right with putty and going wrong with your linux client sessions. Perhaps you can track in the logs the differences.

Thanks, I'll try and post results here.

One thing to try is to telnet to port 22 on the machine you are trying to ssh into.

This way YOU can be the ssh client - you *might* just see something in the reply when you try to telnet into port 22 that helps you.

(I used this technique once to telnet into port 25 to see what my mail server was doing. I had a conversation with my mailserver - surreal :) )

Here is how to do it and the result I get:

$ telnet fred 22
Trying 10.10.10.3...
Connected to fred.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1

h

Protocol mismatch.
Connection closed by foreign host.
$


I typed 'h' which freaked it out - I can't speak ssh of course ;)

Hopefully this will shed some light on the issue. Perhaps the connection is not going to where you think it is? Who knows.

Also, router might be doing the right thing by not returning the packets.
You don't have 2 machines with the same IP address do you? Router (switch part) could be faulty, it's possible, though not likely.

I'll keep thinking...

What make of router do you have?
What IP addresses and netmasks are you using for your machines and your router?

I wonder if packets are just getting dropped?

Does this link help at all?

http://serverfault.com/questions/237...ort-forwarding

Hi,

Hmmm.... I don't like to enable telnet on any of my machines...

The fact is that router returns packets. I have checked packet sniffer on router itself and it is returning packets. And there are no two machines with the same IP address.

My router is MikroTIK running on RouterOS v4.4. Router is configured to have two internal networks: one for WiFi (172.16.5.0/20) and other for LAN (192.168.5.0/24). And I'm trying from WiFi to LAN and from WiFi to WiFi.

No packets are not getting dropped. And still I can go until authentication.

[/QUOTE]

I don't think so. The most problem is that with PuTTY is everything ok, no packets dropped, no hangs, everything's working just fine. So NAT and firewall is ok. The only problem is Gnome terminal.
I have also checked the logs for PuTTY and Gnome sessions and found that Gnome session hangs on opening shell. PuTTY opens it successfully, but Gnome hangs on this step.

Regarding telnet, I am only saying using the telnet client. You don't need to enable a telnet server anywhere.
The whole point is to connect to the SSH server, and you can use telnet to connect to it as a human. It might just tell you something. I don't have telnet enable anywhere either by the way.

If you suspect gnome-terminal, then try using an xterm or kde terminal or anything really. Try from console even.

Oh, and I assume there is packet forwarding in both directions everywhere necessary, and that there are routes both ways through your router for the ssh packets to get back?

If ssh is almost working, then surely some packets are not getting back properly??? Have you run wireshark/ethereal packet sniffer on the machine you are running the ssh client on? Do the packets come back from the ssh server to client machine ok?

An re: authentication, you did try protocol v1 and v2 I assume?

HTH

Hi,

1. Telnet is not working. It just hangs on 'Trying...'
2. xterm gives the same result as GNOME
3. Packets are returning, at least I can see them on router's packet sniffer
4. I will use packet sniffer on computer I use SSH and see what might be the problem.

You need to run ssh in debug mode:

try:

ssh -v -v -v whoever@1.2.3.4

and paste the output

A1. In which case packets are not returning or something like that. It's not a fault with your sshd server or your ssh client I would bet. Your routing configuration or perhaps the router itself is at fault I reckon.

A2. So, nowt to do with Gnome then. :) A1 is your answer.

A3. You need to check by running a sniffer on the client machine and the sshd server machine! I think packets are not getting back if the router can see them but the client machine cannot.

A4. Ah, OK, good. :)

Good luck with it! :)

Recently I've found I have the same issue with samba as well. Ok I checked packets and saw that returning packet's IP is router IP. For example:

LAN network: 192.168.5.0/24
WiFi network: 172.16.5.0/20
Router: 192.168.5.254 and 172.16.5.254/0

I go from WiFi to LAN:
ssh 192.168.5.55 -p 22 -l user
and returning packet's src address is 172.16.5.254
I think this is a problem, but for now I don't know how to solve it and how to find out if it's really the problem.