Hi Charlie,
My replies are inline.
1. First, I got this:
Connecting to xxx.xxx.xx.xxx...
Could not create directory '/home/MRPVER/.ssh'.
Host key verification failed.
Connection closed
Press ENTER to end terminal session.
SSH maintains a list of digital keys for each user. This is part of how
it protects you -- by verifying the identity of sites with digital keys.
To do that, it needs a place to store them.
The Unix convention for per-user data is to create a hidden directory in
each user's home directory. Since your home directory is /home/MRPVER,
it's creating a directory named .ssh inside the /home/MRPVER -- in other
words, /home/MRPVER/.ssh. However, if there isn't already a
/home/MRPVER directory, it will fail with the error you've given.
Regarding that error... I'm not sure why it would get an error trying to create a directory?
The user ID I'm running this under is MRPVERSFEL.
Does it always take the first six bytes of the User ID and create a directory?
No. The default value would've been /home/MRPVERSFEL -- it's the full
user profile, it's not shortened. However, each user's home directory
is configurable in their user profile. You can change it with:
CHGPRF HOMEDIR('/blah/blah')
- or -
CHGUSRPRF USRPRF(MRPVERSFEL) HOMEDIR('/blah/blah')
So most likely someone changed yours in the past. It might even be your
company's standard to use the first 6 characters? Or maybe this was
done to try to get around the "You don't exist" problem? (It wouldn't
help with that, but someone might've tried, not knowing...)
Anyway.. the problem had nothing to do with the name of the directory,
the problem was that it simply didn't exist.
Can I expect such an error for any User ID I run this under?
Will I have to create such a directory for any User Ids that access this function?
Yes, you'll get this error for each user, unless you create the
directory first. This is a one-time setup. I would suggest creating the
directory, doing a keygen, and doing a keyscan for each site they need
to connect to, all as part of the one-time setup.
On a Unix system, the home directory would be created when the user
profile was created... The SSH tools will create the .ssh subdirectory
for you, though.
2. I tried manually creating the directories, and then, got this error.
Connecting to 151.151.65.203...
Host key verification failed.
Connection closed
Press ENTER to end terminal session.
Yes, that's normal and expected. Interactive password entry doesn't
work with a 5250 terminal. This is documented in every single document
I've seen about SSH on i.
Your choices:
1) Use a Unix terminal instead of a 5250 terminal.
2) Use digital keys instead of passwords
3) Use a scripting tool like Expect.
My understanding is that our Operations Manager set up the Host Keys.
I'm not sure why I would be getting the "Host key verification failed" error.
Host keys identify a computer. User keys identify a user on that
computer. The host keys weren't the problem, the user keys were.
I googled and found instructions for setting up the keys, but as I said, my
understanding was that this was already done by our Operations manager.
Sounds like the host keys were, but the per-user keys weren't. (At
least not for MRPVERSFEL)
My understanding is that the keys were set up for user TSU8V5S6,
which was created specifically for this.
Please read my previous message to you where I explained that there are
two userids, one on each end of the connection...
This command is running out of a CL program, so I tried something else, just to see if it would work.
I tried calling the program in batch using a SBMJOB instead of calling the program interactively.
I made the user for my SBMJOB USER(TSU8V5S6)
Are you saying the userid should be TSU8V5S6 on _both_ sides of the
connection? (If so, why didn't you say that earlier?!)
Please log on (or swap to) the TSU8V5S6 userid, then set up his keys and
get the sftp running interactively. Once that part is done, /then/ try
to get it running in batch. It's much easier that way.
Error found with QSH session, reason code 4, errno 3489.
You are submitting your job to a single-threaded job queue. Qshell
needs to be able to spawn multiple background jobs. Try submitting it
to a multi-threaded job queue.
However, it'll be much easier to get this working interactively first.
Unix software like OpenSSH does not write messages to the job log. Why
not? Because Unix systems don't have job logs -- therefore there's no
code in the programs to write messages to job logs. So once you get
past the QSH0002 error, the only errors you'll get in your logs will be
QSH0005 -- which won't tell you much. (Though, by default a spooled
file will have more info -- but for sure an interactive job is a lot
easier to deal with.)
Also, I've written several articles about this... there's a list of my
articles and other resources about OpenSSH here:
http://www.scottklement.com/openssh/
midrange.com
