I have a shell scripte that i have to configure for updating some svn repository set up with crontab in order to backup the repository on an other machine.
The thing is one of the repository is protected with an key which is password protected.
I'd like to make the scripte automatically answering the question, and i don't know how to do this.
I already tried the "yes | svn co svn+ssh... " and it doesn't seems to be working.
Is there a way to make the scripte answering it, or simply juste stop svn from asking the password by storing it somewhere?
Thanks for your time.
That would only be possible if you have launched first an ssh-agent.
See for instance "svn + ssh without password from command line?", and this tutorial.
The first connection will ask for the passphrase and register it.
The other connections won't ask for the passphrase at all.
Related
I am a new programmer, and also still a "noob" using Debian based distributions and Linux in general. Every time I push to my GitHub repository as u know, I have to write username and password which is my GitHub token, I have the token stored in a file and I have to enter the file copy the token and use it, and it's a bit annoying, I know it's possible to store commands in variables to make shell use faster, is there some sort of way to do the same with my token? or which would be a good practice to do so?
Thanks in advance for your time.
You can cache your username/password with this command:
git config --global credential.helper 'cache --timeout=secs'
where secs (seconds) defaults to 900 (15 minutes).
I would suggest using SSH keys which you can find more information about here. When authenticating using SSH keys you don't have to type in your password manually.
A few things that would change would be that you should select the SSH option instead when you're going to clone your repository.
I believe the following command can change this configuration for repos that you've already cloned using HTTPS:
git remote set-url origin git#github.com:<username>/<repository-name>
I am creating a build script for a project using Grunt and I want to commit->tag->push to a remote server, but I do not know how to enter credentials for Bitbucket when they are asked for during the git push. The docs for grunt-git on https://www.npmjs.org/package/grunt-git do not seem to address this issue. The credentials (just a password) would be read from a config file stored elsewhere and then, ideally, given when asked for.
I was thinking perhaps I could use grunt-shell to address this, but even then I am not sure. Upon further thought, it seems that maybe I should just use grunt to do the git commit and git tag commands, then leave it to the CI server software (in this case Jenkins) to handle the credentials and pushing to remote.
So my question is really twofold:
1) Is it possible to give the credentials when they are requested in this case? if so, how?
2) Would it be a better solution (better practice/easier) to simply leave this responsibility to the CI server (Jenkins)?
Thanks.
1) Is it possible to give the credentials when they are requested in
this case? if so, how?
If you add your SSH key to Bitbucket and given that when you generated the SSH key you didn't enter a password, then you won't be prompted for any credentials when you try to push.
2) Would it be a better solution (better practice/easier) to simply
leave this responsibility to the CI server (Jenkins)?
Jenkins uses its own SSH key, and if it's passwordless it can run a build that pushes to any host in which you imported the Jenkins key without credentials.
It's usually the job of the CI server to handle this, not the build tool. But if all you need at the moment is to bypass the password on your local machine, generate a passwordless SSH key, or try something like SSH Agent.
I have a user called ec2-user and by this user I am getting connected to my EC2 instance by the help of the pem file I am able to connect to the machine,
Now I have added this user to the sudoers list by this command:
echo 'ec2-user ALL=(ALL) ALL' >> /etc/sudoers
This command executed successfully but after that when ever I want to do sudo its asking for password, when there is no password on the ec2-user.
Now, I have some of the questions:
If this is the wrong way, why Linux allows it to complete the command?
If this is right, then how to give the password?
If this I did in wrong way, how can I come back to my normal situation?
Thanks all
If this is the wrong way, why Linux allows it to complete the command?
No point in blaming Linux, It assumes that you have password set for an user.
If this is right, then how to give the password?
No, you can't provide a pasword because there is no pasword
If this I did in wrong way, how can I come back to my normal
situation?
Only way out is to boot the machine in single user mode and undo your changes. Unfortunately, you cannot boot an EC2 instnace into single user mode. Check with Amazon support whether they can help you with that.
You are pretty have run out of options. Create a new instance and then copy over your data by attaching EBS volume of this instance.
I assume you are using Amazon Linux AMI. For this AMI, by default the only account that can log in remotely using SSH is ec2-user. Also by default, password authentication is disabled to prevent brute-force password attacks. You must provide your key pair to the instance at launch, as you have already done. Please note that ec2-user has sudo privileges by default. When you do sudo, you don't have to enter any password. When you changed the sudoers file manually, you kind of changed the setting to require the password for any sudo operation by user ec2-user. Sorry that I don't know a easy way to get back to normal. I would suggest launching a new AMI instance and terminating your old one.
I am using ssh for connecting one of the systems.
I have a perl script in that system which I have to run from my machine. But the commands in remote system runs only when it is in Super user mode (I give su - to become the super user, if I am working directly on the remote system)
But if I have to run the perl script from my system ( I am using OpenSSH for this purpose), in super user mode, how should I do it?
By the way, I have placed the command $sh->system("su -") . But it asks for the password but does not proceed further. I have waited for 5 mins atleast, even then I didnt get any response after I entered the password.
Can anyone say how to deal with this situation?
You could use sudo, and allow your user to become root with no password
Read the entry titled "Can't change working directory" on Net::OpenSSH FAQ to know why it doesn't work.
Then read the other entry, "Running remote commands with sudo", to see how you can solve it.
If you don't want ssh to ask for the password, you can add your client user key in the server .ssh/authorized_keys file of the target user. Using this, ssh won't ask for a password anymore.
Every time I commit a file in svn I get the following message:
ATTENTION! Your password for authentication realm:
http://domainname.com:80 “domainname.com”
can only be stored to disk unencrypted! You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible. See the documentation for details.
You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in '/root/.subversion/servers'.
Store password unencrypted (yes/no)? no
I don't want this authentication; how can I get rid of this warning?
You are not storing the password in Subversion because you answered no to the question whether or not you want to store this password.
I take it you want to eliminate this error warning message entirely. There are two ways to handle that:
The easy, but hard way: You can specify svn --no-auth-cache each and every time you a Subversion command. It's easy to do since it requires no real action on your part. It's hard because you have to do this almost every time you use a Subversion command (especially one that touches the repository like checkout and commit).
The hard, but easy way: You can modify your user's Subversion configuration not to ask if you want to store this information. (BTW, why are you running as root? You like living life on the edge? Better off running as a user and configure sudo to allow you to do the root stuff you need. That way, you can track who's doing what, and you don't do something that could accidentally bring the server down. In fact, many Unix/Linux systems by default no longer allow a user to sign in as root. You have to do sudo). This is hard because you have to do something, but easy because once you do it, you don't have to do anything again.
You have the name of the file that you need to edit (/root/.subversion/servers). Look for the [global] section and look for the line # store-passwords = no and remove the # from the beginning of the line. You can also do the same for the # store-plaintext-passwords = no line and the # store-auth-cred = no line. While, you're at it, you can also delete the files under the auth directory which is where Subversion stores its credentials. This will completely eliminate already stored passwords. More information can be found in the on line Red Bean Subversion manual.
Now, when you do a Subversion command that touches the repository, it'll ask you for a user name and password and won't ask if you want to store them.
You copied the full warning message here. Reading it instead of just copy/pasting it would answer your question:
you can avoid future appearances of
this warning by setting the value of
the 'store-plaintext-passwords' option
to either 'yes' or 'no' in
'/root/.subversion/servers'.
The subversion client is only asking for authentication because the server requires it. To get rid of the authentication requirement, you'll have to change the server's configuration (e.g., in Apache, get rid of AuthType, AuthName, and AuthUserFile). You can use other authentication methods which do not require passwords (for example, client certificates).
If you just want to get rid of the save password unencrypted prompt, you can set store-plaintext-passwords=off (by editing ~/.subversion/config) or you can make encrypted passwords work by getting (on Unices) the GNOME keyring or KDE wallet running. On Windows, SVN should automatically use built-in NTFS encryption; on Mac OS X, the Keyring. See the Client Credentials section of the SVN Manual for further details.
You could also encrypt your home directory on Unix. Then the credentials would be encrypted as well (but of course available to any program running as you or root while you're logged in, similar to the NTFS encryption).
If you don't want SVN to store passwords at all, encrypted or not, set store-passwords=no in the SVN config file.