65

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

  • 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 Jul 27 '12 at 17:32

10 Answers 10

131

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)
  • 56
    +1 for "Laugh at their impending disconnection (this step is optional, but encouraged)" – Josh Dec 9 '10 at 15:57
  • 8
    kill -9, huh? You really are in BOFH mode on this one. – Jander Feb 18 '11 at 7:43
  • 10
    @Jander You're kicking a user off the system; how nice do you need to be? – Michael Mrozek Feb 18 '11 at 7:58
  • 5
    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 Jul 27 '12 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) – Ulrich Dangel Jul 31 '12 at 18:21
31

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. – John WH Smith Oct 15 '14 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 Aug 17 '16 at 9:36
  • @Kunok under what situtation would you want kick the root user off the machine? Like if that account got hijacked or something? – Alexej Magura Oct 25 '16 at 16:42
23

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.

  • 1
    While the pseudo-omnipotent feeling that accompanies a kill -9 is fun, this suggestion is probably better. An up-vote from me. – Andrew Falanga Aug 13 '14 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 Oct 15 '14 at 18:10
12

Logout the user 'username':

skill -KILL -u username

See man skill

  • 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 – Michael Mrozek Aug 18 '10 at 18:35
  • I don't really see this working on RHEL7 – antivirtel Sep 19 '18 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.

  • 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 Aug 18 '10 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.) – countermode Sep 30 '16 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}
  • 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. – xenoterracide Aug 19 '10 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 Aug 21 '10 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 Aug 21 '10 at 1:43
  • -1 for reading things into the question that don't logically follow and dragging the Q/A off-topic. – Wesley Aug 6 '11 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. – Parthian Shot Jul 9 '14 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.

  • also if there are processes run by that user, perhaps SSHD you will never come into the Server, cause SSH shutdown. – Mailo Sep 16 '13 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)? – a CVn Sep 16 '13 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
    This is already mentioned in bsd’s answer. – Stephen Kitt Jun 11 at 14:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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