Remove SFTP access for sudo user and allow user to run only specified script

I have created a username test123 and added it to wheel group.But adding it to wheel grants all privileges.So I removed it.

So My condition is
1.I want to give the user only "shutdown -r now" command rights
2.And to run 2 python script abc.py and xyz.py
3.Remove SFTP access for user test123

I achieved the first 1 by editing sudoers file and adding line
test123 ALL = (ALL) /sbin/shutdown -r now

But for 2nd and 3rd I need help
 
1 - You can just add the user to the operator group, however it will also be allowed to reboot, halt etc;
2 - Those scrips should be run by root? You may want to take a look on security/doas [doas.conf(5)] to use that instead of security/sudo.
3 - SFTP access is handled in the /etc/sshd_config.

I want to run the script as test123 and also want to remove the SFTP access for test123.But test123 should have to access to run these 2 python script.
I don't know to remove SFTP access for a particular user.
 
You can block SFTP but you cannot block SCP if the user has SSH access.
 
The user
You can block SFTP but you cannot block SCP if the user has SSH access.

What you said is right ,I added the line DenyUsers test123 in sshd_config file and I saw that I cant connect to sftp as well as ssh

But my requirement is that user should not connect to FTP as he may can download my files which are in other location.But he should be able to execute python pyton script

If somehow I can restrict the test123 user to his home directory ,its ok for me.I am stuck here and need help
 
If somehow I can restrict the test123 user to his home directory ,its ok for me.
This is probably your best option, you can do this using the ChrootDirectory option:
Code:
     ChrootDirectory
             Specifies the pathname of a directory to chroot(2) to after
             authentication.  At session startup sshd(8) checks that all
             components of the pathname are root-owned directories which are
             not writable by any other user or group.  After the chroot,
             sshd(8) changes the working directory to the user's home
             directory.  Arguments to ChrootDirectory accept the tokens
             described in the TOKENS section.

             The ChrootDirectory must contain the necessary files and
             directories to support the user's session.  For an interactive
             session this requires at least a shell, typically sh(1), and
             basic /dev nodes such as null(4), zero(4), stdin(4), stdout(4),
             stderr(4), and tty(4) devices.  For file transfer sessions using
             SFTP no additional configuration of the environment is necessary
             if the in-process sftp-server is used, though sessions which use
             logging may require /dev/log inside the chroot directory on some
             operating systems (see sftp-server(8) for details).

             For safety, it is very important that the directory hierarchy be
             prevented from modification by other processes on the system
             (especially those outside the jail).  Misconfiguration can lead
             to unsafe environments which sshd(8) cannot detect.

             The default is none, indicating not to chroot(2).

If you really want to get fancy you can put it inside a Match User block so only this particular user is in a restricted chroot(8) environment.
 
For the standard ftp server (which comes with the system) chrooting is straight forward: create file /etc/ftpchrootwith
Code:
tempuser /home/test123/.
This will lock that user in his home directory.
 
Somehow I restricted user test123 to his home directory by following these steps

Created a group sftponly and added test123 to that group

Code:
pw groupadd sftponly
pw group mod sftponly -m test123
chown -R root:sftponly /home/test123
chown -R test123:sftponly files/

Add this line at the end sshd_config

Code:
Match group sftponly
PasswordAuthentication no
ChrootDirectory /home/%u/
ForceCommand internal-sftp
X11Forwarding no
AllowTcpForwarding no

But I have to allow shell access to execute 2 python scrips for example script abc.py and xyz.py
 
Just a small sidestep, I'm a little late to the thread (just spotted it) but want to set one thing straight:

I have created a username test123 and added it to wheel group.But adding it to wheel grants all privileges.So I removed it.
Whatever gave you that weird idea? The wheel group is just that: a group. It does not give a user "all privileges", the only user account which gets that treatment is an account with UID 0.

Code:
feliner:/home/peter $ id
uid=1001(peter) gid=1001(peter) groups=1001(peter),0(wheel),1002(video)
feliner:/home/peter $ shutdown -r now
ksh: shutdown: cannot execute - Permission denied
feliner:/home/peter $ ls -l `which init`
-r-xr-xr-x  1 root  wheel  606136 Feb  1  2017 /sbin/init*
feliner:/home/peter $ init 0
init: Operation not permitted
What it does do is grant the user permission to execute the su(1) command in order to switch to root (UID 0). But the only reason why that is happening is because of /etc/pam.d/su, there are no 'magical powers' at work here which suddenly elevate a users permission just by placing him in the wheel group. That is plain out nonsense.

Also noteworthy is that even if a user is in the wheel group then they'd still need to know the root user password before they can actually invoke that.

I'm not saying that usage of the wheel group should be casual, but it's also hardly as dangerous as you make it out to be here.
 
