How can you provide the password to ssoconfig.exe -restoresecret as parameter?
I'm trying to use the sysprep scripts from Colin Meade on TechNet
Checked on MSDN and ssoconfig -restoresecret only has <restore file> as a parameter ... no reference to "password"
Yet when I run the command, I get the prompt for a password, along with the password hint!
As described in http://msdn.microsoft.com/en-us/library/aa560589.aspx, the command does not let you restore a secret with a password as a parameter. So it doesn't seem to be viable via the command line.
I don't know what the use-case is in your case, but in general I'm not sure if this would be something you want to automate?
What you can do is automate it yourself by writing a wrapper (e.g. console application) for it. You can do so by sending keystrokes to the command line, there are various examples available here on SO.
Related
I am currently working on Swfit. For safe, the op ask me to set password for rsync.
While, as we use Swift, we just set rsync work as server with "/etc/rsync.conf" , then Swift works as the client without password.
So, my question is, if i start the rsync with "secrets file" option, which set the user:password. Then, how to set Swift with the password?
Read the Swift code about the rsync in replicator, i can't find the option to set the password.
Or, Swift doesn't support the function?
Luckly, by reading the source code, i find the way to support rsync with 'secrets file' option:
By adding the '--password-file=/your_passwd_file_path' to rsync order in this two function:
swift/common/db_replicator.py/_rsync_file() and swift/obj/replicator/rsync()
Then, restart your swift, it will work right.
In shell script I am hardcoding username and password to connect to db.
If the password field has $ followed by numeric value it is considering as the argument or parameter hence not connecting to db.
Please suggest how this can be resolved.
I cannot change the db password
Quote your password with single quotes.
For details, see your friendly manual - open a terminal and type man sh or man bash (if bash is the shell you're using).
The online Bash reference manual also has pages on quoting. (I found these with Google, literally within a second.)
Inspired by this awesome post on a Git branching model and this one on what a version bumping script actually does, I went about creating my own Git version bumping routine which resulted in a little package called bumpr.
However, I don't like the current way of handling (GitHub) HTTPS credentials. I'm using the solution stated in this post and it works great, but I don't like the fact that I need to store my credentials in plain text in this _netrc file.
So I wondered:
if one could also obfuscate console input when prompting via readline(), scan() or the like in much the same way as when using the Git shell. See code of /R/bump.r at line 454:
input <- readline(paste0("Password for 'https://",
git_user_email, "#github.com': "))
idx <- ifelse(grepl("\\D", input), input, NA)
if (is.na(idx)){
message("Empty password")
message("Exiting")
return(character())
}
git_https_password <- input
how RStudio realizes that a "Insert credentials" box pops up when pushing to a remote Git repository and how they obfuscate the password entry.
if file _netrc is something closely related to the GitHub API or if this works for HTTPS requests in general
Git has a mechanism to store, cache or prompt for credentials. Please read http://git-scm.com/docs/gitcredentials.
Within a script, you can use the git credential command to access it: http://git-scm.com/docs/git-credential
I want to copy files from local machine to remote server through SCP command. I was able to copy files through Cygwin. Now I want to achieve this thru Qt. How do I invoke 'SCP' command? If I make use of QProcess, then how will I get to know about password prompt?
As fara as I know, you will hit the same issue with scp prompting for the password whichever way you try to call the command (even if you try writing a bash script that calls scp, for instance)
Possible solution I'm aware of includes:
create a public/private key and distribute them so that you do not need to be prompted with the password. An interesting paper on the topic is here
create an expect script and invoke it with QProcess
Require your users to use public keys and your problem is solved: https://hkn.eecs.berkeley.edu/~dhsu/ssh_public_key_howto.html
scp, ssh, sftp, etc. deliberately make it hard to take a password other than directly from the user. Specifically, things like expect will not work. And if they did, they wouldn't be secure.
I have a program that is going to take a password as input and then do a shell execute to perform a "su" (switch user) command in UNIX. However, I don't know how to pass the password variable to the UNIX su command. The language I have to use for this is pretty limited (UniBasic).
Any ideas?
Well, the best way to do that would be a setuid-root binary that ask for the password then execute whatever command is needed but it requires knowledge you say not to possess. I'd advise in looking at sudo(1) instead.
You could ssh to localhost as another user to execute whatever command you want. Or, use sudo and edit /etc/sudoers such that sudo does not ask for a password. However, there could be security implications.
EDIT: Please let me know why when you vote it down. My answer may not be perfect but at least it works. I do that myself for some licensed software that can only be run under a weird user name.
You do not want to specify the password as a command-line argument. Not so much because of #unwind's answer (scripts could be made private) but because if someone runs a list of processes, you could see the command argument and hence the password in question.
The version of su I have on my Linux server does not support such an option. I checked sudo, but it doesn't either. They want to do the prompting themselves, to ensure it's done in a safe manner and (I guess) to discourage people from putting passwords verbatim in scripts and so on.
You could also look at the 'expect' utility that was designed to script complex user inputs into a programs that weren't flexible enough to receive this input from places other than stdin.