Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Restrict SSH or SFTP function, where vms account shares home dir with other users.

 
SOLVED
Go to solution
Doug_81
Frequent Advisor

Restrict SSH or SFTP function, where vms account shares home dir with other users.

Hello everyone:
I've been wrestling with the setup of sftp from a vms system to a unix system, utilizing batch mode (e.g. sftp "-B" "filename.com" remoteuser@remotehost.com)

I got it working and now the application support group has given me a list of accounts which require access to this function.

No problem, I simply have to copy the public keys and the identification. file to the ssh2 directory of each user and that's it.

That also works, but here (finally) is the problem.

I have a few hundred users who share the home directory and we want to restrict this function to a few accounts.

Any suggestions?

Here's some technical details:

Client:
HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 6 on a AlphaServer DS15 running OpenVMS V7.3-2

SSH version:
SSH Secure Shell OpenVMS (V5.5) 3.2.0 on AlphaServer DS15 - VMS V7.3-2

Thanks,
Doug
11 REPLIES 11
Hoff
Honored Contributor

Re: Restrict SSH or SFTP function, where vms account shares home dir with other users.

TCP/IP Services Tips: configuring ssh to disallow sftp and scp access:

http://64.223.189.234/node/347

has details on a couple of means of controlling access.
Doug_81
Frequent Advisor

Re: Restrict SSH or SFTP function, where vms account shares home dir with other users.

Tried modifying the sshd2.config in sys$sysdevice:[tcpip$ssh.ssh2] with the following line:
SftpDenyUsers username

I then restarted tcpip$client and the username I entered on that line was still able to exectute all of the following:
ssh username@remotehost.com
sftp username@remotehost.com
sftp "-B" "commandfile.com" username@remotehost.com

Doug
John Gillings
Honored Contributor

Re: Restrict SSH or SFTP function, where vms account shares home dir with other users.

Doug,

It sounds like the issue here is "share the home directory".

This is often a recipe for management headaches. I'd look at the reasons for this decision, as it can cause many nasty problems to do with file ownership and name clashes (for, example, do your users perform SORTs with default work files? Have you ever had two users SORT simultaneously?)

Assuming you decide you can't give each user their own directory... I'd expect that the keys and identification file are read before LOGIN.COM is executed, so you could create unique, "real" home directories for those users, as defined in the UAF. Then have their "real" LOGIN.COM (ie: the one in their home directory) redefine SYS$LOGIN, SYS$LOGIN_DEVICE and SYS$SCRATCH to point to the common directory, set default there and execute the common LOGIN.COM (even better, leave SYS$SCRATCH pointing at the unique directory to prevent temp files from clashing across users).

From the user's perspective, nothing will be different, but from the system perspective (at least up until LOGIN.COM has completed), they have distinct directories. So, things like SSH, MAIL, SORT and other utilities and applications can continue with their assumptions about unique directory space without problems like the one you describe.

You can distinguish these users because system defined SYS$LOGIN* logical names are EXEC mode, and yours will be SUPER mode, so you can have code which can find the "real" login directory, by requesting an explicit EXEC mode translation.

On the other hand, depending on the way your system is used (captive users?), it may be sufficient to simply SET DEFAULT to the common directory and leave SYS$LOGIN pointing to the unique directory.
A crucible of informative mistakes
Thomas Ritter
Respected Contributor

Re: Restrict SSH or SFTP function, where vms account shares home dir with other users.

Doug, if you just want a way to restrict the access then ACL the [.SSH2...] contents.
Something like

$ set file/acl=(id=*,access=none) ssh2.dir
$ set file/acl=(id=user1,a=r+e) ssh2.dir

you get the idea. The [.ssh2] contents provide the keys for non-password batch mode access to the destination host. Got that "non-password" access. The Auditors may spit the dummy on that.

As John has pointed out, sharing the same sys$login will have other problems.
John Gillings
Honored Contributor

Re: Restrict SSH or SFTP function, where vms account shares home dir with other users.

Thomas's idea should also work:

>restrict the access then ACL the
>[.SSH2...] contents. Something like
>
>$ set file/acl=(id=*,access=none) ssh2.dir
>$ set file/acl=(id=user1,a=r+e) ssh2.dir
>
>you get the idea

but rather than creating an ACL listing every user, I'd create a general identifier which can be granted to users who require access:

$ MCR AUTHORIZE ADD/IDENT SSH_ACCESS_ALLOWED
$ SET FILE/ACL=(-
(ID=SSH_ACCESS_ALLOWED,ACCESS=R+E),-
(ID=*,ACCESS=NONE)) SSH2.DIR

$ MCR AUTHORIZE GRANT/IDENT SSH_ACCESS_ALLOWED USER1
$ MCR AUTHORIZE GRANT/IDENT SSH_ACCESS_ALLOWED USER2
etc...
A crucible of informative mistakes