Interupt Character does not work with ssh/sshd.

[Darrell Tschakert]

Hi,
We have an HP 9000/810/D380 running HP-UX 11.00. I just loaded Secure Shell A.03.81.002.
I am able to ssh into this computer using any of three ssh clients (Tectia SSH, Cygwin ssh, and Secure CRT). Things work fine except that the stty intr character does not work. When I hit ^C from my PC, I see nothing on the screen. If I change the intr character to DEL, ^B, or ^A and then hit that character, I see nothing at the screen and nothing happens. If I use these same three ssh clients to log into a Linux machine, the stty intr character (^C) works just fine.

Has anyone else seen this problem?

I did a google on "ssh interrupt" and found a number of hits which indicate that this problem may be common, but nobody posted a fix, solution, or workaround.

Can anyone advise me on this?

Thanks,

Darrell Tschakert

[Steve Post]

I've been using ssh for a while with no problems. The control-C interrupt has been working fine.

TERM=dtterm
stty kill=^C (i.e. control-C)
stty by itself will show you your settings.
I bet I'm preaching to the choir here.

When you hit control-C on your screen why do you expect to see it? It means interrupt. It does not show up on the screen for me. And I don't care if I see it. Do you care?

If you really want to actually see the a ^ and a C on the screen, you could always do this:
vi /tmp/junkfile.txt
type i (for insert mode).
type control-v, then control-c.
The control-v tells vi to the next literal character sequence you want into the file junkfile.txt.

If you run something like "bdf|more", you are in the more command. If you type control-C, does it drop you out of the more command? If it does, then you have verified that the interrupt is working.

steve

[Darrell Tschakert]

I was not very clear in my original posting. When I said that I see nothing on the screen when I hit ^C, I should have said that I don't see that appropriate response to the intrrupt character on the scren, when I hit ^C.

Anyway, I finally got the ^C to work. I rebooted the computer and it started warking. One of the first things that I ask people to do when they ask me to debug a problem is to reboot the computer. I have to start following my own advice.

The trouble that I am having now is with setting up for passwordless logins between a small group of HP's, all of which trust each other. I can get a Linux computer to let root from an HP get in passwordless, but not Linux to HP-UX.

Thanks,

Darrell T

[Steve Post]

Darrell,
I would put in a new forum question on being able to login without a password. I know I can log in without a password. But that's because I log in once each morning with a huge pass phrase using putty's authentication agent.

I don't log in as root. And I log out of every daily.

If you're looking for automation, a lot of folks have mentioned "expect". I never used it myself though.

steve

[Colin Topliss · Accepted solution]

Try using the verbose option to ssh to see what is happening. Multiple '-v' options increase the amount of information returned.

I have seen problems with:
1) exchanging keys between openssh and commercial ssh.
2) Some clients not allowing a user to log in if the host key has changed (some clients will error and tell you of an invalid key - others will not).
3) If you are trying to do this as root, make sure that you do not have root login disabled for ssh (check sshd_conf)

Col.

[Darrell Tschakert]

Much later:

Steve - I found a document outlining how to set up passwordless logins. I used that info to write a little shell script that helps set up the passwordless logins. Thanks.

Colin - I did not know about the "-v" option. I have solved my problems some time back and was just going back to pass out points. That's when I saw your "-v" note. This is a nice bit of information to have. The man entries do not describe the "-v" option.
Thanks,
Darrell T.

[Ed Vogt]

Darrell,

I have been struggling with this same problem for over a year now. Seems to be entirely random and (my guess) an issue with the source code. It stuns me that no one else has mentioned this on any forums before.

If I have any success down the road, Ill touch base with you again. The fix for us at this time it to have our users re-login until they get a functioning break key.

-Ed

[Peter Kielbasiewicz]

I have the same problem with SSH on our HPUX10.20 boxes.
I am now running ssh 4.1p1 and the problem is still there since openssh 3.1
The fact is, that the ssh daemon (when started from a tty) inherits the tty settings. Hhus it accepts ctrl-C as interrupt when it is set in the invokings shells tty settings. So if I start sshd manually from a shell everything works fine.
Unfortunately when sshd is started from the bootup processes (namely /sbin/init.d/sshd) there is no tty attached and thus there is no tty setting for the intr key.
I could not figure out a way to attach the sshd start to a tty when it is started from init and I would greatly appreciate if someone knew a trick to do this.

[Darrell Tschakert]

Silly me. All it took to fix this problem was a reboot. I would have tried rebooting earlier, but I have to wait until the third Saturday of the month to do so.

Thanks for all the advise solving this problem.

Darrell Tschakert

[Darrell Tschakert]

Rebooting the computer fixed the problem.
Thanks,

Darrell Tschakert