Take the 2-minute tour ×
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.

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

share|improve this question
    
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

7 Answers 7

up vote 56 down vote accepted

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)
share|improve this answer
2  
kill sends a signal to a process, with -9 indicating a 'kill' signal. You can see a list of all signals with man kill or unixhelp.ed.ac.uk/CGI/man-cgi?kill - +1 for the evil laughter :-) –  invert Aug 18 '10 at 9:42
23  
+1 for "Laugh at their impending disconnection (this step is optional, but encouraged)" –  Josh Dec 9 '10 at 15:57
3  
kill -9, huh? You really are in BOFH mode on this one. –  Jander Feb 18 '11 at 7:43
4  
@Jander You're kicking a user off the system; how nice do you need to be? –  Michael Mrozek Feb 18 '11 at 7:58
2  
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

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.

share|improve this answer
    
+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 at 19:25

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.

share|improve this answer
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

Logout the user 'username':

skill -KILL -u username

See man skill

share|improve this answer
2  
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

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}'`

# 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 ~/backup/home-backup/
$ sudo tar -cfj ~/backup/home-backup/$BADUSER-`date +%F`.tar.bz2 $BADHOMEDIR
$ sudo rm -rf $BADHOMEDIR/.* $BADHOMEDIR/*

# find all files owned by user
$ sudo find / -user $BADUSER > ~/backup/$BADUSER-files-`date +%F`.txt

# remove user
$ sudo userdel $BADUSER
share|improve this answer
    
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 at 15:27

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.

share|improve this answer
    
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 at 17:54
    
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 at 18:10

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.

share|improve this answer
    
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)? –  Michael Kjörling Sep 16 '13 at 9:49

Your Answer

 
discard

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.