similar to: [Bug 26] ssh setting O_NONBLOCK on stderr can upset CVS

http://bugzilla.mindrot.org/show_bug.cgi?id=26 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From djm at mindrot.org 2003-01-07 15:03

The quick summary is that we invoke git from a parallel invocation of "make". Git invokes ssh to pull stuff from a remote repo. Ssh sets O_NONBLOCK on stdout and stderr if they do not refer to a tty. During our build, stderr refers to a pipe that other jobs run by make (and make itself) may also write to, and since this is a parallel build, they may write to that pipe while ssh has it

> ssh has to set NONBLOCK otherwise it can, well, block - there's > no way for ssh to know a priori how much data it can write to a fd. I don't know anything about how ssh is structured, but I think it must be a bit more complicated than that. Ssh only sets O_NONBLOCK on an fd if isatty(fd) returns false, so it's able to function with blocking input and output if the relevant

> Case in point; EAGAIN can come if you give your fd to another process > and continue using it yourself. > Short counts; It is documented behavior that read() and write() may > return short counts. It is not documented why, so you can not make > any assumptions. You might be right about short counts but if you're right about EAGAIN, there are bugs everywhere. My first

> So the make process gets an EAGAIN on the write syscall and doesn't > retry? That sounds like a bug in whatever make you're using, since > that could potentially occur in other circumstances too. What other circumstances? EAGAIN means that something put the device into non-blocking mode, and normally, that should only happen if the program calling write had itself previously

http://bugzilla.mindrot.org/show_bug.cgi?id=88 ------- Additional Comments From markus at openbsd.org 2002-01-31 23:01 ------- this is an installation error on the target host, see: scp: warning: Executing scp1 compatibility. scp: FATAL: Executing ssh1 in compatibility mode failed (Check that scp1 is in your PATH). ------- You are receiving this mail because: ------- You are the assignee

Hello, I'm running OpenBSD 2.9 (-rOPENBSD_2_9) on i386. Remote port forwarding doesn't work. Attached are 2 logs of ssh -v -R2828:localhost:22 localhost and sshd -p 2222 -d Note that server tries to forward to Connection to port 2828 forwarding to 0.0.0.0 port 0 requested. instead of localhost port 22 as it should. what ssh, what sshd and /etc/sshd_config are also attached. Thanks

http://bugzilla.mindrot.org/show_bug.cgi?id=961 Summary: CVS annotate problems Product: Portable OpenSSH Version: 3.8.1p1 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-bugs at mindrot.org ReportedBy: sb at dod.no I had a

http://bugzilla.mindrot.org/show_bug.cgi?id=961 Summary: CVS annotate problems Product: Portable OpenSSH Version: 3.8.1p1 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-bugs at mindrot.org ReportedBy: sb at dod.no I had a

On 11/08/2020 16:28, mwilck at suse.com wrote: > From: Martin Wilck <mwilck at suse.com> > > If a program opens /dev/hwrng with O_NONBLOCK and uses poll() and > non-blocking read() to retrieve random data, it ends up in a tight > loop with poll() always returning POLLIN and read() returning EAGAIN. > This repeats forever until some process makes a blocking read() call.

On 11/08/2020 16:28, mwilck at suse.com wrote: > From: Martin Wilck <mwilck at suse.com> > > If a program opens /dev/hwrng with O_NONBLOCK and uses poll() and > non-blocking read() to retrieve random data, it ends up in a tight > loop with poll() always returning POLLIN and read() returning EAGAIN. > This repeats forever until some process makes a blocking read() call.

I sent in a patch a week or so ago for a problem a customer of mine was seeing when trying to connect to their OpenVMS system with an 3.8.1p2 OpenSSH client (running on a linux box or in cygwin) and trying to login to an account who had an expired password. The problem continues although now it has nothing to do with what my patch handled as they have since upgraded their SSH software on the VMS

http://bugzilla.mindrot.org/show_bug.cgi?id=257 ------- Additional Comments From markus at openbsd.org 2002-05-27 17:09 ------- openssh is not derived from ssh.com-2.x or 3.x. but adding support for 32bit int is not hard. you can attach patches to this bug. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=454 ------- Additional Comments From markus at openbsd.org 2002-12-10 20:14 ------- hm, i think about adding ManglePort=yes to the options. This option will create Hostkeyaliases on the fly if the port is != 22, and use 'foor.bar.com at portXXX' as an alias. ------- You are receiving this mail because: ------- You are the assignee for

http://bugzilla.mindrot.org/show_bug.cgi?id=557 Summary: scp over ssh-relay insists in asking passphrase Product: Portable OpenSSH Version: 3.4p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: scp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy:

can someone confirm this? it does not happen on openbsd. -------------- next part -------------- An embedded message was scrubbed... From: Florian Wunderlich <fwunderlich at devbrain.de> Subject: Re: fds closed after SIGCHLD bug still in newest version Date: Wed, 22 Nov 2000 14:44:17 +0100 Size: 3926 Url:

https://bugzilla.mindrot.org/show_bug.cgi?id=1478 Summary: ssh -V sends output to stderr instead of stdout Classification: Unclassified Product: Portable OpenSSH Version: 5.0p1 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Documentation AssignedTo:

http://bugzilla.mindrot.org/show_bug.cgi?id=179 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From markus at openbsd.org 2002-03-22 22:37 ------- hm, sshd is not sending channel data after

http://bugzilla.mindrot.org/show_bug.cgi?id=148 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From markus at openbsd.org 2002-03-08 08:10 ------- packet_read_expect(SSH2_MSG_NEWKEYS);

I also made the code a bit more robust about closing the socket along error paths. --- generator/states-connect.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/generator/states-connect.c b/generator/states-connect.c index ba8b240..a69b70f 100644 --- a/generator/states-connect.c +++ b/generator/states-connect.c @@ -27,6 +27,7 @@ #include