Adopted authority won't work in this case, since SSH doesn't care about
   that and will only look in the home directory of the current user.
   You can either swap profiles (QSYGETPH/QSYSETPH) or run under a SBMJOB
   USER(somebody) or you can add the server's host key fingerprint to the
   system-wide known_hosts file under
   /QOpenSys/QIBM/UserData/SC1/OpenSSH/etc/ssh_known_hosts. This file doesn't
   exist by default, so you'll have to create it (make sure it's CCSID 819
   and *LF line endings).
   Kevin Adler
   Software Development - PASE, Open Source, IBM i Access ODBC
   IBM Systems, Dept 47U
   Phone: +1-507-253-5111
   Email: kadler@xxxxxxxxxx
   015-3 C117
   3605 HWY 52 N
   Rochester, MN 55901-1407
   United States
     ----- Original message -----
     From: Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>
     Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
     To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
     Cc:
     Subject: Re: SFTP and .openssh files
     Date: Thu, Nov 8, 2018 1:38 PM
     Before I forget this -
     In various responses there are references to the /home/user directory
     and I
     assume user is not the literal word "user" but the name of the user
     doing
     this.
     The user in my case will not always be the same person.  So do I
     ultimately
     need to set up a user "SFTPUSER" (for example) and run any CL program
     with
     USRPRF(*OWNER) and SFTPUSER be the owner of said program?
     So many gotchas . . .    :)
     On Thu, Nov 8, 2018 at 12:41 PM Carel <coteijgeler@xxxxxxxxx> wrote:
     > Odd.
     >
     > Yesterday we make a connection with a new client. They sent us their
     > public key but that did not work correctly.
     >
     > So we retrieved their public key with QP2TERM and the command I gave
     in
     > an earlier post. (ssh -l loginname server)
     >
     > It will tell you it will retrieve the key and ask you if to continue.
     > Answer yes, then it wil ask 2 or 3 times for a passphrase which will
     not
     > be required, so 2 or 3 enters.
     >
     > Then it says it has retreived the key.
     >
     > It is stored in the file known_hosts on the IFS; if it does not exist
     it
     > will be created, otherwise appended to it. No EBCDIC there as it is
     > transferred directly to the IFS, you are in a UNIX type environment.
     >
     > Then you can interacively connect with the other server with sftp.
     >
     > We do it like this:
     >
     > sftp -vvv �o UserKnownHostsFile=/home/[user]/.ssh/known_hosts -o
     > IdentityFile=/home/[user]/.ssh/id_rsa loginame@server
     >
     > In a CLP programme:
     >
     > QSH CMD('sftp -vvv -o UserKnownHostsFile=/home/[user]/.ssh/known_hosts
     > �o IdentityFile=/home/[user]/.ssh/id_rsa loginname@server')
     >
     > You can add �b testscript to the command with a path to the text
     file
     > with commands (get, (m)put, quit, rm, etc).
     >
     > If you have 1 connection working this way, then the others will be
     much
     > simpler to implement.
     >
     > Of course this is a wat yo do it. For it works.
     >
     > KInd regards,
     >
     > Carel Teijgeler
     >
     > Op 8-11-2018 om 18:11 schreef Kevin Adler:
     > >     The first time you connect to an SSH server it asks you to
     validate
     > their
     > >     host key (sftp is just a special use of an SSH server). This
     > validates
     > >     that the server is who you think it is. Once you've accepted the
     key
     > >     fingerprint, it will be saved in /home/user/.ssh/known_hosts and
     you
     > won't
     > >     get asked again.
     > >
     > >     The problem is that when using sftp from QSH/QP2TERM there is no
     way
     > for
     > >     it to ask you to validate the key (since there's no TTY
     environment)
     > and
     > >     so it doesn't even try and just says that it can't validate it
     > ("Host key
     > >     verification failed").
     > >
     > >     You have a couple options to fix it:
     > >
     > >     - request the host key fingerprint from your partner and add it
     to
     > >     /home/user/.ssh/known_hosts manually. The fingerprint will look
     > something
     > >     like:
     > >
     > >     example.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEApkxN82QhSqYFD...
     > (this
     > >     string is usually really long)
     > >
     > >     You need to ensure that the file is in ASCII and uses Unix line
     > endings
     > >     (LF, not CRLF).
     > >
     > >     - connect once with ssh instead of sftp and accept the
     fingerprint:
     > >
     > >     ssh -T example.com
     > >     The authenticity of host 'example.com (9.5.67.117)' can't be
     > established.
     > >     ECDSA key fingerprint is
     > >     SHA256:5BYrcHeU+0QXkDqor8bfH+M7AbZz4a33ViCbE6G906M.
     > >     Are you sure you want to continue connecting (yes/no)?
     > >
     > >     Once you say yes, it will be stored in
     /home/user/.ssh/known_hosts.
     > Note
     > >     that you don't actually have to succeed in connecting, just
     answer
     > yes to
     > >     the prompt.
     > >
     > >     - use ssh-keyscan to automatically add the fingerprints to
     > >     /home/user/.ssh/known_hosts:
     > >
     > >     ssh-keyscan example.com >> /home/user/.ssh/known_hosts
     > >
     > >
     > >     Note that you should run these commands from QP2TERM. When run
     from
     > QSH,
     > >     it will not be able to find the commands unless you add
     > /QOpenSys/usr/bin
     > >     to the $PATH environment variable. Also, you could end up with
     > EBCDIC data
     > >     in known_hosts if it doesn't already exist, which will cause ssh
     to
     > fail.
     > >
     > >
     >
     > --
     > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
     list
     > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
     > To subscribe, unsubscribe, or change list options,
     > visit: [1]
https://lists.midrange.com/mailman/listinfo/midrange-l
     > or email: MIDRANGE-L-request@xxxxxxxxxxxx
     > Before posting, please take a moment to review the archives
     > at [2]
https://archive.midrange.com/midrange-l.
     >
     > Please contact support@xxxxxxxxxxxx for any subscription related
     > questions.
     >
     > Help support midrange.com by shopping at amazon.com with our affiliate
     > link: [3]
https://amazon.midrange.com
     >
     --
     Jeff Crosby
     VP Information Systems
     UniPro FoodService/Dilgard
     P.O. Box 13369
     Ft. Wayne, IN 46868-3369
     260-422-7531
     direct.dilgardfoods.com
     The opinions expressed are my own and not necessarily the opinion of my
     company.  Unless I say so.
     --
     This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
     list
     To post a message email: MIDRANGE-L@xxxxxxxxxxxx
     To subscribe, unsubscribe, or change list options,
     visit: [4]
https://lists.midrange.com/mailman/listinfo/midrange-l
     or email: MIDRANGE-L-request@xxxxxxxxxxxx
     Before posting, please take a moment to review the archives
     at [5]
https://archive.midrange.com/midrange-l.
     Please contact support@xxxxxxxxxxxx for any subscription related
     questions.
     Help support midrange.com by shopping at amazon.com with our affiliate
     link: [6]
https://amazon.midrange.com
References
   Visible links
   1. 
https://lists.midrange.com/mailman/listinfo/midrange-l
   2. 
https://archive.midrange.com/midrange-l
   3. 
https://amazon.midrange.com/
   4. 
https://lists.midrange.com/mailman/listinfo/midrange-l
   5. 
https://archive.midrange.com/midrange-l
   6. 
https://amazon.midrange.com/
As an Amazon Associate we earn from qualifying purchases.