Changing password via a script. Ask a question. To change a password in Linux through a Bash script, he two scripts that are most important are 'Create Users' and 'Change Passwords Shell' scripts, for the system admin which regularly uses the mail servers, as there might be multiple functionalities associated with the admin job. This tutorial describes how to change a user password in Ubuntu from the command line, or through the Ubuntu GUI. Ubuntu Change Password from Command Line. In Ubuntu and other Linux distributions you can change the password of a user account with the passwd command. To change your user account password run the passwd command without any options. The standard Unix command to change your password is: passwd The computer will prompt you for your old password, ask for a new password, and ask that you repeat your new password for verification.
I connect to 8 different unix servers from Windows, using connection type 'SSH' in putty. I use the same username/password for each server.
Currently when I need to change passwords (every 60 days), I need to open putty, select the session I want to connect to, type my current password (in the putty window that opens), type 'passwd', enter my current password, and then enter my new password.
Then I exit and repeat the process 7 times.
How can I convert this to an automated process where I simply need to supply a script/batch process with my old and new password?
3 Answers
Here is how I automated the process:
Download and install ActiveTCL Community Edition (download the 32 bit version, even if you are on 64 bit windows, as the 64 bit version does not have 'Expect' which is what you need to run the automated script)
Open the tclsh85 executable that was created by the install
Run this command 'teacup install Expect' (note, this is case sensitive. You may need to setup special http settings if you receive an error and/or are on vpn or using a proxy)
Download Putty's 'plink.exe' and either place it in the bin directory of ActiveTCL (default install directory is 'C:Tclbin') or alter your 'Path' environment variable to include the path to this executable (wherever you downloaded plink.exe). This is the command-line version of Putty which your script will use.
Anywhere on your drive, create a text file named 'servers.txt' with a list of the servers (one per line). They should all share the same password, as the script will login to all of them with the same password (that you supply), and change the password to the one you supply.
In the same directory as 'servers.txt' create a new text file called 'ChangePassword.tcl' (or whatever you want to call it, but be sure its file type is 'tcl'). Right click the file and edit in notepad (or whatever text editor you prefer) and paste this script in it.
Save the script and then launch the ChangePassword.tcl file.
Here is a picture of what it looks like when you open the ChangePassword.tcl file:
The rest should be self explanatory. Note the program does not output when your password change was successful but it will tell you when it fails. Also note, this was my first tcl script (and first time using Expect) so the script is by no means 'optimized' and could probably be improved but it gets the job done. Feel free to edit, or make suggestions/improvements.
Jacob SchoenHow To Change Password
Sounds like you want Expect, an extension of TCL that can mimic typing at a keyboard for a console application. See the examples for how to do this.
Now there is something you've written that worries me:
I connect to 8 different unix servers, using connection type 'SSH' in putty. I use the same username/password for each server.
Why aren't you using SSH keys for automating the logon?
chrisaycockchrisaycockGreat article! Just elaborating on step-3. Please note the commands to provide Proxy server information in case 'teacup install Expect' fails due to connectivity issue:
Not the answer you're looking for? Browse other questions tagged unixscriptingbatch-filesshputty or ask your own question.
Unix Change User Password
How can I hide a password in shell scripts? There are a number of scripts that are accessing database. If we open the script others also aware the username and password. So if anyone knows how to hide please let me know.
I have one way: place the password in a file and make the file as hidden and no one going to access the file (change the permissions and use the file in script while going to accessing database).
Gilles8 Answers
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 are compromised. You shouldn't have just one password for all access to the database, you should have different credentials with different levels of access. You could, for instance, have one DB user that has the ability to perform a search in the database - that user should have read-only access. Another user may have permission to insert new records, but not to delete them. A third one may have permission to delete records.
In addition to restricting the permissions for each account, you should also have restriction on where each account can be used from. For instance, the account used by your web server should not be allowed to connect from any other IP address than that of the web server. An account with full root permissions to the database should be very restricted indeed in terms of where it may connect from and should never be used other than interactively. Also consider using stored procedures in the database to restrict exactly what can be done by each account.
These restrictions need to be implemented on the DB-server side of the system, so that even if the client side is compromised, the restrictions cannot be altered from it. (And, obviously, the DB server needs to be protected with firewalls etc in addition to the DB configuration...)
In the case of a DB account that is only permitted limited read-only access, and only from a particular IP address, you might not need any further credentials than that, depending on the sensitivity of the data and the security of the host the script is being run from. One example may be a search form on your web site, which can be run with a user that is only allowed to use a stored procedure which extracts only the information that will be presented on the web page. In this case, adding a password does not really confer any extra security, since that information is already meant to be public, and the user can't access any other data that would be more sensitive.
Also make sure that the connection to the database are made using TLS, or anybody listening on the network can get your credentials.
Third, consider what kind of credentials to use. Passwords are just one form, and not the most secure. You could instead use some form of public/private key pair, or AD/PAM or the like.
Fourth, consider the conditions under which the script will be run:
If it is run interactively, then you should enter the password, or the password to the private key, or the private key, or be logged in with a valid Kerberos ticket, when you run it - in other words, the script should get its credentials directly from you at the time that you run it, instead of reading them from some file.
If it is run from a webserver, consider setting up the credentials at the time when you start the webserver. A good example here is SSL certificates - they have a public certificate and a private key, and the private key has a password. You may store the private key on the webserver, but you still need to enter the password to it when you start Apache. You could also have the credentials on some kind of hardware, such as a physical card or an HSM, that can be removed or locked once the server is started. (Of course, the downside to this method is that the server can't restart on its own if something happens. I would prefer this to the risk of having my system compromised, but your mileage may vary...)
If the script is being run from cron, this is the hard part. You don't want to have the credentials lying around anywhere on your system where someone can access them - but you do want to have them lying around so that your script can access them, right? Well, not quite right. Consider exactly what the script is doing. What permissions does it need on the database? Can it be restricted so that it doesn't matter if the wrong person connects with those permissions? Can you instead run the script directly on the DB server that nobody else has access to, instead of from the server that does have other users? If, for some reason that I can't think of, you absolutely must have the script running on an insecure server and it must be able to do something dangerous/destructive... now is a good time to re-think your architecture.
Fifth, if you value the security of your database, you should not be running these scripts on servers that other people have access to. If someone is logged in on your system, then they will have the possibility to get at your credentials. For instance, in the case of a webserver with an SSL certificate, there is at least a theoretical possibility of someone being able to gain root and access the httpd process's memory area and extract the credentials. There has been at least one exploit in recent times where this could be done over SSL, not even requiring the attacker to be logged in.
Also consider using SELinux or apparmor or whatever is available for your system to restrict which users can do what. They will make it possible for you to disallow users to even try to connect to the database, even if they do manage to gain access to the credentials.
If all this sounds like overkill to you, and you can't afford or don't have the time to do it - then, in my (arrogant and elitist) opinion, you should not be storing anything important or sensitive in your database. And if you're not storing anything important or sensitive, then where you store your credentials is also not important - in which case, why use a password at all?
Lastly, if you absolutely cannot avoid storing some kind of credentials, you could have the credentials read-only and owned by root and root could grant ownership on an exceedingly temporary basis when requested to do so by a script (because your script should not be run as root unless absolutely necessary, and connecting to a database does not make it necessary). But it's still not a good idea.
Jenny DJenny D
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 it. You can for example source that file from the main script:
You could also restrict the permissions of the main script so that only authorized persons can execute it, but it's probably better to do as you suggest and store only the password itself in a restricted file. That way you can allow inspection of the code itself (without sensitive secrets), version-control and copy around the script more easily, etc...
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 database to make specific queries using a shared account, then you probably shouldn't. Instead, make sure they have accounts on the database and that those accounts have no more permissions than they need (probably read on much of it, and very little write access). If they need to make specific queries on certain tables that they can't otherwise access, provide stored procedures with SECURTY DEFINER to allow them to do so.
If none of the above avoids you needing to store credentials, then read the other answers here.
Toby SpeightToby SpeightYour 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 such purposes, for the simple reason that ssh complains if the access rights for ~/.ssh are not restricted enough.
There are however other things you can do to prevent such glancing of username and/or passwords.
Obfuscating:If you don't want anyone to read the username or password while you edit a script you can put it in the text but not as plain text, but obfuscated. If the obfuscated version is long enough preventing its memorization by someone looking at it, it cannot be known even if the decryption method and key are in plain sight. This would of course still be trivially circumvented by someone having access to your account.
Using GPG:
Slightly better, but still not full proof against attacks by the root user on your system, is to encrypt username/password pairs in a file your gpg public and having the script retrieve the content on the file (possible prompting you for a password, if not cached/expired). I use ggp-card so that when I leave my laptop around but pull the card out, no access is possible even if the pin would still be cached. At least if I run thing 20 times in a few minutes I have to provide the pin only once.
Security seems always inversely related to convenience (setting up and using).
AnthonAnthonThere's a way to store passwords in a bash script but you have to encrypt and obfuscate the script so that no one can actually read it or run any type of debugger on it to see exactly what it is doing. To encrypt and obfuscate a bash/shell script and have it actually be executable, try copying and pasting it here:
On the above page, all you have to do is submit your script (you can submit a sample script first for your peace of mind). A zip file will be generated for you. Right click on the download link and copy the URL you're provided. Then, go to your UNIX box and perform the following steps.
Installation:
wget link-to-the-zip-file
unzip the-newly-downloaded-zip-file
cd /tmp/KingLazySHIELD
./install.sh /var/tmp/KINGLAZY/SHIELDX-(your-script-name) /home/(your-username) -force
What the above install command will do for you is:
It'll install the encrypted version of your script in the directory /var/tmp/KINGLAZY/SHIELDX-(your-script-name).
It'll place a link to this encrypted script in whichever directory you specify in replacement of /home/(your-username) - that way, it allows you to easily access the script without having to type the absolute path.
Ensures NO ONE can modify the script - Any attempts to modify the encrypted script will render it inoperable...until those attempts are stopped or removed. It can even be configured to notify you whenever someone tries to do anything with the script other than run it...i.e. hacking or modification attempts.
Ensures absolutely NO ONE can make copies of it. No one can copy your script to a secluded location and try to screw around with it to see how it works. All copies of the script must be links to the original location which you specified during install (step 4).
NOTE:
I don't believe this works for interactive scripts that prompts the user for a response. The values should be hard-coded into the script. The encryption ensures no one can actually see those values so you need not worry about that.
Another solution, without regard to security (I also think it is better to keep the credentials in another file or in a database) is to encrypt the password with gpg and insert it in the script.
I use a password-less gpg key pair that I keep in a usb. (Note: When you export this key pair don't use --armor, export them in binary format).
First encrypt your password:
That will be print out the gpg encrypted password in the standart output. Copy the whole message and add this to the script:
In this way only if the usb is mounted in the system the password can be decrypted. Of course you can also import the keys into the system (less secure, or no security at all) or you can protect the private key with password (so it can not be automated).
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.
mikeserv