SVN keeps prompting me for passwords and refuses to cache my credentials - linux

Environment : Eclipse Indigo, Ubuntu 11.04, Subclipse 1.6
SVN Clients : Subclipse, RabbitVCS
I'm connecting via svn+ssh. My URL looks like :
svn+ssh://[MY NAME]#[MY DOMAIN]/[PATH]
I can connect to the repo just fine. The problem is that every time I try to communicate with the repo, it prompts me for a password. Really annoying!
I get the impression that SVN has the ability to cache passwords -- I've read that's what the ./subversion/auth folder is for. However, my ./subversion/auth folder contains four empty folders.
I've experienced this behavior with both Subclipse and RabbitVCS.
Is there any way to force SVN to cache my credentials?

You need to use Public Key Authentication with SSH:
https://help.ubuntu.com/community/SSH/OpenSSH/Keys
It will enable you to used svn over ssh without entering a password every single time, with help of a common SSH agent.
Subversion itself caches credentials only to servers using HTTP/DAV.

Maybe this may help to someone. Check whether ~/.subversion folder is owned by wrong user, so it may be read-only to user who is using it.
sudo chown -R your_username:your_group ~/.subversion

Related

GitHub Authentication using PAT

All this while I have been using username and password while pushing my changes to github. But from Aug 13 2021, github will no longer accept password based authentication and hence I have to use Personal Access Tokens. I have couple of questions regarding this:
Do I need to make any changes to my previous repos which were pushed using password?
What are the next steps that I need to do after creating PAT, if there are any? should I just use it the next time I am pushing a repo or is there more to it?
Thanks!
The change to personal access tokens doesn't affect data that's already pushed. It only affects new attempts to push, so all of your old code should be fine.
Because a personal access token is pseudorandomly generated and hard to remember, if you haven't already, you should set up a credential manager. On Linux, that's usually the libsecret credential helper. If your distro has it packaged, install it, and then the next time you're prompted for your username and password, enter your username and PAT instead. Then it will be saved for the future.
On Debian and Ubuntu, the libsecret credential helper isn't packaged, and you'll need to copy the contents of /usr/share/doc/git/contrib/credential/libsecret into a temporary directory, install the libsecret-1-dev and build-essential packages, and then run make in that directory. Then copy the git-credential-libsecret binary into someplace in PATH, such as ~/bin (if you have such configured).
Note that if you're working on a Linux system without a desktop environment, then the libsecret credential helper won't work, and you may wish to use an SSH key and SSH remotes instead.

Setting up jenkins slave on Mac OS

I'm confused about setting up Jenkins slave on Mac. Google seems to have a great answer for java web start option (https://blog.codecentric.de/en/2012/01/continuous-integration-for-ios-projects-with-jenkins-ci/), however can someone clarify steps for setting up jenkins slave on mac with ssh start option.
Currently jenkins master is on Centos. As I understood, to make a slave on Mac you should:
1. Go to Mac and create a new full-fledged sudo user for jenkins with home folder where agent itself will reside.
2. Set up node as ususal linux node in Jenkins web interface with login|pass for this user.
3. Restrict your mac build to this node.
However I'm not sure if first step is right - do i need to set up jenkins user by hand with elevated privileges, ability to log onto machine, etc. Perhaps it's possible to create a "hidden" user - if that is so, can someone help or point to good manual for this? I'm new to mac terminal, so not sure if steps all the same as linux or different.
Thank you.
Just finished setting up my Mac mini slave for ssh access. Lots of old tutorials and ones with unnecessary information. I had to reboot my mini to start over again and this time it worked.
To put it quickly (this is all through terminal/command line, no Ubuntu nothing else):
Create ssh private and public keys with ssh-keygen. In my case keys were given to me with -C "name" but no passphrase and with file names of id_rsa and id_rsa.pub. Keep private (non .pub) key to be used by Jenkins Credentials later and for testing purposes while verifying things are working for ssh connection without having to relaunch Jenkins agent, the private key should be kept in the /Users/<username>/.ssh directory and readable permission and ownership of the user of local test host if that's how I'm testing it
mkdir .ssh in remote Mac mini slave's /User/jenkins/ directory
on Mac mini make sure owner of .ssh directory and any sub directories or files are jenkins and NOT root (sudo chown ...).
make sure permissions of .ssh directory and any sub dirs or files are read and writeable (if you haven't set ownership properly, in order to change permissions you will be required to use sudo. If you are using sudo to set permissions, you haven't properly set ownership to the jenkins user)
allow remote login in the Mac mini system preferences -> Sharing -> check Remote login and allow Administrators and static IP -> Network -> TCP/IP -> DHCP with manual or completely manual
on test host/local machine (non Mac mini) terminal and command line ssh jenkins#static.ip.address.of.MacMini to make sure you can ssh into remote Mac mini with password authentication. You may get a request to okay the new host (at remote Mac mini's IP address).
then logout and in local machine use ssh-copy-id -i to copy contents of id_rsa.pub (whether its in .ssh or wherever) to authorized_keys found here.
this will automatically generate authorized_keys file in .ssh directory
make sure authorized_keys file is also of proper permission
in Jenkins manage nodes. Create a new node. Add credential and make it ssh username with private key. Username: jenkins. Private key: enter directly. String should be copied from local machine test host private key (pbcopy<~/.ssh/id_rsa) including the ==== begin and end private key ====== parts and then save.
Then on new node configuration No need for toolkit. Remote root directory: /Users/jenkins. Host: Mac mini's static IP address. Host Key verification strategy: Manually Trusted Key verification strategy. Check require manual verification of initial connection
upon first connection attempt if you don't have JDK setup and running then do so. I downloaded Java 8 Stack Exchange Development Kit and once I confirmed it was installed on Mac mini with javac-version and java-version I launched agent again and authenticated no problem.
My mistakes from reading old tutorials were:
trying to remove the need for passwords in /etc/ssh/sshd_config. This was completely unnecessary
Also, I may have not paid attention to the owner and/or screwed up permissions of .ssh, .ssh/authorized_keys & .ssh/id_rsa in remote and my local machine as well.
Initially I deleted the ===== Begin private key and ======End private key when I manually entered the private key when creating the credential in jenkins. Those should be included. The file of id_rsa should be left as is.
You do need a user on the Mac which the Jenkins master will use to ssh in. But this is exactly the same as setting up a Linux slave.
Whether the user needs elevated privileges depends on what you want Jenkins to do with the account.
You also need to log into Mac from the console using an admin user and turn on remote login in the Sharing panel of System Preferences. In the same panel you can restrict the remote login to specific users or allow all users to log in.
If I were you, I would create a normal user for Jenkins using the Users and Groups panel in System Preferences. Creating a hidden user using command line tools is possible, but it is a bit involved. If you really want to go there, you can check how postinstall script in Jenkins Mac installer creates a user named jenkins:
https://github.com/jenkinsci/packaging/blob/master/osx/scripts/postinstall-launchd-jenkins

