How does one get into the console without installing an add-on like the SSH add-on or Studio Code Server? How does one that does not have administrator access do so?
This discussion is specific to the HassOS setup. Getting direct console access is one of the following ways:
Hardware: connect a screen and keyboard to your device. You’ve got console access
VM: Use your VM console
One of the primary reasons for wanting a password on the console is for people (like me) that have HA systems in use at multiple locations. While we can secure the device physically, it’s still a best practice to also ensure that any administrative consoles are secured with some sort of authentication / authorization setup. In this case, a password.
1 Like
In an attempt to add some clarity (to this long lasting topic).
Maybe it is a difference in perspective, why people see no need for a console password.
I think everyone would agree that access control (password) is a best practice, but that some people just don’t see the need for it.
-
if HA is ran on a physical device, and if a thieve/hacker has physical access to that device, then indeed the information on the device can be fairly easily accessed, and a password could seem superfluous.
-
however, if HA is ran on a virtual system, the host could protect that virtual system with disk encryption (and other security measures), which reduces the risk of access to (or theft of) the HA configuration/information on the disk.
In that case, additional protection of the console with some sort of authentication/authorization (password) is adding value.
This request is probably supported by people who have already made sure that (offline) access to the file system of the HA box is difficult or impossible. Such setup is common and realistic (e.g. with HA is ran on a VirtualBox).
1 Like
Both require physical access to the hardware, the availability of additional hardware (keyboard and mouse), and possibly the ability to get past an existing password (in the case of a virtual machine running on a secured server). Can it happen? Sure, but how likely is it that it actually will. Yes, I get that you want to eliminate that last little bit of risk, but most users don’t see the need for it, nor do I think that most users even understand that such things are possible.
Thank you everyone for sharing your input. While there may be differing opinions on this matter, I would still like the feature for myself.
Here are the key points to consider in my eyes:
-
Defense in depth - security best practices advocate for a multi-layered approach to protect systems and data. By implementing a console password, you add an additional layer of security, even if other security measures are in place.
-
Risk mitigation - console passwords help mitigate risk, especially in scenarios where physical access is possible. While physical security is a very important aspect, it should be accompanied by authentication mechanisms to deter unauthorized individuals from gaining access to the system.
-
Accountability - a console password enhances accountability by providing an audit trail of actions performed within the CLI. A password-protected console can help attribute actions to specific a individual.
-
Delaying unauthorized access - while it’s true that determined attackers MAY find ways to bypass security measures, the goal is to delay unauthorized access as much as possible. By adding a console password, you increase the complexity and time required for an attacker to gain access, which gives you time and data to detect and respond to incidents.
-
Security best practices - following established security best practices includes implementing authentication mechanisms at all levels of access.
In the end, sure, the decision to implement a password should be based on your own security requirements and your specific use case.
I can’t believe it and it scares me that we have cybersecurity professionals out there advocating against additional security measures, especially when those align with industry accepted best practices.
4 Likes
I like to have an option to enable console authentication too. If you are running a virtual installation of HASIO, for example in ESXI, you don’t need to have physical access to the device to obtain console access.
I’m working with different Virtual Appliances, all of them requires a console authentication, for example pfsense.
It’s just a best practice to enable this.
Linux Security Stats, Tools, and Best Practices | phoenixNAP
3 Likes
Just checking in to register additional concerns over the console not being authenticated. The vnc or equivalent console of any virtual machine will just dump you in a prompt with privileges. The hypervisor “having a password” is just not an acceptable solution, as that implies authorization is not important, which greatly increases the attack surface of the home assistant setup.
Access the vm console itself is generally not behind AAA, just limited to connections from localhost or some network sources in most setups.
This lowers the bar for access from having credentials on the hassos system to executing something as any uid, including unprivileged ones, on the hypervisor, which is much easier to clear.
Not to mention nearly every hypervisor setup has access control of various tiers too, and having this wide open on the console negates these benefits as well.
Dev/moderator seems to strongly feel it is just security theater, which I feel is somewhat (but not entirely) appropriate for a dedicated headless box in your home that can be subverted the second it is touched, but this is not the case for virtual machines as “physical access” is no longer the main barrier.
I would appreciate if you could reconsider since the usage scenarios that the software actively supports has changed.
4 Likes
Ok and what about virtual deployments and secure shell installations in the GUI? They are both very valid deployment scenarios and therefore you should be able to do this. I have this set on both the firewalls I have deployed infront of my home assistant deployment and would very much appreciate this as a secure way to prevent tampering with solar equipment. As changing settings to solar batteries can cause overloading and from what we’ve seen in phones as well as cars, this is a highly dangerous tamepring scenarios and it wouldn’t be much of a smart home if you weren’t able to utilise the power source as part of automation. If you cannot I see OpenHab has the capability so I am sure many will look towards them as the future considering this is not a hard feature to develop:
The real irony is there is a plugin, which anyone can enable via the front end with a simple installation from a repository, so its not actually physical. They’ve allowed there system to access the “physical” port over the http interface. The scary thing is how do you have a smart home if you cannot control the power of the house and since overloading batteries can create a bomb, look at electric cars and phones. So if HA cannot do it their competition can by default, look at OpenHab it has the capability and since HA is on a linux deployment they have developed things with no consideration for security of the underlying system. That means what ever you put on top is not worth anything. You cannot secure the top layers without securing the bottom 1st…
OpenHabs standard documentation for this feature:
I cannot believe this si the case of modern day development and this has been open for over a year…so basically someone who has no network understanding is expected to secure their home how?? What is more important for you, money of development or brand name, as just one hack and you’re going to spend the rest of your careers trying to prove you are secure. You want us to spend money then connecting to your cloud, like hell I will as if this is how secure your onpremise system is I would hate to see how weak your cloud security is.
Distrust is a company’s tombstone
1 Like
You’re confusing SSH access with the console that is displayed when you hook up a monitor and keyboard. SSH is passworded by default.
If by plugin, you are referring to the SSH add-on, that is also enabled by the user, requires user configured option for user/pass authentication or keys, and is running in a container that does not have access to the host system.
Also, a cloud instance is not provided by Nabu Casa. Users and passwords are required there, within HA itself, and MFA is available to be configured for each user. There is no automatic access provided by the cloud service.
That’s what I thought they were saying.
I’ve been an IT systems engineer for a few years now designing, deploying, auditing and maintaining large infrastructure systems across almost every sector. I’m not new to OT infrastructure either but I am new to automating my home and heard good things about home assistant so I thought I’d give their appliance a try in ESXI.
However, seeing this disappointing ongoing discussion from 2021 as the first result for a simple console password is fairly concerning. I appreciate the response from the moderators but honestly it just highlights the HA team’s nonchalant stance on security. My first thought is what other known and easy to resolve security flaws does this software have.
Watching a team fight against best practices, even when their competitors have implemented it, isn’t something I usually see at any enterprise (big or small) as I’m sure they would be replaced quickly.
Guys please do the right thing here and at least admit a console password is an extra layer of security. And no we’re not talking about an SSH password, this is the console password when accessing the console. HA seems like a cool product and I appreciate the work that’s gone into it, but this isn’t the hill to die on.
4 Likes
Hi!
I recently wanted to set up home assistant at my house and discovered this blatant vulnerability and the repeated refusal to follow information security best practices. It’s really disappointing to see this and now I’m wondering if I have to maintain my own fork just to add something as basic as “a password” because of this refusal to consider defense in depth.
I would hope open source projects would be better than this with regards to basic security hygiene.
As for the arguments that it’s a local console and therfore can ignore all security practices, consider that aside from the obvious issue of VM installations, many of us are running this on hardware with SMI interfaces that provide networked KVM console functionality.
E: On some level I am surprised this issue has not been reported and assigned a CVE number - it absolutely falls afoul of this and could quickly become an exploitable vulnerability: CWE - CWE-306: Missing Authentication for Critical Function (4.14)
2 Likes
Seriously, have you put the CVE in yet? Someone should.
2 Likes
The front door to my home is also only accessible through physical access, but I still prefer keeping it there.
Hypervisors such as XCP-ng use a browser based VM orchestration tool - Xen Orchestra, which gives direct access to the Text Console. So no, not even that argument stands, that the console is only accessible through physical access.
I suppose this is just an oversight that hasn’t been pushed for a lot, and we really should be taking care of this. There are absolutely 0 downsides to having a checkbox so users can make their own choice whether to require a password or no.
TrueNAS checkboxes for example:
I can see both arguments here. There whole point of HAOS as I see it is for it to be a simple thing that you can configure when it boots up.
There are ways around the “if you have physical access, you are doomed” tho.
Trusted computer group (TSG ) made an Opal spec about disk encryption. Lots of hardware supports this, example the Nuc 14. Using this and a yubikey with a static password and you have a fairly good setup with transparent encryption and a hardware token you can store away and bring back when you need to boot.
Home-assistant have too many credentials stored on it to be just a sitting duck for theft and people left with access to the device for an extended period (like airbnb residents). Console password is whats needed for the last step.
1 Like
I was looking around thinking about a solution that would please everyone…
Adding a password here doesnt look that trivial after all.
The ui we see is kickstarted from operating-system/buildroot-external/rootfs-overlay/usr/sbin/hassos-cli at e97b1231dc8d48680a9d5b5a8145f30a536d8327 · home-assistant/operating-system · GitHub . It starts a container that runs cli.sh.
cli.sh is located at plugin-cli/rootfs/usr/bin/cli.sh at d7822d8def96ad3f755dcebdd2de85e9712c662e · home-assistant/plugin-cli · GitHub . Here is where the banner is from and a simple wrapper (rlwrap) that is the prompt. You are in a loop here, not a “shell”.
To be honest, I don’t think I even need to be logging into the console at all.
What we introduced a simple check in cli.sh around line 4 that checks if a file exists (example /homeassistant/.no-tty-prompt), and does nothing.
Or it can be done at top of hassos-cli.
What do others think? For me, it’s about protecting it from curious airbnb types of people and feeling a little more safe leaving the box out of sight. Would be very nice to have a file I can make to lock it down.
Making the physical TTY non-responsive would be a fine solution IMO as long as it’s something that we could enable / disable via the UI which is behind the admin only settings.
I made a temporary solution if you want this now. As many noted above, this only really make sense to do if the disk is encrypted so you can’t just reboot it.
This is something that works
docker exec -it hassio_cli bash
vi /usr/bin/cli.sh
- Put this at the top of the script
cat /proc/cmdline | grep -q "systemd.unit=recovery.target"
if [ $? -ne 0 ]; then
clear
echo "..."
sleep infinity
exit 143
fi
exit and commit the image locally
hassio docker commit hassio_cli ghcr.io/home-assistant/amd64-hassio-cli:2024.07.0
You can now boot it normally, without anyone having access to a console. Or boot it using recovery (then hit ^d to continue when prompted) and get access to the shell.
This would be a fairly good solution if there was a way for the hassio_cli container to query homeassistant for a config parameter to check if “no_interactive_tty=true” is set (or something).
The hassio_cli has access to the supervisor api, but I didnt find a good place to put a configuration parameter like that in it.