Im probably the one missing something…apologies. I was just hoping there as a way of changing the default port so that -p was not required. I thought I was doing this in the config of the add-on but it does not appear to translate through the the CLI of the docker container. I suppose I was wanting to do the same as what we can do in linux by simply editing the ssh config file and changing default port number.
No there isn’t. Unless you do somthing on your network or router to make port 22 point to the other port on your HA IP address.
I think you are confusing things. You are setting a port that will respond to SSH commands on your HA server. But when you are using the SSH command you are not using it internally, so the terminal has no idea what port to use, and the default is 22.
Hugely useful! 
A small update that the OP (@CentralCommand) might want to include in the original post, if they are still around. ssh supports a command line option to specify the configuration file location, which can make the SSH command lines used in other shell commands so much simpler, avoiding repetition and possibilities for errors, and reducing work required to make changes.
For example, I created /config/.ssh/config containing:
Host router
User root
Hostname 192.168.1.1
Port 2222
Host *
UserKnownHostsFile /config/.ssh/known_hosts
UpdateHostKeys yes
IdentityFile /config/.ssh/id_rsa
Now my shell_command automation looks like:
shell_command:
update_certificate: ssh -F /config/.ssh/config root@core-ssh "scp -F /config/.ssh/config -O router:/etc/acme/mydomain/fullchain.cer /ssl/"
Background: I have letsencrypt with a wildcard domain set up on my router where it gets renewed periodically. I want to copy this certificate from the router using SSH into a place where the nginx addon can use it.
This shell command firstly ssh’s into the core-ssh addon’s container because homeassistant’s container doesn’t have write permissions to /ssl/ to update the certificate. Then it uses the same configuration file (and associated id_rsa) to ssh to my router to copy the letsencrypt certificate into the /ssl directory, where it can be used by the nginx addon.
This is a mega thread so somebody may have already mentioned however I was stuck on this for quite a while:
If you are running Home Assistant in docker after moving id_rsa file withing /config folder do not forget to cmod it so HA docker user can read it.
I’m running HA in a docker is there any way to get a shell working like how the addon works but without the addon
This seems to add sensors but not an interactive shell
Would like something like this
Hello,
i’m trying to connect passwordless from HA ssh terminal addon to a Synology NAS, i followed this thread guide + this guide but it still asks for password. Is there anything else i can do?
> ssh -v -p 65022 [email protected] -i /config/.ssh/id_rsa -o UserKnownHostsFile=/config/.ssh/known_hosts -o StrictHostKeyChecking=no
OpenSSH_9.3p2, OpenSSL 3.1.4 24 Oct 2023
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 192.168.1.211 [192.168.1.211] port 65022.
debug1: Connection established.
debug1: identity file /config/.ssh/id_rsa type 0
debug1: identity file /config/.ssh/id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2
debug1: compat_banner: match: OpenSSH_8.2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.1.211:65022 as 'userxxx'
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:1hEBHLWpXrcJ+SPs0D4llWDuAuRGgFtGOQIjdzUMzTI
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host '[192.168.1.211]:65022' is known and matches the ED25519 host key.
debug1: Found key in /config/.ssh/known_hosts:2
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /config/.ssh/id_rsa RSA SHA256:ajJiAl+IyU2Ucq5iNe9BBy/mvvir2Hoe7caj09QlIoc explicit
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,[email protected],ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected]>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /config/.ssh/id_rsa RSA SHA256:ajJiAl+IyU2Ucq5iNe9BBy/mvvir2Hoe7caj09QlIoc explicit
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
[email protected]'s password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
[email protected]'s password:
Authenticated to 192.168.1.211 ([192.168.1.211]:65022) using "password".
debug1: channel 0: new session [client-session] (inactive timeout: 0)
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug1: Remote: Ignored authorized keys: bad ACL permission for file /volume1/homes/userxxx
debug1: pledge: fork
Synology strongly advises you not to run commands as the root user, who has
the highest privileges on the system. Doing so may cause major damages
to the system. Please note that if you choose to proceed, all consequences are
at your own risk.
Thanks
Nevermind, it was a permission problem:
chown -R <user> /volume1/homes/<user>
chmod 750 /volume1/homes/<user>
chmod 700 /volume1/homes/<user>/.ssh
chmod 600 /volume1/homes/<user>/.ssh/authorized_keys