Logging a pts/X session {where X is an Integer}

I have an account on 1and1.com - They give me an SSH account access.  When I log-in, I get this message:


For security reasons all ssh and telnet sessions are logged, and may
be monitored. By logging in you give consent to these conditions.

Shell access is provided for web development and not for running
irc-bots, arbitrary tcp/udp servers (e.g. gameservers) or cracking toolkits.
Disregard leads to suspension of your contract.

Well, I simply want to know if anyone has an idea of what they are using to monitor/log my session.  I'd like to implement this on my own server...I've asked a similiar question here:


But didn't really get a 'solid' response...so I thought I'd pick at the experts' brains once more.

So, I'm simply looking for a way to log - in relative detail, an ssh login session (pts/X).

Who is Participating?
You can download screen binary package from:
you need to remember to install required packages.

I have tested to log all the use command including screen out put with screen, it works.
but I would not use it to monitor the users. (tons of reason).

I suggest you to use Solaris BSM, please have a look at the following pages for more

http://docs.sun.com     -- Search for BSM
That statement doesn't really say anything about what level of logging they are doing. It could be as simple as the standard collection of login/logout data. Or as full as the capture of all commands passed to the server in a session. The later, as far as I know would require modified sshd or telnetd servers.

If the server is a Solaris box they might be running full auditing, which will log what applications get run, but not all of the shell commands.
rambleAuthor Commented:
I just discovered that "screen" is in it's path:

u55373445:~ > which screen

So, I'm trying to figure out if it can be used...but, your right, it's very ambiguous, and there really isn't any way to find out what methods they are employing.

There not running solaris:
Linux infong224 2.4.27-grsec-20040809a #1 SMP Mon Aug 9 10:21:08 CEST 2004 i686 unknown

But, screen is available for both platforms...don't think it will do what I want it to do...but I'm still working with it.

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

rambleAuthor Commented:
Well, screen seems to be installed by default with Red Hat, so I don't think it means anything for it to be found in the path...
The warning message is pretty much a standard type of message to cover legalities.

I suspect that their logging is no more than your average Linux system.  Most of the info they would look at would be in the various log files under /var/log

rambleAuthor Commented:
Hey...I've been working more with screen...it seems to be a pretty robust logging solution...check it out:

I've got many of the features to work, trying to figure out how to set the permissions, and create a robust .screenrc file.

Doesn't seem to work in all shells...? Which could be a big problem.
A tool installed by default on almost any UNIX server is script.  It can be setup to spawn the users shell and log everything that is displayed to the terminal in a file.  I doubt this is what the warning is hinting at but it may be what you are looking for on your own server.

Try a 'man script'

rambleAuthor Commented:
script seems to be an extemely easy way to do it...

How would I hide it from the user?  Not in a "complicated" fashion...just in general.  Script starts up like this:

Script started, file is script_testing
Script done, file is script_testing

Also, it seems to change the default prompt for the login file.  I'd like it to keep the same "characteristics" of the prompt.

example: (normal login)

Research SVR>

But, putting: exec script /logs/session_logs/script_log
in the .login file makes the prompt simply display:

#echo $SHELL

rambleAuthor Commented:
Here's an "actual" example of the 'alias' command being overwritten.  So, I'm not clear on how I can retain the same environment BEFORE the script spawned a new shell.

Research SVR> alias
h       history
set3151 setenv TERM ibm3151
set803  setenv TERM tvi800
setpc   setenv TERM ibmpc
setsvt  setenv TERM svt1220
settvi  setenv TERM adds25
setuvt  setenv TERM svt1220
setvt100        setenv TERM vt100
setwyse setenv TERM wyse50
sus     exec bash
Research SVR> script
Script started, file is typescript
$ alias
autoload='typeset -fu'
command='command '
functions='typeset -f'
history='fc -l'
integer='typeset -i'
nohup='nohup '
r='fc -e -'
stop='kill -STOP'
suspend='kill -STOP $$'
the ways to go are script or screen
sript is a simple thing and can simply detected with ps. There is no problem with the prompt, you description sounds like you have a broken SHELL environmen variable.
> How would I hide it from the user?
you can't (except with a modified /bin/ps and no acces to /proc)

screen is hard to detect, at least if you have no root access.
rambleAuthor Commented:

Yes, that was what I was guessing with the environment variable.  

I tried screen, and it works fine...in root.  

But when I'm in the SHELL environment of the users that I want to log...I get:

[screen is terminating]

And it immediately exits...No other error messages, or reasons on why.

Another user I get the error message:

Cannot open your terminal '/dev/pts/5' - please check.

I'm guessing that this is env related as well.  Any suggestions?

Unix is secure, in most things ;-)
obviously you need to be root then to use screen to monitor other user's tty.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.