9

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 pi@jamestheawesomedude.cu.cc, but NOT when accessing pi@192.168.2.128. This is unbelievably frustrating.

JamesTheAwesomeDude
  • 1,985
  • 2
    Please show us the logs. ssh -vvv user@host on client side, sudo tail -f /var/log/auth.log on server side. Perhaps it makes sense to increase verbosity in SSH server config as well. – Andrejs Cainikovs Apr 22 '13 at 22:13
  • There's really nothing interesting, just a "connection refused" message: http://pastebin.com/Nc1W8Mja – JamesTheAwesomeDude Apr 22 '13 at 22:28
  • 3
    FYI: There is also a Raspberry stack http://raspberrypi.stackexchange.com/ – Meer Borg Apr 23 '13 at 10:05
  • 3
    @MeerBorg I'm already a user there, and I actually considered asking this there, BUT Ubuntu is the only one having issues connecting. If I couldn't connect via any method, I'd suspect an issue with the Pi itself, but since Ubuntu is the odd one out here, I made the decision to ask it on this site. – JamesTheAwesomeDude Apr 23 '13 at 22:16
  • @JamesTheAwesomeDude, there should be something more descriptive than plain connection refused. This message is a result, but there should be an error message as well. – Andrejs Cainikovs Apr 24 '13 at 09:50
  • @AndrejsCainikovs I'll be very happy to oblige with any logfiles needed. Just tell me what you need, and I'll Pastebin it and post it here. As of now, the output of ssh -vvv pi@192.168.2.128 is exactly as appears here: http://pastebin.com/Nc1W8Mja – JamesTheAwesomeDude Apr 26 '13 at 03:48
  • Please provide output of iptables --list on your Ubuntu machine. SSH config would be nice as well: ~/.ssh/config and /etc/ssh/ssh_config. – Andrejs Cainikovs Apr 26 '13 at 06:29
  • @AndrejsCainikovs http://pastebin.com/NmKenVpD Line 18 makes mt think that my firewall isn't the issue, though. – JamesTheAwesomeDude Apr 27 '13 at 03:58
  • sounds simple but try seeing if ubuntu computer is actually connected to router properly. Had the same problem but it went away after proper connection. –  Apr 27 '13 at 03:32
  • Yes, it's connected to the router perfectly. – JamesTheAwesomeDude Apr 27 '13 at 03:42
  • When you boot ubuntu, does it get a different an IP address on a different range to when you boot under anything else? It could be the Pi refusing connections to devices not on its own subnet. +1 straw being clutched at. – FreudianSlip Aug 10 '13 at 08:26
  • @FreudianSlip No.. Both devices have a static IP. – JamesTheAwesomeDude Aug 10 '13 at 21:07
  • On Ubuntu, what do you get for ip addr and arp -a just after the failure? Make sure the IP address is mapping to the MAC address you expect for your Pi. – Steven K Oct 01 '13 at 02:38
  • It could be an issue with your dns server configuration – Prarobo Nov 20 '13 at 17:43
  • @Prarobo nope, no DNS involved at all. – JamesTheAwesomeDude Nov 27 '13 at 21:19
  • Do you have something like fail2ban running on the Pi? The fact that you could access it externally from your net but not internally leads me to think that there is an IP-specific block happening on the Pi. – douggro Jan 01 '14 at 08:44
  • I do this all the time it works for me. What operating system are you using on the PI? I use the pi version of debian, which works perfectly. – Alvar Jan 14 '14 at 04:09

5 Answers5

1

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 pi@192.168.2.128 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.

falconer
  • 15,026
  • 3
  • 48
  • 68
  • #ufw allow to add an exception. #ssh -v user@address to get verbose output, which will tell you more about why you cannot connect. "conection refused" frequently means the default port is wrong, ot the firewall client or server, is blocking the connection. – j0h Jan 15 '14 at 13:09
  • 1
    @j0h I think you wanted to post this comment as a comment to the question. But anyway: In the comments the OP already provided ssh -vvv output. He also said in the question that the Pi has no firewall enabled, so the ufw is on the client, and he said he did disable it, but he still can't log in. The port can't be a problem either because he can connect to that same port from other machines. – falconer Jan 15 '14 at 13:36
1

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:

route -n

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.

ImaginaryRobots
  • 9,136
1

On Ubuntu 13.10 , I could not ssh to my pi , when I previously could on 13.04 and Mint 16. When trying

ssh -vvv user@host

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.

Priizim
  • 11
  • 2
  • How to change MTU: http://askubuntu.com/questions/230926/how-do-i-change-the-mtu-value-on-ubuntu – jmunsch Apr 10 '14 at 00:39
0

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
cat /etc/resolv.conf
arp -n
netstat -rn
sudo iptables-save
sudo grep ssh /var/log/auth.log | tail -50

And on your desktop:

sudo ifconfig -a
cat /etc/resolv.conf
arp -n
netstat -rn
sudo iptables-save

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.

Luno
  • 118
  • 5
0

Delete ~/.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

jet
  • 7,274