Both. It’s my understanding that using the ssh add-on allows me to ssh into the Home Assistant folder in the container as well as host folders. But native SSH would not allow me to access folders in the container.
My Home Assistant computer (an Intel NUC) is in the basement along with my MQTT broker and Plex servers. SSH is a lot easier than going to the basement with a thumb drive to do anything.
I have always run Home Assistant supervised. I realize that the ops want to depreciate Supervisor, but no one has ever explained why, or how would a
I access snapshots, addons, system and other features of supervisor.
I can’t help but feel that your post is on a complete tangent from how you started the thread, but here’s an attempt at a response.
‘Native SSH’ (as you described it) will work fine with a supervised install. The files ‘in the container’ will be perfectly accessible as they are, in fact, mapped data directories and do not exist solely inside the container.
That said, it doesn’t explain why you cannot locate the addons, which would imply there is something else wrong with your system. If I were you I would want to fix it.
Accessing “snapshots, addons, system and other features of supervisor” is done by tapping on the supervisor menu item in the sidebar. The supervisor is designed to be operated entirely via the Web interface, you do not need SSH to achieve anything in this regard.
Not a complete tangent, but my rant about the depreciating of supervisor would be better in another thread. But, on your last paragraph, how do I access the features of supervisor if supervisor is depreciated in a future update?
But that has nothing to do with SSH which I use for maintenance, access to backup files, etc.
Native SSH refers to installing SSH with sudo apt-get install openssh-server
“That said, it doesn’t explain why you cannot locate the addons, which would imply there is something else wrong with your system. If I were you I would want to fix it.”
This is precisely why I am here. Nothing in the log files look amiss, so how would you fix this? I thought of doing a snapshot then reinstalling Home Assistant again.
There’s this weird feeling of a disconnect between what we’re saying to each other here.
Presuming you mean deprecated, if supervisor is ever deprecated then you won’t needs to access it because it won’t be there. I can’t see supervisor ever being deprecated, it’s part of the whole homeassistant ecosystem.
Yeah, and if you’re planning on accessing ‘the host system’ because you’ve multipurposed your machine, I would have expected setting up SSH to be one of the first things you did, in fact I would have expected that was done before installation of homeassistant.
Well, I guess that depends on what else you’re seeing. Is it only a couple of addons that you can’t get? If it’s several are they all the ones that you need advanced mode for? If so, then it looks like advanced mode hasn’t carried through for your user. If not, is there any other relation between the addons you can’t get? Or indeed the addons you can get? Etc
Normally adding SSH server is one of my pre-HA steps, but I was informed that this would not allow me to SSH into folders in the container, and that I should use the SSH add-on instead.
I see lots of available add-ons, just not SSH. (The original topic of this thread).
The only reason I got onto this tangent about supervised is because you asked if I was running supervised.
There was a discussion last May (you were there) that said that the main dev team wants to discontinue Home Assistant Supervised and the Supervisor service.
Let’s roll the clock back.
I have been happily running Home Assistant on an Intel NUC with Ubuntu for the past year. I am also running an NAS and a WikiMedia server on that NUC.
Recently, I am rudely reminded that Ubuntu is not supported. Rude in that I can’t update my HA or any add-ons because of Ubuntu.
So, I make the decision to change the OS to Debian. Installing HA on Debian went fairy easy because of the completeness of Snapshots. The pain is in migrating my MediaWiki server to Debian. (Database issues).
I know that you think running an Intel NUC for a single application is silly, but that is my new plan. I would rather run HA in its own dedicated NUC/Debian than go through the pain of moving all of the MediaWiki databases and image files. They will stay on the existing NUC/Ubuntu.
So, my migration to Debian is on hold until the new NUC arrives, then I will install Debian 10 Buster and HomeAssistant on that.
There’s definitely a disconnect between what we’re talking about and I don’t know why, but ignoring most of your post and focusing on…
If you’re running a NUC for homeassistant only then the best option would be to use homeassistant OS.
Personally I would have saved the money, backed up the contents of your current NUC, installed proxmox on it, put homeassistant OS in one VM, and then restored your old nuc image to another VM - but it’s your money
I appreciate the dialog even though we have long passed up the original question.
“If you’re running a NUC for homeassistant only then the best option would be to use homeassistant OS.”
I originally installed Home Assistant following the tutorial by Jason Reibelt (Kanga_Who) titled “Home Assistant Supervised on Ubuntu 18.04.04”, dated May 28, 2020. But it was about the same time that Ubuntu was declared unacceptable. I missed that memo.
The reason I want to silo my Home Assistant apart from other functions on its own NUC is really that I want to isolate my MediaWiki. The last time I moved the MediaWiki database to a new server, it took me two days to get it completely working again. Moving Home Assistant is really painless- after deciding on which of five installation methods to use.