I'm trying to get a CI setup going and have got Mavericks server downloaded and linked with Xcode all on one machine.
Here's the set up:
Two git repos, hosted on OS X server, named CI and CISubmodule.
CISubmodule added as a submodule to CI
Every time I add bot I get a Host key verification failed error on integration. It's clear from the logs that the server is unable to clone CISubmodule due to an authentication error (I've tried SSH, HTTP, HTTPS) but I don't know why it's failing authentication.
I've set up the server so that logged in users can read and write.
I've tried everything mentioned here.
I'm guessing it's because the server is running as teamsserver and the repo is probably under my username, but I can't figure out how to give it permission to clone. Could it be that the SSH key requires a password? If so, how do I set it up so that it doesn't need a password any more?
Any guidance would be greatly appreciated.
Thanks,
Simon
I had the same case and I am not sure what happend exactly, I think the reason was I had more remote repository accesses and ssh keys pointing git-server side pointing to the same repository.
Deleting the remote repository accesses and cleaning up authorized_keys file helped.
I can confirm the CI server works with submodules, but make sure the .gitmodules file and xccheckout file point to the same repos
you may need to use passphrase-LESS keys for os x server to properly connect to 3rd party hosted git repos. it cannot connect with there is a passphrase needed.
ssh-keygen -p
it worked for us
One thing that helped me was to change my submodule URLs to use HTTPS instead of SSH.
When doing this, make sure that Xcode is actually using the new URLs. Even though I made the changes and pushed them, Xcode was caching the SSH URLs and using them. Remove all your SSH URLS from your server, then also remove them from your client under Preferences->Accounts. Then restart the server and restart Xcode, confirming that the new HTTPS URLs are being used when you create your bot.
Related
I have a set up a private remote git server (not GitHub).
I can perform all operations fine from the command line without problem. This server also works fine with IntelliJ.
From within Xcode I can PULL changes. But mysteriously I cannot push changes even though both require authentication. I am using SSH.
I've seen lots of posts about windows authentication, IIS, and other special cases. But I have not seen anything about being able to pull but not push. And I have no idea where Xcode might write any logging. At the user level it just says Authentication failed. I am using SSH (no certs).
Any advice on where to even start looking would be greatly appreciated.
Posting for posterity, but: check your ssh keys if you are using key-based auth. I was having a devil of a time trying to get Xcode to do any git ops, until I changed the ssh setup to use an RSA key. ECDSA doesn't work. Not sure about any other keys, but apple docs on setting up continuous integration with xcode always talk about RSA keys, which was my clue.
Well it seems this has been broken since Xcode 7, two years ago.
THE solution (all caps because this is the ONLY thing that works) is to put the password in the git server URL. So you can have function or security - but not both. Apparently the Xcode parsing of the git config is VERY VERY defective.
git config --edit
Use THIS exact syntax for the git server URL (assuming ssh without certificate)
url = ssh://username:passwd#server/path/to/project.git
Ugly but works.
After updating domain password, accessing git-repo is no longer possible. VS Code and Source Tree as well as Visual Studio are returning the following error message on pull, push, fetch etc..
fatal: Authentication failed
Normally a credentials pop-up should appear however this is not happening. Also the common recommendation is not working:
git config --global credential.helper wincred
The password is stored in windows credential manager and needs to be updated. Open command prompt and enter the following command to view the list of stored passwords:
rundll32.exe keymgr.dll,KRShowKeyMgr
Scroll down in the list until you spot the git-related entries. Click it and edit the correct password.
Voilà!
I agree with Jesper, Other way to do is - On windows, if you can navigate to :
Control Panel\User Accounts\Credential Manager
Under Windows Credentials\Windows Vault page on Generic Credentials, you can update the password of existing GIT record or can also add new Generic Credentials.
Updated answer for Mac users :
In case if you're here with similar issue on Mac, you can do similar thing in keychain access - by deleting the existing GIT record, & then if you pass your credentials again in git bash or any other tool a new record gets created, things should work.
Try the following:
Click Start
Type: Credential Manager
See the Windows Credential Manager shortcut and double-click it to open the application.
Once the app is open, click on the "Windows Credentials" tab.
Locate the credentials that you want removed, they will start with "git:" and might begin with "ada:"
Click on the credential entry, it will open a detail view of the entry.
Click Remove and confirm removal when prompted.
I have experience a similar issue with Windows 10 and here's how I have solved it:
From Windows Search, type Credential Manager:
Open Credential Manager, and navigate to Windows Credential Tab:
You should see an entry for git credentials in Windows Credential Manager:
Here is the root cause, this git credentials is locally cached/saved to your local computer, and since we have changed our Active Directory password, it is currently out of synch.
Click Edit, and change this to your new/changed Active Directory password (this password has to match your new/changed Active Directory password) :
Note: This is for using git with https only, not for SSH: https://docs.github.com/en/free-pro-team#latest/github/using-git/which-remote-url-should-i-use
Save, it should work (does not require terminal or machine restart).
Lastly, if you do not have access to Credentials Manager (due to admin/security policy), you can force git to prompt for password by do a git pull from the specific repo by using username based repo url, e.g.
git pull https://{yourgitusername}#{gitrepo}.git
Note that, this is repo specific so you will have to do this each repo.
Good luck.
Nothing worked for me, even uninstall git and reinstall. What worked for me was to create a Personal Access Token from your github account and use that as the password. This page will detail the procedures: https://medium.com/#ginnyfahs/github-error-authentication-failed-from-command-line-3a545bfd0ca8
I faced the same issue and none of the above mentioned solutions did work. Finally I just removed git for windows and reinstalled the same without any credential managers. This solved the authentication issue with git.
Using Git for Windows (2.30.0), with the cross platform credential manager, with the remote set as a https GitHub address, to a public repository, doing git push by itself wasn't sufficient.
Instead I had to explicitly do git push origin main (replace main with master, or whatever your branch is) to have Git for Windows load a GitHub authentication page where I could authorize the application.
Creating a personal access token, as noted in another answer, was not necessary. Windows credentials were not present in Windows Credential Manager, but were added as Generic Windows Credentials via this method.
I had the same issue when Cloning the repository via Bash/VS Code with "fatal:Authentication failed". I used SSH Key authentication instead to connect my repository following the article: [https://learn.microsoft.com/en-us/azure/devops/repos/git/use-ssh-keys-to-authenticate?view=azure-devops&tabs=current-page][1]
I didn't get any errors after with any bash commands!
Above solution works only if your machine can SSH.
Try to manually remove setting
credential.helper=wincred from
C:\Users\<YOUR LOGIN>\.gitconfig file it it's there.
For me it helped after password change in LDAP.
Command to change setting didn't helped.
Honestly, what worked for me was installing the latest version of Git (2.36.1) to the day of this comment.
Happened the same: it stoped working after I changed the AD password. But it seems to be a bug in older releases.
This was a tip that Azure DevOps gave:
The only thing which worked for me was to remove the remote and add it back. I have tried deleting the credentials and even reinstalling the git the latest version. But the suggested way to access the remotes repos from Github and Microsoft DevOps is by using a shared key.
I was having the same problem and the best solution would be to insert whenever putting " git clone https://#praat.scm.azurewebsites.net:443/.git " [Insert after http:// your username and # ] and the cloning will work.
We already had a secured VPN using OpenVPN, so we don't want to use Git with SSH to avoid double encryption.
I successfully set up Bonobo Git Server on IIS 7 on Windows 2008 RC2 and created an repository. But when I tried to clone that repository from my laptop using Git GUI, it kept asking me username and password repetitively although I gave it the correct username and password created on Bonobo Server.
When I intentionally gave it incorrect credentials, it threw an expected authentication error.
Do you have any advice for me so I can connect to Git Server? Is it due to the lack of SSH keys?
As far as I can see, Bonobo offers three different authentication mechanisms: Forms, Basic, and Windows authentication. None of these involve SSH, so no, you are not using SSH and you don’t need SSH keys to make this work. SSH is just one mechanism that is commonly used for Git servers (simply because they run on Linux machines, and SSH access is very common there).
Bonobo uses the forms authentication by default. I believe you cannot preset the login information anywhere so you don’t have to enter it over and over again. You can do that with basic authentication though by changing the remote URL to include the credentials (e.g. http://user:password#bonobo-server/project.git). Of course, this will put the credentials in clear text into the repository’s configuration file, and also send the password in clear text over the network. The VPN connection will prevent someone outside of the VPN connection reading out that password, but inside of the VPN connection it is sent as clear text, so keep that in mind.
The more secure way would be Windows authentication. It uses your Windows login to authenticate at the server, and you won’t need to store your password somewhere. To Windows, it’s the “natural” authentication system, just like SSH is to Linux.
I was successful with poke's suggestion in his comment, which is utilizing a shared folder pointing to a remote bare repository.
I've set up a Mavericks box with OS X Server and Xcode 5.01. My source code is on a git repo that I have to access via https with a username and password.
In Xcode (on the same machine), I've cloned the project, built it and run it to check that all is fine. Then I've created a bot, selected the current server and scheme, and hit "integrate now". It fails after 5 seconds. I get:
Cloning into 'https_code_saers_com_myproject'...
fatal: could not read Username for 'https://code.saers.com': Device not configured
I checked that Xcode5 could pull new commits, so it has the username and password, yet by bot does not. Also, the "Device not configured" confuses me.
Any suggestion to how I can explicitly set the Username and Password?
Cheers
Nik
This may just be confusion in terminology, but the bot itself shouldn't be connecting to your repository. OSX Server does that. Before you can create a bot, you should've had to setup your repository in Server. When you do that, you get the opportunity to set username and password for accessing the repository.
It sounds like perhaps you have XCode configured to synch with your repository, but you must separately set up Server to access it as well. See the "XCode" tab in the Server app.
you may be running into the same problem we had- it was passphrase-protected keys. xcode + server + git cannot properly use passphrases on the keys.
thus, you must use a pashphrase-less key with os x server connecting to the git repo.
ssh-keygen -p
hope it helps.
edit: you might need to enable HTTP access to the git repo with this command:
git update-server-info # If planning to serve via HTTP
I am having trouble connecting Redmine to a locally hosted subversion repository using SSL.
I suspect it's the self-signed certificate that usually triggers a warning in the SVN client and browser.
When I try to connect to the local repo through SSL in Redmine, I get a red "Revision not available" error. When I try connecting through svn://, the connection times out, and I have to restart the web server.
Connecting without SSL works without problems.
It would be nice to run subversion on SSL to make it safely accessible from the outside as well. I could run the repository through plain HTTP but would like SSL for outside communication. As far as I understand, subversion can't be run both ways at the same time.
Does anybody know what to do in such a situation? Is there a configuration setting to ignore invalid certificates somewhere?
Looking at the source all redmine does is shell out to the svn binary, see: http://www.redmine.org/projects/redmine/repository/entry/trunk/lib/redmine/scm/adapters/subversion_adapter.rb
So if you can somehow workout how to get the binary to accept your SSL certificate then you will be good.
From http://groups.google.com/group/bitten/browse_thread/thread/d18b21a703c68344?pli=1 it seems you need some manual interaction with svn to accept the cert.
So my suggestion: run svn checkout against your repo as the user running redmine and permanently accept the cert
The reason you are getting this message is because the default user under which redmine is running (www-data) calls the “svn” client to communicate with the repositories but the client replies back to it saying that the certificate is untrusted, thus the connection is closed.
Here's a step by step fix:
http://haknick.tumblr.com/post/2380507902/redmine-svn-subversion-certificate-issue-ubuntu
since you control both the client and the server, is having the client accept the server certificate's issuing authority an option?
if it isn't a permanent option, at least you'd know if it was the problem if you did it temporarily.