When I try to encrypt the password by using the following command on my linux machine:
slappasswd -h {CRYPT}
I am prompted for a new password:
Re-enter the new password :
After typing this I encounter the following error:
Password generation failed for scheme {CRYPT}: scheme not recognized.
Why am I getting this error? I am using the OpenLDAP.
this might be caused by your shell (tcsh?) treating the {} characters special. does
slappasswd -h '{CRYPT}'
work?
also, your openldap must be built with crypt support ($LDAP_SRC/configure --enable-crypt):
ldd /usr/sbin/slappasswd | grep libcrypt
(adapt the path to slappasswd as necessary) should output something.
it could be simply that your version of openLDAP does not support the use of the CRYPT encryption scheme.
you can instead use, for instance, SSHA:
slappasswd -h {SSHA}
i had the same problem, using LDAP 2.4.33 on CentOS 6.3.
Related
I am unable to apply changes using ldapmodify for the first time after installing openldap on my rhel7 server.
I have installed openldap from the scratch. Now i want to modify the olcDatabase={2}hdb.ldif to put my own olcSuffix,olcRootDN and olcRootPW.
I have generated the encrypted password with ldappasswd and put that along with other two parameters to .ldif file.
Now when, i try to apply these changes to my ldap setup using following command
ldapmodify -Y EXTERNAL -H ldapi:/// -f db.ldif
i get the error as
ldap_sasl_interactive_bind_s: Local error (-2)
further if i wish to use -D to bind with the default user -D "cn=Manager,dc=my-domain,dc=com" it needs a password. i do not know what username password combination i should use to run my first ever ldapmodify on this newly installed openldap.
Your help is much appreciated.
Best regards,
Amit Joshi
You're hitting an OpenLDAP bug (see ITS#8998).
The solution is to either
unset option SASL_NOCANON in ldap.conf or
specify the full path in the LDAPI URI (with URL-quoting of slashes).
The first option might be easier but might affect binding with SASL/GSSAPI (Kerberos).
i have installed latest version of Artifactory Pro (5.8.3) on Centos7. The default admin credentials are admin/password. i want to change the password through command-line but unable to do so.
Does any one has any inputs how to do this?
Following troubleshootings i tried:
jfrog rt c rt-server-1 --url=http://domain/artifactory --user=admin --password=password ...
nothing happens , when i try to use a new password i get 401: unauthorize error
jfrog guide tells to generate security.xml and add the hash code of the new password but security.xml does not get generated even after following all their steps.
also tried to use curl commands but no use.
If any one has gone through similar issue please share your findings. let me know if you need more info.know on case
JFrog CLI currently does not support changing of a user's password. the CLI config method you were using simply lets you configure your server and credentials to be used by other CLI command later.
What you can do is use a simple curl command to invoke the change password API as described here.
specifically, in your example changing the Admin's password to "NewPassword" will be something like:
curl -X POST -u admin:password -H "Content-type: application/json" -d '{ "userName" : "admin", "oldPassword" : "password", "newPassword1" : "NewPassword", "newPassword2" : "NewPassword" }' http://yourartifactory:8081/artifactory/api/security/users/authorization/changePassword
I am currently writing a batch script to automate signing and encrypting files, on GnuPG version 2.0.30.
Can someone explain why the following will not work on my Windows machine:
echo "passphrase"| gpg2 --batch --yes --always-trust --passphrase-fd 0 -es -r "Public key for encryption" "Path of file to encrypt"
To my knowledge, this should be piping the output of echo (my passphrase) as the input of --passphrase-fd 0 (0 operating on STDIN handle of course). I can't seem to get this to work, and wasn't sure if it was my code, or if it's just an issue running this on Windows.
Whenever I execute this command, I get
"no default secret key: Bad passphrase"
"sign+encrypt failed: Bad passphrase"
As a workaround, I was able to use redirection operater < and passed the filepath to my passphrase, still using the STDIN handle (0):
gpg2 --batch --yes --always-trust --passphrase-fd 0 -es -r "Public key for encryption" "Path of file to encrypt" < "Filepath to passphrase"
I realize it's bad practice to store a passphrase in a local file, and may consider removing the signature altogether, but for my own sake, I want to better understand why this won't work using piping (on Windows).
Thanks!
I almost been stuck a day on the following issue,
I installed LDAP using: apt-get install slapd
and use the following configuration:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
allow bind_v2
loglevel 0
moduleload back_sbdb.la
database bdb
suffix "dc=test,dc=nl"
rootdn "cn=Directory Manager,dc=test,dc=nl"
rootpw test
directory /var/lib/ldap
index objectClass eq
index userPassword eq,pres
index givenName,mail,mobile,sn,title,cn,description eq,sub,pres
index displayName eq,sub,pres
index postalAddress,facsimileTelephoneNumber pres
access to *
by self write
by * read
and I then try to bind using
ldapsearch -D cn=Directory Manager,dc=test,dc=nl -w test
but I still recieve the error ldap_bind: Invalid Credentials (49)
Anyone has any idea or clues what this could be?
Thanks in forward
Try it using quotes like;
ldapsearch -D "cn=Directory Manager,dc=test,dc=nl" -w test
Space character in Directory Manager may cause the problem.
Edit: Also, are you sure you don't need -h -p parameters?
-h The host name of the directory server
-p The port number of the directory server
Edit2: Just figured out what is wrong. You are using rootpw unencrypted in your slapd config file. You should use an encrypted password created by slappasswd tools output. This may cause problems under special circumstances.
Check this link for details: http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-ldap-quickstart.html
A few things you could try:
Turn on more verbose logging (loglevel 255), and see if anything shows up in the log file.
Verify that the server really is reading the configuration file you think by checking the access time on the slapd.conf file (ls -lu slapd.conf)
Try binding using an invalid dn (ldapsearch -D cn=no-such-user -w test) and see if the error message changes (if so, that confirms that the problem is with the password, not the dn).
Try man ldapsearch.
I'm not really sure on debian/ubuntu, but in FreeBSD you need to add a -x to use simple authentication instead of SASL. I think this might be your issue?
Also, you could use -W instead of passing the password plain text on the commmand line.
I set a passphrase when creating a new SSH key on my laptop. But, as I realise now, this is quite painful when you are trying to commit (Git and SVN) to a remote location over SSH many times in an hour.
One way I can think of is, delete my SSH keys and create new. Is there a way to remove the passphrase, while still keeping the same keys?
Short answer:
$ ssh-keygen -p
This will then prompt you to enter the keyfile location, the old passphrase, and the new passphrase (which can be left blank to have no passphrase).
If you would like to do it all on one line without prompts do:
$ ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]
Important: Beware that when executing commands they will typically be logged in your ~/.bash_history file (or similar) in plain text including all arguments provided (i.e. the passphrases in this case). It is, therefore, is recommended that you use the first option unless you have a specific reason to do otherwise.
Notice though that you can still use -f keyfile without having to specify -P nor -N, and that the keyfile defaults to ~/.ssh/id_rsa, so in many cases, it's not even needed.
You might want to consider using ssh-agent, which can cache the passphrase for a time. The latest versions of gpg-agent also support the protocol that is used by ssh-agent.
$ ssh-keygen -p worked for me
Opened git bash. Pasted : $ ssh-keygen -p
Hit enter for default location.
Enter old passphrase
Enter new passphrase - BLANK
Confirm new passphrase - BLANK
BOOM the pain of entering passphrase for git push was gone.
Thanks!
You might want to add the following to your .bash_profile (or equivalent), which starts ssh-agent on login.
if [ -f ~/.agent.env ] ; then
. ~/.agent.env > /dev/null
if ! kill -0 $SSH_AGENT_PID > /dev/null 2>&1; then
echo "Stale agent file found. Spawning new agent… "
eval `ssh-agent | tee ~/.agent.env`
ssh-add
fi
else
echo "Starting ssh-agent"
eval `ssh-agent | tee ~/.agent.env`
ssh-add
fi
On some Linux distros (Ubuntu, Debian) you can use:
ssh-copy-id -i ~/.ssh/id_dsa.pub username#host
This will copy the generated id to a remote machine and add it to the remote keychain.
You can read more here and here.
To change or remove the passphrase, I often find it simplest to pass in only the p and f flags, then let the system prompt me to supply the passphrases:
ssh-keygen -p -f <name-of-private-key>
For instance:
ssh-keygen -p -f id_rsa
Enter an empty password if you want to remove the passphrase.
A sample run to remove or change a password looks something like this:
ssh-keygen -p -f id_rsa
Enter old passphrase:
Key has comment 'bcuser#pl1909'
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.
When adding a passphrase to a key that has no passphrase, the run looks something like this:
ssh-keygen -p -f id_rsa
Key has comment 'charlie#elf-path'
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.
On the Mac you can store the passphrase for your private ssh key in your Keychain, which makes the use of it transparent. If you're logged in, it is available, when you are logged out your root user cannot use it. Removing the passphrase is a bad idea because anyone with the file can use it.
ssh-keygen -K
Add this to ~/.ssh/config
UseKeychain yes
On windows, you can use PuttyGen to load the private key file, remove the passphrase and then overwrite the existing private key file.
In windows for me it kept saying
"id_ed25135: No such file or directory" upon entering above commands. So I went to the folder, copied the path within folder explorer and added "\id_ed25135" at the end.
This is what I ended up typing and worked:
ssh-keygen -p -f C:\Users\john\.ssh\id_ed25135
This worked. Because for some reason, in Cmder the default path was something like this C:\Users\capit/.ssh/id_ed25135 (some were backslashes: "\" and some were forward slashes: "/")
If you have set a passphrase before and is using mac, use the keychain instead, you'll need to enter your passpharase for the last time and that's it
ssh-add --apple-use-keychain ~/.ssh/id_rsa
Enter passphrase for /Users/{{user_name}}/.ssh/id_rsa:
Identity added: /Users/{{user_name}}/.ssh/id_rsa(/Users/{{user_name}}/.ssh/id_rsa)
If you are using Mac
Go to .ssh folder
update config file by adding "UseKeychain yes"