But I have to allow shell access to execute 2 python scrips for example script abc.py and xyz.py

https://research.kudelskisecurity.com/2013/05/14/restrict-ssh-logins-to-a-single-command/

Since he'll need access to two scripts, you need to create a shell wrapper with a case-statement:
Code:
# cat /usr/local/bin/wrapper.sh
                                      
#!/bin/sh
script_cmd="/usr/bin/script -a [-q] log.file"
case "$SSH_ORIGINAL_COMMAND" in
    "ps")     $script_cmd ps -ef ;;
    "vmstat") $script_cmd vmstat 1 100 ;;
    *) echo "Sorry. Only these commands are available to you:"
       echo "ps, vmstat"
       exit 1 ;;
esac

# cat ~user/.ssh/authorized_keys
command="/usr/local/bin/wrapper.sh" [user's key]
https://serverfault.com/questions/749474/ssh-authorized-keys-command-option-multiple-commands

It's been awhile since I set that up, but it's clear it will log whatever activity that user performs on the server, and will restrict his access to the ps and vmstat commands. Edit it to accomplish your task.

Edit: I found the guide I used years back: http://www.linuxjournal.com/magazine/paranoid-penguin-managing-ssh-scripts-and-cron-jobs
 
https://research.kudelskisecurity.com/2013/05/14/restrict-ssh-logins-to-a-single-command/

Since he'll need access to two scripts, you need to create a shell wrapper with a case-statement:
Code:
# cat /usr/local/bin/wrapper.sh
                                     
#!/bin/sh
script_cmd="/usr/bin/script -a [-q] log.file"
case "$SSH_ORIGINAL_COMMAND" in
    "ps")     $script_cmd ps -ef ;;
    "vmstat") $script_cmd vmstat 1 100 ;;
    *) echo "Sorry. Only these commands are available to you:"
       echo "ps, vmstat"
       exit 1 ;;
esac

# cat ~user/.ssh/authorized_keys
command="/usr/local/bin/wrapper.sh" [user's key]
https://serverfault.com/questions/749474/ssh-authorized-keys-command-option-multiple-commands

It's been awhile since I set that up, but it's clear it will log whatever activity that user performs on the server, and will restrict his access to the ps and vmstat commands. Edit it to accomplish your task.

Edit: I found the guide I used years back: http://www.linuxjournal.com/magazine/paranoid-penguin-managing-ssh-scripts-and-cron-jobs

The solution works perfectly given by you but what if in future I want the user to execute any commands but with no sftp access?
 
The solution works perfectly given by you but what if in future I want the user to execute any commands but with no sftp access?
You're overlooking something really important, you can copy files with SFTP yes, but you can copy the exact same files with scp(1). So even if you somehow manage to disable SFTP access you cannot disable scp(1) without also denying regular SSH access. And even if you manage to block SFTP and SCP you can still use ssh user@host cat /some/file | cat > local_copy to effectively archive the same result, copy a file.

Allowing someone SSH access implies certain abilities, some of which simply cannot be prevented by configuring sshd(8). In those cases you're going to need to rely on proper permissions/access rights.
 
Allowing someone SSH access implies certain abilities, some of which simply cannot be prevented by configuring sshd(8). In those cases you're going to need to rely on proper permissions/access rights.

This is not true. [Edit: missed updated “run any command” desire from poster above.] A carefully crafted .ssh/authorized_keys file with a command= directive (and potentially a wrapper as described above is using only one key is desired) for users with no password set — and no alternative authentications via pam.d, such that only shared-key authentication is available — will do what it requested; access to particular command with no shell access. (This requires the commands to not be “escapable” — allowing the user to only run “/use/local/bin/python” would not work, as it is just another shell, effectively. A python script (controlled, and audited to not have any way to “get out”) should be OK.)

This configuration is often used for svn+ssh:// configurations with one ‘svn’ user on the system, but multiple users for the svn server: http://zeroset.mnim.org/2012/08/14/...d-a-single-unix-account-without-shell-access/

It is true that disabling sftp for a ssh user with shell access is pointless from a security standpoint, which I think was what you were getting at.
 
This is not true. A carefully crafted .ssh/authorized_keys file with a command= directive (and potentially a wrapper as described above is using only one key is desired) for users with no password set — and no alternative authentications via pam.d, such that only shared-key authentication is available — will do what it requested; access to particular command with no shell access.
Except that wasn't what he asked:
what if in future I want the user to execute any commands

So that excludes the command directive.
 
Except that wasn't what he asked

Too right! That’s what I get for skimming new posts and not reading the entire thread! Apologies.

TLDR; disabling sftp for a user who can run “any command” is security theater of the highest form. (Pointless and dangerous by implying some form of security.)
 
Back
Top