Pour connecter le smartphone au PC, j’utilise le très pratique KDE Connect, avec l’extension Gnome GSConnect.

J’apprécie particulièrement que la musique du PC se mette en pause lors d’un appel (entrant ou sortant). J’utilise aussi la possibilité de copier des fichiers sur le smartphone sans avoir besoin d’utiliser un câble USB, et enfin quelques fois pour les SMS, bien que la synchronisation si on a un long historique ne fonctionne pas toujours très bien. Voilà pour l’essentiel de mon usage.

C’est le deuxième point qui me posait problème, le menu « Monter » ne faisant pas apparaître le smartphone dans Nautilus :

Voyons voir comment analyser ce qui se passe… et résoudre le problème ! 😎

Heureusement, l’extension GSConnect permet de voir facilement les logs :

En choisissant l’option « Générer les logs pour le support », une boite s’ouvre vous demandant de faire le nécessaire pour reproduire l’erreur, puis un bouton « Vérifier les logs » vous permet de les visualiser immédiatement. Dans mon cas, cela donnait ceci :

Bon, le message est clair : « La connexion a échoué »… mais cela n’aide pas vraiment !! On voit tout de même l’adresse IP du smartphone (192.168.1.138), le numéro de port, le nom d’utilisateur utilisé, le nom du dossier partagé, et le protocole sftp.

Il faut ici comprendre que la connexion se fait à partir du PC vers le smartphone, qui pointe sur un répertoire qui doit être définit auparavant dans KDE Connect :

On peut dès lors simuler la connexion dans un terminal :

$ sftp -P 1740 kdeconnect@192.168.1.138
Unable to negotiate with 192.168.1.138 port 1740: no matching host key type found. 
Their offer: ssh-rsa
Connection closed.  
Connection closed

On y voit déjà plus clair : il s’agit d’un problème de clefs ssh, et la négociation échoue (en sftp, la connexion est chiffrée).

Après quelques recherches sur le net, le problème a été remonté ici. Ce n’est pas un bug de GSConnect, mais plutôt un problème côté Android qui utilise une version de chiffrement ssh-rsa qui n’est plus utilisée (deprecated) car jugée non sécurisée. Voir ici pour plus d’infos.

Heureusement, il est très facile de corriger le problème en autorisant cette méthode pour cet appareil : le « trou » de sécurité sur mon LAN est à mon avis minime et négligeable ! 😉

Le plus simple est de créer un fichier config dans ~/.ssh et d’y mettre le contenu suivant :

$ cat ~/.ssh/config 
Host 192.168.1.138
  HostKeyAlgorithms +ssh-rsa

Et voilà, le problème est réglé, le smartphone apparaît désormais dans Nautilus comme il se doit en faisant « Monter » :

Conclusion

Le problème était donc côté smartphone. J’utilise LineageOS for microG 18.1, dûment mis à jour tous les mois.

On peut donc dire que sur LineageOs, le système d’échange de clefs ssh utilise toujours ssh-rsa (qui utilise la fonction de hachage SHA-1) pour le chiffrement de la connexion. Mais côté PC (Debian 12 « bookworm »), avec une version openssh 9.0, cet algorithme n’est plus utilisé. Voilà d’ailleurs la notice d’information publiée à l’époque (pour openssh 8.2, en avril 2020) :

Future deprecation notice

It is now possible to perform chosen-prefix attacks against the SHA-1 hash algorithm for less than USD$50K. For this reason, we will be disabling the ssh-rsa public key signature algorithm that depends on SHA-1 by default in a near-future release.

This algorithm is unfortunately still used widely despite the existence of better alternatives, being the only remaining public key signature algorithm specified by the original SSH RFCs.

Bon, faut quand même avoir 50 000 $ pour s’offrir le moyen d’attaquer le système ! 😎