Setting SSH keys on IFS prevents User Profile from Accessing IFS

[AntonyRobbins]

Hi, I'm a forum newbie here so any help with this would be very much appreciated and apologies if I've posted in the wrong place.

We have a user profile on our iSeries (V5R3) XX_PGMR and recently we needed to add ssh encryption keys to access an external unix server via SFTP. As QPGMR already had a set of keys that were different and not wanting to change them as other jobs on the system would likely be affected by this, we created a folder on the IFS called XX_PGMR under the /home directory and placed the necessary keys within this folder.

Suddenly, any job using CPYFRMIMPF under profile XX_PGMR fell over with a CPF2817: Copy command ended because of error. The job log showed File system error occurred. Error number 3025. We only found out the keys (or IFS folder we created) had caused the problem by sheer chance and once we renamed the IFS folder so that it no longer matched the user profile everything worked correctly again.

Is anybody able to identify why this may have occurred please? The IFS folder XX_PGMR had *PUBLIC *RWX authority so there should have been no authority issues but everyone is a little befuddled as to why just adding a folder that matches the user profile name to the IFS and adding (technically text files) encrypted ssh keys to the folder would prevent the user profile from being able to access the IFS using a CPYFRMIMPF command.

Thanks for your help.

[chris_hird]

Re: Setting SSH keys on IFS prevents User Profile from Accessing IFS

3025 converts to no such file or library? what is the XX_PGMR home directory set to? By default it would use /home/XX_PGMR, then this would be used as the base directory, so if you were trying to access a file in say /etc/temp, it would convert to /home/XX_PGMR/etc/temp. You can set the user profile up so it has no home directory or root, or simple change the command with the fact that XX_PGMR will always have /home/XX_PGMR as its starting point. The fact that it exists will probably enforce it as the base directory for any IFS commands?

Hope that helps.

Chris..

[Robert Clay]

Re: Setting SSH keys on IFS prevents User Profile from Accessing IFS

...we created a folder on the IFS called XX_PGMR under the /home directory and placed the necessary keys within this folder. ...

Try putting the keys in a SUBdirectory named ".ssh" under the user's home directory (note the preceeding dot character).

So, you would want the keys in '/home/XX_PGMR/.ssh'. I made a note long ago that this is case-sensitive but that could be a bogus note.

Also, check the home directory on the user profile to make sure it isn't directing somewhere else. As Chris said, it should default to '/home/XX_PGMR'.

Robert

[AntonyRobbins]

Re: Setting SSH keys on IFS prevents User Profile from Accessing IFS

3025 converts to no such file or library? what is the XX_PGMR home directory set to? By default it would use /home/XX_PGMR, then this would be used as the base directory, so if you were trying to access a file in say /etc/temp, it would convert to /home/XX_PGMR/etc/temp. You can set the user profile up so it has no home directory or root, or simple change the command with the fact that XX_PGMR will always have /home/XX_PGMR as its starting point. The fact that it exists will probably enforce it as the base directory for any IFS commands?

Hope that helps.

Chris..

Thanks for the response Chris. The Home directory is set to /home/XX_PGMR but prior to us creating this, it never existed. Does this mean that currently any job using XX_PGMR as it's User to run under will attempt to use the home directory but, if it's not found, will revert back to root "/"?

If that's so, that would make sense. All the while the XX_PGMR folder doesn't exist, everything will work. By creating it, we've pushed any IFS commands 2 levels further up the directory chain (/home/XX_PGMR/blah/blah instead of /blah/blah).

Thanks again Chris, this is much appreciated.

[AntonyRobbins]

Re: Setting SSH keys on IFS prevents User Profile from Accessing IFS

Thanks for the response Robert. Unfortunately, this is what we did and this is what caused the problems. It appears the home directory of that profile is ignored as the /home/XX_PGMR folder doesn't exist therefore forcing the home directory to actually be root. Most of the code that has caused the problem begins without a leading slash (to force root directory). This has always worked as there hasn't been a XX_PGMR folder before but the minute we created it, everything else stopped working as it appears it was now looking for directories within /home/XX_PGMR that never existed. The keys are a bit of a red herring (as we now know) and the creation of the XX_PGMR folder was the problem.

Once we renamed this folder out of the way, everything worked again because it was going back to root directory. To be able to have this folder exist, we will need to get every reference to an IFS directory path (that uses this user profile) preceded by a slash so it forces the address to begin at root.

[Scott Klement]

Re: Setting SSH keys on IFS prevents User Profile from Accessing IFS

Hello,

I can only guess at what the problem is... but if Chris's guess is correct, then it means that the call to CPYFRMIMPF is coded incorrectly, and was working by "luck". I can explain this, but unfortunately it's going to require me to explain some background info first, so the explanation won't be very short.

You see, there are two ways of providing IFS path names:

1) Relative path names
2) Absolute (or "fully qualified") path names.

