6

I've done a minimal install using buildroot's default config for the Raspberry Pi. I also selected openssh and openssl from menuconfig:

Package Selection for the target ---> [*] Networking ---> [*] openssh [*] Library --> Crypto --> -*- openssl [*] openssl binary [ ] openssl additional engines

I assigned the Pi to 192.168.0.14, but couldn't ssh to it. nmap shows all ports are closed for the Pi, and sometimes doesn't show the Pi at all, which I found odd - the LINK LED blinks whenever nmap scans it, so I guess it's connected just fine.

I usually manage startup services with update-rc.d or systemctl, however I can only connect to the Pi via ssh - I have no HDMI or Serial Port. I'm unsure how to set it up manually. /etc/init.d/S50sshd is present in the Pi so it should be starting ssh after boot, shouldn't it?

Relevant config files: /etc/ssh/sshd_config, /etc/init.d/S50sshd.

I couldn't find any relevant logs in the SD card.

Edit:

Following X Tian's suggestion from the comments I was able to obtain the logs. The only thing logged was /var/log/messages. Relevant part:

Jan 1 00:00:02 buildroot auth.info sshd[75]: Server listening on 0.0.0.0 port 22.

It seems sshd is starting. The issue seems to be something else. 

root@pc:~# ssh 192.168.0.14 ssh: connect to host 192.168.0.14 port 22: Connection refused root@pc:~# ping 192.168.0.14 PING 192.168.0.14 (192.168.0.14) 56(84) bytes of data. 64 bytes from 192.168.0.14: icmp_seq=1 ttl=64 time=32.8 ms 64 bytes from 192.168.0.14: icmp_seq=2 ttl=64 time=55.6 ms 64 bytes from 192.168.0.14: icmp_seq=3 ttl=64 time=79.1 ms ^C --- 192.168.0.14 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 32.808/55.871/79.140/18.917 ms root@pc:~# exit debian@pc:~ nmap -F 192.168.0.14 Starting Nmap 6.47 ( http://nmap.org ) at 2015-05-30 03:25 BRT Nmap scan report for 192.168.0.14 Host is up (0.085s latency). All 100 scanned ports on 192.168.0.14 are closed

