"expect" question

[Red Squirrel]

I've been using this to pipe ssh passwords and it works great.

Only one issue, if something goes wrong, such as not being able to connect, it outputs the password right at stdout, or worse, right inside the log file. WTF? Thats a HUGE security issue. Is there a way to supress it from showing this anywhere?

 

[yoda291]

redirect stdout, stderr, and the logfile to /dev/null ?

 

[QuixoticOne]

You could just rebuild your local SSH to take a password from storage or whatever.
I'm sure it'd take about one line of C code changed.
Or use the dsa/rsa key which is the intended way to automate it.

You could enforce expect to wait for an explicit text password prompt before sending the password, I think that is what the "expect" in "expect" is "expecting" you to do.

 

[Red Squirrel]

Yeah I had an expect, but if something goes wrong (like not being able to connect to the host) it will then display a syntax error with the contents of the line.

Actually never even thought of rebuilding ssh... I could just add a -password= parameter or something, or make it look for a text file.

I tried the RSA key approach but two problems: 1: it still needs a passphrase, 2: if I configure my client for it, it cannot connect to any other server but THAT one. (I tried). I can leave passphrase blank but that's just as insecure as not having a password to begin with.

Think I got it working though, using log_user 0 but from what I've been reading there's also a log file, just cant find where it is to see if its going in there or not.

 

[Nothinman]

I tried the RSA key approach but two problems: 1: it still needs a passphrase, 2: if I configure my client for it, it cannot connect to any other server but THAT one. (I tried). I can leave passphrase blank but that's just as insecure as not having a password to begin with.

You're wrong on both counts. You can create a passphrase-less key pair and ssh will try the key first but will fall back to keyboard-interactive if that fails.

 

[Crusty]

Originally posted by: RedSquirrel
Yeah I had an expect, but if something goes wrong (like not being able to connect to the host) it will then display a syntax error with the contents of the line.

Actually never even thought of rebuilding ssh... I could just add a -password= parameter or something, or make it look for a text file.

I tried the RSA key approach but two problems: 1: it still needs a passphrase, 2: if I configure my client for it, it cannot connect to any other server but THAT one. (I tried). I can leave passphrase blank but that's just as insecure as not having a password to begin with.

Think I got it working though, using log_user 0 but from what I've been reading there's also a log file, just cant find where it is to see if its going in there or not.

That's because you did it the wrong way. You generate your keypair on your LOCAL machine, not on the server.

 

[Brazen]

Originally posted by: Nothinman

I tried the RSA key approach but two problems: 1: it still needs a passphrase, 2: if I configure my client for it, it cannot connect to any other server but THAT one. (I tried). I can leave passphrase blank but that's just as insecure as not having a password to begin with.

You're wrong on both counts. You can create a passphrase-less key pair and ssh will try the key first but will fall back to keyboard-interactive if that fails.

It's also going to be much more secure than any of the other options.

 

[QuixoticOne]

Just to be SUPER clear,

a) a secret key lacking a passphrase is effectively perfectly secure as long as your CLIENT machine(s) where you have that file or a copy of it stored aren't compromised to the point where someone can read your SECRET key file. The SECRET key *is* like a passphrase in the sense that it is the secret effectively unguessible proof of authentication presented by the CLIENT to the SERVER. The benefit of the public key system is that the SERVER machine NEVER EVER GETS a copy of the SECRET key, so even if the server is backdoored, they can (obviously) get any unencrypted FILES you have on that backdoored server, but even after you SSH RSA/DSA login to that server, they still won't and can't know / discover your SECRET key. Whereas if you login to a backdoored server with a PASSWORD the server will effectively be able to steal your PASSWORD identity and use it for whatever other possible purposes there may be for that PASSWORD. So in all respects a PKI KEY DSA/RSA authentication is MORE secure than a PASSWORD system. If you leave a copy of your PASSWORD or your SECRET PKI key without a key passphrase on a CLIENT machine that is compromised, well, in either case you've lost. The PKI is no LESS secure than a PASSWORD in that case. The ability to specify a passphrase for the SECRET PKI KEY is effectively a PASSWORD (phrase) for unlocking your secret (PKI) PASSWORD. But if you keep the file(s) on the clients secure, it is irrelevant if you don't have a PASSWORD for your SECRET KEY. And, yes, the SECRET KEY stays with YOU / the connecting CLIENT. It should NEVER be stored on the public / externally managed SERVER to be connected to by the CLIENT backup application.

b) EXPECT can be told to EXPECT a fixed string and then (and ONLY then) REPLY with a given string. Hence
EXPECT: "PLEASE ENTER YOUR PASSWORD?"
SEND: verysecretpassword
...if it doesn't get the EXPECT string, it won't SEND the password in reply. Thus it won't send that unless the program actually asks for a password assuming you're using the system fully / correctly in that fashion.

 

[Nothinman]

It's also going to be much more secure than any of the other options.

It's more secure than using an expect script but it's not more secure than using a proper passphrase with or without keys.

 

[QuixoticOne]

PS in case your client machine is shared use or whatever, if you run a program:
foo --password="this is secret stuff"
then anyone on the machine running:
ps -axlwww
will see joe user is running the command: 'foo --password="this is secret stuff"' -- which is why most programs don't take sensitive arguments on the command line, but rather read them from disk or environment variables or whatever.

 

[QuixoticOne]

Err.. no. I previously stated why a PKI system is MORE secure than even having a proper passphrase at least in some cases.

If you have a passphrase and send it to a server to authenticate, it is conceivable that the server will be compromised at the time you do that, and so the server side attacker then knows enough about your passphrase to potentially use it to exploit other servers or whatever where that passphrase is in use.

If a compromised server captures your PKI authentication session, it STILL doesn't know enough about your secret key to be able to forge your secret key and use it to identity forge attack OTHER servers that may be set up to authenticate based on that same SECRET key.

Originally posted by: Nothinman

It's also going to be much more secure than any of the other options.

It's more secure than using an expect script but it's not more secure than using a proper passphrase with or without keys.

 

[Nothinman]

And if your client gets compromised they now have the keys to all of the servers that you have trusting those keys.

 

[Brazen]

Originally posted by: Nothinman

It's also going to be much more secure than any of the other options.

It's more secure than using an expect script but it's not more secure than using a proper passphrase with or without keys.

I was assuming we were talking about automating ssh logins. That's hard to do with a passphrase without storing the passphrase in plaintext. But I only skimmed the thread, so maybe I misunderstood something.

 

[Red Squirrel]

I ended up going with a passphrase less key and it works now.

Only a few questions, how does one passphrase-less key differ from another passphrase-less key? Is there any security things I should look into, like can someone try to brute force "forge" a key until it works? I'd just like a more technical explaination of how this works as I will most likely be using it more now given it makes automating stuff easier.

 

[Crusty]

http://en.wikipedia.org/wiki/RSA