ssh giving stty: Not a typewriter error

[Jay Core]

Hello everyone!

I'm having a little problem with ssh.

Whenever I try to connect to my server using ssh, I must use -T to keep my formatting (I'm using a command prompt window), and I use a
-v to print all the debug messages, and I get the error:

ttytype: couldn't open /dev/tty for reading
stty: : Not a typewriter.

then,

stty: : Not a typewriter

repeats twice and then just hangs - i never get a prompt. I checked a bunch of stuff, permissions, .rhosts, /etc/hosts, /etc/profile(for ttytype issues), my .profile, pored over the ssh manpage, even killed/restarted ssh, all to no avail. I've got to be missing something small and stupid. Any help would be greatly appreciated.

Thanks,
JC

[Bill Hassell]

> stty: Not a typewriter error

This is not an ssh error. It is exactly what you will see when you try to run commands that require a terminal and none is available. This occurs most often when a primitive /etc/profile and/or .profile is used with a batch process such as cron. All profiles must protect terminal commands to prevent these errors.

So your profiles must be changed to something like this:

if tty -s
then
eval $(ttytype -sa)
stty ...
tabs
fi

This prevents a batch program (or more accurately, a program without a terminal attached) from running these commands.

Now you are using ssh -T which disables the terminal connection, yet it sounds like you are running an interactive ssh login. Anytime you have terminal formatting errors, it is due to bypassing the system's ability to identify the terminal properly. If you have *any* line in your local or remote profiles that have TERM=something, that is the problem. The TERM value must match your terminal and manually setting it will cause a lot of problems.

Make sure your local system has removed the useless test whether TERM is set. Instead, don't ever use TERM as it comes into /etc/profile. Always use:

eval $(ttytype -sa)

ssh won't change terminal features -- it is just a transport. Are you using Xwindows? This gets more complicated because the emulator is usually on another computer and Xwindows bypasses proper terminal handling by default.

[Jay Core]

Hi Bill,

thanks for the reply. I was just looking around ITRC about an hour ago, and I saw one of your old responses and said to myself how much I admire your knowledge. Then, bam, an hour later you respond to my question! That's karma! Anyway, a few clarifications and answers to your questions.

I guess I didn't think it was really an ssh issue - but I just called it that. sorry. I've got 2 systems I just built, almost identical. I log into my laptop, open a command prompt window, telnet successfully into both servers. I open another command window, and ssh to server1 with no problem - with or without the -T; I try the same on server2, and I get the error - the -T just makes the format of the screen much prettier and more readable. I also tried this on both servers from a putty window of a different server and got the same results - success on server1, and the error on server2. Both servers .profile's and /etc/profile's are the same. So by process of elimination, I'm stuck! Also, as you can see, no Xwindows. Thanks for your time.

JC

[Bill Hassell · Accepted solution]

> laptop, open a command prompt window, telnet..

This is the first problem area. The command prompt (or DOS) window is not a terminal emulator. It is just a DOS shell and when you type telnet, some telnet/terminal emulator program will be run. It could be Hyperterminal, putty, or any of several dozen emulators. So the first thing to do is to use a known terminal emulator. Putty is a good (and free) emulator:

http://www.chiark.greenend.org.uk/~sgtatham/putty/

Since you use HP-UX, having an HP smart terminal emulator is a real treat for programs like swinstall, sam and glance. Get a free emulator called QCTerm from AICS:

http://www.aics-research.com/qcterm/

You can use both on your laptop. Run QCTerm for HP programs, putty for the rest. Be sure to setup putty for the emulation you need (ANSI, vt220 and so on). vt100 is a (bad) catchall for emulators and while commonly used, it is a really dumb emulation.

Since you mentioned that the format of the screen is better with different connections, the issue is how your terminal is defined at each login. First, make sure that a statement such as TERM=vt100 is removed from login profiles. Then replace all this code in (the default) /etc/profile:

# set term if it's not set

if [ "$TERM" = "" -o "$TERM" = "unknown" -o "$TERM" = "dialup" \
-o "$TERM" = "network" ]
then
eval `ttytype -s -a`
fi

export TERM

# set erase to ^H, if ERASE is not set
if [ "$ERASE" = "" ]
then
ERASE="^H"
export ERASE
fi
stty erase $ERASE


with:

if tty -s
then
eval $(ttytype -sa)
tabs
export HISTFILE=${HISTFILE:-$HOME/.sh_history}
export HISTSIZE=5000
stty erase "^H" kill "^U" intr "^C" eof "^D" -parity ixoff
stty susp \^Z dsusp \^Y
fi

Make this change on all your HP-UX servers. Then after loading putty, leave a shorcut icon on your laptop and connect to your server. After login, check that the ttytpe program is correctly identifying your terminal:

ttytype -sa

Now run your application program(s) to see that the screen displays correctly. Then ssh to the second server. The application should look the same.

[Jay Core]

Thanks Bill - I really appreciate all your help. That did it.

[Jay Core]

Thanks!