I'm way out of my league now, so this is just speculation on my part. But did your test sftp go to the same site and user at that site? I just wonder if it is possible if the problem is at the far end. I really don't know, I'm just musing out loud.
I am at home on my Linux system. Where I have a full OpenSSH setup. I set up two ids for testing. Call them "local" and "remote" for fun. I created a ssh key using "local". I put the public key in remote's .ssh authorized_keys file. I could then do an sftp connection from local to remote. But if I changed the filemode on remote's .ssh to other than 700, I could not use the cert (it asked for the UNIX password). Also, if I changed the authorized_keys file in remote's .ssh subdirectory to where anyone other than the user had write access to it, I could not use the digital cert, but was prompted for the password. Now, if I disable the use of passwords in /etc/ssh/sshd_config, then I cannot connect at all. What I'm getting at is that I __think__ there __might__ be a problem on the far end for one of the ssh files. On Tue, 2010-11-30 at 17:58 -0500, Leonard Sasso 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 -- John McKown Maranatha! <>< ---------------------------------------------------------------------- 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
