Bug 984 - Hangup to script while forced command ...
Summary: Hangup to script while forced command ...
Status: CLOSED WORKSFORME
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sshd (show other bugs)
Version: 3.9p1
Hardware: All Linux
: P2 normal
Assignee: OpenSSH Bugzilla mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-17 22:58 AEDT by Damien Touraine
Modified: 2006-10-07 11:38 AEST (History)
0 users

See Also:


Attachments
script running as forced-command (1.37 KB, text/plain)
2005-02-18 20:10 AEDT, Damien Touraine
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Damien Touraine 2005-02-17 22:58:42 AEDT
I have an account named demo. In its $(HOME)/.ssh/authorized_keys, I entered my
public key with a forced command that is a script. This script allows the user
to make a choice to launch a nohup backgrounded X-window (forked, without hang
up signal and without standard I/O). Then, the script leaves, that close the ssh
connection.
If I connect through ssh to this account without any command (ie : "ssh
user@computer"), xinit receives a hangup signal, causing X-window to shut down.
However, if i connect to this account with whatever string as command (ie : "ssh
user@computer foo"), my script is executed as expected : xinit don't receive any
hangup and X-window don't shutdown unless I do it explicitely.
Comment 1 Damien Miller 2005-02-17 23:18:39 AEDT
Try setting setting no-pty on the key too. E.g.

no-pty,command="xscript" ssh-rsa ....

Does that help? HUP is only sent to shells with a controlling terminal
Comment 2 Damien Touraine 2005-02-18 19:26:03 AEDT
(In reply to comment #1)
> Try setting setting no-pty on the key too. E.g.
> 
> no-pty,command="xscript" ssh-rsa ....
> 
> Does that help? HUP is only sent to shells with a controlling terminal

Actually no, because this script is asking the user through the read bash
command inside the script.
The most important problem, I think, is the strange behaviour that whenever I
specify one command (whatever command), it don't hang up my xinit. However, when
I don't give any command, a hangup is send to the xinit causing X-window to
shutdown.
Comment 3 Darren Tucker 2005-02-18 19:44:25 AEDT
(In reply to comment #2)
> > no-pty,command="xscript" ssh-rsa ....
> 
> Actually no, because this script is asking the user through the read bash
> command inside the script.

Did you try it?  "read" just reads from stdin and doesn't need a controlling
terminal.

> The most important problem, I think, is the strange behaviour that whenever I
> specify one command (whatever command), it don't hang up my xinit. However,
> when I don't give any command, a hangup is send

By default, when you "ssh yourserver" you get a pty and when you "ssh yourserver
somecommand" you don't.  Try "ssh -T yourserver" to prevent allocation of a pty.

You could also launch the command in your script with nohup.
Comment 4 Damien Touraine 2005-02-18 20:10:40 AEDT
Created attachment 829 [details]
script running as forced-command

Here is the script I am running as forced-command. As you can see, there is
already nohup to launch commands.
The problem when I set no-pty in the authorized-files, is that the display
seems strange (loosing the width of the term). But the most important problem
is the fact that I can't type anything. I must kill this script from another
console.

However, the command "ssh -t user@computer" works fine !
Comment 5 Damien Miller 2006-03-13 16:00:56 AEDT
This isn't an SSH bug, your SIGHUPs are a result of the process' controlling terminal going away. You can either:

1. Run without a pty as Darren suggested

2. Ensure that startx is called without a controlling terminal. Linux has a setsid(8) command for this, otherwise you might be able to use something like: 

      perl -e 'use POSIX ; setsid();'

3. Make your script stick around until the X session exits by not backgrounding itself or by explictly calling the "wait" shell builtin.

Comment 6 Darren Tucker 2006-10-07 11:38:41 AEST
Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.