Now within an ideal world, and yes, believe it or not,
there is an ideal world, we wouldn't want to put a
user password on the command line.
So we can prompt for it during script execution.
The read command is what we need to use and when we look at it here.
okay we've got a few options, but if we go through and take a look at this,
we're using the read command.
The ‑s is silent so don't echo the password to the screen,
so if somebody is shoulder surfing,
then they're going to be able to see the password as you type it.
‑P, we can put in our own prompt message.
It's nice at the end of the prompt message that we
do have a clear and open space, so you could see after $1,
I've got a colon and then we can go through and specify a space so that gives
a little bit of tidy space for the user to enter their password without it
being pushed right up against the prompt message.
The last thing that we've got there is the USER_PASSWORD,
so this is going to be the variable that we use,
USER_PASSWORD.
If we don't supply a variable name,
then the default variable of $REPLY will be where it's going to be stored.
When we're actually setting our password,
we can go through and use the passwd command.
The advantage that we have in RHEL 8 is that we have the option
‑‑stdin so we can read the password from standard input.
But if you're using another distribution such as an Ubuntu,
they don't have that option available so we would
have to use the chpasswd command.
The advantage of the chpasswd command is it can be used on pretty much
any Linux distribution because the chpasswd command just takes a
username and password as a colon separated list.
Now, of course, we need to see this working.
So we're going to move out to our command line,
and first of all,
we're going to be taking a look at the read command to
collect data during the script execution.
And you know what we're going to do first, don't you?
What is that, go and edit our file. Though,
I could go through and use my up arrow key like this,
but isn't that laborious and isn't that what we're trying to stop? Now, I'm
using vim and pretty much I know that the last command then that would have
started with vim would have been editing my file.
So I just use !v.
Obviously, if you're using Nano,
you'd use exclamation mark and n, hit the Enter key and,
of course, then it reruns the last command,
which was vim and then the name of my file.
So again,
another shortcut seeing how we can use it. If I go through an O to insert
a new and empty line after my current line, we can then go through and
start looking at populating our passwords.
So read ‑s for silent input, ‑p so we can have our prompt and we can say
Enter a password for the new user and that's going to be $1. Now we can put a
colon after that and then a space and then close off our quotes. Again, the
idea is that space a little bit within your ordinary prompt ps 1, we want to
make sure then that we differentiate between the prompt message and what
you're typing. Now if I don't put a variable name in, the variable where the
answer is going to be stored is going to be in $reply, but if we go through
and put in our own name, the idea is then obviously this becomes more
descriptive of what's going to be stored in our variable. Now, of course, I'm
in vim, so to save and exit, I can hit the big Esc key.
With that done,
it should give me the prompt in the bottom corner when I type
colon and then I can use X to save and exit.
We've saved our changes and we're ready to execute our script. Now if
I go through and execute it with a user account that doesn't exist.
Fred, I don't believe exists on my system, and look at this, we're
being prompted for the password.
As I start typing the password, the ‑s option then hides the password.
Now I can just hit Enter twice to get my prompt back normally,
but we will then have entered the password.
And of course,
we're not creating our user, but the whole idea is not to
put the password on the command line.
If I used it as the second argument, now we could use that, and of course I
am still prompting, we haven't changed that, but we could see from the
command line history perspective, that password is now compromised because
it's stored in my command line history.
So there you go. We've progressed, but we still got a little way to go.