Cross platform terminal emulator?

Is Termius the only cross platform emulator that includes Android as one of the platforms? It is quite good, in my limited experience, but too expensive for a hobbiest. I like that I can use my Linux desktop, MacOS laptop, and Android tablet/phone and the UX is the same across them all. The sync (trial for free, then charge) is great. But I'd be fine if it was something where I could DIY a sync method with something like Syncthing.

I'm aware of the likes of Alacritty, but no mobile app. And of course Termux is great for mobile, but no desktop versions.

It all boils down to wanting some sort of sync function either DIY or otherwise that includes hosts and SSH keys and while not as important, I do like the consistent UX between platforms. Is there something else to consider?

You're viewing a single thread.

31 comments

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:
  undefined
  
  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!

31 comments