SSH connection issues

Desktop
1

I’m also having an issue with the SSH block. I’m sure there’s a reason, but it seems that SSH is not using the default config file in ~/.ssh/config. This basically means that I can’t use the SSH block, because:

  1. This is where I configure my SSH agent with:

    Host *
  IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"

  2. I connect to almost all my hosts by alias (though I can work around this one) :

    Host prod-swarm
  HostName 192.168.12.14

  3. I connect to almost all my hosts through a jump host:

    Host prod-*
  User ubuntu
  ProxyJump prod-bastion

(I don’t know how other people use SSH, maybe it’s me being weird, but I heavily rely on the config file to define everything I can.)

I can work around 1 and 2 by adding keys on the filesystem to the normal agent before I launch Atuin, and specifying the username and IP address in the SSH block, but I haven’t found a way to work around 3.

Another way I thought of working around 1 is to use an environment variable block to define SSH_AUTH_SOCK, but it doesn’t seem to be passed to the SSH process from the SSH block.

I’m not complaining, because it’s prerelease software, but it drastically impairs how I can test Atuin Desktop, because almost all the use cases I could think of for it so far imply doing things on remote servers.

Of course, I’m open to testing things, discussing use cases, etc. Thank you for giving us the opportunity to try this early.

1 Like
2

Hey, thanks for the feedback! SSH support is still pretty early, and we’re using libssh2 so a lot of this will need configuring/implementing vs what ssh can do. Definitely working on it!

If you open the app with

SSH_AUTH_SOCK=<path> open /Applications/Atuin.app

does that make things work?

3

Yes, setting SSH_AUTH_SOCK when launching Atuin makes it use the correct agent, so it addresses 1. Thanks.

1 Like
4

Ran into the same issues just now. Setting the socket env var manually works, but is cumbersome.

I worked around this issue for now by creating an Automator app that wraps the command line call and made it run at login.

Config file parsing would be incredibly convenient. As far as I’m aware, libssh2 currently (sadly) does not support it natively, whereas libssh does. Any particular reason for the library choice? License maybe?

5

We originally went with libssh2 because tbh I found the Rust bindings to be much better. Licensing should be fine, as I believe libssh is LGPL and libssh2 is BSD, so no real difference for our use

I think longer term we’re more likely to switch to Russh:

I’d like to avoid C in our toolchain where possible, and it seems to handle SSH config files just fine

One thing to note though; as runbooks are supposed to be shareable, we will be exposing as much ssh config as possible in the runbook itself. Relying on local config will break portability (which might be fine for your use case?)

Sorry about the hassle here - should have it sorted out pretty soon!

1 Like
6

Is there a way to get more details why ssh connections fail?
Failed connection to ... is not that helpful, same as invalid args ...

Support for socket-reuse (SocketMaster/SocketPath/… in ssh config) would also be nice, as well as interactive authentication for e.g. 2FA. Should I create separate threads?

7

I’m just wrapping up a rewrite of our ssh to use Russh instead of libssh2, and it has pretty good support for ssh config files

We don’t support interactive auth just yet (soon!), and currently handle our own connection pooling internally. I’m not 100% sure how we could fit in with SocketMaster/etc, but happy to explore if it’s something important for you?

Feel free to open another thread, or an issue: GitHub - atuinsh/desktop: 📖 Runbooks that run - code coming soon

2 Likes