Icenowy Posted May 9, 2019 Posted May 9, 2019 Recently I borrowed my Orange Pi PC2 to a friend, and he fails to set up SSH connection w/ it. After debugging w/ HDMI monitor, I found ssh_host_ecdsa_key, ssh_host_ed25519_key and ssh_host_rsa_key are preloaded to the Orange Pi PC2 image, which prevented SSH from working. Even if it doesn't prevent working of SSHD, it's also a severe security hole -- that means all Armbian installation with the same image will uses the same host key and they're vulnerable to MITM attack. I think these files should be purged when generating image, and regenerated when first powerup. It's what AOSC OS images do.
Igor Posted May 9, 2019 Posted May 9, 2019 1 hour ago, Icenowy said: Recently I borrowed my Orange Pi PC2 to a friend, and he fails to set up SSH connection w/ it. After debugging w/ HDMI monitor, I found ssh_host_ecdsa_key, ssh_host_ed25519_key and ssh_host_rsa_key are preloaded to the Orange Pi PC2 image, which prevented SSH from working. Even if it doesn't prevent working of SSHD, it's also a severe security hole -- that means all Armbian installation with the same image will uses the same host key and they're vulnerable to MITM attack. I think these files should be purged when generating image, and regenerated when first powerup. It's what AOSC OS images do. But they are (should be) regenerated. https://github.com/armbian/build/blob/master/packages/bsp/common/usr/lib/armbian/armbian-firstrun#L61-L67 I'll check if we made some bug ... Thanks. 1 hour ago, Icenowy said: I think these files should be purged when generating image, and regenerated when first powerup. It's what AOSC OS images do. 1 hour ago, Icenowy said: Even if it doesn't prevent working of SSHD, it's also a severe security hole Until you don't login to the system, security hole (root/1234) is wide open, but still better than setting fixed password or automated login.
Recommended Posts