search for: controlpersist

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, There seems to be just a bit to do with the latest openssh (5.8p1) and ControlPersist. I encountered two problems: 1. When I use ControlPersist in combination with ProxyCommand to reach a other host over that proxy I get the following message: Bad packet length 1397966893. Disconnecting: Paket corrupt When I fist ssh to the proxy, close the connection (that persi...

http://bugzilla.mindrot.org/show_bug.cgi?id=1330 Summary: RFE: 'ControlPersist' support -- automatically fork and leave ControlMaster behind as a d?mon Product: Portable OpenSSH Version: 4.6p1 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Comp...

https://bugzilla.mindrot.org/show_bug.cgi?id=2394 Bug ID: 2394 Summary: Provide a global configuration option to disable ControlPersist Product: Portable OpenSSH Version: 6.8p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org Reporter: jjelen at...

Good afternoon! I've been looking for a way to avoid having to keep my "master" ssh session open while I have others open. This is particularly a pain when my "master" is an scp connection. After searching the archives, I came up with this thread "ControlPersist and multiple X11 forwardings." However, I can't find anything saying that it was incorporated or not, or what has happened. The last reply to this thread was in 2005. Unlike the originator of the thread, I don't have a patch to offer, only a request to make: I would find the Co...

https://bugzilla.mindrot.org/show_bug.cgi?id=1943 Bug #: 1943 Summary: [PATCH] ssh -W opens two connections when ControlPersist is enabled. Classification: Unclassified Product: Portable OpenSSH Version: 5.9p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: unassigned-bugs at mindro...

Hi, While testing the ControlPersist option (which is very useful by the way, thank you), I find out that setting it to 0 has the same behaviour as setting it to yes, while I would have expected to exit as soon as the last client exits. I'd like to make this behaviour clear, I think it should be documentated in the man page for e...

https://bugzilla.mindrot.org/show_bug.cgi?id=1988 Darren Tucker <dtucker at zip.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dtucker at zip.com.au Blocks| |2076 -- You are receiving this mail

https://bugzilla.mindrot.org/show_bug.cgi?id=1812 Summary: ControlPersist causes defunct/zombie processes Product: Portable OpenSSH Version: 5.6p1 Platform: All URL: http://bugs.debian.org/594687 OS/Version: All Status: NEW Severity: normal Priority: P2 Component: ssh...

https://bugzilla.mindrot.org/show_bug.cgi?id=2420 Bug ID: 2420 Summary: Race condition regarding ControlPersist and ControlMaster=auto Product: Portable OpenSSH Version: 6.6p1 Hardware: amd64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: ssh Assignee: unassigned-bugs at mind...

https://bugzilla.mindrot.org/show_bug.cgi?id=3220 Bug ID: 3220 Summary: Possible bug if ControlMaster + ControlPersist and `-t` Product: Portable OpenSSH Version: 8.4p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org...

...know what are your open file descriptors and close the other "hanging around". But aside all of this, what would be proposal if you would need to preserve this open file descriptor? In above mentioned bugzilla, I'm proposing to close these FDs only if we have configuration option ControlPersist enabled (as comments in code describes). This requires to move the the whole closing thing down after reading config files and commandline options. But this can interfere with debug logging enabled (using -E option), so to make it working, it is required to reopen this log file after closing ot...

...m at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |djm at mindrot.org --- Comment #7 from Damien Miller <djm at mindrot.org> --- If ControlPersist's stderr handling is incompatible with the way nagios manages its processes when why enable it? -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

...|Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|REOPENED |RESOLVED --- Comment #9 from Damien Miller <djm at mindrot.org> --- So use ControlMaster without ControlPersist? *** This bug has been marked as a duplicate of bug 1988 *** -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2000 --- Comment #10 from Christoph Anton Mitterer <calestyo at scientia.net> --- Hmm AFAIU, when not using ControlPersist, that would simply mean that if the last session is closed, the mux closes either, right? This is however undesirable as well for the above use-case: First, considers hosts where only one check runs (i.e. executed via ssh),... the check would finish, the mux would close, and next time, even if th...

...Attachment #2810| |ok?(dtucker at zip.com.au) Flags| | --- Comment #14 from Damien Miller <djm at mindrot.org> --- Created attachment 2810 --> https://bugzilla.mindrot.org/attachment.cgi?id=2810&action=edit close ControlPersist stderr when logging to file/syslog or when not in debug mode We want to keep stderr open when in debug mode, so it's a little more complex than that. This patch tries to do the right thing. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching som...

...Attachment #2811| |ok?(dtucker at zip.com.au) Flags| | --- Comment #16 from Damien Miller <djm at mindrot.org> --- Created attachment 2811 --> https://bugzilla.mindrot.org/attachment.cgi?id=2811&action=edit close ControlPersist stderr when logging to file/syslog or when not in debug mode (v2) Same as last patch, but the logic is a little more readable this way -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug.

...|FIXED --- Comment #17 from Damien Miller <djm at mindrot.org> --- patch applied - this will be in openssh-7.3 commit d2d6bf864e52af8491a60dd507f85b74361f5da3 Author: djm at openbsd.org <djm at openbsd.org> Date: Fri Apr 29 08:07:53 2016 +0000 upstream commit close ControlPersist background process stderr when not in debug mode or when logging to a file or syslog. bz#1988 ok dtucker Upstream-ID: 4fb726f0fdcb155ad419913cea10dc4afd409d24 Referenced Bugs: https://bugzilla.mindrot.org/show_bug.cgi?id=2076 [Bug 2076] Bugs intended to be fixed in 6.3 https://bugzilla...

...enum { oEnableSSHKeysign, oRekeyLimit, oVerifyHostKeyDNS, oConnectTimeout, oAddressFamily, oGssAuthentication, oGssDelegateCreds, oServerAliveInterval, oServerAliveCountMax, oIdentitiesOnly, - oSendEnv, oControlPath, oControlMaster, oHashKnownHosts, + oSendEnv, oControlPath, oControlMaster, oControlPersist, oHashKnownHosts, oDeprecated, oUnsupported } OpCodes; @@ -197,6 +197,7 @@ static struct { { "sendenv", oSendEnv }, { "controlpath", oControlPath }, { "controlmaster", oControlMaster }, + { "controlpersist", oControlPersist }, { "hashknownho...

...ere, So I created a patch that makes ssh behave more like sudo. You connect to a host typing your password, you quit, you connect again and you are let in immediately. If you wait for too long you have to type your password again. It works if you have a ControlPath, ControlMaster is auto, ControlPersist is yes and ControlTimeout is for example 5m. This will make a master when you quit your shell, and it will exit if no data has passed through for 5 minutes. You can find it here: https://bugzilla.mindrot.org/show_bug.cgi?id=1330#c5 It works really well as long as you exit by closing you...

...ter = auto, which also makes the mux process spawned on the first check. As checks are typically sequentially scheduled I want the mux process to persist but it should also go away automatically after some days if not re-used (e.g. when I don't check a host anymore). So I have something like ControlPersist 2d. Now I stumbled across the following problem (and I'm actually not sure whether it's a ssh issue or Icinga): The first time the check is done (which is when the mux process is spawned) it times out. The mux process keeps running and everything works on subsequent checks. The timeou...