sshd não inicia após o boot no linux embutido construído com o buildroot?

Question

Eu fiz uma instalação mínima usando a configuração padrão do buildroot para o Raspberry Pi. Eu também selecionei openssh e openssl de menuconfig:

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

Eu atribuí o Pi para 192.168.0.14 , mas não consegui ssh para ele. O nmap mostra que todas as portas estão fechadas para o Pi, e algumas vezes não mostra o Pi, o que achei estranho - o LED LINK pisca sempre que o nmap o verifica, então acho que está bem conectado.

Geralmente, gerencio serviços de inicialização com update-rc.d ou systemctl , mas só consigo conectar ao Pi via ssh - não tenho HDMI ou porta serial. Não tenho certeza de como configurá-lo manualmente. /etc/init.d/S50sshd está presente no Pi então ele deve estar iniciando o ssh após o boot, não deveria?

Arquivos de configuração relevantes: /etc/ssh/sshd_config , /etc/init.d/S50sshd .

Não encontrei nenhum registro relevante no cartão SD.

Editar:

Seguindo a sugestão de X Tian dos comentários, consegui obter os logs. A única coisa registrada era /var/log/messages . Parte relevante:

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

Parece que o sshd está começando. A questão parece ser outra coisa.

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

Engraçado é que, depois de desligar o Pi e desconectar o cabo Ethernet, eu ainda consegui fazer o ping naquele endereço. Agora estou realmente perdida. Eu imaginei que seria melhor apenas tar e fazer upload de todos os arquivos em / se alguém souber onde olhar ( não é um ambiente de produção, as senhas e chaves privadas não estão em uso, elas foram configuradas para fins de teste).

    

Answer 1

Na sua análise, você disse:

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

Este é um sintoma de IP duplicado. Em outras palavras, você tem 2 (ou mais) dispositivos com o mesmo endereço IP.

Você deve verificar o endereço MAC do seu dispositivo usando estas duas formas:

Um dispositivo, faça um ifconfig e verifique o campo HWaddr .

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

Um computador remoto, faça um arp -a <device IPaddr> e verifique o campo ether '.

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

No meu exemplo, os dois endereços MAC são os mesmos. Caso contrário, você terá que verificar todo o endereço IP da sua rede (estática e dinâmica).

Na maioria das vezes, esse problema ocorre devido a um erro de configuração de um servidor DHCP usado com outro endereço estático. Por exemplo, se o seu servidor DHCP tiver um pool entre 192.168.1.10 e 192.168.1.20 , você não deverá ter outro endereço estático dentro desse intervalo.

Para voltar ao seu problema de Pi. Apenas tente atribuir um novo endereço IP que não esteja no seu alcance DHCP. Ou reconfigure seu servidor DHCP para deixar mais espaço para seus endereços estáticos.

    

Answer 2

Seu sshd_config não permite senhas vazias que você está logando como root e a conta root não possui uma senha definida.

altere o ssh_config

#PermitEmptyPasswords no

para

PermitEmptyPasswords yes

Para obter mais informações no log, tente aumentar o nível de log para ssh

De

#LogLevel INFO

para

LogLevel DEBUG

Leia mais sobre como alterar os níveis de log do sshd em esta resposta .

    

Answer 3

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

Não exatamente. O arquivo /etc/init.d/S50sshd é usado, mas o que é chamado é o arquivo da pasta de nível de execução apropriada. Quando você executa update-rc.d , ele simplesmente cria links simbólicos para o S50sshd no init.d nas pastas /etc/rc?.d/ necessárias.

Você pode ver o status atual com:

ls etc/rc*.d/*ssh*

(Eu esperaria que estivesse presente nos níveis de execução 2, 3, 4 e 5)

E crie-os com:

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

    

Answer 4

Sem roteador + cabo Ethernet comum + RPI 2 + Buildroot 2016.05 + host 16.04 do Ubuntu

Funcionou depois que dividi esse problema em duas partes:

1. obtenha o SSH ethernet trabalhando com o Raspbian e uma conexão direta via cabo (que já possui um daemon sshd configurado corretamente) link

2. saiba como fazer uma configuração adequada do sshd no QEMU + buildroot: link

   No quadro real, você não tem uma janela do QEMU para modificar /etc/ssh/sshd_config , então você precisará:

   • modifique-o no host antes de piscar ( BR2_ROOTFS_OVERLAY , montagem output/images/sdcard.img com link ou reproduza com output/target )
   • conecte via UART TTL. Você vai querer que isso funcione mais cedo ou mais tarde, pois é a melhor maneira de depurar sua distro de buildroot no quadro.

.config é simplesmente raspberrypi2_defconfig + openssh ativado com make menuconfig .

Depois é só:

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

TTL na imagem usada apenas para energia.

    

Answer 5

Eu tive esse problema também com o buildroot. Acontece que o sshd estava falhando ao iniciar, apesar do etc / init.d / S50sshd devido a permissões / var / empty (a dica veio de olhar atentamente para as impressões do console)

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  

Minha solução foi deletar, recriar (eu já era root)

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

E então inicie o sshd manualmente.