Funny thing is, after shutting down the Pi and disconnecting the Ethernet cable I was still able to ping that address. Now I'm really lost. I figured it'd be best to just tar and upload all files under / if someone knows where to look at (it's not a production environment, the passwords and private keys are not in use, they were set for test purposes).

Improve this question
5
  • 1
    I noticed that /var/log is a link to ../tmp try removing it and create a real /var/log directory, hopefully then the log file will be retained between reboots - I'm guessing if you can't access via ssh and have no console, you are looking at the sdcard between reboots. Commented May 29, 2015 at 14:18
  • 2
    @Alex "I was still able to ping that address" -> Seems to be a network issue. You could have 2 devices with the same IP address. Check your DHCP server (if any) and your static devices. You could use arp to check MAC addresses of the 192.168.0.14 device and compare to the RPi one. Commented May 30, 2015 at 10:53
  • I fully agree with the jml analysis. This will explain both a ghost reply to a ping and a lack of reply from sshd: duplicate @IP! Commented Jun 1, 2015 at 13:33
  • @jml: please make an answer of your analysis: right & simple. Commented Jun 1, 2015 at 13:34
  • raise the logging level on sshd, to check what's happening, see my answer below. Commented Jun 2, 2015 at 9:45

5 Answers 5

Reset to default
3

Your sshd_config does not permit empty passwords you are logging in as root and the root account does not have a password set.

change the ssh_config

#PermitEmptyPasswords no

to

PermitEmptyPasswords yes

To get more info into the log, try raising the logging level for ssh

From

#LogLevel INFO

to

LogLevel DEBUG

Read futher about changing sshd log levels in this answer.

Improve this answer
2

In your analysis you said:

After shutting down the Pi and disconnecting the Ethernet cable I was still able to ping that address

This is a duplicate IP symptom. In other word, you have 2 (or more) devices with the same IP address.

You should check the MAC address of your device using this 2 ways:

One your device, do a ifconfig and check the HWaddr field.

root@rpi# ifconfig eth0 Link encap:Ethernet HWaddr B8:27:EB:BE:1C:67 inet addr:192.168.1.11 Bcast:192.168.1.255 Mask:255.255.255.0

One your remote computer, do a arp -a <device IPaddr> and check the ether field`.

jml@pc$ arp -a 192.168.1.11 ? (192.168.1.11) at b8:27:eb:be:1c:67 [ether] on eth0

On my example, both MAC address are the same. If not, you will have to check all the IP address of your network (static and dynamic).

Most of the time this issue is due to a misconfiguration of a DHCP server used with other static address. By example, if your DHCP server have a pool between 192.168.1.10 and 192.168.1.20, you must not have other static address within this range.

To get back to your Pi issue. Just try to assign it a new IP address which is not in your DHCP range. Or reconfigure your DHCP server to let more space for your static addresses.

Improve this answer
2
  • Most definitively a misdiagnosed (because of the previous absence of sshd logs) network issue. I'm not running a DHCP server and the only computers with physical access to the network are my desktop (192.168.0.10) and the Pi (192.168.0.14). I tried assigning a different IP address anyway, to no avail. I also disabled the router firewall. I even tried enabling the DHCP server to see what happened, but it only made things worse, as it wouldn't assign the Pi an IP address. Now I'm getting No route to host, which confirms the network issue. I'll try tomorrow with a different router. Thanks Commented Jun 2, 2015 at 0:10
  • @Alex jml is correct - if you can still ping your RasperryPi when it is disconnected and off, then you are not pinging RasperryPi but something else, and you have to resolve that issue before even trying anything else (or you'll be in word of pain) Commented Sep 3, 2016 at 12:52
0

/etc/init.d/S50sshd is present in the Pi so it should be starting ssh after boot, shouldn't it?

Not exactly. The /etc/init.d/S50sshd file is used, but what is called is the file from the appropiate runlevel folder. When you run update-rc.d it simply creates symlinks to the S50sshd in init.d at the required /etc/rc?.d/ folders.

You can view the current status with:

ls etc/rc*.d/*ssh*

(I would expect it to be present on runlevels 2, 3, 4 and 5)

And create them with:

ln -s /etc/init.d/ssh /etc/rc2.d ln -s /etc/init.d/ssh /etc/rc3.d ln -s /etc/init.d/ssh /etc/rc4.d ln -s /etc/init.d/ssh /etc/rc5.d
Improve this answer
4
  • BusyBox init has no runlevels AFAIK. Commented May 30, 2015 at 6:32
  • @Alex, Is it generating a runlevel-less system? From your Raspberry Pi mention, I assumed a Raspbian system, which seem to have runlevels. Commented May 31, 2015 at 2:32
  • As I mentioned, I've done a minimal install using buildroot. It's nor Raspbian. Commented May 31, 2015 at 4:04
  • This could be an issue with either the source or the destination firewall, or sshd not running/listening. Can you log in to the Pi without ssh? IF yes, then please try netstat -tulpanw as root to see whether sshd is up and listening on port 22. If not, try starting it up manually, like sshd -D & as root. Commented Jun 1, 2015 at 10:16
0

No router + regular Ethernet cable + RPI 2 + Buildroot 2016.05 + Ubuntu 16.04 host

Got it working after I've split this problem into two parts:

  1. get ethernet SSH working with Raspbian and a direct cable connection (which already has a properly setup sshd daemon running) https://raspberrypi.stackexchange.com/a/54394/33424

  2. learn how to do a proper sshd configuration on QEMU + buildroot: https://stackoverflow.com/a/39301480/895245

    On the real board, you don't have a QEMU window to modify /etc/ssh/sshd_config of course, so you will need to either:

    • modify it on host before flashing (either BR2_ROOTFS_OVERLAY, mount output/images/sdcard.img with https://askubuntu.com/a/496576/52975 , or play with output/target)
    • connect via UART TTL. You will want to get this working sooner or later, as it is the best way to debug your buildroot distro on the board.

.config is simply raspberrypi2_defconfig + openssh enabled with make menuconfig.

Then just:

ssh "root@$(cat /var/lib/misc/dnsmasq.leases | cut -d ' ' -f 3)"

TTL on image only used for power.

Improve this answer
0

I've had this issue as well with buildroot. Turns out that sshd was failing to start despite etc/init.d/S50sshd due to /var/empty permissions (the hint came from looking closely at console prints)

Starting sshd: /var/empty must be owned by root and not group or world-writable. # ls -l /var/ total 0 .. drwxr-xr-x 2 sshd sshd 40 Jan 1 00:09 empty

My solution was to delete it, recreate it (I was already root)

# ls -l /var/ total 0 .. drwxr-xr-x 2 root root 40 Jan 1 00:09 empty

And then start sshd manually.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.