88

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)?

1
  • 3
    Changed question to reflect assumptions given the accepted answer. In the context of a security breach, the only way to kick a malicious user off your system is to be much smarter than that user. A clever user is not going to let themselves show up in utmp or get found by something as trivial as who(1) or w(1). The only foolproof way to get rid of any potential rootkits that may be installed is to completely wipe and reinstall the system.
    – jw013
    Commented Jul 27, 2012 at 17:32

10 Answers 10

181

There's probably an easier way, but I do this:

  1. See who's logged into your machine -- use who or w:

    > who  
    mmrozek  tty1         Aug 17 10:03  
    mmrozek  pts/3        Aug 17 10:09 (:pts/2:S.0)
    
  2. 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
    
  3. Laugh at their impending disconnection (this step is optional, but encouraged)

    > echo "HAHAHAHAHAHAHAHA" | write mmrozek pts/3
    
  4. 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)
10
  • 80
    +1 for "Laugh at their impending disconnection (this step is optional, but encouraged)"
    – Josh
    Commented Dec 9, 2010 at 15:57
  • 10
    kill -9, huh? You really are in BOFH mode on this one.
    – Jander
    Commented Feb 18, 2011 at 7:43
  • 14
    @Jander You're kicking a user off the system; how nice do you need to be? Commented Feb 18, 2011 at 7:58
  • 6
    Normally, 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.
    – jw013
    Commented Jul 27, 2012 at 17:41
  • 5
    There 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
41

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.

3
  • +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
  • 3
    WARNING: If you use this for root user you will kill all root processes and you will need to physically restart the server.
    – Kunok
    Commented 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
25

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.

2
  • 1
    While 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
  • 4
    To 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)
    – wkschwartz
    Commented Oct 15, 2014 at 18:10
13

Logout the user 'username':

skill -KILL -u username

See man skill

2
  • 3
    I 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
  • I don't really see this working on RHEL7
    – antivirtel
    Commented Sep 19, 2018 at 15:02
11

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.

2
  • 8
    On 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-jan
    Commented 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
3

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}
5
  • 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
  • 3
    Plus, just because you have to kick a user off doesn't necessarily mean they're untrustworthy. Maybe they just forgot to log out.
    – David Z
    Commented 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.
    – cjac
    Commented 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.
    – Wesley
    Commented 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
0

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:

0

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 !

-1

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.

2
  • also if there are processes run by that user, perhaps SSHD you will never come into the Server, cause SSH shutdown.
    – Mailo
    Commented Sep 16, 2013 at 8:45
  • 3
    Why 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)?
    – user
    Commented Sep 16, 2013 at 9:49
-2

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
  • 1
    This is already mentioned in bsd’s answer. Commented Jun 11, 2019 at 14:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .