Mailing List Archive

ssh -f and pid
I'd like to second the patch -- or functionality like it -- that
Folkert van Heusden proposed twelve months ago for the distribution.

Without ssh -f returning the pid to the caller, numerous daemon and
script monitor packages can't manage ssh, as they can countless other
daemons that properly return pid. A monitor needs to record the pids
of ssh processes it has started to kill them or to know when they have
died. Proper keep alive settings are no use against connections reset
by peer.

> Hi,

Ssh -f forks itself in the background. Very usefull if you would like to
e.g. tunnel munin over ssh. Now it's tricky to terminate one process if
you have multiple running.
It seems that ssh currently (looked at 5.1p1) has no write-pid-to-file
functionality
So I implemented a patch which do so. Tested it a little and it seems to
work. Hopefully it is of any use in my form or inspires the developers
to implement this kind of functionality in the ssh distribution.
Url:
http://www.vanheusden.com/Linux/openssh-5.1p1_writepidfile.diff.gz
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: ssh -f and pid [ In reply to ]
On Thu, 4 Feb 2010, Ming wrote:

> I'd like to second the patch -- or functionality like it -- that
> Folkert van Heusden proposed twelve months ago for the distribution.
>
> Without ssh -f returning the pid to the caller, numerous daemon and
> script monitor packages can't manage ssh, as they can countless other
> daemons that properly return pid. A monitor needs to record the pids
> of ssh processes it has started to kill them or to know when they have
> died. Proper keep alive settings are no use against connections reset
> by peer.

It isn't necessary. You can tear down ssh connections from the control
socket and learn the PID of a running SSH, see the commands listed
under -O in ssh(1).

-d

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: ssh -f and pid [ In reply to ]
On Thu, Feb 4, 2010 at 11:21 PM, Damien Miller <djm@mindrot.org> wrote:

> On Thu, 4 Feb 2010, Ming wrote:
>
> > I'd like to second the patch -- or functionality like it -- that
> > Folkert van Heusden proposed twelve months ago for the distribution.
> >
> > Without ssh -f returning the pid to the caller, numerous daemon and
> > script monitor packages can't manage ssh, as they can countless other
> > daemons that properly return pid. A monitor needs to record the pids
> > of ssh processes it has started to kill them or to know when they have
> > died. Proper keep alive settings are no use against connections reset
> > by peer.
>
> It isn't necessary. You can tear down ssh connections from the control
> socket and learn the PID of a running SSH, see the commands listed
> under -O in ssh(1).
>
> -d
>
>
A individual can do an number of things with a understanding of and beyond
the man page, but how do you get ssh to play nicely in a ecosystem of
monitoring software?

Say the os has bunch of ssh processes active. How the monitoring software
in a standard way which ones it created -- and thus track -- and which ones
it hasn't?

ControlPath has to be specified for -O and command line query required? How
is ssh suppose to plug and play with monitoring software?
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: ssh -f and pid [ In reply to ]
On Thu, 4 Feb 2010, Ming wrote:

> > It isn't necessary. You can tear down ssh connections from the control
> > socket and learn the PID of a running SSH, see the commands listed
> > under -O in ssh(1).
> >
> A individual can do an number of things with a understanding of and beyond
> the man page, but how do you get ssh to play nicely in a ecosystem of
> monitoring software?

It isn't above and beyond the manpage, checking the state of a running
connection is a clearly documented feature.

> Say the os has bunch of ssh processes active. How the monitoring software
> in a standard way which ones it created -- and thus track -- and which ones
> it hasn't?

It can request separate control sockets if it likes.

> ControlPath has to be specified for -O and command line query required? How
> is ssh suppose to plug and play with monitoring software?

I think the monitoring software needs to support ssh and not the other
way around. There are lots of ways one might monitor ssh, and I don't think
we could even be "plug and play" with all of them.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: ssh -f and pid [ In reply to ]
On Fri, Feb 5, 2010 at 12:49 AM, Damien Miller <djm@mindrot.org> wrote:

> On Thu, 4 Feb 2010, Ming wrote:
>
> > > It isn't necessary. You can tear down ssh connections from the control
> > > socket and learn the PID of a running SSH, see the commands listed
> > > under -O in ssh(1).
> > >
> > A individual can do an number of things with a understanding of and
> beyond
> > the man page, but how do you get ssh to play nicely in a ecosystem of
> > monitoring software?
>
> It isn't above and beyond the manpage, checking the state of a running
> connection is a clearly documented feature.
>
> > Say the os has bunch of ssh processes active. How the monitoring
> software
> > in a standard way which ones it created -- and thus track -- and which
> ones
> > it hasn't?
>
> It can request separate control sockets if it likes.
>
> > ControlPath has to be specified for -O and command line query required?
> How
> > is ssh suppose to plug and play with monitoring software?
>
> I think the monitoring software needs to support ssh and not the other
> way around. There are lots of ways one might monitor ssh, and I don't think
> we could even be "plug and play" with all of them.
>
> -d
>

The monitoring software just needs to know the pid of the command executed.
That's all it needs to be plug and play. And they only kill the process by
pid. Looking at all the times (via Google) you have offered the same ssh
-O solution across the web to people have asked for a pid the years, it
seems that it is *your* stance not to be "plug and play."

The few monitoring packages I experimented all expect a pid from the daemon.

Luckily, I could find one package, autossh, that specifically -- and only --
monitors ssh. Now, I have to run two packages, one to monitor ssh
specifically and one for all my other daemons and scripts.

