web-dev-qa-db-fra.com

Impossible de ssh déverrouiller à distance le serveur ubuntu chiffré 15.04 avec dropbear / initramfs

J'essaie donc de mettre en place un tout nouveau serveur sans tête Ubuntu 15.04 avec un cryptage intégral du disque et des capacités de déverrouillage à distance. J'ai réussi à le faire avec un Raspberry Pi sous Raspbian-Wheezy et un autre serveur sans tête Ubuntu 14.04.

Pour les tentatives réussies et la dernière tentative infructueuse, j'ai suivi les instructions données dans ce guide .

Installez Dropbear/busybox:

Sudo apt-get install busybox dropbear

Copiez les clés SSH générées sur le client:

Sudo cp /etc/initramfs-tools/root/.ssh/id_rsa ~/id_rsa_dropbear
Sudo scp ~/id_rsa_dropbear client@client:~/.ssh/id_rsa_dropbear

Étant donné que mon client est un client Windows exécutant cygwin, modifiez les autorisations sur la nouvelle clé:

chgrp Users ~/.ssh/id_rsa_dropbear
chmod 600 ~/.ssh/id_rsa_dropbear

Dropbear ajoute automatiquement la clé publique au fichier allowed_keys lors de la génération de la clé. Création du script crypt_unlock.sh comme indiqué dans le lien ci-dessus, rendant exécutable:

Sudo vi /etc/initramfs-tools/hooks/crypt_unlock.sh
Sudo chmod +x /etc/initramfs-tools/hooks/crypt_unlock.sh

Mettre à jour initramfs:

Sudo initramfs-update -u

Redémarrez le serveur en essayant de SSH root @ serverip demande une phrase secrète de clé, puis le mot de passe de l'utilisateur root. Il n'y a pas de phrase secrète pour cette clé, je pensais que dropbear ne supportait pas les clés cryptées? Ce qui devrait arriver est que la clé devrait être reconnue et que je devrais être à une invite busybox, où je peux taper 'unlock' puis entrer le mot de passe de cryptage pour déverrouiller le disque racine sur le serveur.

Je peux entrer la phrase secrète de chiffrement localement (lorsque le serveur est directement connecté à un clavier/moniteur) et le serveur démarrera correctement. Ce que je ne comprends pas, c'est pourquoi Dropbear ne joue pas à Nice avec la clé privée. J'ai même essayé de recréer manuellement les clés privées/publiques en utilisant les instructions du fichier Lisez-moi cryptsetup plusieurs fois. Dropbear commence avec succès avec initramfs, vous pouvez le voir à l’invite de mot de passe complexe locale.

Si quelqu'un a des suggestions, ce serait grandement apprécié. Comme je l'ai dit, je suis vraiment énervé. Je l'ai déjà fait deux fois avec zéro problème. J'ai essayé de chercher s'il y avait un problème avec 15.04, mais je n'ai rien trouvé.

MODIFIER:

Sortie de ssh -vv root @ serverip:

    $ ssh -vv alphabot_dropbear
OpenSSH_6.7p1, OpenSSL 1.0.1j 15 Oct 2014
debug1: Reading configuration data /home/Pete/.ssh/config
debug1: /home/Pete/.ssh/config line 2: Applying options for alphabot_dropbear
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/Pete/.ssh/config
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.82.125 [192.168.82.125] port 22.
debug1: Connection established.
debug1: read_keyfile_line: /home/Pete/.ssh/id_rsa_dropbear line 3 exceeds size limit
debug1: read_keyfile_line: /home/Pete/.ssh/id_rsa_dropbear line 3 exceeds size limit
debug1: key_load_public: No such file or directory
debug1: identity file /home/Pete/.ssh/id_rsa_dropbear type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/Pete/.ssh/id_rsa_dropbear-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7
debug1: Remote protocol version 2.0, remote software version dropbear_2014.65
debug1: no match: dropbear_2014.65
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],ssh-rsa,[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],[email protected],arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],[email protected],arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1,[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1,[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: [email protected],ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,[email protected]
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-cbc,twofish128-cbc
debug2: kex_parse_kexinit: aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-cbc,twofish128-cbc
debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: zlib,[email protected],none
debug2: kex_parse_kexinit: zlib,[email protected],none
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: setup hmac-sha2-256
debug1: kex: server->client aes128-ctr hmac-sha2-256 none
debug2: mac_setup: setup hmac-sha2-256
debug1: kex: client->server aes128-ctr hmac-sha2-256 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server Host key: RSA ea:e6:df:5a:82:d6:db:20:3e:c9:5b:93:ad:f5:3b:3a
debug1: Host '192.168.82.125' is known and matches the RSA Host key.
debug1: Found key in /home/Pete/.ssh/known_hosts.initramfs:1
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/Pete/.ssh/id_rsa_dropbear (0x0), explicit
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/Pete/.ssh/id_rsa_dropbear
debug1: key_load_private_type: incorrect passphrase supplied to decrypt private key
Enter passphrase for key '/home/Pete/.ssh/id_rsa_dropbear':
debug2: no passphrase given, try next key
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
[email protected]'s password:
3
Pete Buonomo

Je ne sais vraiment pas quel était le problème. J'ai essayé d'utiliser une clé id_rsa dropbear différente, mais qui ne fonctionnait toujours pas. J'ai fini par réinstaller complètement une nouvelle version 15.04, en suivant à nouveau toutes les étapes et j'ai pu déverrouiller à distance sans problème.

3
Pete Buonomo

Je viens de rencontrer le même problème. Ce qui s’était passé est que la clé a été stockée dans l’ancien format:

cat /etc/ssh/ssh_Host_rsa_key
SSH PRIVATE KEY FILE FORMAT 1.1
<encoded private key here>

Cependant, le nouveau sshd attend les nouvelles clés codées en base64.

cat /etc/ssh/ssh_Host_rsa_key
-----BEGIN RSA PRIVATE KEY-----
<base64 encoding here>
-----END RSA PRIVATE KEY-----

Il existe probablement un moyen de copier les numéros de clés privées et publiques et de les reformater en base64. Cependant, l’option la plus simple serait de régénérer les clés à l’aide du dernier ssh-keygen

2
sverasch