ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I am not sure if that Subject really explains it, basically I have a script that executes a CLI java-applet that requires a passphrase from the user. I can easily execute this by issuing the -p argument followed by the passphrase however that shows up on possible logs or at least on the results of the ' ps ' command. If you do not supply this -p argument it provides a new line with the echo " Enter Passphrase: " and asks for input.
My question is how can I provide a result/input for the Passphrase request and is it still possible to throw this application in the background with the ' & ' following the command?
I have seen a few examples that show a /bin/expect that expects a result and sends a command however I would like to refrain from any extra dependencies.
Note that here you type the actual password instead of "password". This is a common way of passing passwords but has a couple of downsides:
1) You have to store the password in your script so anyone who can read the script can find out what the password is.
2) If there is a timing issue (e.g. the "password:" prompt doesn't appear before you pass in the password) then it fails. You can try adding a sleep statement before the password.
The expect command you don't want to use gets around the latter because you can tell it to explicitly wait until it sees the "password:" prompt before it tries to pass in the password.
This does seem to work, however I have ran into a few problems with this solution unfortunately.
One being the fact that it does not seem to allow variables to be inserted it takes it as a string itself, is there some sort of a break-command or way to issue the multi-line insert with variables?.
The other being that it doesn't appear there's an easy way to push the process into the background while still pass this information to it.
The reason for refraining from adding any extra dependencies is due to the fact that this will be a widely distributed script for ease of obtaining an SSL Certificate and connecting to an SSL-VPN connection. I imagine a more power language can handle all of this such as Perl but I figured a light-weight script would be easier and smaller to pass to a wide variety of boxes.
That's the problem, as described in the first post if I do include this -p argument if someone views the running processes they can view this persons passphrase in plain-text which is the problem itself.
I am not sure what you're exactly indicating is poor-practice, I assume the Multi-Line <<EOF method of passing the information. If this is not correct, I am curious what is poor-practice so I can change this to a better method.
I am not familiar with this ' isatty ' however I will try to look into that to see what you're describing.
He is saying it is poor practice for the downside reasons I'd indicated. He is saying it would be best if the utility you're using had a way to do automated logins (e.g. something like the way ssh trusts work) so that you're not ever exposing the password at all.
Given the issue with the tty it seems you're going to end up having to use expect.