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.
Related
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.
Im using cent os 6 for my work. For educational purposes I want to add user to the cent os by only editing configuration files.I know we can easly add user by useradd command and change their password using passwd command. But I need to use exactly above mentioned way. To do this first I need to understand what are the files I have to change
By searching I found that following files are responsible for handling user
/etc/passwd
/etc/group
/etc/shadow
/etc/gshadow
What I did is first I add the user using useradd command and then study the strings that commands created in above files. And then I try to replicate it with manually editing files using VI editor. After I replicate every line of string I make a directory for my new user in /home. the I reboot the VM and try to login as manually created user. I can log in without any problems but the terminal showing bash-4.1$ instead of my username. but when I use whoami terminal prints my username correctly.
My question are
Is there any other files do I need to modify to add user successfully?
By adding user manually what are the functionalities that user lost ?
How to create MD5 hashed password for manually created user ?
I know to you this is may be little bit odd. but I need to do this exactly this way. If this question is inappropriate please let me know without down voting
thanks
Those are the essentials, obviously you'll need to create a home directory for that user with proper permissions, as well as any additional user specific resources.
You might want to also read up on the Pluggable Authentication Module or PAM. This provides increased authentication functionality to Linux beyond passwd, group, shadow files.
Also check out the GETPWNAM() system call.
=D Enjoy the Posix!
Serverfault on password hash creation below.
REF: https://unix.stackexchange.com/questions/81240/manually-generate-password-for-etc-shadow
Is there way to switch between user accounts using WinSCP?
When I am using PuTTY, I can use su command to switch users between different accounts.
For an example:
kitis#localhost$
kitis#localhost$ su abc
abc#localhost$
In the same way, when I am using WinSCP, is there a way for me to switch users while I have logged in to a server?
There is a FAQ for this question on WinSCP site:
How do I change user after login (e.g. su root)?
You need to specify the sudo command in WinSCP session settings, as custom shell (if you are using SCP) or use sudo in custom SFTP server startup command (if you are using SFTP).
Though there are some limitations, notably that you need to configure sudo not to require a password.
See the link for details.
No, it is impossible. When you want to switch user using SCP (WinSCP in your case) your need to relogin. You can't run any commands in SCP-session, just manage files; fnd SCP-protocol itself supports no mechanisms to change current users' id. You must use SSH if you want to have a possibility to change a user in a session.
If the user has sudo to another user via SSH.
The same sudo to another user works via WinSCP following the below settings.
In File Protocol select SCP, pass the hostname, username, and password/key and in advanced settings under SCP/Shell in Shell pass the value as /usr/bin/sudo -u username -i, click on ok and save the settings.
Now in Winscp, the user is logged in as the username provided in SCP/Shell.
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
I am creating a graphical installer that should run on Linux. Installing should consist of copying files to some places in /usr. Currently the installer is written in Python.
How can I escalate the privileges of my installer when I need to copy files? I looked at PolicyKit but
a) there doesn't seem to be a generic "install files" action-id for PolicyKit
b) of the action ids I can use, I don't think they are standard across distros
I also looked at PAM and I have code that uses libpam but I can't seem to do anything with it. After authenticating my user (by providing username and password) I don't have write access to /usr. I tried changing my user with os.setuid(0) after authentication but I get an error from the OS.
Also, strangely, it doesn't seem to matter what service I provide to pam_start. As long as the username and password are correct I can pass anything I want. I see I have /etc/pam.d/sudo. The below code is simplified, the password is correctly stored in a pam_conversation object and I do pass a handle object.
pam_start("my_user", "my_pass", "sudo_garbage_12345");
works just as well as
pam_start("my_user", "my_pass", "sudo");
That is, they both succeed.
As a last resort I can probably execute gksudo or kdesudo but I don't want to be tied to those programs. Requiring users to invoke my installer with sudo is a (very) last resort.
You might be better off wrapping RPM with a front end that takes the user options and invokes RPM to do the hard work. This also gives you infrastructure for managing dependencies and plays nicely with the existing package management system. If you need to run on a .deb based system (Debian or Ubuntu) you may also need to consturct a .deb and put some mechanism in the front end that works out which package management system is active.
Granting random users access to root privilege is generally viewed as bad form on Linux or Unix systems (or any multi-user system for that matter) as it is a significant security risk. However you do have the option of letting the user install it under their home directory (~/bin) if they don't have root access or sudo permissions that allow them to write to system areas. In this case you can require them to install it as root if they want to install in /usr/bin but permit them to install it under their home directory for their own use if they don't have root privileges.
For a graphical installer, stick with a graphical environment. Use gksudo or kdesudo if they are available, otherwise fail with an error dialog saying they need root. People (newbies in particular) will download your installer and double-click to launch it from their desktop, and you need a graphical way to ask them for their password. You don't want to pop open a terminal on them.
Given that, don't do sudo for them even if they are running from the terminal. Just output an error saying you need root and exit. If the user is already at the command prompt (like I most likely would be), I already know how to sudo or su myself into root if I want to do so. I promise you you will most likely ruffle some feathers if you attempt to make an experienced user root when they can do it themselves.
If you INSIST on doing a sudo yourself from within your installer, for God's sake please force a 'sudo -K' before you do to remove the previous timestamp. If you don't do this, and I have sudo'd recently, you will run your installer with me as root without my knowledge (since I don't expect that to happen). A 'sudo -K' will force a prompt that I can then decide whether I want to proceed as root or not.
The best way in this case is to use su within your program. Redirect inputs/outputs and you're good to go!