For a typical computing tutorial the students have been given some exercises to do, usually programming or similar, so will spend most of their time working on the computer rather than in discussion or question and answer sessions. As this is a bit different from other tutorials across the university, here are some specialised suggestions to accompany the general university resources.
Your correct place is standing behind, or sitting next to, the student. You tell them what to do, they actually type or click what you said. Never type in code or commands for a student, of any kind, whether related to the tutorial or not.
It is very tempting to show a student what to do by doing it yourself, or to fix some setting or environment option that will make the lab easier. You'll tell yourself it will be much quicker and avoid the student floundering around or running into dead ends. But it's the wrong thing to do.
Students have to be able to do this stuff themselves. Obviously, they can't expect you to be present half an hour before midnight when the assignment is due. Less obviously, it is essential that computing students develop a sense of control over the computer, that they feel there is nothing in the course they can't do themselves if they have to. They can only develop by doing not watching, just as you can't become a professional footballer from watching TV.
For the same reason, don't let students type anything for other students either. Encourage them to talk to one another, but make it clear that the keyboard and mouse are for the owner's use only.
If you see a student typing in code that you know is wrong, or a command you know won't work, don't interfere. Keep quiet and wait to see if they need any help in understanding what went wrong. Again, students have to learn how to solve these problems without your help. Saving them some time now will ultimately cost them more time later on.
This isn't quite as absolute as the "Never type anything" suggestion. One exception is for mistakes that can't be corrected, such as typing rm *. If you see something disastrous about to happen, by all means ask "Are you sure you want to do that?" before they can hit the Enter key.
Another is that once students are competent in basic syntax error detection and correction, say second year onwards, you can help them with typos. These are always difficult to spot if you are the original author, so they will just waste time without actually learning anything new if you leave them staring at the screen.
Once students have made a mistake, try not to tell them the answer. I like the Socratic method myself: instead of pointing to a section of code and saying "This is wrong", point to a section of code and ask "What are you trying to do here?" (Since none of us are infallible, this also avoids embarrassment when the piece of code you are pointing at turns out to be correct.)
For first year students in particular, never try to solve all the problems at once. If there are several lines in the source code generating a lot of error messages from the compiler, it's better to help the student fix just the first line and try again, even though you know there will be further messages.
Don't sit at one end of the room and assume students will come to you for help. Do slow circuits of the lab instead. Try not to be obtrusive about it, but keep up to date on how students are progressing.
By watching what some students have problems with, you can anticipate problems elsewhere. If a number of students in the lab seem to be having the same problem, you might choose to stop everyone for a brief micro-lecture.