Re: SFTP and .openssh files

That makes me think of something else though, a bit of an aside.

If user JOE is going to do a SBMJOB USER(JANE) doesn't user JOE have to
have some kind of authority to user JANE? It sticks in my mind I've read
something like that on these lists.


On Thu, Nov 8, 2018 at 2:56 PM Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>
wrote:

It will ultimately be submitted to batch via SBMJOB so that part should at
least be OK.

On Thu, Nov 8, 2018 at 2:47 PM Carel <coteijgeler@xxxxxxxxx> wrote:

Jeff,

You are correct, the known_host file is created in the current directory
of the active user. You can change that with option 13 in WRKLNK, IIRC.

On the SBMJOB command and the WRKJOBSCDE you can indicate under which
user those jobs should run.

Adoptive authority may not work as that does not work on the IFS.

Do you want to run it in interactive jobs? Then perhaps a profile swap
may work (profile handle APIs).

At my work we run it under 1 user profile, but that are all batch jobs.

Kind regards,

Carel Teijgeler


Op 8-11-2018 om 20:38 schreef Jeff Crosby:

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: 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 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: https://amazon.midrange.com

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