Solved Scripting - How do you store your credentials and call them later?
-
This is one thing that has so many ways to do it and none of which seem like the better approach.
I have a shell script, I have to run the shell from an wheel user, but am still prompted for credentials at certain points.
How do you hash your credentials and then call them later?
-
#!/bin/sh read -s -p "Enter a wheel username: " USER read -s -p "Enter a password for wheel: " PASS # Setting (office) offname variable read -p 'What office are you in?: ' offname # Setting (computer username variable) compuser variable read -p 'Enter this computers username (SAMAccountName) IE jdoe: ' compuser # Setting the asset tag (tagnumber) variable read -p 'Enter this computers asset tag: ' tagnumber echo $PASS | sudo -S scutil --set HostName $offname$compuser && sudo -S scutil --set ComputerName $compuser$tagnumber && sudo -S scutil --set LocalHostName $offname$compuser$tagnumber
-
Currently, I don't store any credentials in any of my scripts and just manually type the creds in when asked.
This sucks however and I'm wanting to improve the process a bit.
-
@DustinB3403 said in Scripting - How do you store your credentials and call them later?:
Currently, I don't store any credentials in any of my scripts and just manually type the creds in when asked.
This sucks however and I'm wanting to improve the process a bit.
Is this for Bash scripting or Powershell or what?
-
@dafyre Bash, I'd even be okay with prompting once at execution time for a username and pass to use and then just pipe those credentials into the relevant parts.
-
@DustinB3403 said in Scripting - How do you store your credentials and call them later?:
@dafyre Bash, I'd even be okay with prompting once at execution time for a username and pass to use and then just pipe those credentials into the relevant parts.
Are you connecting to a mysql database or what?
-
@dafyre No, just running a local setup script for OSX, and there are additional locations where you need to elevate to root. I think I have figured something out, just making a few edits to a backup copy of this script and will test shortly.
-
@DustinB3403 said in Scripting - How do you store your credentials and call them later?:
@dafyre No, just running a local setup script for OSX, and there are additional locations where you need to elevate to root. I think I have figured something out, just making a few edits to a backup copy of this script and will test shortly.
I'd be interested in seeing what you come up with for that.
-
Actually this doesn't seem to be working, back to the drawing board. . .
-
Well, it accepts the credentials and prompts for it and progresses, but it doesn't auto complete the "prompt".
So it's a meh answer so far as it doesn't work
-
What I have currently is this
#!/bin/sh read -s -p "Enter a user: " USER read -s -p "Enter the password for $USER: " PASS sudo -u $USER -p $PASS <command>
As soon as it hits the actual <command> you get an onscreen prompt for credentials, which is what I'm trying to populate with these credentials at execution time.
-
@DustinB3403 said in Scripting - How do you store your credentials and call them later?:
This is one thing that has so many ways to do it and none of which seem like the better approach.
I have a shell script, I have to run the shell from an wheel user, but am still prompted for credentials at certain points.
How do you hash your credentials and then call them later?
I use the built in Windows Credential Manager on servers, or the one in Azure.
It works well with Python in Azure.
-
@Obsolesce This isn't windows.
-
@DustinB3403 said in Scripting - How do you store your credentials and call them later?:
@Obsolesce This isn't windows.
You can still store it in an encrypted file in Linux too, that only is decryptable on that system.
-
@Obsolesce said in Scripting - How do you store your credentials and call them later?:
@DustinB3403 said in Scripting - How do you store your credentials and call them later?:
@Obsolesce This isn't windows.
You can still store it in an encrypted file in Linux too, that only is decryptable on that system.
Storing the creds isn't the issue in reality, it's filling the prompt for credentials that I now need to figure out.
maybe
--expect
or something can handle that -
@DustinB3403 said in Scripting - How do you store your credentials and call them later?:
@Obsolesce said in Scripting - How do you store your credentials and call them later?:
@DustinB3403 said in Scripting - How do you store your credentials and call them later?:
@Obsolesce This isn't windows.
You can still store it in an encrypted file in Linux too, that only is decryptable on that system.
Storing the creds isn't the issue in reality, it's filling the prompt for credentials that I now need to figure out.
maybe
--expect
or something can handle thatNot sure off the top of my head. You could install PS Core and do it easier to save time lol.
-
@DustinB3403 said in Scripting - How do you store your credentials and call them later?:
What I have currently is this
#!/bin/sh read -s -p "Enter a user: " USER read -s -p "Enter the password for $USER: " PASS sudo -u $USER -p $PASS <command>
As soon as it hits the actual <command> you get an onscreen prompt for credentials, which is what I'm trying to populate with these credentials at execution time.
Are you trying to enter credentials for the SUDO command or the <command> ?
-
@dafyre for the actual <command> that's a typo I put it after and you still get prompted for credentials.
-
This is the sort of prompt, it isn't within the terminal that I get prompted.
https://vtcri.kayako.com/base/media/url/R4YZS0B19iFjV9eMoQ5WRzipOS6IVXMy
-
Use
autoexpect
to generate an expect script.autoexpect user-prompt.sh
It will create a file called
script.exp
and within that file, it will like like this:#!/usr/bin/expect -f # # This Expect script was generated by autoexpect on Tue Jul 2 10:53:53 2019 # Expect and autoexpect were both written by Don Libes, NIST. # # Note that autoexpect does not guarantee a working script. It # necessarily has to guess about certain things. Two reasons a script # might fail are: # # 1) timing - A surprising number of programs (rn, ksh, zsh, telnet, # etc.) and devices discard or ignore keystrokes that arrive "too # quickly" after prompts. If you find your new script hanging up at # one spot, try adding a short sleep just before the previous send. # Setting "force_conservative" to 1 (see below) makes Expect do this # automatically - pausing briefly before sending each character. This # pacifies every program I know of. The -c flag makes the script do # this in the first place. The -C flag allows you to define a # character to toggle this mode off and on. set force_conservative 0 ;# set to 1 to force conservative mode even if ;# script wasn't run conservatively originally if {$force_conservative} { set send_slow {1 .1} proc send {ignore arg} { sleep .1 exp_send -s -- $arg } } # # 2) differing output - Some programs produce different output each time # they run. The "date" command is an obvious example. Another is # ftp, if it produces throughput statistics at the end of a file # transfer. If this causes a problem, delete these patterns or replace # them with wildcards. An alternative is to use the -p flag (for # "prompt") which makes Expect only look for the last line of output # (i.e., the prompt). The -P flag allows you to define a character to # toggle this mode off and on. # # Read the man page for more info. # # -Don set timeout -1 spawn ./user-prompt.sh match_max 100000 expect -exact "Enter a user: " send -- "user1username\r" expect -exact "Enter the password for user1username: " send -- "user1password\r" expect eof
-
Another reference using expect.
https://likegeeks.com/expect-command/