It might be easier to see if you'd post the JCL and SYSIN type input for the 
failing step. Does the production RACF id have an OMVS segment? Does it have a 
HOME subdirectory? Is there a .ssh subdirectory in the $HOME for this user? Is 
the UNIX filemode for .ssh subdirectory set to 700 or 600? Are the files in the 
.ssh subdirectory all set to filemode 600? Is .ssh and all its files owned by 
the production RACF id? Just some questions.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
[email protected] * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

> -----Original Message-----
> From: IBM Mainframe Discussion List 
> [mailto:[email protected]] On Behalf Of Leonard Sasso
> Sent: Tuesday, November 30, 2010 2:59 PM
> To: [email protected]
> Subject: "FOTS1346 Permission denied, please try again"
> 
> Our Mainframe Batch job is successful using a Test Userid and 
> Password to 
> SSH to a remote host using password authentication (via 
> askpass).  When we 
> try the same job with the Production Userid and Password, we 
> receive the 
> following error: "FOTS1346 Permission denied, please try again". This 
> causes user authentication to fail. The SSH client then 
> eventually fails 
> with the error: "FOTS1373 Permission denied 
> (publickey,password,keyboard-interactive)". 
> 
> Per the IBM Ported Tools for z/OS User's Guide (page 111 - # 22):
> 
> "Verify that you are not trying to use ssh while switched to 
> another user 
> ID. In other words, did you issue ssh after the su command? 
> The original 
> controlling terminal (displayed by the tty command) is owned 
> by the user 
> ID originally logged in. Your target user may not have 
> permission to read 
> from it."
> 
> We are not issuing the "su" command (what is the "su" command)?
> 
> Any help would be appreciated.
> 
> 
> 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.
> 

----------------------------------------------------------------------
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

Reply via email to