similar to: [Bug 1007] sftp client hangs on tru64 5.1A

http://bugzilla.mindrot.org/show_bug.cgi?id=1007 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- OS/Version|All |Tru64 Component|sftp |ssh CC| |djm at

https://bugzilla.mindrot.org/show_bug.cgi?id=1007 --- Comment #17 from Damien Miller <djm at mindrot.org> 2009-08-18 11:12:32 EST --- Can't replicate this and can't diagnose without a truss or similar; ssh-rand-helper includes subcommand timeout logic that should avoid this. Please reopen if it recurs and you can trace it. -- Configure bugmail:

http://bugzilla.mindrot.org/show_bug.cgi?id=1007 Summary: sftp client hangs on tru64 5.1A Product: Portable OpenSSH Version: 4.0p1 Platform: Alpha OS/Version: All Status: NEW Severity: normal Priority: P2 Component: sftp AssignedTo: openssh-bugs at mindrot.org ReportedBy: paulstepowski at

https://bugzilla.mindrot.org/show_bug.cgi?id=1007 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |WORKSFORME --- Comment #18 from Damien Miller <djm at

https://bugzilla.mindrot.org/show_bug.cgi?id=1007 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #19 from Damien Miller <djm at mindrot.org> --- Close all resolved bugs after 7.3p1 release

https://bugzilla.mindrot.org/show_bug.cgi?id=1241 Darren Tucker <dtucker at zip.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dtucker at zip.com.au Blocks| |1353 --- Comment #2 from Darren Tucker

https://bugzilla.mindrot.org/show_bug.cgi?id=1241 Darren Tucker <dtucker at zip.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #1194| |ok? Flag| |

https://bugzilla.mindrot.org/show_bug.cgi?id=1241 Darren Tucker <dtucker at zip.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|1452 |1560 --- Comment #7 from Darren Tucker <dtucker at zip.com.au> 2009-07-31 10:12:10 --- OK, well

I am just looking for a quick answer as to whether or not OpennSSH is compatible with Digital Unix Tru64 v 4.0F. Hing Fei Wong Systems Engineer Building 100, M1309 Valley Forge, PA Admin # 4-6242 -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: Friday, June 23, 2006 3:53 AM To: Wong, Hing Fei Cc: www at openbsd.org Subject: Re: OpenSSH compatibility with

Dear openssh-unix-dev; I recently downloaded the tarball openssh-3.4p1 and built it for my Tru64 Unix ( OSF/1 ) 5.1a system. My configure statement is: ./configure --prefix=/usr/local/security/tools/openssh-3.4p1 \ --exec-prefix=/usr/local/security/tools/openssh-3.4p1 \ -with-ssl-dir=/usr/local/security/tools/openssl-0.9.6g \ -with-zlib-dir=/usr/local/compress/tools/zlib-1.1.3 \

https://bugzilla.mindrot.org/show_bug.cgi?id=831 Darren Tucker <dtucker at dtucker.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #9 from Darren Tucker <dtucker at dtucker.net> --- Mass close of all bugs fixed in 8.4

https://bugzilla.mindrot.org/show_bug.cgi?id=430 Darren Tucker <dtucker at zip.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dtucker at zip.com.au Blocks| |1626 Status|NEW

The ls_file function in sftp-server.c calls snprintf with "%8llu" as part of the format string and a "unsigned long long" type argument. The "%ll" format is not a valid format on Tru64 (at least 4.0F). Apparently it can confuse snprintf as well - sftp-server will segfault and core dump if the user types "ls". This isn't really a needed format string on

https://bugzilla.mindrot.org/show_bug.cgi?id=1691 Darren Tucker <dtucker at zip.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #2 from Darren Tucker <dtucker at zip.com.au> 2010-03-26 10:50:58 EST --- With the

Hi All. There have recently (well, today :-) been changes to OpenSSH Portable's auth-passwd.c from OpenBSD to accomodate forced changes of expired passwords. (Rabid password expirers shoulon't get excited yet, it's currently bsdauth only, but support for other platforms should start trickling in shortly). As part of that, some individual platforms have gained their own

https://bugzilla.mindrot.org/show_bug.cgi?id=2681 Bug ID: 2681 Summary: postauth processes to log via monitor Product: Portable OpenSSH Version: 7.4p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: sshd Assignee: unassigned-bugs at

On Fri, Feb 23, 2018 at 05:01:00PM +1100, Darren Tucker wrote: > You could try this patch which defers resetting the "tried" flag on the > pubkeys until the list of authentication methods changes. I don't have > a server with this behaviour so I'm not sure if it helps (and I'm not > sure it's the right thing to do anyway). I think this is a better way to

https://bugzilla.mindrot.org/show_bug.cgi?id=831 Darren Tucker <dtucker at dtucker.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #3437|ok?(dtucker at dtucker.net) |ok+ Flags| | -- You are receiving this mail because: You are

http://bugzilla.mindrot.org/show_bug.cgi?id=933 Summary: compile problem on tru64 5.1A code outside of a #ifdef that should not be included on tru64 Product: Portable OpenSSH Version: 3.8p1 Platform: Alpha OS/Version: OSF/1 Status: NEW Severity: normal Priority: P2 Component: Build

On Fri, 8 Dec 2023 at 07:39, Philip Prindeville <philipp_subx at redfish-solutions.com> wrote: [...] > Problem is that if their default shell isn't sh, ash, dash, bash, zsh, etc. then things break. > Is there a workaround to allow scp/sftp to continue to work even for non-shell accounts? sftp should work regardless of the user's shell since it is invoked as a ssh subsystem