Hi all, You are correct, it is a private key.
I don't know about crypto, so I will try to describe what we discovered. I was told that the first algorythm used to generate the key is not compatible with the z/OS crypto stack. Therefore, when RSA PEM algorythm is used to create a new KEY, it is accepted by z/OS. Successfully checked with OMVS command ssh-keygen -y -f new_key_pem Thank you for your time; it was appreciated. Best Regards Ituriel do Nascimento Neto z/OS System Programmer Em quinta-feira, 5 de março de 2026 às 11:46:31 BRT, Colin Paice <[email protected]> escreveu: Several things jump out at me. - The file has OPENSSH PRIVATE KEY, but you think it is the public key.May beyou've uploaded the wrong one. - check you have read permissions to the file - try sftp with -v or -v -v options for more verbose info - it could be the remote end does not have the key matching your private key, and so it is complaining Colin On Thu, 5 Mar 2026 at 13:31, Ituriel do Neto < [email protected]> wrote: > Hi all, > > I'll try to explain what I did and what is needed. > I have a public key and uploaded it to my z/OS with a single ftp, like > below: > > ftp ... > put c:/temp/my_key.txt /u/temp/my_key > > When I browse my_key into /u/temp it seems to be correct, exactly like > file my_key.txt in windows. > > -----BEGIN OPENSSH PRIVATE KEY----- > aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa > aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa > aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa > -----END OPENSSH PRIVATE KEY----- > > The next step is a sftp in OMVS, using the following input: > sftp -P xxxx -i /u/temp/my_key myuser@myIP > > And I get the following results: > > FOTS3426 Load key "/u/temp/my_key": invalid format > FOTS1373 myuser@myIP: Permission denied > (publickey,gssapi-keyex,gssapi-with-mic). > Connection closed. > FOTS0841 Connection closed > > The point is, what am I doing wrong? > > Best Regards > > Ituriel do Nascimento Neto > z/OS System Programmer > > > > > > > Em quinta-feira, 5 de março de 2026 às 09:52:54 BRT, Rick Troth < > [email protected]> escreveu: > > > > > > > If so, then you need to transfer the PRIVATE/secret key to the z/OS > > host, and tell the sftp client which identity key to use. > > Forgive me Stefan. > I strongly recommend NOT doing this. > Instead, use an /SSH agent/ on the workstation and NEVER let THAT > private key escape into the wild. > > You will need agent proxy enabled on all systems, but then can ... > > # from the workstation > ssh -A mvshost > # and once in the USS shell > ssh -A otherhost > # and from there > ssh -A original > > Above example makes a loop, but the point is, with SSH agent service, > you can avoid the risk of multiple copies of your SSH private key (or of > multiple SSH private keys). MUCH better security posture and yet full > access to all systems of interest. > > You can simplify the mechanics (and avoid having to add the "-A" flag > every time) by adding ... > > ForwardAgent yes > > ... to your~/.ssh/config file. > > > -- Rick Troth, CISSP; <>< > > > > On 3/4/26 9:51 PM, Stefan Skoglund wrote: > > Do you want to connect with ssh/scp/sftp from USS in z/OS to a linux > > host ? > > > > If so, then you need to transfer the PRIVATE/secret key to the z/OS > > host, and tell the sftp client which identity key to use. > > > > Personally i would prefer generating a key pair on z/OS and then > > copying the public key to the linux host. > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email [email protected] with the message: INFO IBM-MAIN > > > -- > -- R; <>< > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
