Hi there, I’ve detected a misconfiguration by default for the ssh server. I created a user and disabled the ssh access. However, if you go over sftp (filezilla client) the user is able to log in and even, can access the top level in the root directory. Keep the user into his home directory via sftp will be great.
Regards,
Dx
5 Likes
Hi @Dixan83 and welcome in our community. Nice to have you here!
I confirm this security issue.
Tried with WinSCP and had access to the whole file system, but not everywhere permissions to copy, open or modify files. Also I was not able to open a ssh session.
But, I was able to copy the vpn certs from /var/lib/nethserver/certs or to modify netlogon.bat in /var/lib/nethserver/netlogon. Don’t know what else is possible…
Thanks for reportig this in my opinion serious issue!
/cc @dev_team
5 Likes
Correct me if I’m wrong, but I think we have three issues:
- ssh access set to disabled permits sftp
- sftp permits to read files on the system
- sftp chroot (keep user in his home)
Regarding sftp vs ssh, I think that we could allow a user to read “his” files, without giving him shell access. I can’t think of a better/different option.
Regarding reading your files on your system via sftp, I think that we are behaving as expected.
Regarding the chroot, if we restrict a user to a single directory, he will not be able to read his files outside of that directory. If a specific user needs to be confined into a custom directory, we could develop a customization.
2 Likes
If you can copy the private keys it is a BIG issue… If you can copy just the public key there is NO issue.
This can be an issue just for NS6. IIRC it is not used anymore in NS7.
1 Like
is a big issue, if you disable ssh the sftp must deny the access. Then we have a security breach if the user with or without ssh access can navigate inside all server file directory via sftp. There are certain permission defined that the user cannot access but is possible read critical folders and files from the server.
The solution will be:
1- If ssh acces is disabled, sftp must be disabled also.
2- SSH-SFTP must be used inside a chroot jail to prevent escalate into the top directories outside the user home.
Thanks for the fast response team. I will be making testing
note: Im able to access to a lot of folders inside /var/lib/nethserver even into ibay with diferent folders with acl defined 
note 2: I can access to /etc and modify a lot of files with a normal user
Cannot reproduce this. Otherwise it would be a serious issue…
sftp> put yum.conf
Uploading yum.conf to /etc/yum.conf
remote open("/etc/yum.conf"): Permission denied
I don’t consider a security issue if a system user can read a configuration file.
Instead, it is a problem if a system user can read passwords and other secrets, or files that shouldn’t be readable.
1 Like
Please run this test
cp /etc/yum.conf /etc/yum.conf.bak ; stat /etc/yum.conf- modify it through winscp (with normal user access - not root
) - save in Notepad++
stat /etc/yum.conf ; diff /etc/yum.conf.bak /etc/yum.conf
1 Like
doublechecking all from zero:
user test without ssh enable but still has access via sftp and can escalate his own home directory:
Yes it is possible. This is not an issue at all as long as the expected file permissions are enforced.
1 Like
I will work on the chroot enviroment for ssh and post results but Im a little concern about the integration with all the services and the system.
That is normal for ssh, all user with ssh permision in a server (debian, centos, fedora, ALL) can navigate to the top but is is not acceptable modify or read critical file/folder, that is why jail the ssh service will hardening the server, then if we enable ssh for certain user the other user cannot allowed to access to sftp.
sorry my english
1 step: define as default /bin/rbash instead /bin/bash for all domain user. Via cli is possible define that but for cockpit or the old gui must be added that option.
O.k. I shot to quick. Sorry. 
I’m able to open the files and read it, but they are not saved or modified.
Is it obligatory that a normal user has to have sftp access?
If not, why not give another option to enabled/disable sftp access directly beneath the ssh checkbox with disabled by default?
Regarding the cert files: I’m able to copy the crt, csr, p12 files, the crl.pem and the dh1024.pem, but not the key file itself. But isn’t the private key bundled in the p12 file? Although it’s password protected, isn’t it?
That is the point, the regular user created for the AD even with the ssh disable can access to the entire server via sftp. Of course, there are some folder that contain permission that cannot access but, in my case, I was able to download critical files even from /etc and /var/lib/nethserver
Must be solved the initial issue: ssh disable sftp must be disabled also. With this issue solved then we can go over the jail for ssh users. For now, I disabled the ssh service globally. I will try to recreate the ssh jail from my own but will be in the weekend.
systemctl disable sshd.service
systemctl stop sshd.service
I can work with the console via cockpit until ther issue is solved.
The console in cockpit also needs ssh. You better should’t disable ssh if you can’t access the server physically.
I have access via terminal using the gui with the ssh service disabled. I gess that are diferent way to access to the server cli.
to disable sftp comment the line in /etc/ssh/sshd_config
Subsystem sftp /usr/libexec/openssh/sftp-server
then restart sshd
systemctl restart sshd
but it is global, yo can still use ssh
I tried that also, but still working for some reason. Let me try again
to exclude a list of users (typically no shell access)
Match User stephane,toto,tatta,titit
MaxSessions 0
these users wont even see the motd, I think it is the good security way
we need to make a template, list users without access and expand there)
cc @dev_team