Hello,
I'm running an nginx server on debian jessie.
This is a physical (single core, 2GB RAM, 1TB hd) machine sitting under my fridge.

I want to give an interested young person a "server playground" - much like shared hosting, I'd say:

• user account
• ssh access
• access to installed programs
• a fixed webroot with the possibility to execute php and other server-side scripting.
• no sudo access, no root password

How can I make reasonably sure that if something goes wrong, it will only affect that user account?
In other words, how can I keep my server safe?
Right now I have no idea what this person might be up to, but that's sort of the point: they should get a playground to get aquainted with things and maybe make a decision if they want to pursue a career with networking/computing/linux etc.

For now I'd just assume that I don't need to cap filesystem usage, but if performance is possible to cap, would be good.

I'd also assume that they won't try to deceive me, but of course it's possible they'd unwillingly install some malware or give access to it...

Also, if I decide to do this, is there a possibility to provide them with an ssh key straight away, to avoid password access completely?

Virtualbox. Spin up their own instance, and let them have at it. Since it'll be running THROUGH your machine, a squid/dansguardian server should be trivial to throw up between the VM and the rest of the network. Same with disk quota...allocate a smaller image, and they CAN'T go bigger. Make a copy of the VDI somewhere before they start...if the instance gets hosed, you can just copy it back and delete the damaged one. If they do something bad....easier still to ban/remove access.

For SSH access, you can have them send you a public key and then you put it in their authorized_keys file yourself. A password is not needed but if it is you can put a temporary one in a file hidden in their home directory with the requirement that they change it when they first log in. That is easy enough to verify, too.

As for sudo it is not all-or-nothing root access. There may be some level of control that you want to grant. Then again there may not be.

Server-side includes, especially if done noexec, would be a very good place to start for them before moving on to php, python, or perl CGI. For you the benefit is that it is secure and there are no moving parts so to speak. For them they have the benefit of templates and standardized menus, headers, footers, and so on. They should definitely have their own vhost in nginx, it can be a port-based vhost if you don't have multiple domain names for that box.

As for PHP, there is a not a snowball's chance that it can be let safely out on the net with a beginner. Similar warnings go for python and perl CGI too. So if you let them do those on the web, I'd give them their own vhost in nginx but make that vhost visible only to 127.0.0.1 and then let them tunnel their connection to it over SSH.

For resource limits, you might check "man limits.conf" for PAM.

TB0ne: virtualisation was my first thought, too.

maybe i haven't made it clear enough, but the machine in question has a 32bit cpu and virtualisation would get no hardware support. it's a 10 year old laptop.
that made me think that virtualisation is out.
maybe "squid/dansguardian" are still useful keywords...

but if i just give them the user without any superuser privileges, what could go wrong? where do i have to put in some extra effort not to endanger my server?

i'm fairly clear that for now there will be no elevated privileges.
this machine only runs as a server with no gui, and i think the default user has suitably limited privileges anyway (debian tradition).
if the person turns out to be interested, they will hit a wall and probably contact me about that.

good tip!
never knew nginx manages that.

i hear you.
i think i'll have to reconsider my original plans there.

For learning purposes, you might still give them privileges for something more or less harmless, such as starting/stopping nginx. It will probably seem like a big responsiblity to them to have the option even though they will never need to do it. Thus it helps teach them a bit of responsibility and maybe restraint. At the same time, it is fairly innocuous and unlikely to cause trouble for you.

Well, Turbocapitalist had some good suggestions; didn't know about your machine situation, so yeah, VM would be right out.

That said, restricting sudo access to certain commands is easy enough. You can also set up a chroot jail for the SSH USER itself:
http://allanfeid.com/content/creatin...ail-ssh-access

...much like FTP users. That way, the rest of your system is insulated.

... is in fact what sudo was designed for originally before Ubuntu decided to get involved.
Do read up on the warnings though that many programs let the user out eg editors and many others might be possible to break out of...

^ are you refering to the article linked by TB0ne, or to sudo in general?
what exactly do these programs break out of?

hmm.
i started learning linux first, and when i got to doing some "server stuff" it was shared hosting with no sudo access.
i still had plenty to learn, and in retrospect it was good to feel the limitations, and understand the reason.
the person in question hasn't even started with linux, yet they claim to be interested in... well, that's where it gets a little foggy... computers? coding & design?

thanks!
looks like the sort of advice i've been asking for.

Creating a general-system chroot for shell access is quite a bit of work. Some of it can be automated using the package debootstrap. Harddrive space will not be an issue since you have a humungous drive. chroot is only for the file system, it does not isolate memory, processes, the kernel, network, or anything else.

You might also consider setting up a short script to launch a shared tmux session. Then if you want to walk them through something you can be on the phone or VoIP (SIP such as Jitsi, Blink, etc.) while both looking at the same login session. The preparation for that is to have a group where you are both members. Then launch tmux and chgrp the tmux socket to be in that group and chmod to g=rwx It is easier if the socket path is set manually by the script so as to take the guess work out of finding it.

There are shell escapes in quite a few programs. vi and less are two common programs with that misfeature.

For general programs that is fixed by adding NOEXEC to the appropriate rule inside the configuration.

For editors, that is fixed by using sudoedit to launch the editor instead of raw sudo. It makes a copy of the target file, then launches the editor of choice as an unprivileged user. When the file is saved and the editor exits, the changed file is copied over the target file. So the editor never has elevated privileges and thus any escapes are rendered moot.