SUMMARY: Odd ssh using command=

Thanks to all who responded. Darren dunham, Kevin Inscoe, JV, Brad
Morrison, Clark Crist, Chris Hoogendyk.

There were some questions/ideas i shall answer :-

    Q: Perhaps the 'awk' being used by the two invocations is different.
I would suggest using a full path for awk.
    A: Tried it. No difference but i know the awk was running on the
remote machine due to ...

    Q: The point is to disallow running anything else, from anywhere
else, or with any kind of forwarding. It's adding restrictions. But your
scheme looks like you are trying to get around the restriction that the
command= is intended to impose.

    A: This is just a demo. The script im actually going to run is going
to parse $SSH_ORIGINAL_COMMAND and exit if funny characters or commands
not in a list are tried to run. I just wanted to see what was being
passed from my calling script in case i missed anything.

    Q: Also, isn't .ssh2 and authorized_keys2 an anachronism? I don't
think current versions of Open-SSH require that distinction between ssh
and ssh2.
    A: Yeah i think they are. Its perhaps just habit but i have known in
the past authorized_keys to not work and have to be named authorized_keys2

    Q: What does /tmp/ssh_command look like after you have done that?
    A: Well /tmp/ssh_command on the destination server was showing the
awk as being passed correctly. This is why i couldnt understand why it
wasnt working. Such commands as uname -a or ls were working so why was
awk being funny.
       
    Contents of /tmp/ssh_command before i fixed the problem

/usr/bin/uname -a
/usr/bin/awk '/^\// {print $1}' /etc/novab_backup_location
/usr/bin/awk '/^\// {print $1}' /etc/novab_backup_location
awk '/^\// {print $1}' /etc/novab_backup_location
awk '/^\// {print $1}' /etc/novab_backup_location


The FIX was to just add eval $SSH_ORIGINAL_COMMAND in the remote shell
script. This now all works correctly. Im thinking that the
original_command was running on remote server but not being passed back
over the ssh pipe correctly and therefore the eval fixed this. Thats
just a guess though as im not totally up on shell interaction.

Thanks to  Crist Clark for the answer
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers