similar to: [Bug 1917] New: Escape sequence (~) doesn't work right with ControlMaster/ControlPersist connections

https://bugzilla.mindrot.org/show_bug.cgi?id=1917 Darren Tucker <dtucker at zip.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dtucker at zip.com.au --- Comment #10 from Darren Tucker <dtucker at zip.com.au> --- Created attachment

https://bugzilla.mindrot.org/show_bug.cgi?id=1917 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #14 from Damien Miller <djm at mindrot.org> --- Set all RESOLVED bugs to CLOSED with

https://bugzilla.mindrot.org/show_bug.cgi?id=1938 Bug #: 1938 Summary: EscapeChar sometimes don't work when using ControlMaster Classification: Unclassified Product: Portable OpenSSH Version: 5.8p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2

Hi I'm trying to wrap ssh in an application using glib. For now, I'm launching the ssh client in master mode and want it to detach, keeping the control socket around. I figured I could do that using the -f flag and the usual Control* options to force ssh to daemonize (ideally without executing any command), but it turns out that glib doesn't recognize the daemonized process as

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

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 Component:

Hi. Perhaps you can help me with this: What I do is using Nagios (actually Icinga) and having checks on remote hosts executed via ssh. In order to dramatically speed checks up (from about 0,300 ms to 0,010 ms) I use ControlMaster = 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

https://bugzilla.mindrot.org/show_bug.cgi?id=2000 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|REOPENED |RESOLVED --- Comment #9 from Damien Miller <djm at

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2000 Damien Miller <djm 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

https://bugzilla.mindrot.org/show_bug.cgi?id=2000 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #5 from Damien Miller <djm at mindrot.org> --- Set all RESOLVED bugs to CLOSED with release

https://bugzilla.mindrot.org/show_bug.cgi?id=2000 Christoph Anton Mitterer <calestyo at scientia.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |--- Status|CLOSED |REOPENED --- Comment #6 from Christoph Anton

https://bugzilla.mindrot.org/show_bug.cgi?id=2000 --- Comment #8 from Christoph Anton Mitterer <calestyo at scientia.net> --- Uhm? Well I thought that was obvious... using SSH to remotely execute checks seems desirable because it's a) the protocol meant for doing this b) secure (unlike e.g. NRPE). But without control channel muxing, it's much slower than e.g. NRPE, as all the

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2000 Bug #: 2000 Summary: when using ssh with ControlMaster/ControlPersist, one may get zombie processes Classification: Unclassified Product: Portable OpenSSH Version: 5.9p1 Platform: All OS/Version: All Status: NEW Severity: major

-----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

Dear Mailing List We are using a ControlMaster with a short ControlPersist to access the bastion host which then gives access to customer hosts. Our Information Security Manager would like to disallow the ControlMaster. His attack scenario is an admin workstation with a compromised root account. An attacker can then use the ControlMaster to trivially get shell access on the bastion host

https://bugzilla.mindrot.org/show_bug.cgi?id=2065 Bug ID: 2065 Summary: double confirmation with ssh-add -c and ControlMaster autoask Classification: Unclassified Product: Portable OpenSSH Version: 6.0p1 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P3

https://bugzilla.mindrot.org/show_bug.cgi?id=3589 Bug ID: 3589 Summary: ControlMaster auto, persist and -f fail. Product: Portable OpenSSH Version: 9.3p1 Hardware: amd64 OS: Linux Status: NEW Severity: minor Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org

Hello. Yes, i think that was the cause why agent forwarding wasn't performed at all, i had to rm(1) the control socket and the next ssh(1) connection forwarded the agent normally again. (It was a huge timeshift by several hours.) I.e., just in case this is something you didn't have on your radar yet. Ciao. --steffen