Hi All,
I am facing the below mentioned error, while executing unix script from windows through WinSCP.exe.
I am using the below command, i am getting the below mentioned error in the production, but in the test environment, i can able to execute the script, kindly help
C:\Gop\WinSCP\WinSCP.exe /console emerg1:Vm41L000@10.20.210.240 /command "call /home/emerg1/test.sh"
Searching for host...
Connecting to host...
Authenticating...
Using username "emerg1".
Authenticating with pre-entered password.
Authenticated.
Starting the session...
Reading remote directory...
Session started.
Active session: [1] emerg1@10.20.210.240
Searching for host...
Connecting to host...
Authenticating...
Using username "emerg1".
Authenticating with pre-entered password.
Authenticated.
Starting the session...
Connection has been unexpectedly closed. Server sent command exit status 255.
Error skipping startup message. Your shell is probably incompatible with the application (BASH is recommended).
winscp>
Thanks
Gopal
Page 1 of 1
Error while executing unix script from windows thro WinSCP Error while executing unix script from windows thro WinSCP
#2
Posted 18 November 2008 - 03:39 AM
hey there,
do your test and this environment both have the same setup for the user you're connecting as? The error seems to indicate that the default shell for the user on the machine you're attempting to run the script on is incompatible. That may or may not be the case, but I would look at the default setup for the user on your dev box and on this box and see what's different, then change (if possible) the user attribute on the non-working box to match the dev setup and see if it works.
If you don't see anything, and it's okay, can you login to the good box and the bad box (via SSH) and run either "set" or "env" and post the output for both. If the winscp error message is close to correct, the answer might be in there.
Best wishes,
Mike
do your test and this environment both have the same setup for the user you're connecting as? The error seems to indicate that the default shell for the user on the machine you're attempting to run the script on is incompatible. That may or may not be the case, but I would look at the default setup for the user on your dev box and on this box and see what's different, then change (if possible) the user attribute on the non-working box to match the dev setup and see if it works.
If you don't see anything, and it's okay, can you login to the good box and the bad box (via SSH) and run either "set" or "env" and post the output for both. If the winscp error message is close to correct, the answer might be in there.
Best wishes,
Mike
The greatest viral marketing idea of all time, get your copy of this Free Report now!
----
Linux Tips, Trick and Advice -- The Linux and Unix Menagerie
----
Linux Tips, Trick and Advice -- The Linux and Unix Menagerie
#3
Posted 21 November 2008 - 09:38 PM
eggi, on Nov 18 2008, 03:39 AM, said:
hey there,
do your test and this environment both have the same setup for the user you're connecting as? The error seems to indicate that the default shell for the user on the machine you're attempting to run the script on is incompatible. That may or may not be the case, but I would look at the default setup for the user on your dev box and on this box and see what's different, then change (if possible) the user attribute on the non-working box to match the dev setup and see if it works.
If you don't see anything, and it's okay, can you login to the good box and the bad box (via SSH) and run either "set" or "env" and post the output for both. If the winscp error message is close to correct, the answer might be in there.
Best wishes,
Mike
do your test and this environment both have the same setup for the user you're connecting as? The error seems to indicate that the default shell for the user on the machine you're attempting to run the script on is incompatible. That may or may not be the case, but I would look at the default setup for the user on your dev box and on this box and see what's different, then change (if possible) the user attribute on the non-working box to match the dev setup and see if it works.
If you don't see anything, and it's okay, can you login to the good box and the bad box (via SSH) and run either "set" or "env" and post the output for both. If the winscp error message is close to correct, the answer might be in there.
Best wishes,
Mike
Hi Mike,
Your reply seems to be positve, here is the env and set variables in test and production.
test
===
$ env
_=/usr/bin/env
CAIHPAD10=/usr/gems/CA/agents/data/hpa
LANG=en_US
LOGIN=oatbcrs
IMQCONFIGCL=/etc/IMNSearch/dbcshelp
PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:/home/oatbcrs/bin:/usr/bin/X11:/sbin:/usr/oracle/1020/bin:
DMS_PATH=/opt/CA/dmscript
LC__FASTMSG=true
IMQCONFIGSRV=/etc/IMNSearch
CGI_DIRECTORY=/var/docsearch/cgi-bin
LOGNAME=oatbcrs
MAIL=/usr/spool/mail/oatbcrs
ORACLE_SID=BCRSTST1
LOCPATH=/usr/lib/nls/loc
DOCUMENT_SERVER_MACHINE_NAME=localhost
USER=oatbcrs
AUTHSTATE=compat
DEFAULT_BROWSER=netscape
SHELL=/usr/bin/ksh
ODMDIR=/etc/objrepos
TMOUT=900
DOCUMENT_SERVER_PORT=49213
HOME=/home/oatbcrs
TERM=vt100
MAILMSG=[YOU HAVE NEW MAIL]
ORACLE_HOME=/usr/oracle/1020
PWD=/home/oatbcrs
DOCUMENT_DIRECTORY=/usr/docsearch/html
TZ=HKT+08:00:00
UMASK=022
A__z=! LOGNAME="*TMOUT
NLSPATH=/usr/lib/nls/msg/%L/%N:/usr/lib/nls/msg/%L/%N.cat
$
$
$ set
AUTHSTATE=compat
CAIHPAD10=/usr/gems/CA/agents/data/hpa
CGI_DIRECTORY=/var/docsearch/cgi-bin
DEFAULT_BROWSER=netscape
DMS_PATH=/opt/CA/dmscript
DOCUMENT_DIRECTORY=/usr/docsearch/html
DOCUMENT_SERVER_MACHINE_NAME=localhost
DOCUMENT_SERVER_PORT=49213
ERRNO=0
FCEDIT=/usr/bin/ed
HOME=/home/oatbcrs
IFS='
'
IMQCONFIGCL=/etc/IMNSearch/dbcshelp
IMQCONFIGSRV=/etc/IMNSearch
LANG=en_US
LC__FASTMSG=true
LINENO=1
LOCPATH=/usr/lib/nls/loc
LOGIN=oatbcrs
LOGNAME=oatbcrs
MAIL=/usr/spool/mail/oatbcrs
MAILCHECK=600
MAILMSG='[YOU HAVE NEW MAIL]'
NLSPATH=/usr/lib/nls/msg/%L/%N:/usr/lib/nls/msg/%L/%N.cat
ODMDIR=/etc/objrepos
OPTIND=1
ORACLE_HOME=/usr/oracle/1020
ORACLE_SID=BCRSTST1
PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:/home/oatbcrs/bin:/usr/bin/X11:/sbin:/usr/oracle/1020/bin:
PPID=786684
PS1='$ '
PS2='> '
PS3='#? '
PS4='+ '
PWD=/home/oatbcrs
RANDOM=11516
SECONDS=8
SHELL=/usr/bin/ksh
TERM=vt100
TERM_DEFAULT=lft
TMOUT=900
TZ=HKT+08:00:00
UMASK=022
USER=oatbcrs
_=env
$
Production
=========
# set
EDITOR=vi
ERRNO=0
FCEDIT=/usr/bin/ed
HOME=/home/infra2
IFS='
'
LANG=en_US
LINENO=1
LOGIN=root
MAILCHECK=600
OPTIND=1
PAM_SERVICE=su
PATH=/usr/bin:/bin:/etc:/usr/sbin:/etc:/omniguard/upm/usr/local/bin
PPID=1851556
PS1='# '
PS2='> '
PS3='#? '
PS4='+ '
PWD=/home/infra2
RANDOM=14840
SECONDS=4
SHELL=/usr/bin/sh
TERM=vt100
TMOUT=300
TZ=HKT+08:00:00,,
_=pwd
# env
_=/usr/bin/env
LANG=en_US
LOGIN=root
PATH=/usr/bin:/bin:/etc:/usr/sbin:/etc:/omniguard/upm/usr/local/bin
EDITOR=vi
IFS=
TMOUT=300
PAM_SERVICE=su
HOME=/home/infra2
TERM=vt100
PWD=/home/infra2
TZ=HKT+08:00:00,,
A__z="*TMOUT
#
Thanks
Gopal.
#4
Posted 22 November 2008 - 04:05 AM
Hey Gopal,
I wish I saw something definite in there. I don't mean that you didn't provide enough information, just that I don't see anything that looks like it "must" be the problem. The only thing I saw that made me curious is that one machine uses pam for auth and the other doesn't. It may be a stretch, but most disconnect (1 or 255) errors have something to do with a bad password (yours says it's okay), bad shell (you're using ksh on both - I'm assuming they both allow login) or some other reason to dump the session.
If it's possible, can you do an ssh to that box and just run a command like hostname?
For instance:
It might be different depending on what ssh you use. Most versions don't allow you to pass the password in cleartext, so you might need to do:
and manually type in the user password. If that drops, the information from that debug output, plus the extensive environment info you already provided should narrow it down so I can make a reasonable suggestion to you. Right now, I'm at a loss to tell you what to try except "anything and everything" which is no help at all
Look forward to hearing back from you. hopefully, we'll get this worked out soon!
Take care,
mike
I wish I saw something definite in there. I don't mean that you didn't provide enough information, just that I don't see anything that looks like it "must" be the problem. The only thing I saw that made me curious is that one machine uses pam for auth and the other doesn't. It may be a stretch, but most disconnect (1 or 255) errors have something to do with a bad password (yours says it's okay), bad shell (you're using ksh on both - I'm assuming they both allow login) or some other reason to dump the session.
If it's possible, can you do an ssh to that box and just run a command like hostname?
For instance:
Quote
ssh -v -v -v emerg1:Vm41L000@10.20.210.240 "hostname"
It might be different depending on what ssh you use. Most versions don't allow you to pass the password in cleartext, so you might need to do:
Quote
ssh -v -v -v emerg1@10.20.210.240 "hostname"
and manually type in the user password. If that drops, the information from that debug output, plus the extensive environment info you already provided should narrow it down so I can make a reasonable suggestion to you. Right now, I'm at a loss to tell you what to try except "anything and everything" which is no help at all
Look forward to hearing back from you. hopefully, we'll get this worked out soon!
Take care,
mike
The greatest viral marketing idea of all time, get your copy of this Free Report now!
----
Linux Tips, Trick and Advice -- The Linux and Unix Menagerie
----
Linux Tips, Trick and Advice -- The Linux and Unix Menagerie
#5
Posted 24 November 2008 - 09:40 PM
Hi Mike,
You are great
, thanks very much, atlast the problem solved after 1 month.
it's working now.
C:\Gop\WinSCP\PuTTY\plink.exe 10.20.210.240 -l user22 -pw summa1 /tmp/test.sh
Thanks
Gopal
You are great
it's working now.
C:\Gop\WinSCP\PuTTY\plink.exe 10.20.210.240 -l user22 -pw summa1 /tmp/test.sh
Thanks
Gopal
#6
Posted 25 November 2008 - 05:00 AM
Awesome,
Great work
I'm glad to see that there actually is a real way to pass the password on the command line. I think too many years of openSSH have narrowed my mind on that subject. You learn something new every day 
Cheers,
Mike
Great work
Cheers,
Mike
The greatest viral marketing idea of all time, get your copy of this Free Report now!
----
Linux Tips, Trick and Advice -- The Linux and Unix Menagerie
----
Linux Tips, Trick and Advice -- The Linux and Unix Menagerie
#7
Posted 29 April 2009 - 08:20 AM
then change (if possible) the user attribute on the non-working box to match the dev setup and see if it works.
If you don't see anything, and it's okay, can you login new york asian escort to the good box and the bad box (via SSH) and run either "set" or "env" and post the output for both. If the winscp error message is close to correct, the answer might be in there.I'm glad to see that there actually is a real way to pass the new york escort password on the command line. I think too many years of openSSH have narrowed my mind on that subject. You learn something new every day smile.gif
If you don't see anything, and it's okay, can you login new york asian escort to the good box and the bad box (via SSH) and run either "set" or "env" and post the output for both. If the winscp error message is close to correct, the answer might be in there.I'm glad to see that there actually is a real way to pass the new york escort password on the command line. I think too many years of openSSH have narrowed my mind on that subject. You learn something new every day smile.gif
Share this topic:
Page 1 of 1

Help












