SSH key auth with custom port in configuration for git server doesn't save / work

[mxtm]

If you import an SSH key, set the git server to use ssh-key auth, enter a custom SSH port, and press save, it doesn't actually save nor work for syncing.

[mxtm]

Jeez, I can't type nor speak English properly today, sorry

[zeapo]

Fixed in 1.2.0.21

[mxtm]

It isn't fixed on my end; will update with the exact behavior.

Thanks for the quick response & update, wow!

... I didn't mean to close this, could you reopen it? Thanks.

[mxtm]

So, I have the repo information filled in, correct username, server, repo path, etc. The resulting URL is the same I use to clone and pull on my laptop.

It saves now, but if I go to either "Synchronize repository" or "Pull from remote" and press enter for no passphrase, it throws:

Internal exception occurred
Message from jgit:
Attempt to get length of null array

After a few seconds of "Running command...".

[zeapo]

How did you get your repository on your phone? Was it by cloning using this path, or creating a new repository then adding the server information?

[mxtm]

Cloning using the path. I created the repository on the server. I was using the same repo that used to have the old connection information, however; I'll try re-cloning the repo from scratch after clearing the cache & data of the app.

[mxtm]

I'm still having this issue on the latest version from F-Droid, here is the error message I receive: https://i.imgur.com/8k8JeGC.png

(apologies for sucking at GH issues, did not mean to close & reopen...)

[rndstr]

FWIW I have that first error message Attempt to get length of null array as well in the Play Store version (1.2.0.28). I do «Clone existing», no custom port but ssh-key. The F-Droid version seems to be older than the Play Store and didn't yet find the time to build it myself

[atom-42]

There is a workaround for this issue (v1.2.0.35 F-Droid), as part of it is git related and not Android-Password-Store related.

Let's say you want to use a repo with ssh-keys.
Using linux, if you would like to clone this repo you would use this command line :
git clone username@host:repo-name
and it would be ok, but you would like to use a custom ssh port, so you would try to adapt your command line :
git clone username@host:custom-port/repo-name
and it wouldn't work, with git you have to specify the protocol in your URL if you use a custom port with ssh (and haven't set it as default port in ssh_config file). So, the correct command line to clone your repository would be :
git clone ssh://username@host:custom-port/repo-name
and only then it would be ok.

The issue is the same in Android-Password-Store, if you want to use ssh protocol and a custom port, you have to add the protocol ssh:// in the 'resulting URL' field before the username.

Worked for me ^^

A good idea would be to systematically add the protocol in the 'resulting URL' field or the command line used internally.

[hughdavenport]

It looks like the solution to this problem is to prepend ssh:// to the connection string for custom ports. For the root cause, which also makes #153 happen, it can be fixed by catching git errors and displaying to the user in a friendly way, which seems to be #219, so this bug in itself could probably just be closed.

[ti-mo]

This issue still persists when the hostname resolves to an IPv6 address.

Error occured during the pull operation, Message from jgit: ssh://git@git.example.com:42/pass.git: Connection refused

The URL magically has ssh:// prepended when a custom port is given, so all good there. 👍

[hughdavenport]

Hmm, maybe that is a bug in jgit not supporting ipv6? Does it work fine with ipv4?

[ti-mo]

@hughdavenport Actually, I can't get password-store to pull from IPv6 endpoints at all when there's a custom port involved. Tried through AAAA records, plain IPv6 addresses and addresses within square brackets, there are different errors everytime.

A quick search yields this, but perhaps there's an issue with the way password-store handles the URLs/addresses.

IPv4 works fine with plain addresses and hostnames. Can troubleshoot further if you can't reproduce.

[zeapo]

Probably our fault :)

I will try to reproduce this.

[msfjarvis]

This should be fixed after the logic was refactored in b94b52a.