posted February 11, 2004 09:24 PM            

My program creates an SCP command line call and then
uses SHELL to execute that call. Works great to this
point.

The SCP Host then sends back a message asking for the
client password.

This is where my plan falls apart. I can get the password
string to the console, but it won't actually send the
password string unless I physically hit the ENTER key.
I have appended a Chr$(13,10) to the password string but
that doesn't do it. I still have to manually hit the
ENTER key. I want this to run headless and unattended.

Any suggestions? I am using PBCC2.1

posted February 12, 2004 02:27 AM            

If that's the case the better way to make unattended secure
copies is to set up the 2 hosts with key verification. See http://www.astro.caltech.edu/~mbonati/WIRC/manual/DATARED/setting_up_no-password_ssh.html
for a good description on how to do this.

posted February 12, 2004 08:09 AM            

quote:

---

My program creates an SCP command line call and then
uses SHELL to execute that call. Works great to this
point... can get the password
string to the console, but it won't actually send the
password string unless I physically hit the ENTER key.

---

If SCP is looking for that password via its STDIN, instead of SHELL you might use CreateProcess with the USESTDHANDLES flag.

You can pass a handle to a disk file in which you have stored that password + CRLF.

I know there's an example of using CreateProcess with redirected input 'somewhere' on this board, but if you can't find it, you might be able to work it out from the MDSN doc.

MCM

posted February 12, 2004 12:32 PM            

>ssh ame01.jones-i.com,

and they would be able to access our server
and all data there for that client without
a password. We can't leave that door open.

Any other ideas about how to send that
password to the SCH Host from inside the
PowerBasic executiable? [note: we are
using PBCC nor PB/WIN]

Thanks.

posted February 12, 2004 02:31 PM            

quote:

---

Here is the security issue around using that approach:

---

If by "that approach" you are referring to my suggestion of trying to use SCP stdin (can't tell)...

1. Your front end program prompts user for id/password, which they validate
2. You write the uid/pw to a temp disk file. Keep open to retain handle
3. Call CreateProcess with STDHANDLE override
4. Wait on process to end
5. Close and delete the temp disk file.

The only "hole" here is while the file exists, but if you open that file for exclusive access, that hole is gone, too.

As I said before, I don't know how "scp" expects its input.. but it's easy enough to test on your end by executing 'scp' from the command line with input redirection (just use a "notepad" text file containing password + CRLF). If that works, then this CreateProcess method will work, and if you are not comfy with writing it yourself, you can always contract with someone (said he, not so subtly hinting at what he does for a living).

posted February 12, 2004 02:49 PM            

When I said "that approach" I was referring to using a
public key log-in where the remote key is appended to the
list of known key pairs at the SCP host.

I tried the redirected input from the commandline approach:

scp test.tab xyz@ace.acme.com:ghjk/special/ < C:\temp\pw.txt

It does not work. The SCP host still asks for the password.

I do not want to prompt the user for the password. I want it
compiled into the executable. I want the executable to be able
to respond to the request for password from the SCP Host, without
a person present to do anything.

I would be okay with holding the password in a disk file it is
encrypted. I am even okay with have the executable call another
program that only performs this SCP function.

Thanks for examining this problem.
-Mark

posted February 12, 2004 03:08 PM            

>ssh ame01.jones-i.com,

and they would be able to access our server
and all data there for that client without
a password. We can't leave that door open.
[QUOTE]

Here's a possible approach to the Public key problem
you've got. Generate the key pair and place the
client key in the Authorized keys of the server.

On the client side encrypt the client key. Use
your program to decrypt the key and start scp. When
scp is finished delete the decrypted key and re-encrypt.

You can pass the path to the de-encrypted key as a command
line parameter.

Not foolproof of course but then neither is passing the
password on STDIN and storing it your program. At least that
way no one can get the password from the client executable.

If you have a wrapper program which contacts the server first
you could have a server program move the authorized client key
to the Authorized key file when the wrapper client starts the
session and then remove it when the client scp session is finished.

posted February 12, 2004 05:53 PM            

Thanks for thinking about this.

I have two problems.

(1) Our security team will not allow copying the pair to
the Host. Opens too many doors.

(2) SCP will not allow the calling application to pass
the password on the command line when SCP is called.
The appplication MUST respond to the SCP Host when the
HOST asks for the password. [If I could just send a
string back to the Host I would be in great shape right
now. But for some reason putting a Chr$13,10) at the
end of the password is not the same as hitting RETURN.
It is driving me mad...]

You're right about encrypting the client password; we're
already doing that.

In order for a wrapper program to send a secure message to
the Host telling it to temporarily enable a password, we would
require that wrapper program to pass rigorous authentication.
Now we're back to the same problem.

Thanks for thinking about it!

I am open to buying 3rd party software if we need to...

-Mark

posted February 12, 2004 06:04 PM            

You'll probably have to program it yourself using their API
OR
modify the source of the Putty suite http://the.earth.li/~sgtatham/putty/latest/putty-src.zip
to suit your needs (it's free and has been well tested).

I'd go for version 2 - on the other hand the Bitvise solution will probably
give you more reuse potential.

Cheers

Florent

posted February 20, 2004 11:19 AM            

quote:

---

Originally posted by Don Dickinson:
actually, the scp program (pscp.exe) that comes with putty *has* the ability to take a password on the command line. i also tested that it returns a result code of 1 on success on 0 on failure.
--don

---

Yup:

pscp -pw mypassword myusername@myhost:hostdir/hostfile localdir/localfile

posted February 20, 2004 11:31 AM            

Also, thanks to everyone for their advice. It all helped.
-Mark

quote:

---

Originally posted by Don Dickinson:
actually, the scp program (pscp.exe) that comes with putty *has* the ability to take a password on the command line. i also tested that it returns a result code of 1 on success on 0 on failure.
--don

---