Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is it possible to create a "guest" account in Linux? by "guest" account I mean an account that does not require a password to log in graphically.

I want this account for when people come over and are like "can I use your computer to check my email". Then I don't have to worry about them snooping my stuff.

I realize that some of this may require doing stuff specific to the login manager, since I wouldn't be surprised that this is a common problem, it'd be best to include instructions for xdm, kdm, and gdm and any other login managers that I haven't listed.

share|improve this question

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 it allows you. There may be other daemons like Samba you should check for as well. If you want to restrict the user from accessing your local files, you can either go to great lengths like setting up a chroot with pam_chroot.so and the like, or instead, just restrict your data to you. Make use your home directory does not allow the "other" class to read your files and lock down any other locations you think you need to.

share|improve this answer
tried it, I can't su - to guest, which means guest can't log in, which is not what I'm trying to accomplish. – xenoterracide Apr 8 '11 at 0:43
Please do more testing or ask for help before voting a perfectly good answer down. Yes, su - guest will fail when run from an X Terminal or a remote shell session. That's because in some file like /etc/pam.d/common-auth there is an argument to pam_unix.so called nullok_secure That means a null or password-less login is ok only as long as it's on a secure terminal. Some random X Terminal or remote shell is not considered secure, but your trusty X/Gnome/KDE Display Manager is considered trusted as well as a local Text Console. Please try to login via one of those and be happy. – penguin359 Apr 8 '11 at 3:07
You can change nullok_secure to nullok if you really want to always allow guest to login through any old terminal using su - guest or similar, but I recommend against it. It sounds like you really only need guest to login via the nice little Graphical Login screen on your desktop. I tested my exact solution and it did work on a relatively stock and freshly installed Ubuntu 10.10. Yes, su - guest did fail when I did it from an X Terminal, but worked from a Text Console. – penguin359 Apr 8 '11 at 3:10
@xeno The official docs on Down Voting: "What are the alternatives to downvoting? The upvote privilege comes first because that's what you should focus on: pushing great content to the top. Downvoting should be reserved for extreme cases. It's not meant as a substitute for communication and editing." – penguin359 Apr 8 '11 at 3:25
After re-reading my original answer, there was nothing Ubuntu specific in it. It applies equally to Fedora, RHL, Gentoo, and Debian as well. Some more obscure distro might place the sshd_config file elsewhere, but I'd expect you to be able to find it or ask for help. A quick locate sshd_config should locate it. My first comment assumed nullok_secure was enabled by default which might be Ubuntu specific, but hopefully that would encourage one to look at their PAM config and read the man page for pam_unix or at least ask a question. A quick grep -r pam_unix /etc/pam.* should help. – penguin359 Apr 8 '11 at 22:15

Sorry, I don't actually have a way to do what you're asking, but I think this answer will be helpful nonetheless.

What do you mean by “does not have shell access”: do you mean that the user must only be able to use a few applications (e.g. a web browser and a mail client)? If so, you need to make sure that the applications won't inadvertently allow the user to run arbitrary commands. That's hard to ensure in practice.

This is generally known as a kiosk setup. There are many Linux kiosk projects, but most aim at making a kiosk machine, not a kiosk account that must coexist with other accounts.

A kiosk account is harder to secure. I think you'd have to use something like SELinux or a virtualization technology to prevent the guest from snooping on publicly-readable files (or else manually tighten all permissions, but there are things that are cumbersome to protect, such as the user list (/etc/passwd)). I don't know of any project that offers this out of the box.

It should be relatively easy to set up a guest virtual machine with VirtualBox. VirtualBox has a kiosk mode where you can disable all VM controls in the GUI. Then you can run that VM as the sole application on an X server. Make sure to lock all other consoles when you're not using them, and voilà, you have a kiosk vt. Of course, the VM shouldn't be sharing any folder and its networking should be limited to outgoing NATted connections.

Inside the VM, you can run a kiosk setup, but that's not even necessary. Just take a snapshot of the VM and discard that snapshot after a guest has been using it. If you need to perform upgrades, start from the snapshot, upgrade, then make a new snapshot.

Coming back to having a guest user (and not addressing guest restrictions here), on the authentication side, there's nothing special to set up in each login manager. The whole point of PAM is to be independent of the session type. Make a user who can't log in normally, and allow that user to log in through a pam_userdb line for the login method(s) you want to authorize (something like auth sufficient pam_userdb.so db=/etc/passwd_guest in /etc/pam.d/?dm, with /etc/passwd_guest containing guest::9999:9999:/home/guest:/bin/sh and /etc/passwd containing guest:x:9999:9999:/home/guest:/bin/false).

share|improve this answer
I'm just gonna remove the restrictions part, 'cause it's not that relevant to the actual problem, now that I think about it... which makes all your kiosk part of the answer unnecessary. – xenoterracide Apr 7 '11 at 21:48

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.