Volumio2 - No SSH access

I just upgraded to volumio 2 on my Pi model A with HifiBerry and it seems to work well, except that the SSH access is not working. I’ve tried with Putty and Teraterm and they just hang. It seems that volumio shuts down the TCP connection before any negotiation or authorisation has started:

Wireshark log, Volumio is on the .11 adress
61 12.216884 192.168.2.91 192.168.2.11 TCP 66 55561→22 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
62 12.218694 192.168.2.11 192.168.2.91 TCP 66 22→55561 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=32
63 12.219108 192.168.2.91 192.168.2.11 TCP 54 55561→22 [ACK] Seq=1 Ack=1 Win=65536 Len=0
65 12.283859 192.168.2.11 192.168.2.91 SSHv2 95 Server: Protocol (SSH-2.0-OpenSSH_6.7p1 Raspbian-5+deb8u3)
66 12.345509 192.168.2.91 192.168.2.11 TCP 54 55561→22 [ACK] Seq=1 Ack=42 Win=65536 Len=0
77 17.330392 192.168.2.91 192.168.2.11 SSHv2 80 Client: Protocol (SSH-2.0-TTSSH/2.74 Win32)
78 17.335891 192.168.2.11 192.168.2.91 TCP 60 22→55561 [ACK] Seq=42 Ack=27 Win=29216 Len=0
My other non-volumio Pi here responds with Server: Key Exchange Init, but Volumio tears down the TCP
79 17.350712 192.168.2.11 192.168.2.91 TCP 60 22→55561 [FIN, ACK] Seq=42 Ack=27 Win=29216 Len=0

Any ideas how to solve this?

Leave it running for 10 minutes on first boot (especially for slower devices). It regenerates SSH keys, and yours probably has not finished yet

Thanks, but the unit has already been running for over 24 hours.

Then you probably turned it off the first time when first boot process has not finished… Reflash and leave it alone for at least 10 minutes on first boot

I did as suggested with a fresh image and left it running for a couple of hours. Then SSH sometimes worked. If i managed to connect SSH, I was disconnected after a minute or so. Web UI was not working at all.
After waiting overnight, the system is now working well.

So something is taking a loong time to finish, it seems.

After my first boot with the initial image, I set the DAC to HifiBerry, which required a restart. Since that should be a common use case, I think the key generation should be made robust to such handling and restart at the next boot.

Anyway, for me the case is closed. Thanks for assisting!

You’re right, we need to make first boot more robust