I am trying to enforce a policy that logs an idle user out of a bash shell session, even when they are in an active process like a script-based menu, or vi session.
I have tried using "export TMOUT=x" where x is the number of seconds, but this only logs a user out if they are idle at the bash shell prompt.
Is there a bash script or any C code that I can run that will check what users have been idle for too long, and then stop all processes run by that user, and log them out?
Thanks
Ryan
in bash
w | tr -s " " | cut -d" " -f1,5 | tail -n+3
gives you a username/idletime pair for each shell. you can set up a cronjob using this information to logout the correct people.
The idletime is the time since the last keystroke directly in the shell (and not the applications).
Related
I must create a Shell that when a user logs in, it will print on the terminal from which the connection was made how many users are logged in an their number of processes.
The second part ( the one with processes ) was easy, thanks you the following command
ps hax -o user | sort | uniq -c
But I can't go any further. I don't know how to automatically launch this script for every user, and even more, how to write on their terminal. ( I fount commands like msg, write but all require me to insert the username)
Your command ps hax -o user | sort | uniq -c does not show count of processes of logged in users but of every user (including system accounts) not necessarily currently logged in.
List of only logged in users can be get with who command.
To get count of processed per logged in user one can try:
for u in `who -u | cut -f1 -d' ' | sort -u`; do echo -n "$u "; ps hx -u $u | wc -l; done;
Message displayed on users terminal only at login time is set in /etc/motd test file. This is static file. What you need is dynamically generated motd file. This can be achieved with update-motd.
On Ubuntu/Debian update-motd configuration scripts can be found in /etc/update-motd.d/
I'm not sure if similar feature is available on RedHat like systems but you can search for update-motd or dynamic motd.
If you want the message to appear only each time the user opens the terminal, you can edit /etc/bash.bashrc and include the .sh script from there. This file basically contains commands that get executed every time a terminal is opened.
Accessing the IP address of a connecting SSH client is possible via environment variables (such as SSH_CONNECTION), as described in
Find the IP address of the client in an SSH session
In a GNU screen session though, those environment variables are defined by whoever started the screen to begin with. Is there any way to also get hold of the SSH connection information, for someone who enters an already-existing screen session later, like from another host?
I can't think of a way to determine this, but this can be useful in cases where screen sessions are shared between different people, for example.
If the screen session is launched as root, you can but it won't be perfectly reliable
If two users type in the same screen window, they will both interact within the same shell. One can write a command. The other can press the <enter> key.
You have to get access to the environment variable SSH_CONNECTION (or better SSH_CLIENT) which is only possible if you are root, or if you use the same user inside the screen session.
Supposing you are root inside the screen session, you can know the last user active in a screen session by using the ps command and finding the last active session.
ps h -C screen katime -o pid,user
By using the pid, and accessing the /proc/<pid>/environ file, you can get the SSH_CLIENT variable.
sed -z '/SSH_CLIENT/p;d' /proc/`ps h -C screen katime -o pid |head -1`/environ
--> SSH_CLIENT=257.31.120.12
All of this suppose that your screen is executed as root
You can also chose to log all the active connections.
For such need, I would suggest you to store both the full list of connections and their last activity.
ps eh -C screen kstime -o pid,atime | while read pid stime; do echo -n "$stime: ";\
gawk -v 'RS=\0' -F= '$1=="SSH_CLIENT" {print $2}' /proc/$pid/environ; done
Result:
00:00:00: 257.31.120.12 61608 22
00:07:11: 258.1.2.3.4 49947 22
Note that you can also parse the result of the ps eh -C screen kstime -o args command if you find it easier.
EDIT:
This is a working Debian command to get all users currently connected to the same screen session:
find /var/run/screen/
-name $(pstree -sp $$ |sed 's/.*screen(\([0-9]*\)).*/\1/;q').*
-printf "%h\n"
| cut -f2 -d-
You can check the output of the last command that would list of all IP addresses or hostnames of all connection made if sshd is the only way to connect to server.
ec2-user]# last
ec2-user pts/0 115.250.185.183 Sun May 29 13:49 still logged in
ec2-user pts/0 115.250.140.241 Sat May 28 07:26 - 10:15 (02:48)
root pts/4 113.21.68.105 Tue May 3 10:15 - 10:15 (00:00)
Alternatively (on Linux), you can check /var/log/secure where sshd will usually log all details of all the connections made even if they don't result in successful logins.
If you're trying to support the multi-display mode ('screen -x'), then as someone said above you are likely out of luck.
One the other hand, if you could assume single-user mode, then you could create a wrapper/alias for the screen command that carries along an environment variable into screen (see 'screen -X stuff ...'); in this case you are just passing along SSH_CLIENT that will have the appropriate value.
If you can assume a given username comes from a single location (or, if more than one location, then simply choose most recent), then you can do some grep/sed on output of 'last' command.
client_ip=`last -ai | grep "still logged in" | grep "$USER " | grep -v '0.0.0.0' | tail -n 1 | sed 's/.* //g'`
echo "Hello $client_ip"
If your screen is starting usually in detached mode, then in your .screenrc, add the the following:
shell -$SHELL
Then your screen will have all the the variables.
For currently running screens that you are stuck with, simply run.
source ~/.bash_profile
Replace the path and the file name to match your environment.
I want to run jobs in the background so that I can logout from terminal once any job is started. I know two ways
1) run job and then press ctrl+z and then enter bg
mysqldump -uroot -p dbname > dbname.sql
2) using nohup to run job and then press ctrl+z and then enter bg
nohup mysqldump -u root -p dbname > dbname.sql 2>&1
I want to know the difference between above two commands and which one is best in which scenario.
Running your process as a job constrains your job to the current session. So if you run
$ start_running_job &
$ exit
The job will stop when you exit.
Pressing Control-Z has the same effect as the lines above.
Running nohup places the job so that it survives the end of the current session. So if you run
$ nohup start_running_job &
$ exit
The job will continue running.
I agree with answer provided...
"nohup" basically runs your command/script in back-end mode on server itself and it is not related to your current login session while putting "&" just puts the script in background and remains connected to your current login session. In any case you can use fg to bring back script/command.
Which is good for you, for this it depends how you are accessing your server and for how long your script is gonna take to complete. Say your script will take more amount of time and your current login session remains ideal it will close down and script will get killed if you have only given &. So much of the time just give nohup and don't worry it.
When launching a bash script in LINUX, the script succeeds and is successful, yet the terminal hangs. I must always input CTRL+C to end the program. I am able to type in the terminal and press enter, but the script does not respond.
I can not change the script files, but can I launch it so that it disables waiting for the user? Any troubleshooting tips to disable this behaviour?
You can execute the script with & at the end, this will give the control back to the shell (executes the script as a background process).
./script.sh &
If you want to stop the script, you need to get its process id and then kill it. To get the process id, either execute ps aux | grep script where script is your script name, or execute echo $! right after you launched the script. When you have the process id, you can kill the process with kill 1234 where 1234 is the process id.
If the execution time of the script can be estimated, you can kill it automatically after a certain amount of time:
bash -c '(sleep 5m; kill $$ 2> /dev/null) & exec script' &
In this command sleep 5m is the time after the process will be killed, and script is the name of your script (or the command).
For example if the script's execution time is 30 seconds on average, then you can set the timeout to a minute or two to give it some extra time in case the execution is slower than usual. Note that this command doesn't guarantee that the script finished its execution, so use it with care.
I am trying to close a putty session that is running on some other computer.
You kill the process ID of the user's login session:
kill -9 12345
Try running the w command and looking at the output. Something like:
w | grep ssh
will show all users connected via ssh. More scripting and automation is possible to help you narrow down the process ID of the login session:
pgrep -u w | grep ssh| awk '{print $1}' ssh
will give you a list of numbers that are the PIDs of the login session. You can then use ps to verify that this is the session you want to kill. See the kill(1), ps, and pgrep manual pages.
You can get fancy and make a script or shell alias to print the users and their ssh sessions (NB: quick hack for illustration, not portable):
for u in `w| grep ssh|awk '{print $1}'`
do
echo -e "\n"$u
pgrep -x -l -u $u ssh
done
... and other variation on this theme. If you are killing sessions this way oftne it's a good idea to have a script or tool that helps you identify the correct session before your kill -9 it - especially on a busy shell login host. Even more useful are tools that are cross platform and/or POSIX-ish (w who ps etc. vary slightly in their output formats). That kind of tool can be written in perl, ruby or very careful sh and awk.