Greg,
This sounds like an IBM i authority issue and not an sftp issue.
Try granting the batch user
CHGAUT OBJ('/home/biz/') USER(BATCHUSER) DTAAUT(*RX) OBJAUT(*NONE)
CHGAUT OBJ('/home/biz/.ssh) USER(BATCHUSER) DTAAUT(*RX) OBJAUT(*NONE)
CHGAUT OBJ('/home/biz/.ssh/id_rsa') USER(BATCHUSER) DTAAUT(*R) OBJAUT(*NONE)
CHGAUT OBJ('/home/biz/.ssh/known_hosts') USER(BATCHUSER) DTAAUT(*R)
OBJAUT(*NONE)
The 'CHGPGM PGM(ASTHHOBJ/MySFTPclp) USRPRF(*OWNER') command would only help
if adopted authority worked with the IFS.
Rob
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Greg
Wilburn
Sent: Wednesday, April 30, 2025 1:24 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: RE: sFTP User Name - does it need to match user name on the server
So this worked fine under my user profile because I have authority to the
SFTP Users .ssh directory (/home/biz/.ssh).
If I ran the CL program as another user, it failed
"Warning: Identity file /home/biz/.ssh/id_rsa not accessible: Permission
denied.
hostkeys_find_by_key_hostfile: hostkeys_foreach failed for
/home/biz/.ssh/known_hosts: Permission denied Host key verification failed."
I tried CHGPGM PGM(ASTHHOBJ/MySFTPclp) USRPRF(*OWNER) - that didn't help.
I guess I'm back to submitting the CL as the SFTP user? I don't know how
else to overcome this.
(the reason I don't want to submit the job is that it's inside a job stream
that deletes the files after sending)
Any other ideas welcomed.
Greg
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Greg
Wilburn
Sent: Wednesday, April 30, 2025 8:39 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: RE: sFTP User Name - does it need to match user name on the server
That did the trick!
This works as well:
sftp -oIdentityFile=/home/biz/.ssh/id_rsa
-oUserKnownHostsFile=/home/biz/.ssh/known_hosts biz@xxxxxxxxxxxxxx
Thank you Rob!
Patrik - thanks for your input as well. While "biz" is a local user on our
system, it was only created to establish the keys and the trust
relationship. That profile is disabled, *SIGNOFF and has no capabilities.
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Rob W
via MIDRANGE-L
Sent: Tuesday, April 29, 2025 7:46 PM
To: 'Midrange Systems Technical Discussion' <midrange-l@xxxxxxxxxxxxxxxxxx>
Cc: qpgmr400@xxxxxxxxxxxxxxx
Subject: RE: sFTP User Name - does it need to match user name on the server
Hi Greg,
sftp will also try to find the known_hosts file (~/.ssh/known_hosts) in the
current users home directory.
If your logged in as a user other than biz, you will also need to point to
the other users known_hosts file.
Try the following by telling sftp where to find the known_hosts file.
sftp -i /home/biz/.ssh/id_rsa -o
UserKnownHostsFile=/home/biz/.ssh/known_hosts biz@xxxxxxxxxxxxxx
Another option would be to change the command to ssh instead of sftp, then
the system will ask you if you want to add a new host key. Then the sftp
command should work.
Rob W
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Greg
Wilburn
Sent: Tuesday, April 29, 2025 12:16 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: RE: sFTP User Name - does it need to match user name on the server
Let me explain...
If you want to log into a remote machine from a local one, and want to
use a specific private (!) keyfile locally, > use the -i option. If
said
keyfile is named id_rsa or whatever crypto stuff was used, and it's
contained in the user's home directory, subdirectory .ssh, the ssh, sftp and
scp commands find the file automatically.
This is what I want to do... I've tried to use the -i option to indicate the
location of the keys, but I must not have the syntax correct.
I get "Host key verification failed"
So if the key is in /home/biz/.ssh and is called id_rsa, what is the correct
syntax for the command line option?
sftp -I /home/biz/.ssh/id_rsa biz@xxxxxxxxxxxxxx did not work
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Patrik
Schindler
Sent: Tuesday, April 29, 2025 2:49 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: sFTP User Name - does it need to match user name on the server
Hello Greg,
Am 29.04.2025 um 20:29 schrieb Greg Wilburn
<gwilburn@xxxxxxxxxxxxxxxxxxxxxxx>:
I know this goes back a while... but I can't seem to find the
"appropriate
command line switch" on the SFTP command to point to the public key.
In my case, the key is in /home/biz/.ssh
If I log on as user "biz" I can establish a connection.
If I log on as another user, I cannot connect unless I CHGUSPRF
USRPRF(me) HOMEDIR('/home/biz')
I'll be using this in batch... what am I missing?
I'm confused about which direction you're talking. :-)
If you log into a machine via any ssh protocol, the public key is read by
the server (job). It is always found in the connecting user's home
directory, subdirectory .ssh, file authorized_keys.
If you want to log into a remote machine from a local one, and want to use a
specific private (!) keyfile locally, use the -i option. If said keyfile is
named id_rsa or whatever crypto stuff was used, and it's contained in the
user's home directory, subdirectory .ssh, the ssh, sftp and scp commands
find the file automatically. No need to specify -i.
If you want to connect as another user to the remote machine, use
username@destination.
Does that help?
:wq! PoC
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
Greg Wilburn
Director of IT
301.895.3792 ext. 1231
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
Greg Wilburn
Director of IT
301.895.3792 ext. 1231
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
Greg Wilburn
Director of IT
301.895.3792 ext. 1231
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
.
midrange.com
