This answer should still help you, even taking the edits to the
question into account. In particular, an account created with
--disabled-login has no password set and no other means of logging
in, but it should still be possible to use
sudo (explained below)
to run commands or a shell as the user. This is, in fact, how the
root account is set up in Ubuntu.
There are multiple problems with the command
su - irssi.
This command tries to start a shell owned by a user named
It will fail if:
- There is no
irssi user's account is disabled.
irssi user's account is disabled for interactive login. Sometimes an account is permitted to use services like FTP but prohibited from logging in normally by setting their shell to something that quits immediately, like
/bin/false. Then a login immediately ends, with no message.
- The password you're entering is not correct for the
- flag makes it so the shell simulates an initial login shell--that is, so it's really very much like logging on as
irssi. Without the
- flag, if the
su command succeeded, you'd still get a shell owned by
irssi, but environment variables like
HOME would be unchanged.
If you instead want to run a program called
irssi, you must invoke
su username - -c irssi
If you leave out
-c username, it's the same as
-c root--it attempts to run the command as root.
Alternatively you can start a shell and then run the command:
- Start the shell with
su username -.
- In the shell, run the command (
- If you're done, leave the shell by running
Running Commands as
If you want to run
su is not the way to do it. Root logins are disabled by default on Ubuntu, and there is only rarely any reason to re-enable them. If you have enabled
root login, then you should be able to use
su to become
root. The reason it's unnecessary to enable the
root account is that, whether or not you do, you can still run commands as
When you run commands with
sudo, you put in your password, not the password of the user under whose identity you wish the command to run. Only administrators may run arbitrary commands as
sudo (unless you reconfigure
sudo to allow others to do so, of course). So a user who is not allowed to administer the system is not allowed to run commands as
root with their own password.
And you would enter your password when prompted, not
Except what password you enter, this does the same thing as:
su -c irssi
sudo version can succeed because it doesn't require the
root account to be enabled.
su, you can use
sudo to run commands as another, non-
root user. To run
sudo -u username irssi
If you want
sudo to behave like
su - with respect to
HOME--that is, you want to use the target user's
HOME environment variables, you can run
sudo with the
sudo -H irssi
sudo -H -u username irssi
You can start a whole shell with
sudo, like you can with
su. Except for whose password you put in, this command has the same effect as
And this command has the same effect as
i stands for initial login shell.)
You can start a shell as another user, too:
sudo -u username -s
sudo -u username -i
Further Reading on
To learn more about
sudo, take a look at:
gksu work when
gksu probably worked by running
gksu is a frontend for both
sudo. In Ubuntu, it defaults to using
sudo (since in Ubuntu,
su is typically not used for becoming
root, and is only a secondary way of becoming other, non-
You can make
su as the frontend by running
You can find out whether
gksu is in
su mode or
sudo mode, and (if you wish) change this setting, by running
gksu-properties. This is a per-user setting.
gksu is in
sudo mode, it behaves the same as
Further Reading on
You found ultimately that you were able to run the necessary command with:
sudo -u username irssi
(Which is of the techniques listed above.)
Ultimately, you reported two pieces of information, which are sufficient to explain why it was that other techniques had failed, but that had succeeded:
username account was created with the
--disabled-login flag, which makes it have no password (and no other means of logging in). Having no password doesn't mean it's possible to log in with a blank password. It means no password is sufficient to authenticate. In combination with the elimination of other means of authentication, this means
username cannot authenticate at all.
su-based solutions are out.
sudo can work though, because with
sudo you don't authenticate as the user you're about to impersonate. Instead, you have to be authorized to impersonate them, and you authenticate as yourself (i.e., enter your own password, not theirs).
It's possible to set a password on the account, which removes this barrier to logging in:
sudo passwd username
However there might be a good reason the user is not allowed to log in. For example, if this user were allowed to log in, and logged in graphically, would bad problems arise from the user's environment or privileges being poorly suited to running X11 apps? If this user could log on, would that make it possible to log on remotely as that user (for machines where you have exposed network services)?
If you ever want to re-disable it:
sudo passwd -dl username
Related: Re-disabling the
root account after having temporarily enabled it.
username account has
/bin/false as its login shell.
When a shell like
bash runs as your login shell, it sets up your environment and gives you an interactive prompt with which to control the machine.
/bin/false runs, on the other hand, it does nothing, and reports failure. (
/bin/true does nothing and reports success.)
true commands are useful in scripting and for various testing purposes, but also for disabling an account so that when someone logs in, their login session immediately ends. That way, a password (or other means of authentication) can be enabled, and people can log in, just not for shell access. For example, if there is an FTP server, they could still access their account via FTP. If there is an SSH server, they wouldn't be able to get a shell via SSH, but they could still use
scp to transfer files.
username's login shell was nonfunctional, commands like
su - username,
sudo -u username -s, and
sudo -u username -i could not work.
But commands that don't give a shell, like
sudo -u username command or
su username -c 'command' could still work.
Since commands can be run, you can change the user's login shell to something functional:
sudo chsh -s /bin/bash username
However, this should also be done with caution, as there may be a good reason to disable interactive logins for the user.
username both had disabled password and "disabled" shell. The absence of any working password prevented all
su-based solutions from working, while the absence of a working interactive login shell prevented all shell-spawning solutions from working (except manually invoking a shell, like
sudo -u username bash).
sudo -u username command is what remained.