Sync for hosts and SSH keys seems like a really weird feature to put into a terminal emulator (except maybe on Android with its very restrictive security model) considering that those have literally nothing to do with the job a terminal emulator does.
Hmm, I'm probably explaining myself poorly. What I'm currently using Termius for is to connect to my local servers as well as two VPS I rent. In order to either make quick changes, or troubleshoot. Having that sync between Termius instances on my various devices with Alias, IP, and SSH key so I can connect with a single tap/click is what I'm after. If possible. Like I said, I'm still pretty new to this in general. I've run PiHole on a Pi3b for years, but that was it until Spring of this year when I started self hosting in earnest and learning Linux, etc. So I apologize if I used the wrong verbiage. Hopefully this explains it better?
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?
Yes I suppose that is right. I hadnt considered that the hosts would also be stored locally. Termius' home screen has my saved hosts arranged by alias and I tap on whichever server I want and it connects without password because I already set up ssh keys. And if I add a new host it syncs with the other instances of the app on my tablet, phone, laptop, and desktop. In fact, it's so handy that I often reach for my android tablet with attached keyboard to fiddle with the servers.
A similar system can be achieved using a synced .ssh
folder, along with a .ssh/config
file. The folder will have all the keys, and the config file will have the aliases aka bookmarks. Then you can do something like ssh media_server
, and login without entering a password.
For the actual terminal emulators, I can recommend Alacritty for desktop OSes and Termux on Android.
Or you could use a separate key on each device.
Terminus IMO is utter crap, their sales team are useless and didn't want to engage with me in a useful non-automated way. Their 'Linux' support is actually just a Ubuntu based deb installer which you need to manipulate to be useful on other distros. I am also very cautious of their cloud sync which holds your passwords and keys especially since it doesnt use your systems defaults on Linux.
However it is currently the best ssh client I can install on android via Google play on a device I can't sideload Juice onto, I just don't let it remember passwords and keys.
Wrapper - https://gist.github.com/adamboutcher/76aa402ad4478faeed95a4e953fdd200
Why do you need to sideload JuiceSSH, rather than install from the play store?
Because if your android forces the newer android security contexts for storage, it won't install.
Also their display scaling doesn't always work under Wayland gnome. (I use fractional display scaling on my 4k monitor).
So you're sandboxing the app to prevent any calls home? Am I understanding that correctly? I haven't had to interact with their support at all but found the cross platform continuity to be nice for a newbie. I know I can do all of this on whatever terminal emulator is installed on the different devices, just looking for something like Termius feature-wise, but is less expensive, maybe FOSS if possible, and allow me to have more control of my data by using something like Syncthing? Might be too tall of an order though.
No sandboxing because I'm only using it on one device with no saved details....
Why can't you use native clients under Windows, Mac and Linux then? Use what your platform offers for the best experience. I do this and sync my ssh config file with Syncthing.
In iOS we can't have Syncthing so I've to use https://panic.com/prompt/ and live with it.
That is not something I had considered. That the config files are universal. So that helps quite a bit. I'll have to look into setting that up. I read elsewhere that some check theirs into github and sync from there.
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
Oh that's very helpful, thank you.
It all boils down to wanting some sort of sync function either DIY or otherwise that includes hosts and SSH keys
I don't know of any free terminal emulator that runs on all those platforms. Much less one that is a combination ssh client and has host bookmarks. There are gonna be some pretty fundamental UI differences on desktop and mobile platforms.
Alacritty
That's not an ssh client and doesn't run on Android.
I suppose you can use openssh. I think that that runs on all those platforms -- use it with Termux in Android. But while it is an ssh client, it's not a terminal emulator; you'd run it in a terminal emulator on each platform. And while you can synchronize the files it uses with external software, it itself doesn't sync.
Same story for Dropbear.
I don't know what you're referring to when it comes to syncing keys, public or private.
You don't want to move your private keys around. Those are supposed to be per-host, so that if one gets compromised you can deauthorize just that host.
SSH itself will pull over remote public SSH keys the first time it contacts a host. Normally, people don't distribute those outside of that.
If you're worried about falling prey to a man-in-the-middle attack if the first use of a host is on an untrusted network and don't want to make use of ssh's key fingerprint verification, then I guess you could maybe make an argument for syncing a list of public keys. For openssh, you'd need to have something that can bidirectionally synchronize and merge changes in ~/.ssh/known_hosts, which is a text file. It's not the normal mode of use, though, and it means that compromise of any of your hosts running the ssh client will compromise the others in terms of trusting a given key to identify a remote host. I would not do that, myself.
And if your synchronization system permits for overwriting arbitrary files other than ~/.ssh/known_hosts, like ~/.ssh/authorized_keys, then you've got yourself a rather-larger security issue; compromise of one client can directly compromise the others to the point of allowing remote shell access to it.
X.509 certificates -- what most non-ssh programs use for key distribution -- don't have the issue of public key distribution on a per-host basis. They all trust a cerificate authority to sign certs. It looks like some implementations of ssh support X.509 certs. I suppose you could look into setting that up. Create a certificate authority, have all clients trust the CA, provide each ssh server with a signed certificate. That's going to be an exotic setup. But you won't have the man-in-the-middle vulnerability.
You can also set up a Kerberos environment, which looks like a more-common configuration for SSH than X.509. You are gonna need to be able to access the KDC from all the involved machines, though. That'll also avoid the man-in-the-middle risk; Kerberos relies on the fact that the password is a shared secret known to the KDC and client to bootstrap trust. That'd still be a kind of an unusual setup. This is pretty elaborate, though.
If you just want a list of bookmarked hosts to click on, all this is probably overkill. You don't need to synchronize keys. Any system that permits synchronizing a text file would do, as long as you can view that file in software that permits opening ssh: URLs in your terminal program. Like, have a synchronized Markdown file or something.
Based on your very detailed response, I have some fundamental misunderstandings of Terminal and SSH...
I'm not stuck on the UI similarities, only mentioned it since Termius has it and I appreciate the feature. And I'm not opposed to paying. But Termius' $10/mo is far too much for what I use it for. Perhaps if I made a living with this sort of thing it would be easier to swallow.
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? I can look into that as I have several methods of syncing already lined up. I'd just need to point the programs at whichever folder location has the "goods", so to speak.
Everything I reach aside from the two VPS are on my local network with no services exposed to the internet and no ports forwarded other than one for Wireguard so I can tap that server from outside of my network.
I'll have to poke around more and make sure I can find where those config files are. I'm guessing Termius has them stored somewhere other than where a native terminal app would, but I can certainly check.
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.
Thank you, that helps clear it up. I was certainly conflating the two previously. This makes sense now.
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:me@vps1.mydomain.com
ssh:me@vps2.mydomain.com
ssh:me@home1.mydomain.com
ssh:me@home2.mydomain.com
ssh:me@home3.mydomain.com
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:
- Run
ssh-keygen
on client. Follow directions. Now the client has a pubkey and privkey in ~/.ssh/ at id_rsa.pub and id_rsa. - 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. - Now you have passwordless access. Repeat 1-3 for other clients.
- 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.
- All clients have passwordless access to all servers.
With PuTTY or other ssh clients, there will be a comparable way to generate a pubkey.
You bring some valid points up. Considering the low number of servers and clients I might need to reach, a sync certainly isn't critical. I sought it out because I started distro-hopping when I built my first dedicated Linux PC recently and was annoyed having to set up the password-less logon to the servers I use. Now that I've settled, it's not a concern anymore. And if I do want to try another down the road, I can make sure to back up the config files and import them in the new OS.
I actually lied. I said that OpenSSH doesn't have a "bookmarking" feature. OpenSSH does have a "bookmarking" feature -- the Host entries in ~/.ssh/config, with a Hostname field.
I haven't used that feature much, since normally, I'd rather add a short hostname to /etc/hosts, and then all software on the system can use that short hostname, not just OpenSSH.
The last time I used it was to set up a tunnel that bounced through multiple machines running ssh servers with a single command, over a decade ago, which is something else it can do.
But it is there.
I actually lied
How dare you!
In all seriousness that's good to know. Gives me options to pick from. Thanks!
I thought KDE was working on some cross platform programs, but I can't recall the name of the project or the tools, they had a file manager, and a few other things. I thought it included a basic terminal emulator.
I may be thinking of the following project.
it shows screen shots for 'station' on mobile, but I can't find a .APK for it.
That's because there isn't an APK, it's designed to work with Plasma Mobile, which uses AppImages
but they have an APK for the file manager 'index'. so that's what's confused me.
Ah yeah. Looking back, I see that almost all of them are listed as compatible with android. Station and Clip appear to be the only ones that aren't.
Interesting. I'll keep an eye on that project. Thanks!
I'm seeing some hints that Wezterm can be built for Android. But l haven't found specific instructions, and I don't think it has a feature to sync hosts and keys.
No personal experience but if I were to try I would start with Syncthing and probably synchronize config files and aliases.
Linux
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0