I maintain a fleet of servers and the Snippets feature used to be a huge timesaver because you could:

1- enter a sudo command as first step
2- immediately proceed to apply the next snippet containing the password to run the sudo command across all servers

In the updated Snippets functionality, unless I’m mistaken, you can no longer do this because you’re no longer allowed to input another snippet before the first one has completed.

This means you’re stuck when using commands that prompt you for the user password and will have to go into each server one by one anyway, making Snippets useless for this scenario.

For my use case, Snippets unfortunately took two steps backwards and became useless.

I’d like to see the previous ability restored which’d make Snippets the killer feature it was for sudo commands.

I am using iPadPro keyboard, since the ESC key is simulated by command + `, I personally common keys like PageDown / PageUp should be simulated ,too. In macOS, such key is already simulated with some key + UP/DOWN. I wonder such implementation could happen in Termius.

And for “all custom combination key”, could be a premium service too, that users could design their own combination key with the UI similar to “custom keyboard” but like

Page UP = command + UP
Page DOWN = command + DOWN
INSERT = command + ...

More slots are reserved for the premiums.

Thanks for the attention.

I didn’t really want to report what I consider to be a security issue this way, but I don’t see another way to contact you for bug reports.

TL;DR: I believe Termius is truncating display of a new key fingerprint when it encounters a 00 byte.

We rebuilt a server recently, and it got a new host key. I deleted the old key fingerprint from the Known Hosts section, then connected. I got the usual “Are you sure you want to continue connecting?” dialog that lets me check the key fingerprint, except it skipped straight from “RSA key fingerprint is” to “Continue will add host to the list of known hosts” ****without filling in the actual fingerprint****.

I repeated my steps several times, with the same effect, then tried another server we rekeyed today. Connecting to the other server displayed the key fingerprint as expected. These two servers are configured using the same build script. The new public key fingerprint Termius does not display is 00:60:2a:9d:b7:68:1b:70:ff:94:78:30:ad:c3:38:0e. My theory about why this happened is that when you/your long-gone predecessor converted the bytes for the new key fingerprint to hex, you treated the initial bytes as a string and stopped converting when you hit the NUL byte. Since the NUL was first in this fingerprint, it didn’t display anything at all. A good fix would be to convert the number of bytes expected for a key fingerprint for that hash and type of key, in this case 16.

Perhaps my theory about the underlying bug is wrong, but in any case it seems important to display the key fingerprint in all cases when there is an option to add something to known hosts.