Oh, I wasn’t talking about the phrasing, just the fact that SSH Keys and hosts tend to be just files used by one of hundreds of programs a terminal emulator displays, not really different from having your terminal emulator sync the RSS-Feeds in your terminal RSS reader or the bookmarked folders in your terminal file manager.

It seems you are talking about some sort of bookmark system to open a terminal and start SSH for a specific host directly though?

Because if your android forces the newer android security contexts for storage, it won’t install.

No sandboxing because I’m only using it on one device with no saved details…

I have some fundamental misunderstandings of Terminal and SSH…

You can have a virtual terminal program to run text-based programs on the local system. On Linux, alacritty, xterm, urxvt, kitty, gnome-terminal, konsole, and the Linux kernel’s native virtual terminals all can do this. They have nothing to do with remote communication. They’re just pretending to be a traditional (non-virtual) terminal, something like this. You used to plug a bunch of those dumb terminals directly into a single (extremely expensive) computer to let many people share it. Those are pretty much gone, but we still provide virtual terminal software that emulates it. It deals with stuff like scrolling text on the window and colorizing it.

Inside those terminal emulators, you can run text-based programs. One text-based program that you might run is a text-based ssh client, like OpenSSH. That’ll deal with securely connecting to another host over the Internet, authenticating, and encrypting data between the two.

You can also have a single software package that provides both a terminal emulator and an ssh client, which is more-common on, say, Windows. PuTTY is an example of this. ConnectBot on Android.

I think that all the platforms I know of provide some way of doing both the separate terminal emulator program/text-based ssh client and the combined model. Windows, Linux, Android, MacOS. But historically, Unix has had a considerably-nicer text-based environment than Windows, so I suspect that more users on Windows use combined ssh/virtual terminal programs, because they’re rarely using text-based programs on their local system.

So if I’m understanding correctly, I just need to copy the host config over between platforms and not worry about the keys. Is that an accurate statement?

If your goal is to have a list of synchronized “bookmarks” for all the servers you want to talk to, and you want passwordless access, yes.

The conventional way to set this up is that each client machine (I guess you have three?) has a private ssh key. Each server (you have two rented VPSes, plus apparently some on your home network, based on your other comment) has a list of fingerprints of private keys that it trusts in ~/.ssh/authorized_keys. If a client has a trusted private key, it’s permitted passwordless access as thst user. If a client is compromised – like, you lose your Android phone – you remove the key fingerprint from the servers, but normally, the authorization is a one-off affair.

If you have a mostly-unchanging and small list of servers, I wouldn’t even bother with synchronizing a list of host bookmarks myself, unless you’re worried about remembering the names. You’ve only got three clients and a handful of servers, and if you can remember the names of the servers (like, someone else didn’t impose a naming scheme on you with long and elaborate names, which doesn’t sound like it’s the case), it’s not essential to do synchronization at all. I’d just type out the name of the server each time, or if I want to shave off a few taps on Android, manually set up a shortcut in ConnectBot or whatever Android ssh client you use. But it sounds like you want to be able to do that bookmarking. So assuming that that is the case:

Openssh and dropbear don’t really have a list of “bookmarks”. Well, I guess that in bash, you can tab-complete on entries in /etc/hosts. I don’t know if that’s what you want. What I mean is that as long as you can have a piece of software that can maintain a list of URLs, including ssh: URLs, and can open them in an external program, you’ve got a way of keeping a list of hosts. If you have a Markdown or org-mode or text editor that can open ssh URLs with an external program – like, I can do that in Emacs – that’d do it. If you have a “bookmark manager” that maintains a synchronized list of URLs – and it can open ssh URLs in an external program – across systems, that’d do it. I don’t use a bookmark manager, but I know that they exist. So you’d have something like:

ssh:[email protected]
ssh:[email protected]
ssh:[email protected]
ssh:[email protected]
ssh:[email protected]

So if you don’t mind using, say, ConnectBot on Android, which is a free and open-source client but Android-specific, and if it can handle ssh: URLs shared by other programs – I don’t know – then you can have the other program manage your bookmarks and open them in your SSH client.

But if your only concern is passwordless access for one user on three clients and a handful of servers, like I said, I personally probably wouldn’t bother with any synchronization system or bookmarks at all. It’d only buy much if you couldn’t remember the server names or they were constantly changing. I’ve used ssh for many years, sometimes with a bunch of ssh-accessible hosts in labs, and never bothered to set up a bookmarking system to choose servers from a list.

If you’ve never done passwordless access, and that’s the issue, setting up passwordless access is gonna vary, but normally it’ll look like this, if both ends are gonna use OpenSSH:

1. Run ssh-keygen on client. Follow directions. Now the client has a pubkey and privkey in ~/.ssh/ at id_rsa.pub and id_rsa.
2. Run ssh-copy-id me@server1 on client. Log in once with password at prompt. This basically just appends ~/.ssh/id_rsa.pub to ~/.ssh/authorized_keys on the server. Permissions on that file do matter; which is a common gotcha if people manually create the file; I believe that ssh-copy-id will set it up correctly for you.
3. Now you have passwordless access. Repeat 1-3 for other clients.
4. Since you have other servers that all apparently trust the same list of clients, you can just dump the same authorized_keys from that first server onto your other servers.
5. All clients have passwordless access to all servers.

With PuTTY or other ssh clients, there will be a comparable way to generate a pubkey.

SSH config is versatile, what I do is keep a simple .ssh/config file like this in every machine that isn’t synced:

Host *
  IdentitiesOnly no
  AddKeysToAgent yes
  IdentityFile "machinexyz-key-file"

Include "~/Preferences/ssh/config"

This file will simply configure it to use the IdentityFile of this machine and import another file that has the actual host definitions at ~/Preferences/ssh/config - that is the one I sync with Syncthing. This gives a nice way to customize settings for each machine (key path and whatnot) while keeping a global file with in sync between all of them.

For reference here is ~/Preferences/ssh/config:

Host *
  IdentitiesOnly no
  AddKeysToAgent yes

host server1
  hostname x.x.x.x
  user xxxxx
  port 1111

host server2
  hostname x.x.x.x
  user xxxxx
  port 2222

but they have an APK for the file manager ‘index’. so that’s what’s confused me.