Shell Programming and Scripting

Hi,

I have a simple question about I/O redirection. the question is:
"How can I redirect all characters from a Bash screen to a file?"

Let me describe a little more: I know about I/O Redirection in Bash.
and also about stdin/stdout/stderr. something like: # ls 2>&1 1>ls.out

But! sometimes it's not possible to capture output of some Apps.
SSH is a good sample. I tried to capture a complete output of an
ssh session but it was not possible! when you are trying to do an
ssh for the first time, it will shows a message like this:

Code:

 
The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.
RSA key fingerprint is ****
Are you sure you want to continue connecting (yes/no)?

And, this message couldn't be captured!

Any suggestions would be appreciated

Certain things like ssh (and many other authentication systems) don't use stdin/stdout/stderr but directly open the controlling terminal, often /dev/tty (which on linux at least is kind of 'magic' in that /dev/tty is always your own terminal, no matter what that may be.) This happens after the shell runs the program, and can't be redirected.

You'd need to create your own virtual terminal device to intercept traffic at this level. The virtual terminal would be the controlling terminal and ssh would open and interact with it. This is how the expect language is able to interact with programs that demand a terminal device.

Thanks for these helpful information.

So, if it's using /dev/tty* why we can't redirect it? ("is kind of 'magic'"!)
Assume that we create a link from /dev/tty* to /dev/stdout and then handle it like any other output of stdout, isn't it possible?


Just as a Clarification:

Your shell can only redirect its own file descriptors. It can't stop any program from opening new ones.

Security-wise, unencrypted passwords are grade-A dangerous. They shouldn't ever get stored in any retrievable form, and should go directly from actual humans to system logins in as few vulnerable steps as possible.

The obvious way to tell a human apart from an intermediate program is that humans will always be found using terminals... ssh, and indeed most login systems(su, sudo), demand that an actual terminal be used to enter passwords. Pipes, files, and sockets won't do.

There's another property a process has beyond stdin/stdout/stderr, the controlling terminal. If there's a terminal in charge of a process, there's probably a logged-in human behind it that's using that terminal. They can be contacted directly via opening /dev/tty regardless of whether a program inherited any references to that terminal or not.

So, to guarantee that they're getting passwords from a human and not an automated password cracker or an in-between password recorder, and talking to a human and not a script -- and to let su - work even if it's crammed in the middle of a pipe chain! -- these things go directly to the terminal in charge of the process and accept nothing less.

/dev/tty knows what your terminal is without any effort on your part. Open it and it acts like you opened your proper terminal, which might be /dev/pts/3, or /dev/tty1, or any of a lot of possibilities. No. It uses a system call to see whether what it's opened is actually a terminal. You'd probably mess up some important things by playing with device files like that anyway.

The solution is to open your own virtual terminal, and use that to control your program. It's as good as any other terminal as far as ssh's concerned. The expect language does this. Otherwise this'd mean some C coding.

Your abstract questions of late need the context of a commercial requirement.

Hard to guess the requirement in this case:

1) If you are trying to write shell to answer the SSH question, it is better to configure the system so it does not ask the question.

2) If you just need to record screen output for documentation purposes, maybe consider quality PC-based terminal emulation software with screen logging features. This is not quite as sophisticated as it sounds because CRT terminals in the 1980s were capable of repeating the screen output to a serial port on the same terminal.



Ps. We don't want to make public information about unix terminal I/O which would assist anybody to write a keylogger, a password cracker or a virus.

Whoa...dont you mean

Code:

ls 1>ls.out 2>&1

...the order IS important.

I would be surprised if you couldn't capture this....have you tried something like "script" ? That seems to capture my ssh sessions fine...
If that captures it, then anything can (cos it doesnt run setuid)

BTW, There are oddities that you have to be aware of, for example if you have:

Code:

cat /tmp/foo | more

The "more" command throws up a prompt onto the users screen, and waits for the user to press a key. This obviously isnt from stdin (as it takes that from the cat /tmp/foo). Actually what the shell does is to pass the stderr to the "more" command and the more command checks to see if that is attached to a tty and then does its input/output through that....but thats another story)

Although its theoretically possible for programs to open /dev/tty, this is almost never done by useful applications. This is because the shell would normally be in control of the tty, and uses it for job control. If another program opened /dev/tty and started trying to do I/O through it, the shell would probably quit out or get arsey.

I hope this makes things a little clearer

---------- Post updated at 11:48 PM ---------- Previous update was at 11:35 PM ----------

Yep, looking at script, it allocates a new pseudoterminal (pty), which pretends to be the logged in users tty. This is the same as "expect", and indeed exactly the same method that sshd and telnetd use to emulate terminals. If you look at the code to expect or script (or indeed sshd) you will see their method of allocating pty's and from there you can do interactive I/O to any process, even the ones, like passwd, that insist on a controlling pty.

---------- Post updated 01-26-11 at 12:03 AM ---------- Previous update was 01-25-11 at 11:48 PM ----------

(BTW, I just noticed your original question contained the sentence "I have a simple question about I/O redirection. "....So, I apologise for my over complicated answer...I realise now that it probably wasn't what you were after...)

Messing with the terminal device is unwise. It can for example make your application behave as if it is in background.

I avoided mentioning the unix "script" command because it has many quirks and limitations. There was a lengthy thread on this subject some months ago.
The main issue with automation and the "script" command is with exiting "script" without typing ctrl/D on a real keyboard.
If anybody knows how to exit the unix "script" command from a shell script, please post now !