The idea behind relative path names is that you don't have to hard-code the full path name into programs. This is useful, for example, when you want to have the same application able to access two different environments. One environment for development, one for production, or something like that. The idea is that with a relative path name, the user's "current directory" (sometimes called "current working directory", abbreviated "cwd") is always prepended to the paths that are specified. Therefore, by changing your CWD you can change where the files are accessed from.

Absolute paths always provide the full path name from the root of the IFS, so point to an explicit location. The CWD does not come into play at all with an absolute path.

Syntactically, the way you specify an absolute path is by starting the path name with a slash. The leading slash means "start at the root". By contrast, a relative path will never start with a slash.

For example... Let's say you have a whole set of files in /usr/local/acmeapplications/production/myapplication/data and there are multiple files, file1.dat, file2.dat, file3.dat, etc in that directory. Then you also have a set of files (same files, file1.dat, file2.dat, file3.dat) in /usr/local/acmeapplications/test/myapplication/data.

If you want to always get the production copy, you could use an absolute path name like CPYFRMIMPF FROMSTMF('/usr/local/acmeapplications/production/myapplication/data/file1.dat'). This would always, explcitly, get the one from the subdirectory under 'production'.

But what if you wanted the user to be able to control which directory? In that case, you could use a relative directory like this: CPYFRMIMPF FROMSTMF('myapplication/data/file1.dat') (Note that there is no leading slash). Before the user runs this command (or a CL that runs the command) he/she would do CHGCURDIR DIR('/usr/local/acmeapplications/production') or CHGCURDIR DIR('/usr/local/acmeapplications/test') Since the current directory is prepended to the path name, they'd be able to switch between environments without changing the code.

Here's how it relates to the home directory: When a job starts, the CWD is defaulted to the home directory. If the home directory does not exist, then it is defaulted to the IFS root.

So let's say some programmer who didn't understand absolute vs. relative paths wrote a CPYFRMIMPF FROMSTMF('usr/local/acmeapplications/production/myapplication/data/file1.dat') He doesn't understand that he's using a relative path name, he left off the leading slash out of habit maybe (since LIB/OBJ paths don't use a leading slash, perhaps) and he tested it and all worked great. The problem is, it'll ONLY work if his CWD happens to be the root of the IFS... which it would be by default if his home directory doesn't exist. And if he doesn't know about relative vs absolute paths, he may not even know that there is a concept of CWD. Since his CWD is / ("root"), then it's prepending the leading slash, and resulting in /usr/local/... etc so it works for him.

But, then as soon a user has their homedir created, the CWD defaults to their home dir, and the same CPYFRMIMPF is trying to access /home/userid/usr/local... which obviously won't exist. The programmer wrote his code incorrectly... if he wanted it to always look under /usr/local, he should've used an absolute path in his CL program -- but if he's not aware of how this works, he may assume that "creating a home dir causes trouble" or something like that.

Of course, the user can simply do CHGCURDIR DIR('/') and the CPYFRMSTMF will immediately work again... but as the CWD is an attribute of the job, they'd have to do this each time they signed on again. And not all users have the knowledge or computer skill to understand and use the CWD appropriately...

Another (really bad) fix that I've seen people do is change their homedir in their user profile so CHGCURPRF HOMEDIR('/'). This is a REALLY bad idea because many applications (especially those ported from Unix, which aren't too common on IBM i yet, but are becoming more and more common every day) expect to use the user's home directory to store user-specific settings. (SSH is an example of this.) If you change their home dir to the root ("/") dir, it will try to store their settings in the root of the IFS, and if all users were to do that, they'd all conflict with one another, and it'd be a big mess. You should never change your homedir just because you want a different CWD. If you really want a different CWD from your home dir, you should have an "initial program" or similar that runs the CHGCURDIR command...

But, really, the only proper fix if you don't want to use CWD, is to fix the CPYFRMIMPF command to use an absolute path.

Sorry for the long-winded reply... Hope that helps you understand what might be going on here.

[AntonyRobbins]

Re: Setting SSH keys on IFS prevents User Profile from Accessing IFS

Hi Scott,

Many thanks for the reply. I think this gives us a great insight into the problems we encountered and I'm now going to upset a few developers by telling them they need to revisit their code

[tomliotta]

Re: Setting SSH keys on IFS prevents User Profile from Accessing IFS

It should be clear that there might be a number of similar "time bombs" in production if the coding technique noted by Scott has been used in multiple places. (And it seemed to be involved from first reading.) Anywhere that IFS-naming has been used could be at risk if relative paths have been specified without simultaneous control of current directories. Developers should make sure.

[chris_hird]

Re: Setting SSH keys on IFS prevents User Profile from Accessing IFS

Scott,

Oops, sorry my code was wrong, as usual I know what I meant to say but did not spend the time defining it. Not enough time in the day as usual but your explanation was excellent.

Chris..