Control-c not work under openssh?

[Garrick James]

I've been realy trying to get around to writing this up.  I think I've
found a work around (and some info for someone with more knowledge to
track down this little glitch) for this control-c problem under Solaris.

Appologies up front for how wordy this is all going to be...

I've used openssh on Linux-x86 2.0, Linux-x86 2.2, and Solaris-SPARC 
2.6.  The bug I'm going to discuss here seems to only manifest itself with
the openssh sshd on my Solaris boxen.

Bug symptoms:  Regardless of the client being used (so far, I have used
SecureCRT, linux openssh, solaris openssh, SSH-inc's ssh, and Tera Term
Pro SSH), when sshing into a Solaris box running openssh, control-c does
not work.  :-(

I've noticed something interesting, though.  The presence of the bug's
symptom is dependant on the state of control-c functionality at the time
that sshd is started on the server.  If control-c is working in the
controlling terminal from which sshd is started, then control-c will work
in all client connections.  If control-c is not working at server daemon
startup time, then clients do not get a working control-c.

For example, if I use an "at" or "cron" job to kill all sshd processes and
then start sshd up again, control-c will not work in client
connections.  However, if I execute the same script that does the stop and
start actions from a session that does have a working control-c (logged in
at the console, via telnet, or via an ssh connection that is working
properly--remember to nohup the script, though:) then control-c will work
properly for client connections.

I do not run sshd from inetd, so I cannot give the results for that case,
but my gut *guess* is that control-c will not work for clients.

So...  I hope all that made sense.  I do not have enough skill/knowledge
to track down in the source why sshd is dependant on control-c working at
startup time on Solaris and not on other OSes (like my Linux
boxen).  Hopefully someone out there can take this info as a starting
place to track down the bug.

Anyway, to work around the control-c problem on Solaris: run sshd in
daemon mode and start it either from an rc init script or from a logged in
session with a working control-c.  Oh yeah, almost forgot.  The above all
holds true for when UseLogin is set to no.  I have no idea about when it
is set to yes.

-Garrick James
 OpenSSH fan.

On Wed, 23 Aug 2000, Jeff Wiegley, Ph.D. wrote:

> I'm a little confused now.
> 
> Am I suspose to use "UseLogin yes"; if I do am I supose to kludge the
> execl function call for login to pass the environment.
> 
> Or...
> 
> Is this really a bug in the way the sshd daemon handles control-c?
> Should I wait for this to be fixed the real way?
> Where in the code would this problem reside? If I knew that maybe I
> could help design and code the solution and provide a patch for it.
> (Though I'm not real intimate with the ssh code :-(
> 
> Let me know how I can help! This has been bothering me for quite some
> time and I would love to help fix it.
> 
> Thanks,
> 
> - Jeff
> 
> 
> douglas.manton at uk.ibm.com wrote:
> > 
> > > Yes, I started doing this myself also when I got sidetracked.
> > 
> > > Looking at Tatu Ylonen's ssh, it does the exact same thing (just a NULL),
> > > so I'm assuming that this is the correct behavior?    So I figured (at
> > > least for my environment) it would be better to turn efforts to fixing
> > the
> > > control-C issue instead of kludging something else.  But I may be
> > > mistaken.
> > 
> > Of course the lack of environment means that the DISPLAY variable is left
> > unset -- an annoyance when 20 lusers are trying to forward X11 back from
> > one of our NetView servers and calling me for tech support :-(
> > 
> > Doug.
> > --------------------------------------------------------
> >  Doug Manton, AT&T EMEA Firewall and Security Solutions
> > 
> >                    demanton at att.com
> > --------------------------------------------------------
> > "If privacy is outlawed, only outlaws will have privacy"
> 
> 
>