Hot answers tagged account-restrictions
24
You can set that user's shell to rssh or scponly, which are designed precisely for that purpose:
rssh is a restricted shell for use with OpenSSH, allowing only scp and/or sftp. It now also includes support for rdist, rsync, and cvs.
scponly is an alternative 'shell' (of sorts) for system administrators who would like to provide access to remote ...
16
Under no circumstances would anyone want to do that. This is what sudo is for, to give users the ability to run things as root. Giving a non-root user all the permissions of root is inadvisable because they would then be able to do literally anything, so if that user account was hijacked, you'd be in trouble.
Summary of above: Don't try to give the user ...
11
Similar to the other answers, but in the direction you wanted.
if [[ $EUID -eq 0 ]]; then
echo "This script must NOT be run as root" 1>&2
exit 1
fi
Alternatively, you can use sudo within the script to force execution as the non-privileged user using the -u flag to specify the user to run as. I don't use Glassfish, but here's a proto-example ...
11
The correct way according to usermod(8) is:
usermod --lock --expiredate 1970-01-01 <username>
(Actually, the argument to --expiredate can be any date before the current date in the format YYYY-MM-DD.)
Explanation:
--lock locks the user's password. However, login by other methods (e.g. public key) is still possible.
--expiredate YYYY-MM-DD ...
9
You don't need to create 'sybase' as a privileged user.
See http://tldp.yolinux.com/HOWTO/Sybase-ASE-HOWTO.html for examples. Useful info:
"create the sybase user group and then the sybase user as a member of it. This is an ordinary user that will be used mainly for starting the database server"
bash$ su - root
bash# groupadd sybase
bash# useradd -g ...
7
There's a command option in authorized_keys file. This options seems to do exactly what you want.
Note that it's not a chroot or a restricted shell. It's allowing to execute only those commands via ssh. With your example, it would be :
ssh somehost /local/remote_only_scripts/foo
For this authorized_keys file :
...
6
On the server side, you can restrict this by setting their user shell to /bin/true. This will allow them to authenticate, but not actually run anything since they don't get a shell to run it in. This means they will be limited to whatever subset of things SSH is able to offer them. If it offers port forwarding, they will still be able to do that.
On the ...
5
You could used a forced command if the users can only connect through ssh. Essentially, whenever the user connects through ssh with a certain key and a certain username, you force him to execute a command (or a script or) you determined in the .ssh/authorized_keys. Commands issued by the users will be ignored.
For example:
# in .ssh/authorized_keys
...
5
This is a pretty standard reason to change the shell. Typically /bin/false or other shells like /bin/cat are used.
Typically you can't escape from /bin/cat and it is unlikely that cat has a security bug but other methods may still work, like creating a DoS or bypassing Firewall rules.
Another probably more severe problem is if you are using the ...
5
Do not do this. rbash should only be used within a chroot unless you know what you are doing. There are many ways to break out a restricted bash shell that are not easy to predict in advance.
Functions can easily be overridden simply by doing command bash or command sh.
As for your questions:
You can't define multiple functions at the same time directly. ...
4
You will need to ensure that the chroot that the users is put in has access to the directory by bind mounting into the chroot tree:
mount --bind /Volumes/Storage /path/to/chroot
The user will also need to have necessary filesystem permissions to read the data on the drive. The easiest way to accomplish this would be to put the user in a supplementary ...
3
There are very many ways of achieving this, you need to have an idea of what "some other actions" are before you can choose the solution.
Assuming that all you want is to prevent copying to usb devices, you could just prevent all usb storage devices from being mounted (blacklist that module). Or you could make the usb storage devices read-only (via udev), ...
3
You can use command keyword in authorized_keys to restrict execution to one single command for particular key, like this:
command="/usr/local/bin/mysync" ...sync public key...
Update:
If you specify a simple script as the command you may verify the command user originally supplied:
#!/bin/sh
case "$SSH_ORIGINAL_COMMAND" in
/path/to/unison *)
...
1
I don't completely understand your requirements: which machine are the users to be jailed on? Can they do anything that doesn't involve the network? Nonetheless I think I can tell you what the necessary building blocks are.
To restrict a user to specific network connections, see
How to restrict internet access for a particular user on the lan using iptables ...
1
You can remove execute permissions for the binaries you don't want the user to run. Create a new group, change the execute permissions (chmod go-rwx), and add the desired user to the group. (This is similar to how only certain users are allowed to use the sudo command.)
Depending on what you want to achieve, chroot jail might also be useful. In case you're ...
1
I guess you can achieve this by setting the user's login shell to something very restricted, e.g. something like "Sleep Dummy Shell". Quoting it's website,
This is a simple do-nothing, sleep-forever program that can be used as a login shell (in Linux or Unix) to keep the connection open but without interactive shell. We use it to create SSH accounts for ...
1
No. Generally speaking, the unix permission model only has two levels: root, and the rest. Root can do everything, and non-root users each have their own domain. Non-root users cannot create subdomains inside their security domain.
There is a way to create security domains as an ordinary user: run a virtual machine of some kind (VirtualBox, User Mode Linux, ...
1
@Tshepang has the right idea. I don't know which is most portable, but here are other ways to detect whether the user is root:
id -u
$UID
Alternatively, you can simply force it to run as another user with the same parameters:
if [ "$UID" -ne 0 ]
then
sudo -u appuser "$0" "${@-}"
fi
1
To delete entirely it use userdel.
Please note that if you delete an account there is a risk that its user ID will still be used in the file system somewhere and a new user would inherit ownership of those files if it came in under that same user id.
You would want to change the owner of any files that are owned by the deleted user.
If you would like to ...
1
Yes, you can create a password-less account.
sudo useradd -m guest
sudo passwd -d guest
Important, though, it to make sure no network daemons like sshd will allow access to password-less accounts. That's usually default, but it's good to check. Make sure PermitEmptyPasswords is no/false in /etc/ssh/sshd_config or just try and ssh into guest and see if ...
1
No, you don't. As Gilles pointed out, rssh works very nicely to this end, as does scponly. See also the discussion in this related question.
Only top voted, non community-wiki answers of a minimum length are eligible
