tcpip$ssh_sshd2 crashes on some users

[David Jones_21]

I'm running TCPIP 5.6-9 ECO3. Users whose default directory is on one disk get an immediate disconnect after successful login via ssh. Users on other disks don't get disconnected.

The tcpip$ssh_run.log files for the disconnecting session show an ACCVIO. I'd guess it's having difficulty looking for the user's ssh2 directory.

[Richard W Hunt]

First question I'd ask is to look for differences in the two disks, such as device permissions (SOGW for a device), volume permissions (SOGW for a volume), and directory permissions for the directories.

Second thing is whether the offending disk is ODS-2 or ODS-5 and is that different from the disks that work?

Third thing is whether the offending disk and the non-offending disks are on the same controller (and is one a SAN and the other local)?

Fourth, I've seen ACCVIO terminations on previous versions of SSHD. The folks that hit us the hardest are those who are either CAPTIVE or RESTRICTED, and for which their command shells trap all errors and log those people off instantly (rather than to allow the shell to abort and let these users see the DCL prompt.)

If you turn up logging level (see, for instance, file SYS$SYSTEM:TCPIP$SSH_RUN.COM as a place to turn up logging level), see what it is trying to do just before it barfs.

[David Jones_21]

It looks like it's not particular disks, but certain home paths it doesn't
like.

It did several tests with a dummy account.
Environment:
physical disk: $21$dka0: (label USERS)
directory tree: [trial9.level1.level2.level3]
logicals:
DISK$USERS $21$DKA0: [conc,term]
BSDISK $21$DKA0:[TRIAL9.] [conc,term]
BSDISK_LEVEL1 $21$DKA0:[TRIAL9.LEVEL1.] [conc, term]

Login default directory tests:
bsdisk_level1:[level2] PASS
bsdisk_level1:[level2.level3] fail
bsdisk:[level1.level2] PASS
bsdisk:[level1.level2.level3] fail
disk$users:[trial9.level1.level2] fail
disk$users:[trial9.level1] fail
disk$users:[trial9] PASS
$21$DKA0:[trial9] PASS
$21$DKA0:[trial9.level1] fail

In general, the accounts that fail use a concealed device logical with 2 levels
in the concealed directory. The test with bsdisk_level1:[level2] should have
failed if it was just simply number of directory levels though.

[Jan van den Ende]

David,

please check whether the concealed devices (as specified in SYSUAF) are defined correctly.

They MUST be systemwide, and MUST be /EXEC mode.

And, while not for any tcp related stuff (Oracle DBMS to wit), I _HAVE_ seen CLUSTERwide LNMs being NOT honored, so that MAY be worth checking as well.

hth

Proost.

Have one on me.

jpe

[David Jones_21]

They are exec mode logical names. Logins via non-SSH paths have no problems.

If you alias [alias3] and [level2.level3] to the same directory, the former works and the latter gets the ACCVIO.

[Richard W Hunt]

Be aware that SYS$SYSTEM:TCPIP$SSH_RUN.COM contains a snippet that will try to purge log files for you. I have seen other errors when users open more than one window at a time from their workstations where the purge fails because a file is locked. Not saying that is it, but just be aware that SSH interactive logins have "baggage."

For instance, the version I'm looking at would attempt to do some define/process commands based on a translation of spec.

TCPIP$SSH_DEVICE:[TCPIP$SSH]

See if there is problem with that definition and whether you can reliably look up

SYS$SYSTEM:TCPIP$SSH_SSHD2.EXE

which is also part of the SSH_RUN file.

Finally, look at all of the TCPIP$SSH_RUN.LOG files to see if they show funkiness before the Access Violation. Like, maybe, warnings that wouldn't abort the implied script but that might indicate something else isn't defined properly.

[Richard W Hunt]

Another thought came to mind.

What is in SYSUAF for the DEFDEV and DEFDIR values for the working and non-working accounts?

[Richard W Hunt]

I was browsing through an SFTP topic when I ran across this issue:

Occasional ACCVIO in SCP when the username and the owner-identifier string don't match - the case in question where the USERNAME was JOE and the account's identifier was [USERS,FRED]. Could this apply to the ones who fail?

[David Jones_21]

I applied ECO 4 and no longer get the crashing of SSHD. I found nothing in the release notes about fixing this particular issue.

[David Jones_21]

Thanks all.