J’essaye de comprendre quelque chose qui pour l’instant est très mystérieuse pour moi.
J’ai un home assistant OS installé sur un Raspberry 4 connecté en Ethernet sur mon réseau.
J’ai installé l’add-on Terminal & SSH.
Quand je me connecte en terminal depuis l’interface Web de HA via cet add-on, je me retrouve dans un directory /root (commande pwd) qui contient :
.
…
.bash_history
.bash_profile
.ssh
.tmux.conf
addon_configs
addons
backup
config
homeassistant
media
share
ssl
Par contre si je me connecte depuis un autre ordinateur sur le PI4 avec ssh, je me retrouve dans un directory /root (commande pwd) qui contient (commande ls -a) :
.
…
.docker
.ssh
Ce ne sont pas les même directory /root !
Le quel est. vraiment utilisé par Home assistant ?
Et comment peut on passer de l’un à l’autre soit via la connection de l’add-on, soit via la connection ssh depuis un autre oridinateur ?
Si quelqu’un voulait bien me donner bune explikcation, j’ai recherché depuis Internet mais je n’ai pas trouvé.
Merci !
Alain
Ma configuration
[center]## System Information
version
core-2025.2.5
installation_type
Home Assistant OS
dev
false
hassio
true
docker
true
user
root
virtualenv
false
python_version
3.13.1
os_name
Linux
os_version
6.6.62-haos-raspi
arch
aarch64
timezone
Europe/Paris
config_dir
/config
Home Assistant Community Store
GitHub API
ok
GitHub Content
ok
GitHub Web
ok
HACS Data
ok
GitHub API Calls Remaining
5000
Installed Version
2.0.5
Stage
running
Available Repositories
1607
Downloaded Repositories
1
Home Assistant Cloud
logged_in
false
can_reach_cert_server
ok
can_reach_cloud_auth
ok
can_reach_cloud
ok
Home Assistant Supervisor
host_os
Home Assistant OS 14.2
update_channel
stable
supervisor_version
supervisor-2025.02.1
agent_version
1.6.0
docker_version
27.2.0
disk_total
916.2 GB
disk_used
11.2 GB
healthy
true
supported
true
host_connectivity
true
supervisor_connectivity
true
ntp_synchronized
true
virtualization
board
rpi4-64
supervisor_api
ok
version_api
ok
installed_addons
Terminal & SSH (9.16.0), Studio Code Server (5.18.3), Mosquitto broker (6.5.0), Zigbee2MQTT (2.1.1-1), Bookstack (2.4.2), MariaDB (2.7.2), Let’s Encrypt (5.3.3), Samba share (12.4.0), AdGuard Home (5.2.5), Linky (1.5.0)
Merci de ton aide.
Comme il manque le message de Gilbert_VAISSIERE, je ne sais pas à quoi correspond ta réponse :
que le client « externe » pointe sur la machine physique.
Sinon, je ne crois pas avoir 2 addons, voici ma config de l’addon « Terminal et SSH » (j’ai effacé le contenu de la clé) :
Je pense donc que ça doit être sur le port 22 (vu l’indication à droite).
Tu me confirmes que ce n’est pas normal que je tombe à deux endroits différents suivant que je passe par l’addon ou par une connexion depuis un ordinateur ?
Le ssh depuis un ordinateur se fait sur le port 22222, la commande est :
ssh root@192.168.1.71 -p 22222
Je viens d’avoir une idée :
J’ai arrêté l’addon dans Home Assistant.
Je ne peux donc plus ouvrir de terminal depuis l’interface web de home assistant (c’est normal !).
Mais j’ai toujours accès en ssh depuis un autre ordinateur, j’ai donc bien un autre accès ssh que celui de l’addon.
2ème manip :
J’ai indiqué le port 22221 dans la config de l’addon (le 22222 est déja pris par l’autre ssh).
je me suis connecté en ssh depuis un autre ordi avec le commande :
ssh root@192.168.1.71 -p 22221
J’ai évidemment un problème de clé, mais je peux rentrer et je me retrouve alors avec le même /root que via l’addon de Home Assistant.
Ah mais oui voila l’addon est sur le port 22 et tu te connecte avec le 22222 voilà l’explication
Connecte toi avec le port 22 et tu arrivera au même endroit que l’addon
Et tu l’as trouve où ce port 22222 ?
En tout cas sur plateforme X86 il n’y a pas de ssh depuis HAos, mais ce n’est pas la même base d’os
Je ne me rappelle plus d’où sort ce port 22222 !?!
Mais j’avais peut être créé un accès SSH en même temps que l’installation de Home Assistant sur le Raspberry ??
Je n’ai pas l’autorisation de me connecter sur le port 22 depuis un autre ordinateur, mais avec l’indication du port 22221 dans la config de l’addon, je peux me connecter via ce port et je tombe bien dans le même dossier /root que depuis l’addon dans Home Assistant.
Je vais donc recréer une clé pour l’accès depuis les ordinateurs de mon réseau.
J’avais supprimé ma réponse trop hative d’hier où j’indiquais que, depuis le module complémentaire Terminal & SSH on accède au container Home Assistant alors que depuis un autre appareil sur le réseau on accède à la machine physique.
Ce n’est pas exactement cela.
Mon HA « de production » étant sur une VM Proxmox, j’ai exhumé un Raspberry pour tester dans une situation proche de celle du message.
Le module complémentaire Terminal & SSH était déjà installé et configuré sur cet appareil, notamment la clé publique pour l’authentification SSH
Test : on accède au container core (prompt core-ssh) dans les deux cas de figure; l’adresse IP est en 172.30.xxx.xxx
[core-ssh ~]$ ip ad
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
18: eth0@if19: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
link/ether 02:42:ac:1e:21:00 brd ff:ff:ff:ff:ff:ff
inet 172.30.33.0/23 brd 172.30.33.255 scope global eth0
valid_lft forever preferred_lft forever
Remplacement par le module complémentaire Advanced SSH & Web Terminal et configuration
Test : on accède au container core dans les deux cas de figure, analogue au cas précédent
Remplacement par le module complémentaire Terminal & SSH (retour à la situation initiale)
Connexion à la console
ha > login
Aucun mot de passe n’est demandé
Copie du fichier authorized_keys depuis /mnt/data/supervisor/addons/data/core_ssh → /root/.ssh
Vérification
ls -Al /root/.ssh/authorized_keys
-rw------- 1 root root 271 Feb 22 22:16 /root/.ssh/authorized_keys
==> Le fichier a bien les droits root:root, mode 600
Démarrage du service SSH
systemctl start dropbear
Test depuis un autre appareil sur le réseau
On peut alors se connecter en SSH sur le port 22222 avec authetification par clés
==> On se retrouve dans la situation décrite dans le message :
Welcome to Home Assistant OS.
Use ha to access the Home Assistant CLI.
pwd
/root
ls -Al
total 2
drwxr-xr-x 2 root root 1024 Apr 4 2023 .docker
drwxr-xr-x 2 root root 1024 Feb 23 14:59 .ssh
ip ad
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: end0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether dc:a6:32:f0:a3:57 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether dc:a6:32:f0:a3:58 brd ff:ff:ff:ff:ff:ff
inet 192.168.48.93/24 brd 192.168.48.255 scope global dynamic noprefixroute wlan0
valid_lft 12952sec preferred_lft 12952sec
inet6 fe80::b59f:e578:e2ce:ab0e/64 scope link noprefixroute
valid_lft forever preferred_lft forever
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:cf:57:33:11 brd ff:ff:ff:ff:ff:ff
inet 172.30.232.1/23 brd 172.30.233.255 scope global docker0
valid_lft forever preferred_lft forever
inet6 fe80::42:cfff:fe57:3311/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
5: hassio: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:ac:63:5b:2d brd ff:ff:ff:ff:ff:ff
inet 172.30.32.1/23 brd 172.30.33.255 scope global hassio
valid_lft forever preferred_lft forever
inet6 fe80::42:acff:fe63:5b2d/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
7: veth54432b1@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
link/ether 9e:50:20:a3:e8:40 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::9c50:20ff:fea3:e840/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
… plusieurs interfaces virtuelles avec des numéros pairs (if8, if10, …) et des adresses en IPv6
Sur cet appareil, à partir du moment où le fichier /root/.ssh/authorized_keys est présent au démarrage du système, le service SSH s’active automatiquement en écoute sur le port 22222
On trouvera des explications :
Parmi les hypothèses, l’appareil aurait pu être configuré depuis une clé USB (configuration réseau, service SSH) ?
A moins qu’il n’y ait une méthode depuis le GUI que je n’ai pas trouvée ?
A noter qu’il existe (ou a existé ?) un module complémentaire qui fait probablement la même chose :
En résumé
Sur mon Raspberry (idem sur la VM Proxmox) :
Depuis Terminal & SSH : container core
Après avoir créé le fichier /root/.ssh/authorized_keys depuis la console, on accède en SSH depuis une machine sur le réseau :
port 22 (par défaut) : container core
port 22222 : Home Assistant OS
Je n’ai pas d’explication sur la raison pour laquelle tu accèdes directement à Home Assistant OS en connexion SSH sur le port 22
J’ai envoyé mon dernier message sans avoir vu les derniers échanges.
Désolé pour la mise en page par copier-coller. Je manque d’expertise sur ce forum.
C’est, pour moi, clair :
tu as configuré le SSH sur le port 22222, soit en démarrant avec une clé USB de paramétrage contenant la configuration IP et la clé publique SSH, soit en configurant depuis rpi-imager.
Si tu supprimes le fichier /root/.ssh/authorized_keys, tu ne pourras plus te connecter sur le port 22222 en aboutissant directement sur HAOS.
Je confirme qu’on a bien le même comportement depuis une VM / Proxmox. Il suffit de créer le fichier /root/.ssh/authorized_keys et de démarrer le service depuis une connexion en console.
