SSH auth under non-default conditions

[HerrDings]

First of all, I am not sure wether this is a bug or just me not understanding ssh auth. And yes, I read the explanation referenced in the wiki of this repo. But there the assumption is made, that one uses bash as shell. I do not use bash, but as far as I can tell, my configuration should be equally fine.

I use:

Client side: 2018 MacBook Pro with MacOS 11.6 "Terminal" as Terminal emulator Friendly interactive shell "fish" as shell Passphrase-protected SSH-Key ED25519 key which is located in ~/.ssh/mysshkey2021.key (mode 0600) / ~/.ssh/mysshkey2021.pub (mode 0644). That is not the only key in ~/.ssh/, but the only loaded key and the only key I want to use.

Server side: Gitea in a docker-container, listening on port 2222 for ssh-connections

I use the ssh-agent, thus I have to add my ssh-key manually after each boot of my client. After this, the ssh-agent stays in the background. It even does not matter if I exit my shell and close my Terminal-app. If I re-open it, I can just continue using my key without re-entering the passphrase.

I have no problem committing, pulling and pushing on the command line. It works fine and does not include a interactive password-prompt. The problems start as soon as I try to use git with Obsidian. Javascript console just tells me on every push or pull attempt, that there is a problem with my ssh-key.

Maybe obsidian-git is using the wrong key, maybe there are problems with communication to the ssh-agent, maybe there is a bug.

Probably a first step to the solution is a better understanding of the problem. Is there a way to get a more verbose log which includes more details on the ssh auth problem?

[Vinzent03]

First, thank you for your detailed description! I am not an expert in ssh. Could you try the config shown in this comment

[HerrDings]

Thank you for your very quick reply! As suggested in the comment behind your link, I added a specific config in my ~/.ssh/config for my gitea-host. For testing purpose I also created (and added it to my git server) a (rsa-)keyfile without passphrase. I configured/forced ssh to use that one temporarily, afterwards I forced it to my usual passphrase-protected file. With the unprotected key it worked. As far as I understand this means, that the ssh config-file is used and not ignored. So I can be sure now it uses the right key and all other parameters are also fine. Whatsoever it does not work with the protected ssh key.

The behaviour of the command line git is unchanged: it works fine for both keys.

I would be really happy to get some advice on how to make obsidian more verbose about that error to be able to narrow it down.

[Vinzent03]

Hmm, I don't know what I could log. Would a custom GIT_SSH_COMMAND env var help?

[HerrDings]

While trying to use GIT_SSH_COMMAND to enable more verbose debugging, I found some help on askubuntu. That post describes how to get more verbose logging on ssh, wich surprisingly showed up in the debug console of Obsidian. I just needed to add LogLevel DEBUG3 under my host in the ~/.ssh/config.

Whatsoever, It seems that obsidian tries to open a tty to get a password for my key. Obviously that does not work.

I would conclude from this, that there is a communication problem between Obsidian and the ssh agent.

I don't really know how to dig deeper in this and how to debug further. Any advice on that?

[jakobbohem]

Really too bad that there is not a way to store or supply the passphrase on boot. I also enjoy safekeeping my .ssh access with passphrases for the keys. Perhaps now I will have to keep a separate key without a passphrase just for Obsidian.

If any solutions present themselves I will keep an eye out.

[tionis]

Does your shell set an environment variable for agent communication, normally that's how it's done and I don't think Obsidian sources your shell config.