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, 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.


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 port 22.

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

root@pc:~# ssh
ssh: connect to host port 22: Connection refused
root@pc:~# ping
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=32.8 ms
64 bytes from icmp_seq=2 ttl=64 time=55.6 ms
64 bytes from icmp_seq=3 ttl=64 time=79.1 ms
--- 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
Starting Nmap 6.47 ( http://nmap.org ) at 2015-05-30 03:25 BRT

Nmap scan report for
Host is up (0.085s latency).
All 100 scanned ports on 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).

  • 1
    Can't help directly, but: add some logging to the init script, restart again, then retrieve the logs. At least you can figure out if the script is even being run or if it's exiting early due to no ssh-keygen or something. Oh, and you are probably interested in sshd_config. – drewbenn May 26 '15 at 4:35
  • 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. – X Tian May 29 '15 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 device and compare to the RPi one. – jml May 30 '15 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! – dan Jun 1 '15 at 13:33
  • @jml: please make an answer of your analysis: right & simple. – dan Jun 1 '15 at 13:34

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:  Bcast:  Mask:

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

jml@pc$ arp -a
? ( 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 and, 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.

  • 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 ( and the Pi ( 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 – Alex Jun 2 '15 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) – Matija Nalis Sep 3 '16 at 12:52

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


PermitEmptyPasswords yes

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


#LogLevel INFO


LogLevel DEBUG

Read futher about changing sshd log levels in this answer.


/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
  • BusyBox init has no runlevels AFAIK. – Alex May 30 '15 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. – Ángel May 31 '15 at 2:32
  • As I mentioned, I've done a minimal install using buildroot. It's nor Raspbian. – Alex May 31 '15 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. – Ned64 Jun 1 '15 at 10:16

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.