Strange SSH "^C" Problem

[Steve Bonds]

On one host (and only one host) when using SSH to connect, ^C no longer works. Connecting with telnet works fine.

I've eliminated the possibility of an SSH client-specific issue by testing with multiple clients from multiple host/OS combinations (OpenSSH, PuTTY, SecureCRT, win32, HP-UX, Linux) all exhibit the same symptoms-- but only on this one host.

I checked the default stty settings when connecting via SSH vs. telnet. They are different (though both have intr set to ^C). Using "stty -g" in the telnet window and copying the setting to the SSH window does not help.

Now the really strange part-- when I use "screen" to create a virtual terminal on the host after telnetting in and re-connect to that virtual terminal from an SSH connection, ^C works fine.

I checked /etc/profile. Although there are some strange things in there (like a nonstandard TERMCAP) selectively commenting out some of the strange things did not help.

Any ideas? This one's been a real head-scratcher.

-- Steve

[Maarten van Rossen]

Steve,

Are you using the .ssh/enviroment file?

I remember a few months back we had a simular problem.
We set in the .ssh/enviroment file the PATH of our ssh installation so that scp would work.
When we did this we had the same problem.
We solved it by changing the default path in the C source of ssh and deleting the .ssh/enviroment file.
Although it sould also be possible to put all the enviroment you need in the .ssh/enviroment file.

Maarten

[Steve Bonds]

Thanks for the hint! However, we're not using the .ssh/environment. In fact, if I compare the environment settings for a telnet login and an SSH login, they are identical except for things that should be different. (i.e. PPID, RANDOM, _)

Does anyone have a pointer to some docs that would describe the HP-UX login process and all the files that *could* be involved? I've checked the ones I know about, but clearly my knowledge is coming up short in this case.

-- Steve

[Ollie R]

Hi Steve,

I don't know if this is still an issue for you, but I've discovered something you might want to try......

The is trapped by the first occurrence of the daemon start up because it is (presumabely) started by "swinstall". Notice that you cannot stop "swinstall" by pressing ! So, the daemons that swinstall starts inherit this little "feature" too.

If you stop and start the ssh daemons again manually, this problem should disappear.

This may be too little too late, but hopefully it'll help someone else out in the future!

Ollie.