ssh query. command line parameters.

[Steven E. Protter]

Two machines both 11.11 64 bit rp5450

Public keys have been exchanged.

I try this command line

ssh -tv hostname command parameter1 parameter2

ssh -tv hostname "command parameter1 parameter2"

Same results with out the -tv

The result is: paramete1 and parameter2 are not passed along with the command.

The command is executed on the target system without parameters. Echo statements in the target script show $1 and $2 have no value.

I kind of need those parameters to pass through.

Suggestions on how I should change my syntax that work are an easy rabbit.

I now I can pass the parameters in a file and modify the target script to read that file and work, but I'm trying to learn something here.

regards,

SEP

[Wilfred Chau_1]

I tested on my linux/unix machine on a command line and in a posix script. Works fine for me.

You must be using perl. Try escape $.

[Sridhar Bhaskarla]

Steven,

It works exactly for me on 11.11 systems.I wrote a small script that prints $1-$4.

ssh -tv remote_host /tmp/junk.sh 1 2 3 4

--trimmed--
debug1: Sending command: /tmp/jun.sh 1 2 3 4^M
debug1: channel request 0: exec^M
debug1: fd 4 setting TCP_NODELAY^M
debug1: channel 0: open confirm rwindow 0 rmax 32768^M
1^M
2^M
3^M
4^M
debug1: channel 0: rcvd eof^M
debug1: channel 0: output open -> drain^M
debug1: channel 0: obuf empty^M
--trimmed--

Write your script junk.sh exactly like I did and try again. I don't know if it is the problem with your ssh itself.

cat /tmp/junk.sh
echo $1
echo $2
echo $3
echo $4

-Sri

[Steven E. Protter]

Interesting.

Not using perl.

I suppose leading me the right way is worth a rabbit too.

I'm going to re-run in the morning and post up the debug information. I'll also read it a bit more carefully.

I will run a quickie test on my educational D320 and see what happens.

Thanks.

[Steven E. Protter]

Just ran a test on the educational D320.

It worked just fine.

Wondering if the target script is using korn shell if it makes a difference.

I can't attach a log, because I can't capture a log.

I'm so obsessive, its amazing.

A simple test with junk.sh works, so it probably something about the target script thats broke.

I think this situation requires more analysis.

*** scratching my head and thinking.

SEP

[Jeff Schussele · Accepted solution]

Obsessive's probably a good term - compulsive probably plays a part from time to time as well.
Realistically Steven, my friend, you should consider putting that devotion more towards those little ones & not us.
Believe me, we'll survive w/o your insight from time to time.

Cheers,
Jeff

[Steven E. Protter]

You have me pegged Jeff.

I actually was playing tunes with the kiddies at the 'puter while I was figuring this out.

Obviously the script is broke.

If someone can tell me how to collect that ssh data without cutting and pasting, that would be useful.

I told a manager I could fix this on Friday. I think I'm screwed.

SEP

[Sridhar Bhaskarla]

I didn't actually understand what you meant by "capturing the ssh data".

I first made sure, ssh works without interaction. Then I ran

ssh -tv remote_host /tmp/junk.sh 1 2 3 4 > /tmp/junkssh.out 2>&1

Then I vi'ed /tmp/junkssh.out and pasted only the lines required here.

-Sri

PS: No points please.

[Steven E. Protter]

I tried out the junk script on my educational D320 in the basement. Worked great.

I tried it out from a Windows ssh client on that same box and a Linux box running essentially the same release.

Worked great.

The actual production script with the problem executes like this.

ssh -tv hostnname scriptname parm1 parm2

Yet parm1 and parm2 do not show up in write statements at the top of the target script on the target host.

As I said, I think the script is broke. Perhaps the parameters are being nailed by some script stupidness on the server trying to execute the ssh.

I created the thread, because I honestly thought the command line parameters were not being passed. Thats why I handed out a bunny to Jeff when he suggested the junk script.

I thing the script running the ssh isn't loading the variables right and I can't post it because it tells a wee bit too much about our internal server structure(we are due to our work the target of frequent threats, though no successful hacks).

So, its really in debug mode.

Shridar, I always hand out a point or two, even when Harry posts in a joke. Will you stop working on the problem if I give you points? That would be a shame.

I'll ponder the question for a while.

SEP

[Sridhar Bhaskarla]

Steven,

Unless you post your target script here, we are in a dead-lock situation as we already proved that it was not ssh that's causing the issue. I already posted my response of verifying it by running the junk.sh script. That's why I insisted on not giving the points to the next post. I am a believer of points system and I limit that to only for quickly identifying the solution that fixed the member's problem. Rest is upto the member.

-Sri

PS: No points again. Thanks.

[Steven E. Protter]

Slipped on that points assignment. Everyone that helps gets a few, though I cut down at Shridar's request.

Shridar is right, though I would not use the term deadlock. Its not ssh, or its configuration thats broken, its the script.

Consider this request on hold. If I can't fix the script, I'll get permission from the powers that be and post it.

ON HOLD......

SEP

[Steven E. Protter]

This issue is resolved.

Thanks to all for their input.

Here was the problem:

The ssh from host1 to host2 did not have the proper user environment when it got to host2.

A modification of the script on host2 to load the user environment wiped out the $1 and $2 variables. This was probably the shift command. It wasn't worth modifying the profile load, 120 users need it anyway.

So here was the fix.

p1=$1
p2=$2
# load the user profile
# modify the rest of the script to use p1 and p2 instead of $1 and $2


This brings to light good scripting practices which are to get data out of $1 and $2 at the top of a shell script.

Food for thought.

I may still be giving lousy point free itrc answers today, but at least my #2 number one priority is in the can, fixed.

SEP