You are not logged in.
Pages: 1
Your manager is crazy... Expect is no less (or more) secure than ksh... I don't even
know what that means in the context of a script for a controlled login process like this,
anyway... Secure in what way?? Is he worried about the remote system you're
logging into sending malicious data? If so, I think you can handle that just as well
(or as hard) from an expect script as from a shell script... In fact, I'd guess expect is
far better suited to handle it well... It is explicitly designed for the task, after all, unlike
a generic shell...
I'd really try very hard to convince him expect is the way to go... But, failing that (some
people just won't listen to reason), it sounds like you'd have quite a bit of work to make
things work from just a shell script... If you need to login via password, then you
will probably need to create a local pseudo-tty somehow so that you can send it to
the local ssh, since I suspect it will only read from the tty not stdin... How to do that
without expect from just the shell, I'm not sure... You could do it from your own C
program, of course, but I'm not sure how that'd be any better than just using expect...
But, if you can use ssh auth keys to login without any password required, then you
might be able to pull it off... It'll still be ugly, though... And, I don't know if your remote
menu app is a full-blown curses interface or simple printf() and fgets() type deal...
The latter would be much easier to deal with from a simple shell script... The former
would require you handle/ignore terminal escape sequences and such... And,
somehow you need to both pipe INTO and OUT OF ssh from the shell script... I'm
not sure right offhand how to do that from a script without something that gives you
a pseudo-tty like expect... Perhaps 2 named pipes (FIFOs), one you'd ssh's stdin
from and the other its stdout to... Then, your script would read from the latter and
write to the former... That may or may not actually work as expected, though...
Basically, you're trying to use the wrong tool for the job, and it's a really bad idea...
I can't imagine how any sane person thinks such a kluge job is going to end up
being better or more secure than using the proper tool for the job... *shrug*
Offline
thanks for ur reply RobSeace. I know what you are talking about even I do have the same thought about it. Only problem there I think I have to give password in that expect script so its visible to everyone. Eventhough I have ssh authorised key to login between two servers when I use with that tuxedo account It will ask for password so it will be visible in the code.
Another method what I have tried here is i tried to edit that
get_in_tux.csh file which is needed to login to that account as he wanted.
and tried to avoid those steps like
pressing enter twice and giving options like s or 0 as I mentioned in the problem but I really dont have clue how to do it. I dint see the place where I can write the scripts to skip those steps. I can provide that script if that will be helpful.
Thank YOu
Offline
when i do
ssh servername ===> then it doesnt ask for password but
when i do ssh servername -l tuxedo_account_name
it ask for the password. Initially I thought its asking for the password of the server but in fact its password for that tuxedo account.
but when I do ssh servername only and login to that server and from there
if i do
get_in_tux.csh tuxedo_account_name
then it doesnt ask for the password it goes directly as I previously mentioned in the problem. thats why I have tried to edit that get_in_tux.csh file but I have no clue how to do it and whats happening there coz If i can skip those three manual steps
pressing ENTER twice and selecting some options like s and o i will be done.
this file contains this script
Get_IN_TUX.CSH
! /usr/local/bin/tcsh -f
setenv acct "${1}"
setenv JUL_BLUE_MASTER `ll -d ~${acct}/scripts/JULIET |awk -F/ '{print $7}'`
echo $JUL_BLUE_MASTER
##############################################################################
# Name: inside_terror.csh
# Description: Do inside terror from permitted foreign user .
# Supervisor: OFER ALT
#
# Change History
#-----------------------------------------------------------------------------
# Revision No. Date Time By
# Changes#New Features
#--------------+--------+-------------------+---------------------------------
# $Log: .login,v $
# Revision 1.1 94/05/30 15:05:04 15:05:04 olntux (olntux)
# Initial revision
#
#
##############################################################################
# set echo
if ($?JUL_PID_FILE) then
echo $$ > $JUL_PID_FILE
endif
set permited_user = `whoami`
#set permited_user = "jg3188"
setenv MASTER_CLIENT "CLIENT"
set userName = `ps -fp $$ | tail -1 | awk ' {print $1}'`
setenv HOME "`echo ~${acct}`"
if ("$1" == "-register") then
shift
if ("$MASTER_CLIENT" == "MASTER") then
if (`cat ~/.clients_list | tr ' ' '\012' | grep -c '^'"${userName}"'$'` == 0) echo -n "${userName} " >>! ~/.clients_list
exit(0)
else
echo "ERROR : tuxguns is not MASTER account"
exit(1)
endif
endif
if (("$userName" != "$permited_user") && ("$userName" != "$JUL_BLUE_MASTER")) then
echo "Sorry , your permission is not sufficient to run this ."
echo "Contact your TUXEDO administrator ."
exit(1)
endif
setenv WHERE_CSH `which csh`
cd $HOME
setenv remote "~/scripts/inside_remote"
setenv terror "~/scripts/inside_terror"
if (-e ${remote}) then
echo "Working with $remote"
$remote mq
else
echo "$remote not found trying $terror"
if (-e ${terror}) then
echo "Working with $terror"
$terror mq
else
echo "No sutable script found"
endif
endif
Offline
yeah you are right but I have copied that authorized_keys from local server to the .ssh inside that tuxedo_account on the remote server and its still not working. Actually there was no .ssh inside that i have created and copied into that. I think it wont work inside that otherwise It should work after I have copied inisde that
Offline
Like I said before: check the permissions on the ".ssh" dir and all files under it...
The sshd server can be VERY anal about correct permissions, and will simply ignore
files it thinks have too liberal permissions set... Look in the syslog on the server, and
you'll likely find it complaining about the permissions, or at least it should tell you why
it's not letting you use the auth key and forcing password auth instead... Also, you
might try to do what I suggested and try "ssh -v" to see if that gives any hint as to why
the auth key isn't accepted...
Offline
I assume you mean ksh co-processes as started by "|&"? Yeah, if your script is a
ksh script, then sure that might work similarly to the FIFO approach I also mentioned,
without the need to create your own named pipes... But, I still don't know how well
that'll work with ssh, either... *shrug* If you're using ksh, give it a try, I guess...
But, I still think you need to beat some sense into whoever forbid the use of the
proper tool for the job: expect... They're not going to end up with anything more
"secure" by kluging up a shell script to accomplish the same job in a far more
round-about and non-intuitive manner...
Offline
Pages: 1