GIT stop copying owner and group permissios

Is there any way to say to GIT to stop copying file group and owner settings? My situation is as followed:
I am developing on home server where I need to use my users permissions (not root) in order to develop in Eclipse IDE (Eclipse crying if files are in root owner and group as it cannot work with them).
Once I am done, I am using GIT to synchronize with remote server which is running on Red Hat and file/folders groups and owners are server specific. However when I will synchronize it will copy my home servers permissions as well and apache on remote server throwing errors as it cannot read files so I need to reset it myself after every commit on new/changed files.
Any thoughts how to change my workflow?
P.S: I am using Linux/Debian on home server
Check the answer here: How do you deal with file ownership in git?
You're not doing anything wrong, this is just basic git behavior. You can change the permissions locally to what they need to be on the server and do a new commit. Or you can create a script to fix all of the ownerships/permissions on the server when you do your sync.
If you are using a git push to push the changes to your server via a git repository on the server, you can create a post-receive hook to call this script.
http://git-scm.com/book/en/Customizing-Git-Git-Hooks
One other thing did occur to me. A lot of Linux distros set the default umask as 0077 or 0007. Since I'm the only one using my laptop, I changed mine to 0002 since it just makes many things easier (plus my home directory is still 700). So all files I create will be rwxrwxr-x. Changing your umask would keep you from needing to think about setting the permissions later.
I found my answer to my question after a while and though I will answer just for the record.
User/group ownership is not shared (and therefore stored) through the repository. Only numeric file permissions are transferred (e.g. 644).
The file which is updated/created will adapt user and group ownership from the current user that is running Git commands.

Change SVN password command line

How do I change the SVN password from command line?
It is the best way for me if it can be done from the command line.
There are multiple ways passwords are setup on Subversion. It depends upon the server you're using (svnserve, http, svn+ssh), and the way the administrator has set everything up.
Subversion doesn't contain a built in authentication method. Instead, it can use many different external authentication methods from the very simple to the extremely complex. Some will allow users to change their own passwords and even setup their own accounts. Others require a system administrator to do it. It all depends upon your particular setup.
On our site, we use Apache http to serve our Subversion repository (svn co http://server/src/repos). I've set it up to use our Windows Active Directory, so the user's username and password is their Windows' username and password. It means I don't have to handle users' I forgot my password requests, and passed the whole account headache to our Windows administrators.
Some sites use Apache http, but use a password file located on the Apache server itself. This is usually called htpasswd and its location is configured by the Subversion administrator. It's possible that the System administrator has a way to let the users set their own passwords, but that's not necessarily true. In this instance, you have to contact the administrator and ask them to change your password.
Some sites use svnserve (svn co svn://server/repos). The standard way this is setup is that there's a passwd file in the Subversion repository's config directory. This is located on the system that's running the server, and you have no access to it. Again, you have to contact the system administrator.
Some sites use SASL for their authentication. This can use Windows Active Directory, LDAP, or any number of authentication methods. Sometimes you can set your own password, sometimes you have to ask the administrator how it's done.
So, you're going to have to ask your Subversion administrator how to change your password. If you're lucky, there's a way to do it yourself. If not, you'll have to ask your Subversion administrator to change it.
You must edit a file under your /repo/conf/passwd using a command line editor like Vim.
There is no way to do this with Subversion command-line utilities like svnadmin.
If https is used, the password may be defined by Apache. This is what I needed to do to change password, in case it helps someone else:
# using root account
cd /etc/apache2
cat foo.passwd # the right user, foobar was found here
# copy the line for foobar, in case you want to restore it!
man htpasswd # a little refresher on what the command does
htpasswd foo.passwd foobar
# new password is prompted
cat foo.passwd # check that the line for this user actually got changed
Then do checkout with https to verify the right password got changed.
This is what I have to do:
cd /etc/httpd/conf/svn
backup current svn-auth just in case
cp svn-auth.htdigest svn-auth.htdigest«yymmDD»
htdigest svn-auth.htdigest “Subversion Repository” «user-name»
It was ask for new passwsord
htpasswd -m C:\csvn\data\conf\svn_auth_file admin
I recommend installing the Collabnet SubVersion Edge bundle, since it includes a Web tool for allowing users to change their passwords on their own.

Git Server Frustration (Gitosis, Gitolite, etc)

Please excuse the frustrating undertones as I have attempted to get this set up correctly multiple times to no avail (possibly and most likely due to my ignorance, but also likely due to the lack of thorough and concise documentation).
I am trying to set up a git server so that I can share code amongst a small team of developers. Each developer may connect from multiple client PC's. I come from MS in the past so I am a bit spoiled in regards to development toolset, but it would be awesome if I could get something similar to TFS.
When trying to set up either gitosis (I understand this is deprecated for the git community per https://serverfault.com/questions/225495/ubuntu-server-gitosis-user-naming-convention) or gitolite, it seems as though as soon as I set it up I have to be extremely careful because it seems everything is balancing on toothpicks.
My latest attempt to set up a git server included moving my public key (benny.pub) from my laptop to the server, setting everything using that public key and pulling down the config to set up a repo and permissions. I then realized I want to develop on another PC so I created a new key (benny#desktop.pub) and renamed benny.pub to benny#laptop.pub which screwed things up obviously. This is where I know I was dumb by changing the name.
My question after a long-winded description is this: how can I set up a sturdy self-hosted git server with the ability to have multiple developers log in from multiple machines while maintaining security, etc? There has to be a proven technique (gitolite describes maybe 4-5 different ways...also frustrating) to do this as I'm sure I'm not the only one trying to do this exact same thing. Maybe git isn't right for my team?
Any help is greatly appreciated!
From my experience, all you need is a SSH server with a single git account/login that you are able to connect to using one of your public keys. Install gitolite using SSH (copies gitloite from your client to the server & does the basic setup) and have your developers send you their public keys. Add these keys to the gitolite-admin repository in your ~ and push.
Why does a developer need more than one keypair in the first place, even if multiple machines are used? Such cases will neither influence how SSH handles authentication nor how gitolite handles authorization: they're still SSH keys.
If a developer has to use several keypairs (one for git, another for some other server), let them handle the complexity and advise them to create an entry in ~/.ssh/config for each keypair/server combination they use.
If a developer has a different keypair on every machine used, gitolite groups can combine several public keys:
#agross = agross-1 agross-2
A couple of pointers:
The section about git on the server on Scott Chacon's pro git book
Gitorious is FOSS
I maintain a gitosis config at work, and when a developer has multiple ssh keys, all I have to do is put all these keys in the same keydir/user.pub file.
So concatenate all your keys into keydir/benny.pub and you shoud be all set.
There are a few open source git hosting solutions with a web-based UI for creating repositories and adding users (like GitHub:FI)... though I don't know about restricting access:
Gitorious (Ruby)
InDefero (PHP)
Girocco (Perl, shell scripts)
HTH
i am using debian with every developer having an account on the server. i use ssh with private key login. Finally a developer has to use a url like ssh://username#example.com/git-repo/repo.git to checkout or in any case interact with git on repo
I think the problem is that you ssh client (windows or linux version) is not finding the key file. I had the same problem and solved this way:
In my notebook, generated the key file (rafael.nicoletti#mycorporation) in ~/.ssh folder (where ~ is home folder. windows version is %HOME% env)
I added a file name config in ~/.ssh with following content:
IdentityFile ~/.ssh/rafael.nicoletti#corporation
In every location i want to access my git servers, i just copy those files in my %HOME% folder
You can also put the some things like this in config file:
IdentityFile /d/identity.key
IdentityFile /e/identity.key
IdentityFile /f/identity.key
IdentityFile /.../identity.key
So the config will look for keys in removable medias.

Resources