Original Source Link
Okay, I recently got a Raspberry Pi, and I got it connected to my Wi-Fi – I enabled the SSH and installed Hiawatha, and I could access it just fine from my Desktop, which was running Puppy Linux at that time.
I could also access it just fine when booted into Windows (PuTTY on Win XP Pro,) and the Netbook could access it via PuTTY, as well. (Win 7 Starter)
However, when I booted into Ubuntu, all SSH, HTTP, and HTTPS connections were refused. To confirm that it was Ubuntu, and only Ubuntu, that was having the connection issues, I rebooted into Puppy Linux – connected fine, and into Windows – connected fine. The Netbook could connect to all 3 services without issues either. It was just Ubuntu that said connection refused.
I’d like to know what’s wrong – I’ve already done all the basic troubleshooting: rebooting the RPi, rebooting my computer, rebooting the wireless router, etc. The Raspberry Pi has no Firewall enabled, and my Router offers all devices connected to LAN unrestricted access to each other. I’ve done extensive testing, and Ubuntu has been proven beyond a shadow of a doubt to be the only one not willing to connect.
UPDATE: Just tested accessing via my external IP, and everything runs smoothly on Ubuntu! However, Ubuntu still can’t access the Pi from anything local, and I just re-confirmed that my other OS’s can. I think it’s weird that Ubuntu has trouble connecting locally (unlike my other OS’s,) but is just fine accessing the Pi via my external IP..
UPDATE 2: Disabling my firewall lets me access the device, but the password reports as incorrect every. single. time. I’ve tried typing it into Gedit, then dragging-and-dropping it into the password prompt during SSH login, and it authorizes when accessing
[email protected], but NOT when accessing
[email protected]. This is unbelievably frustrating.
So until you had
ufw enabled with default settings on your Ubuntu machine the connection always reported
Connection refused. After you disabled the
ufw on you client the connection is established but the password is always rejected?
I would guess in that case your problem is that the
192.168.2.128 ip is routed back to your client Ubuntu machine, and actually you are connecting to the
ssh server running on your Ubuntu machine. This would explain:
Why you are able to connect from the internet.
Why your connection was rejected when the firewall was on on your Ubuntu client.
Why the connection is no more rejected with the client firewall turned off.
Why now the connection is established, but the authentication fail.
To troubleshoot this case:
Check the server’s host key with
ssh -v [email protected] both for a local and for an internet connection. Does it report the same key?
Or while you are connecting from local, and you are at the prompt to type your password, from another terminal:
sudo netstat -tupan and see if a connection is established to the
sshd on your Ubuntu.
Although this case would explain everything, but it is so weird that I have doubts that this is your problem.
It’s entirely possible that your ubuntu machine is getting a different network IP address than what is expected. Try the following:
- On the raspi, check its IP address with
ifconfig | grep 192.168
- on the ubuntu machine, check its IP address with
ifconfig | grep 192.168
In order to be able to talk to each other on your local network, they should both be using the same subnet – look at the third section of the IP address to see if they are. In your case, they should both be on the 192.168.2.* subnet.
Make sure they actually have different IP addresses too. This may seem obvious, but can happen if one of them is using DHCP and the other is set statically.
If that all checks out, then run the following command to see where your packets are supposed to be going:
Look in the output for the destination subnet that applies to your raspberry pi. There should really just be 3 rows:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
If you have more rows or things are going to weird spots, then that’s the answer.
My guess is that your ssh connection is ending up hitting a different SSH server from the one on your raspberry pi, which is why changing the ubuntu firewall affected it and your logins aren’t working.
According to what’s in your PasteBin, the “connection refused” indicates you’re getting a TCP reset from whatever is at that IP address.
Sanity check: While troubleshooting, DISABLE ufw.
With your desktop firewall disabled, can you ping the Pi from your desktop? Can you ping the desktop from your Pi?
After attempting the ping in both directions, look at the output of ‘arp -n’ on both machines. Do they see each other’s MAC (Ethernet hardware) addresses or is something redirecting/intercepting the traffic?
If you can ping in both directions and ‘arp -n’ indicates the proper MAC addresses are being used (check ‘ifconfig’ on the opposite machine), the next step is to examine /var/log/auth.log on the Pi. It should tell you what’s wrong with the connection attempt.
If the above doesn’t help, please show us the output from the following commands on the Pi:
sudo ifconfig -a
sudo grep ssh /var/log/auth.log | tail -50
And on your desktop:
sudo ifconfig -a
I see some of this pasted in the comments above, but the whole thing is important to grab with the firewall off, first. If you can make it work with the firewall off, then you can proceed to troubleshooting your firewall rules.
Also, even if you’re targeting an IP address, DNS settings still matter because SSH uses DNS during host key validation.
~/.ssh/known_hosts file and try again.
If previously there was a host with the same IP address ssh accessible, you may keep an invalid fingerprint
On Ubuntu 13.10 , I could not ssh to my pi , when I previously could on 13.04 and Mint 16.
ssh -vvv [email protected]
I got :
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
I ran across a suggestion that said to set MTU for the Machine(not the pi) to 1200 instead of automatic. I did this, turned off -> then on my wifi , and connected with ssh to PI on first try.
Hope this helps someone.