At least it works. Would the security of openssh be so compromised by
spitting out its pid?

-M
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: ssh -f and pid [ In reply to ]
Just to be clear, even with Van Huesden's patch to ssh, it would not be
"plug and play." At least ssh could meet the dominant paradigm of tracking
pid half-way through the pid file. Half-way, part-way, is a lot better than
the socket no-way.

On Fri, Feb 5, 2010 at 2:06 AM, Ming <minger@gmail.com> wrote:

>
>
> On Fri, Feb 5, 2010 at 12:49 AM, Damien Miller <djm@mindrot.org> wrote:
>
>> On Thu, 4 Feb 2010, Ming wrote:
>>
>> > > It isn't necessary. You can tear down ssh connections from the control
>> > > socket and learn the PID of a running SSH, see the commands listed
>> > > under -O in ssh(1).
>> > >
>> > A individual can do an number of things with a understanding of and
>> beyond
>> > the man page, but how do you get ssh to play nicely in a ecosystem of
>> > monitoring software?
>>
>> It isn't above and beyond the manpage, checking the state of a running
>> connection is a clearly documented feature.
>>
>> > Say the os has bunch of ssh processes active. How the monitoring
>> software
>> > in a standard way which ones it created -- and thus track -- and which
>> ones
>> > it hasn't?
>>
>> It can request separate control sockets if it likes.
>>
>> > ControlPath has to be specified for -O and command line query required?
>> How
>> > is ssh suppose to plug and play with monitoring software?
>>
>> I think the monitoring software needs to support ssh and not the other
>> way around. There are lots of ways one might monitor ssh, and I don't
>> think
>> we could even be "plug and play" with all of them.
>>
>> -d
>>
>
> The monitoring software just needs to know the pid of the command executed.
> That's all it needs to be plug and play. And they only kill the process by
> pid. Looking at all the times (via Google) you have offered the same ssh
> -O solution across the web to people have asked for a pid the years, it
> seems that it is *your* stance not to be "plug and play."
>
> The few monitoring packages I experimented all expect a pid from the
> daemon.
>
> Luckily, I could find one package, autossh, that specifically -- and only
> -- monitors ssh. Now, I have to run two packages, one to monitor ssh
> specifically and one for all my other daemons and scripts.
>
> At least it works. Would the security of openssh be so compromised by
> spitting out its pid?
>
> -M
>
>
>
>
>
>
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: ssh -f and pid [ In reply to ]
On Fri, 5 Feb 2010, Ming wrote:

> The monitoring software just needs to know the pid of the command executed.
> That's all it needs to be plug and play. And they only kill the process by
> pid. Looking at all the times (via Google) you have offered the same ssh
> -O solution across the web to people have asked for a pid the years, it
> seems that it is *your* stance not to be "plug and play."
>
> The few monitoring packages I experimented all expect a pid from the daemon.
>
> Luckily, I could find one package, autossh, that specifically -- and only --
> monitors ssh. Now, I have to run two packages, one to monitor ssh
> specifically and one for all my other daemons and scripts.
>
> At least it works. Would the security of openssh be so compromised by
> spitting out its pid?

It is difficult holding a conversation with someone who refuses to
listen to advice, so let me make this as simple as possible:

[djm@demiurge ~]$ ssh -nNfS ~/ctl-sock-blah localhost
[djm@demiurge ~]$ ssh -S ~/ctl-sock-blah -O check localhost
Master running (pid=3517)
[djm@demiurge ~]$ ssh -S ~/ctl-sock-blah -O exit localhost
Exit request sent.

Like I said, it is easy to determine the PID via the control socket.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: ssh -f and pid [ In reply to ]
Ming wrote:
> On Fri, Feb 5, 2010 at 12:49 AM, Damien Miller <djm@mindrot.org> wrote:
>
>> On Thu, 4 Feb 2010, Ming wrote:
>>
>>>> It isn't necessary. You can tear down ssh connections from the control
>>>> socket and learn the PID of a running SSH, see the commands listed
>>>> under -O in ssh(1).
>>>>
>>> A individual can do an number of things with a understanding of and
>> beyond
>>> the man page, but how do you get ssh to play nicely in a ecosystem of
>>> monitoring software?
>> It isn't above and beyond the manpage, checking the state of a running
>> connection is a clearly documented feature.
>>
>>> Say the os has bunch of ssh processes active. How the monitoring
>> software
>>> in a standard way which ones it created -- and thus track -- and which
>> ones
>>> it hasn't?
>> It can request separate control sockets if it likes.
>>
>>> ControlPath has to be specified for -O and command line query required?
>> How
>>> is ssh suppose to plug and play with monitoring software?
>> I think the monitoring software needs to support ssh and not the other
>> way around. There are lots of ways one might monitor ssh, and I don't think
>> we could even be "plug and play" with all of them.
>>
>> -d
>>
>
> The monitoring software just needs to know the pid of the command executed.
> That's all it needs to be plug and play. And they only kill the process by
> pid. Looking at all the times (via Google) you have offered the same ssh
> -O solution across the web to people have asked for a pid the years, it
> seems that it is *your* stance not to be "plug and play."
>
> The few monitoring packages I experimented all expect a pid from the daemon.

Just don't use -f !

The monitoring software should be able fork itself the new ssh process
and get the PID back as the result of the fork call.

Or is your monitoring software allowing the user to introduce the
password or passphrase interactively?

- Salva

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev