Get Zerotier or similar on your dad’s PC. Alternative is to use noMachine or another remote access solution.
If you were to go the hypervisor way things are even more flexible as you can then see the entire network, including all hardware. However you can achieve full LAN access with Zerotier or similar as well.
Ran into the same issue and found some solutions (but I’m clearly no expert) :
You could use the following :
ssh -t user@your-ha-host 'zsh -l'
This will request a tty from the server [-t] and ensure proper user login phase using zsh [zsh -l] (that’s an L). that should put you right into the tmux used on the web interface.
I tried and fiddle with these two options, and I think that removing [-l] will put you into zsh but not the tmux, but I’m getting confused with user configs, login config, etc. If anyone can shed some light, it’d be welcome!
Hi
I am using this on a test machine and just updated it from 2024.6.4 to 2024.10.4.
Now when I try to ssh from Windows Terminal it doesn’t display the banner message and the prompt looks weird.
Any idea what could be the issue?
Otherwise everything seems to work. I can still print the banner with ha banner. And it also looks fine in the web terminal.
Originally I posted about that as a symptom of using mosh + tmux all in one line like I do to start sessions on other Linux hosts:
mosh hassio@hasshost -- tmux a
I just worked around it by doing it in two steps mosh hassio@hasshost then tmux a.
The cause of that problem is that /home/hassio/.profile doesn’t run which does sudo -i to switch from hassio to “root” in the container.
I’ve seen that starting a month or two ago. I thought I broke something in my init script or something. Good to know it isn’t just me.
The cause is similar to above, for some reason /home/hassio/.profile doesn’t run or fails. So the sudo to root doesn’t happen.
The .profile file only contains “exec sudo -i”, which does not appear to be the cause (commenting it out doesn’t remove the symptom).
The question is why isn’t .profile being run? If I run it source ~/.profile (which as just pointed out just does sudo -i ) you wind up in the right state, running as “root” in the container and running the dot files in /root like .zshrc
For me, /home/hassio/.profile is owned by root with mode 0644. I’ve changed that to 0755 and with ownership hassio:hassio but it still doesn’t run correctly.
Do you use the add-on’s init commands or install additional packages? I think the think to do is try this on a fresh install with the default config.
As a result of this I realized I can work around this and get mosh + tmux to run in a single line:
mosh hassio@hasshost -- sudo -i tmux a -t homeassistant
Ok, now I understand what’s breaking the prompt and causing the sudo to root not to happen. The change may have appeared in 19.0. See the github issue: Shell prompt regression #788 for all the details. Note that issue is misnamed.
I believe it was broken by PR #755 which changed the default shell from /bin/sh to /bin/zsh for the added users. However, the script creates only .profile, while, I’m pretty sure that zsh will not run .profile by default for a login shell, and thus requires .zprofile to exist.
A temporary hack is to add the following to “init_commands” configuration option and restart:
This does not only not not but also breaks the terminal addon from starting with current versions because I have no such hassio username.
I tried using ~ or $HOME to make it work, even . while assuming the it would be the current directly but nope, no way to make it work in a portable way. Unless you use the full path it will not work.
Add-on version: 19.0.0
You are running the latest version of this add-on.
System: Home Assistant OS 13.2 (aarch64 / raspberrypi5-64)
Home Assistant Core: 2024.11.3
Home Assistant Supervisor: 2024.11.4