idursun
Passphrase input for SSH remotes doesn't work?
When doing any operation on an SSH-based remote that would ask for a passphrase, jjui just shows the ⣾ animation in the bottom left and the command (eg. jj git fetch --all-remotes) and remains that way, but doesn't actually allow entering the passphrase. Pressing Enter a couple of times brings up the error:
normal ✗ jj git fetch --all-remotes
Error: Git process failed: External git program failed:
[email protected]: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
press esc to dismiss
which is the only way to exit from that state. Trying to enter the passphrase doesn't work, even Ctrl-C is ignored, pressing Enter and going to this failure mode seems the only way out.
Is support for passphrase-based remote connections not there yet, or is this supposed to be working in some way?
Hey, thanks for the report.
Is support for passphrase-based remote connections not there yet, or is this supposed to be working in some way?
Unfortunately, it is not there. I do use ssh based remotes myself but without a passphrase exactly mostly because of this exact reason (i.e. breaking or hanging tools). Well, jjui is not really helping the cause either.
I need to specify if the command to run is interactive or not so that TUI can hand back the user input handling to the terminal. This is done for commands like split, describe, etc but not for the likes of fetch because that would flicker the UI.
I need to try address this in some way and leave the issue as a bug for now.
That makes sense. Until that long term fix lands, handling this via https://github.com/idursun/jjui/issues/87 i.e. doing my pushes via the "arbitrary command" mechanism would be a good workaround to have (assuming that would have terminal input handling enabled).
I use ssh-agent and everything works well except when I just boot into my desktop session and forget to jj git fetch or anything outside jjui so I get asked for my key password. Once I do that, everything goes fine from within jjui. So, for me it happens only the first time that the agent has not loaded my key. Nevertheless, sometimes I still forget to fetch before using jjui and it just hangs til I kill it.
I was thinking on ways to solve this, -for my case that I just need password interaction once per session-, it would be something like "use an interactive jj process on the first git remote operation, all subsequent operations need not be interactive", so the first time a given jjui instance tries to interact with the outside world would be interactive.
However, maybe that is only usable in my case, what about people that prefer to have password protected keys or other means that needs interaction (eg other ssh-pam methods).
Maybe we could have a setting like git-fetch-push-interactive that can be always, never (current), first (like my use case). We can come up with a better name for that setting if we decide to go with it.
Another way to solve this would be to have a init-command setting that may be executed by jjui as part of its initialization process before showing the UI (like shells have "--interactive" so their rc can do initialization for interactive sessions).
It could be used for running an initialization command, like starting a ssh-agent that will use desktop UI and prompt for password or something like that. Just a way to make sure everything is ready for jjui to show its interface.
If it was my decision I'd go for having a init-command, it is simpler than the three-valued git specific setting, and less complicated to implement. But this does not solves for people liking to be prompted each time for their password.
Or, I can just wrap my jjui executable with a simple shell script that always git fetchs before running jjui. EDIT: I just wrapped my jjui to solve this for me.
What do you think of all this?
Thanks for the detailed suggestions @vic
I stopped using passphrases long time ago so I am not not up to date with the experience of having one.
I might be wrong about this but AFAIK users might get prompted for one as simple as running jj describe if they are signing their commits with SSH keys. So I don't think it is only limited to remote operations.
I think your wrapped jjui solution is the best way forward.