I check the password file for extra garbage characters. Received the same error messages.
Thank You. Len Sasso RDC Operations - Systems Administrator CSC Information Technology Infrastructure Services (ITIS) | p: 518.257-4209 | m: 518.894-0879 | f: 518.257-4300 | [email protected] | www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From: Kirk Wolf <[email protected]> To: [email protected] Date: 11/30/2010 06:33 PM Subject: Re: "FOTS1346 Permission denied, please try again" >From the trace it looks like a password packet is being sent to the remote system and is being rejected. Can you logon to the same target system and userid from an interactive sftp client? Make sure that you use the same case in both the userid and password. If so, then perhaps there is a problem with how you are reading the password in your ASKPASS script....maybe you are getting extra garbage characters in your password? Try adding some debugging to your script like: # read pw from a one-line file pw=$(cat pwfile) echo "length of pw is:" ${#pw} > /dev/fd2 # write pw to stdout for ssh consumption echo $pw If this still doesn't work, then you might want to look at the sshd logs from the server to see why it rejected the login. Maybe it has a DenyHosts, etc. Kirk Wolf Dovetailed Technologies http://dovetail.com On Tue, Nov 30, 2010 at 4:58 PM, Leonard Sasso <[email protected]> wrote: > Changed the directory and file permissions, received the same error > messages. > > > Thank You. > > Len Sasso > > > > RDC Operations - Systems Administrator > CSC > Information Technology Infrastructure Services (ITIS) > | p: 518.257-4209 | m: 518.894-0879 | f: 518.257-4300 | [email protected] | > www.csc.com > > This is a PRIVATE message. If you are not the intended recipient, please > delete without copying and kindly advise us by e-mail of the mistake in > delivery. > NOTE: Regardless of content, this e-mail shall not operate to bind CSC to > any order or other contract unless pursuant to explicit written agreement > or government initiative expressly permitting the use of e-mail for such > purpose. > > > > From: > Kirk Wolf <[email protected]> > To: > [email protected] > Date: > 11/30/2010 05:25 PM > Subject: > Re: "FOTS1346 Permission denied, please try again" > > > > Gil is correct. Even though you aren't using keys, OpenSSH will try to > cache a prng in .ssh, so it should be 700. > > Best to stay with these recommendations for file permissions: > http://dovetail.com/docs/sftp/sftp-webinar.pdf slide 29 "Common > Pitfalls" > > Kirk Wolf > Dovetailed Technologies > http://dovetail.com > > On Tue, Nov 30, 2010 at 4:09 PM, Paul Gilmartin > <[email protected]>wrote: > > > On Tue, 30 Nov 2010 16:32:48 -0500, Leonard Sasso wrote: > > > > >Does the production RACF id have an OMVS segment? Yes > > >Does it have a HOME subdirectory? Yes > > >Is there a .ssh subdirectory in the $HOME for this user? Yes > > >Is the UNIX filemode for .ssh subdirectory set to 700 or 600? Set to > 770 > > >Are the files in the .ssh subdirectory all set to filemode 600? Set to > > >600 or 644 or 777 > > >Is .ssh and all its files owned by the production RACF id? Yes > > > > > Those might be too permissive. "For your protection" some > > variants of SSL/SSH prohibit that any files in ~/.ssh, and > > any directories in its path, be group writeable. Stay with > > 700 for directories and 600 for basefiles. > > > > -- gil > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: GET IBM-MAIN INFO > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
