I was googling this a bit ago and noticed a couple of ways, but I'm guessing that google doesn't know all. So how do you kick users off your Linux box? also how do you go about seeing they are logged in in the first place? and related... does your method work if the user is logged into an X11 DE (not a requirement I'm just curious)?
10 Answers
There's probably an easier way, but I do this:
See who's logged into your machine -- use
who
orw
:> who mmrozek tty1 Aug 17 10:03 mmrozek pts/3 Aug 17 10:09 (:pts/2:S.0)
Look up the process ID of the shell their TTY is connected to:
> ps t PID TTY STAT TIME COMMAND 30737 pts/3 Ss 0:00 zsh
Laugh at their impending disconnection (this step is optional, but encouraged)
> echo "HAHAHAHAHAHAHAHA" | write mmrozek pts/3
Kill the corresponding process:
> kill -9 30737
I just discovered you can combine steps 1 and 2 by giving who
the -u
flag; the PID is the number off to the right:
> who -u
mmrozek tty1 Aug 17 10:03 09:01 9250
mmrozek pts/18 Aug 17 10:09 01:46 19467 (:pts/2:S.0)
-
80+1 for "Laugh at their impending disconnection (this step is optional, but encouraged)"– JoshCommented Dec 9, 2010 at 15:57
-
10
-
14@Jander You're kicking a user off the system; how nice do you need to be? Commented Feb 18, 2011 at 7:58
-
6Normally, I'd say don't encourage people to abuse
kill -9
, and start with gentler signals instead, but I suppose in this context it doesn't matter so much. I am just leaving a comment in case people miss the joke.– jw013Commented Jul 27, 2012 at 17:41 -
5There is also slay which basically automates the whole process (even making fun of your victim if you enable butthead mode) Commented Jul 31, 2012 at 18:21
As Micheal already pointed out, you can use who
to find out who's logged in. However if they have multiple processes, there's a more convenient way than killing each process individually: you can use killall -u username
to kill all processes by that user.
-
+1. Using
killall
will also be slightly more appropriate in graphical environments, since there's more than just a shell to kill. Commented Oct 15, 2014 at 19:25 -
3WARNING: If you use this for root user you will kill all root processes and you will need to physically restart the server.– KunokCommented Aug 17, 2016 at 9:36
-
1@Kunok under what situtation would you want kick the root user off the machine? Like if that account got hijacked or something? Commented Oct 25, 2016 at 16:42
Necromancy!
I appreciate the humor of the accepted answer, but professionally I can't advocate it.
The most graceful method I'm aware of is to send a -HUP to the shell to simulate a user hangup. You can send this to the user's idle sshd to simulate their connection being lost, which triggers a cleanup of the entire shell environment (including child shells), or send this to specific nested shells (say, ones setting inside of a disconnected terminal multiplexer that are keeping you from unmounting a filesystem) if you want to be really precise.
Using write
to send messages to terminally idle ptys before you boot them is a fun hobby though.
-
1While the pseudo-omnipotent feeling that accompanies a kill -9 is fun, this suggestion is probably better. An up-vote from me. Commented Aug 13, 2014 at 17:54
-
4To make this answer explicit, what I did was:
echo "Hasta la vista, baby" | write user_name pty_name && sleep 30 && killall -u user_name -HUP
(the sleep gives the user the chance to save and log off, but you're probably only using this on a user who forgot to log off anyway) Commented Oct 15, 2014 at 18:10
Logout the user 'username':
skill -KILL -u username
See man skill
-
3I think that will kill all processes by that user, not just their shell, but if that's what you want then this is definitely simpler Commented Aug 18, 2010 at 18:35
-
Other useful command is pkill
here pkill -u username && pkill -9 -u username
.
killall
have disadvantage that on Solaris IIRC it means something completely different - also pkill
have slightly more advanced options.
-
8On Solaris 'killall' is used by the shutdown scripts to kill (nearly) all the processes on the server. "It does what it says on the tin."– dr-janCommented Aug 18, 2010 at 13:19
-
Folks, why do you fancy SIGKILL so much? Running programs and application won't even have a chance to save data and clean up a bit. SIGTERM (as is used at shutdown) or SIGHUP will do as well and is way more graceful. (You can still send SIGKILL after expiry of a grace period.) Commented Sep 30, 2016 at 11:34
First of all, this indicates a larger problem. If you have users that you don't trust on your system, you should probably level it and re-image.
With that in mind, you can do some or all of the following:
# set up the environment
BADUSER=foo # where foo is the username in question
USERLINE=$(grep '^${BADUSER}:' /etc/passwd)
BADUID=$(echo ${USERLINE} | awk -F: '{print $3}')
BADGID=$(echo ${USERLINE} | awk -F: '{print $4}')
BADHOMEDIR=$(echo ${USERLINE} | awk -F: '{print $6}')
BDIR="~/backup/home-backup/"
TSTAMP=$(date +%F)
TAR_FILENAME="${BADUSER}-${TSTAMP}.tar.bz2"
OWNED_FILENAME="${BADUSER}-files-${TSTAMP}.txt"
# disable the user's future login
sudo chsh -s /bin/false "${BADUSER}"
# kill all of the user's processes
BADPROCS=$(ps auwx | grep '^${BADUSER} ' | awk '{print $2}')
sudo kill -9 ${BADPROCS}
# back up/clear the user's home directory
mkdir -p ${BDIR}
sudo tar -cfj ${BDIR}/${TAR_FILENAME} ${BADHOMEDIR}
sudo rm -rf ${BADHOMEDIR}/.* ${BADHOMEDIR}/*
# find all files owned by user
sudo find / -user ${BADUSER} > ~/backup/${OWNED_FILENAME}
# remove user
sudo userdel ${BADUSER}
-
I don't know that I would agree with "level it an reimage" this is unix not windows... I don't really have this problem... I was just asking. Commented Aug 19, 2010 at 21:17
-
3Plus, just because you have to kick a user off doesn't necessarily mean they're untrustworthy. Maybe they just forgot to log out.– David ZCommented Aug 21, 2010 at 0:10
-
xenoterracide: Maybe I'm just protective of the systems I maintain, but if I had a user who I felt needed to be forcibly removed from a system under my control, something serious would have had to have happened.– cjacCommented Aug 21, 2010 at 1:43
-
-1 for reading things into the question that don't logically follow and dragging the Q/A off-topic.– WesleyCommented Aug 6, 2011 at 18:14
-
you have users that you don't trust on your system
...Or it could just be that you're killing one as a message to the others. After all, is the sysadmin's creed not "It is better to be feared than to be loved"? All jokes aside, Machiavelli should write an O'Reilly book. Commented Jul 9, 2014 at 15:27
I looked all around and could not find a single script to automate this task.
So, based on the solutions proposed here I mixed everything in an interactive Bash script that lists the users and sessions from who -u
for the user to choose what to do.
You can then either:
- kill all sessions for a user
killall -u <username> -HUP
- kill a specific session
kill <PID>
All the required information comes from who -u
and is then parsed using mapfile
and awk
.
I will add the possibility to send a message using write
later (forking the process with a delay).
I will probably add the option to kill a specific session with kill -9
as well. But I had no problems with just kill
and as pointed by others, kill -9
should be avoided if possible.
You can check the code on github if you want to try it or learn more about how I am doing it in an automated way:
So how do you kick [benign] users off your Linux box?
In the end it comes down to identifying and ending those processes that are owned, associated, or spawned from a user-id. Whatever commands you use to get to that end goal doesn't necessarily matter as long as you get there.
Basically two answers...
Option A: causing a log out of said user, for which ever and however many logins they have. So this would mean identifying those processes that are owned by a user, traceable by uid, and classified as part of some login process for the given linux distro you are running. Realize there are parent processes such as SSH or VNC before the "login" and child processes such as GDM after the "login" Usually killing a parent process will kill the child process, but not always. So you would want to kill these other processes that are obviously no longer needed after the log out. In doing all this, this would keep background jobs running... because it's a benign user and maybe you just want to log them out. As far as i know, /usr/bin/w
and /usr/bin/who
will report who has passed through the log in process.
option B: end all processes owned by a specific uid completely, which would simply mean killing any and all processes owned by said user, this would also log them out if they are logged in. This would satisfy the kick them off the system. That only needs to be a simple ps -ef | grep <uid>
and then ending all those processes in whatever manner is acceptable.
fwiw in SLES 11 it reports
man skill ... These tools are probably obsolete and unportable. The command syntax is poorly defined. Consider using the killall, pkill, and pgrep commands instead.
kill -9
FTW !
In my opinion, it is not really useful to use killall -u username
because if it is the same user as you, you will kick yourself off. So kill
the process will be a better solution.
-
also if there are processes run by that user, perhaps SSHD you will never come into the Server, cause SSH shutdown.– MailoCommented Sep 16, 2013 at 8:45
-
3Why on Earth would the SSH daemon (or any daemon) be running using the credentials of a user that needs to be forcibly logged off the system for any realistic reason whatsoever? Also, what does this answer add that is not covered by Michael Mrozek's answer or Andrew B's answer (and possibly others)?– userCommented Sep 16, 2013 at 9:49
This command worked great for the GUI my "significant" refuses to sign out of...
leaves@me:/# skill -HUP -u username
- I don't know what happened.
- There must have been an update.
- The "Google" was down again.
- It was a virus on the InterWebs.
Some diversions in case you need them.
-
1
who(1)
orw(1)
. The only foolproof way to get rid of any potential rootkits that may be installed is to completely wipe and reinstall the system.