passforios
passforios copied to clipboard
Cannot clone repository with SSH private key
When trying to clone a git repository for the first time using SSH and authentifying with an SSH key, I get the error "Unable to extract public key from private key file: Wrong passphrase or invalid/unrecognized private key file format".
I have tried transferring the passphrase using a web server, ASCII Armored QR, and iTunes file sharing. I made sure the passphrase is correct, but it does not work at all.
This happenened after I reset the app in order to clone a new password store. For almost a year, the app worked as intended. An uninstall/reinstall did not fix the problem. The key itself is good too, as I can use it on my PC.
I got this error on both an iPhone and an iPad on iOS 12.0.0.
How you import the key doesn't matter. We keep the ASCII armored key. It is possible that the key format is not supported by the upstream library that we have been using. May I ask what is your key type? I think one possible workaround is that you generate another pair of keys.
We are trying to maintain a list of supported/unsupported keys. You may check https://github.com/mssun/passforios/wiki/Supported-Unsupported-Key-Algorithms to see some keys that are definitely supported.
EDIT: It seems like you were able to clone some of you other repositories. Are you using a new ssh key now?
I'm having this exact same issue with a freshly generated ssh key from ssh-keygen -t rsa -b 2048
and an empty password. Let me know if there's anything I can do to provide more info
iOS 12.0.0 on an iPhone 6S+ here.
I have the same issue with a new iPhone (IOS 12) #202 prevents me from using https with my gogs git server and now this even prevents me from using ssh. My old iPhone also running IOS 12 works fine, but I cloned with an older version of pass for ios and gogs almost a year ago over https. I used an rsa2048 key with and without a passphrase without success.
This is because newly generated keys with ssh-keygen -t rsa -b 2048
start with this string:
-----BEGIN OPENSSH PRIVATE KEY-----
While previously the same command generated a file that started with this string:
-----BEGIN RSA PRIVATE KEY-----
So, the new format is not supported.
@maximbaz Thank you.
I will put this in Supported Unsupported Key Algorithms. And I will add a link to this document in the key setup page.
@genigenigeni Would you please check whether using more compatible PEM format, not the newer OpenSSH format
solves your problem?
@yishilin14 I just tried generating a key in the old format using ssh-keygen -t rsa -b 2048 -m PEM
, but it won't accept the passphrase I provide it in Pass.
I wasn't able to convert an existing private key, but here is a way of generating a compliant key pair
- Get puttygen; I used the version supplied by my Linux distribution.
- Generate a new private key:
puttygen -t rsa -b 2048 -O private-openssh -o pass_for_ios.key
- Generate a matching public key:
puttygen pass_for_ios.key -C "Pass for iOS" -O public-openssh -o pass_for_ios.pub
Resolved. Thank you @hreese I followed your steps exactly and it is working now-successfully cloned into my iphone. Easy peasy lemon squeezy.
I ran into the same issue and was able resolve it by asking ssh-keygen
to generate a new pair of keys in the OpenSSL PEM format.
ssh-keygen -t rsa -b 4096 -m PEM -f ~/id_rsa
From OpenSSH v7.8 onwards, ssh-keygen
will write private keys in the OpenSSH format by default. By using -m PEM
we ensure that the key pair is in the OpenSSL PEM format, regardless of the OpenSSH version. -m PEM
can be omitted as long as the -o
flag is also omitted if OpenSSH is older than v7.8.
@brortao - I also couldn't get ssh-keygen -t rsa -b 2048 -m PEM
to work. Strange since it output the "supported" headers:
-----BEGIN RSA PRIVATE KEY-----
@loizoskounios I tried your incantation as well, which judging from a glance is the same as @brortao's recommendation except with a larger -b
size. I couldn't get this to work either.
I also tried using @hreese's puttygen
suggestion and was unsuccessful.
In all of these attempts, passforios
continually prompts for the password for my SSH key. The UI does not provide feedback about whether the password is correct or incorrect.
I've tried creating SSH keys without passwords. In these cases, passforios
still prompts for a password; I just submit an empty password -- assuming this is the recommendation.
Does anyone have any more insight into the underlying issue? Should we use 2048
or 4096
? How can we check the OpenSSH version our ssh-keygen
or puttygen
is using?
For puttygen
, I'm using:
puttygen: Release 0.71
Build platform: 64-bit Unix
Compiler: gcc 7.4.0
Source commit: abfc751c3ee7d57bf3f127a458c40bb4ca2b6996
I've also tried both @hreese (with & without passphrase) and @loizoskounios solutions but no luck. I'm getting the "Unable to extract public key from private key file: Wrong passphrase or invalid/unrecognized private key file format".
GIT REPOSITORY URL: ssh://git@IP/home/git/.password-store.git USERNAME: git
SOLVED Apparently the ”.git” in the GIT REPOSITORY URL should be omitted: GIT REPOSITORY URL: ssh://git@IP/home/git/.password-store
That, in combination with @hreese puttygen solution worked for me.
@wpcarro does your GIT REPOSITORY URL include the .git ending? Make sure it does not. Worked for me when omitting it.
I'd happily update the wiki if I had permission to do so :)
@kraem what are you using for your SSH keys if you aren't using puttygen
? I'm assuming you're using:
ssh-keygen -t rsa -b 2046 -m PEM
Also, are you using a passphrase for the key?
I tried omitting .git
in the URL and using both puttygen
and ssh-keygen
commands - both without a password. passforios
continuously prompts me for a password. If I finally hit cancel, I get the following error:
Failed to clone repository from <url> to <path>
Underlying error: GTCredentialProvider failed to provide credentials.
Just to cover more variables, I created a key with ssh-keygen
- this time with a password. Same exact error: endless loop; cancel; GTCredentialProvider failed to provide credentials
@wpcarro I got it to work using RSA 2048 key with passphrase created with puttygen
@kraem thanks. Just tested now with a password, and it's still now working.
puttygen -t rsa -b 2048 -O private-openssh -o pass_for_ios.key
puttygen pass_for_ios.key -C "Pass for iOS" -O public-openssh -o pass_for_ios.pub
...and I'm getting the same error. I'm using a private repository on GitHub, and I'm transferring the private, public keys with the following:
xclip -selection clipboard -i <pass_for_ios.pub # uploaded to GitHub
xclip -selection clipboard -i <pass_for_ios.key # emailed to iPhone
Any idea what might be going wrong?
@wpcarro Only difference I can see is that I used https://github.com/yishilin14/asc-key-to-qr-code-gif/ instead of copy-pasting with xclip. I’ll look closer when not afk :)
@kraem thanks for sharing. No luck this way either as I expected. What's interesting, however, is that I can't clone the repository locally either, which is validating.
Update
After running some local tests to reproduce the issue, I finally got this working.
For me, I needed to test the following variables:
Variables
-
.git
extension: shouldn't matter - SSH key password: shouldn't matter
-
puttygen
orssh-keygen
: shouldn't matter - Git repository URL: problematic
- Username: problematic
- SSH key size: problematic (as discussed above)
Take-aways
The URL and the Username I entered into passforios
were both problematic.
Git repository URL and Username
Bad
Git repository URL: ssh://[email protected]/wpcarro/.password-store
Username: wpcarro
Good
Git repository URL: ssh://[email protected]/wpcarro/.password-store
Username: git
In retrospective, it seems as if I should have caught this earlier on in the process. Bear in mind, however, that trying to troubleshoot six variables (listed above) made the troubleshooting quite time-consuming. I also allocated most of my time troubleshooting the puttygen
vs. ssh-keygen
, SSH password, and .git
extension variables. It wasn't until I tried to locally clone the repository that I corrected my errors.
SSH key generation
Both of these should work:
ssh-keygen -t rsa -b 2046 -m PEM -f ./secret.key
puttygen -t rsa -b 2048 -O private-openssh -o pass_for_ios.key && \
puttygen pass_for_ios.key -C "Pass for iOS" -O public-openssh -o pass_for_ios.pub
Recommendations
Thanks again for making this app. I'm quite happy to finally have it up-and-running. I intend on contributing one of these days. I'm in the middle of a trans-Atlantic relocation. Once that settles, I should have some time to contribute! With that out of the way, here are some humble recommendations.
- Better error messages? It's confusing if
passforios
continually prompts for the SSH key password. Furthermore, when you finally click Cancel, the error message mentionsGTCredential
. Perhaps we can catch these errors and suggest a few troubleshooting tips? - Support newer SSH keys or have better error messages about our lack of support for these type of keys.
- Support an alternative repository syntax?
git clone [email protected]:username/repository
@wpcarro Just added your suggestions to https://github.com/mssun/passforios/wiki/Supported-or-Unsupported-Keys . PRs are always welcomed!
The current error messages are far from enough. And after reading all issues, now I feel that they are even a bit "misleading"...
@wpcarro Interesting.
- Git reposoity url: ssh://[email protected]/home/git/.password-store
- User name: git
- SSH key: 2048 bit RSA generated with puttygen. Imported using https://github.com/yishilin14/asc-key-to-qr-code-gif
- Git repository: Bare git repository located on a VPS.
The only variable I'm changing is .git extension in the git repository url. When having the extension I enter my ssh key passphrase and I get an error: "Underlying error: fatal: '/home/git/.password-store.git' does not appear to be a git repository". When I'm not having the extension I enter my ssh key passphrase and it successfully clones the repo.
@kraem strange... I cannot speak to non-GitHub domains. It may be possible that GitHub resolves .git
and non-.git
URLs similarly.
Hey folks, I've spent countless hours trying to solve this. This image below is how the repo url should look.
Got the same issue.
Can't clone ssh://[email protected]:/home/username/pass-store
using ssh-key based auth.
Ssh key is openssh rsa -b 4096.
@infinitylx in your case the colon behind the domain might be the culprit. The Wiki points out that only a slash follows the domain.
@SimplyDanny Thanks that helped. Now I have some issues with key type... But I think someone talk about it somewhere above... So thx for answer.
@infinitylx I battled some time with this issue. The normal way I would clone my password-store repository on laptops using a git client would be something along the lines of
git clone git@myserver:relative/path/to/password-store.git
which I in passforios would translate to the clone url
ssh://git@myserver/relative/path/to/password-store.git
But after much trial and error (and unfortunately some less than helpful error messages), I found out that the url needs to be the complete, absolute path to the repository on the target server, such that if the repository is hosted in /home/git/relative/path/to/password-store.git
, the clone url in passforios needs to be:
ssh://git@myserver/home/git/relative/path/to/password-store.git
All other git clients I have worked with would infer the base path from the login shells notion of $HOME
but this is not the case here.
I think then that your url @infinitylx should be
ssh://[email protected]/home/username/pass-store
Confirming once again for all that the problem is the format of the key. The legacy pem public key format works whereas the default format of RFC4716 does not. Use the -m
option...
ssh-keygen -m PEM
@wpcarro Regarding the GTCredentialProvider failed to provide credentials
error, I got it because the server didn't have the phone's key in its authorized keys.
We have updated libgit2/libssh2/openssl and shipped a TestFlight 0.8.0 (41) with this update. This update will support ECDSA, ED25519 and more algorithms. Please help me to confirm this problem is fixed. Refer: https://github.com/mssun/passforios/issues/305#issuecomment-555885978
I used all options and still don't work. I use Debian and Github. On Debian I can clone my repo, but on iOS not.
EDIT: Ok its fine now. I downloaded public key and I should get private.
Same issue here. Cannot clone because it complains about user name mismatch, but of course they match. I followed the URL scheme in the wiki, but it seems not to work with 0.9.0
The correct format seems documented here: https://github.com/mssun/passforios/issues/336#issuecomment-559924558. Crucially, the username seems to have to come before @github.com
for instance, so it's different from a usual git ssh url and different from what the wiki says.
I just had this issue, and I think this is mainly a usability issue, there's simply too many moving parts and it's hard to determine which problem you are having. I ended up figuring out a solution by double checking everything several times.
Do you think it would help to change the UI in a way that only parts of the URL can be entered? For example:
Scheme: ssh | https
Network location: github.com
Port: (some reasonable default)
Username: git
Absolute path: /absolute/path/to/repo.git
@SimplyDanny: A combobox for selecting ssh/https as protocol might be okay, but splitting the rest of the URL up in individual pieces seems a bit tiresome to type in, especially for those users who knows what he/she is doing.
An alternative would be to allow more formats of the URL, e.g. if it was possible to just tell users "copy in the clone URL" of the repo, then most people would be able to figure out that they need to supply something like [email protected]:username/repo.git
. (but that syntax is not supported at the moment)
Another alternative, would be to detect common errors and show some better error messages, that suggests what to try and change (e.g. if the user has typed github.com:username/repo.git
rather than github.com/username/repo
.
I just revisited this while setting up a new phone.
I'm getting errors when cloning an URL which has to do DNS resolving:
:x: ssh://[email protected]:port/path/to/repo
:heavy_check_mark: ssh://[email protected]:port/path/to/repo
The DNS record is OK, tried cloing the the repo using the domain name on a laptop and it is working (which is on the same wifi as the phone so it shouldn't be a problem with resolving).
EDIT Scratch the above. I solved it and forgot to update this comment. Can't remember what it was but probably human error as per usual :)
I was getting the following error using SSH Key authentication:
Underlying Error: callback returned unsupported credentials type
Adding the username to the URL fixed the issue for me. ( ssh://git.example.com/pass-store
-> ssh://[email protected]/pass-store
).
These were my initial settings which gave the error:
- URL:
ssh://git.example.com/pass-store
- Branch Name:
master
- Username:
git
I found it confusing that the username had to be in the URL and username field. If it is not in the URL, I get the unsupported credentials type
error.
If the username is in the URL but not the Username field, I get a different error:
Cannot Save Please check the entered username and the username in the Git repository URL. They should match.
This is driving me nuts. I have successfully cloned the repo using the same ssh key on my local machine but the app always shows the same error ending in:
Underlying Error: GTCredentialProvider failed to provide credentials
The URL is simply [email protected]:~myuser/myrepo
. I have tried several variations of this like appending .git
but nothing helped.
Any ideas on how to further diagnose this error?
I am using a standard 2048 rsa key, I have also tried the old PEM format, no change to observe.
Edit: Only workaround I could find was to add a second origin to my repo and push it to github. Cloning from there works.
@infinitylx I battled some time with this issue. The normal way I would clone my password-store repository on laptops using a git client would be something along the lines of
git clone git@myserver:relative/path/to/password-store.git
which I in passforios would translate to the clone url
ssh://git@myserver/relative/path/to/password-store.git
But after much trial and error (and unfortunately some less than helpful error messages), I found out that the url needs to be the complete, absolute path to the repository on the target server, such that if the repository is hosted in
/home/git/relative/path/to/password-store.git
, the clone url in passforios needs to be:ssh://git@myserver/home/git/relative/path/to/password-store.git
All other git clients I have worked with would infer the base path from the login shells notion of
$HOME
but this is not the case here.I think then that your url @infinitylx should be
ssh://[email protected]/home/username/pass-store
Thank you. This finally solved my problems. I was able to get past the GTCredentialProvider
error when adding the username in the URL, but couldn't get past the does not appear to be a Git repository
error.
Using an absolute path finally fixed this and I was able to clone my privately hosted repository.
I was getting the following error using SSH Key authentication:
Underlying Error: callback returned unsupported credentials type
Adding the username to the URL fixed the issue for me … I found it confusing that the username had to be in the URL and username field. If it is not in the URL, I get the
unsupported credentials type
error.
I just had the same problem on Pass for iOS 0.12.0. It was hard to troubleshoot, because:
-
#526 made me think I needed to enable
HostKeyAlgorithms +ssh-rsa
andPubkeyAcceptedAlgorithms +ssh-rsa
on my OpenSSH server, but this issue seems to be fixed with the new libssh2 in 0.12.0. -
#218 made me think my ed25519 key was the problem, but that issue has also been fixed.
-
The wiki page on Supported or Unsupported Keys recommends using
ssh-keygen -m PEM
orputtygen
, but this issue also seems to be fixed in libssh2. I'd like to update the wiki, but it seems that edit access is restricted and GitHub doesn't support PRs for wikis. -
Like @svend, I expected the username to get picked up from the username field.
-
The "unsupported credentials type" error is not accurate.
Thank you for an otherwise wonderful piece of software!