Tag Info

New answers tagged

0

On modern linux systems, the reason is that pam_unix.so imposes such a delay. As previously reported, this can be configured down to two seconds by changing FAIL_DELAY in /etc/login.defs. If you want to reduce the delay further, you have to give pam_unix.so the "nodelay" option. For example, on my system, if you trace the includes starting from ...


0

If you can run the command as root, you can force the change to be accepted. Example: # sudo passwd myusername Changing password for user myusername. New password: Retype new password: passwd: all authentication tokens updated successfully.


0

Just boot with a liveCD, mount your Fedora's drive (mount --bind /dev /sys /proc /pro/sys to your mounted Fedora's) chroot to your fedora's drive and passwd to change the password.


0

Go to boot prompt by pressing arrow key,Press 'a' key and when you see rhbquiet press space and type 1 and return to boot. It will land you to a # prompt change the pwd there.


1

FileVault (and OS X in general) does not check /etc/passwd, so a script using it as a trigger will not work. FileVault uses DirectoryServices, so any interception of what is being entered has to be through Apple's OpenDirectory implementation (see documentation on DirectoryService). How to do that is beyond me, but reading up on ...


1

Other answers have addressed the how, but I'll consider the whether. Depending on what kind of database your users are connecting to, you might already have a suitable mechanism that's already used by those client programs, in which case be sure to use them (I'm thinking of ~/.mysqlrc or ~/.pgpass). If you're giving several users the ability to access the ...


0

#!/bin/bash unset username unset password unset dbname echo -n "username:" read username echo -n "dbname:" read dbname prompt="password:" while IFS= read -p "$prompt" -r -s -n 1 char do if [[ $char == $'\0' ]] then break fi ...


8

First, as several people have already said, keeping the credentials separate from the script is essential. (In addition to increased security, it also means that you can re-use the same script for several systems with different credentials.) Second, you should consider not only the security of the credentials, but also the impact if/when those credentials ...


1

Your idea of hiding the password in an inaccessible place might be OK depending on the circumstances. If the information is separate, that means simple editing of the file, e.g. during a code review with a colleague is not going to show it. But realise anyone with access to your account can easily find such a file. I have used a subdirectory of ~/.ssh for ...


-2

I don't believe you should ever store the password. I can't think of a single good reason for that. Rather, you should store a salted hash of that password - some string which is produced reliably by some function when the original password is passed as input, but never the password.


6

First of all, if there is any way at all you can change things to avoid having to store a password inside or alongside a script in the first place, you should make every effort to do that. Jenny D's answer contains a lot of good advice to that effect. Otherwise, your idea of placing the password in a separate file with restricted permissions is pretty much ...


5

On Solaris, password constraints can be configured by editing the /etc/default/password file , eg: $ pfedit /etc/default/password ... MINDIGIT=0 ...


1

Not possible. If you have root access with some way to prevent su for user X, then you also have the reverse way to allow su for user X. So, as long as your team has sudo access to root, there is no 100% solution, because the locked user X has to simply sudo, su to you & revert his locked state. If you can not change the root password (or revoke sudo ...


0

SSL works by matching public and private keys. That is why you first must generate the key, then generate the CSR based on that key. Later, when you are using this certificate, you will find your app or service needs to know where the cert AND where the key is. You need the key to use the cert properly. In some case the key and cert can be concatenated into ...


1

Use the passwd utility. # passwd steve To remove the password: # passwd steve -d


0

I'm going to paste you the website that really helped me when I was creating my ssl certificate and it was really useful. I hope it works for you. How to create a SSL certificate


3

Start with creating a user: useradd -m -d /home/username -s /bin/bash username Create a key pair from the client which you will use to ssh from: ssh-keygen -t dsa Copy the public key /home/username/.ssh/id_dsa.pub onto the RedHat host into /home/username/.ssh/authorized_keys Set correct permissions on the files on the RedHat host: chown -R ...


1

You could use: usermod --lock <username> From the man page: Lock a user's password. This puts a '!' in front of the encrypted password, effectively disabling the password. You can't use this option with -p or -U. Note: if you wish to lock the account (not only access with a password), you should also set the EXPIRE_DATE to 1.


2

On Debian-based systems you can use mkpasswd. mkpasswd -m sha-512 Strangely, that tool is found in the whois package. sudo apt-get install whois


1

OK I re-installed again. I was able to download password tools sudo apt-get install kali-linux-pwtools


1

The first thing you should do is check if the image you used to burn the cd/made a bootable drive with is OK and if it was downloaded from the official Kali Linux website (http://kali.org). Kali has a "Verifying Your Downloaded Kali Image" section on their website, see: http://docs.kali.org/introduction/download-official-kali-linux-images#manual


8

No, the shadow file does not contain encrypted passwords, not on any Unix variant that I've seen. That would require an encryption key somewhere — where would it be? Even the original version of the crypt function was in fact a hash function. It operated by using the password as a key for a variant of DES. The output of crypt is the encryption of a block ...


2

It depends on the settings. A shadow file can still contain an encrypted (with itself and a salt) password, but it depends on the form if it is hashed or not. Your system probably makes the entry for new passwords based on a hash function, but the old format is most likely still supported. If the entry doesn't start with a $ it is assumed to be output ...


6

man 5 shadow section 'encrypted password' refers to crypt(3). If you read that manual (man 3 crypt) you will see that both legacy DES encrypted passwords as currently used hash algorithms can be used. Therefore you are right that 'encrypted password' does not fully covers what the field may contain. A better description should be 'encrypted or hashed ...


2

Identity file = private key file? From the manual, (man ssh-keygen): ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile] The -p switch changes the passphrase of a private key file with a prompt, whereas the -P switch specifies the old password on the command line. Use one of these in interactive mode depending on the encryption ...


1

In general, you don't. Most intelligent programs deliberately mask or simply do not echo a password being entered. You can always type it in plain text in a terminal window and then use cut-and-paste to enter it, but that's defeating the purpose of masking the password as it's being entered.


4

In newer (and backported into RHEL 6) versions of PAM, there is an option to pam_cracklib you want to add — enforce_for_root. This is off by default. Just add it to that line, and there you go. Of course, without a lot of other constraints (SELinux, say), root can always go around PAM and set the password another way (like, writing directly to the ...


1

try 1) single quoting, sshpass -p 'password!%' scp -P 1234 ./test.text user@mydyndns:~/test.txt 2) use other sshpass method file : sshpass -f passwd.txt ... where passwd.txt contains passwd!% environnement var sshpass -e ... where SSHPASS contains your password. 3) I assume there is a good reason for not using public/private key.


2

A password field that starts with * means the corresponding user is not allowed to login. This is generally used for system accounts, such as mysql, mail, apache, etc. However, if the entry is literally ending with :::::::, this means the corresponding user is a NIS / NIS+ account.



Top 50 recent answers are included