search for: requesttti

https://bugzilla.mindrot.org/show_bug.cgi?id=1995 Bug #: 1995 Summary: RequestTTY=no in config doesn't work if stdin is not a tty Classification: Unclassified Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2

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

https://bugzilla.mindrot.org/show_bug.cgi?id=1995 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|unassigned-bugs at mindrot.org |djm at mindrot.org Attachment #2171|

Hey. I've noticed the following behavior and wondered whether it's possibly a bug or why it behaves like this: When having a SSH connection, than it seems there may be two sshd processes for that, one running as root the other as the user. As far as I know this is because of privilege separation, like e.g.: ??sshd(2931)???sshd(10174)???bash(10180) ?

I noticed that this command returns NO through ssh: > $ ssh user at host "if [ -t 1 ]; then echo YES; else echo NO; fi" > NO and YES when run locally (of course): > $ if [ -t 1 ]; then echo YES; else echo NO; fi > YES I can't find any command line option related to running command remotely in terminal. I think users intuitively expect commands to be run in

Oops. That's -T. From the man page, it doesn't really look like there's an ssh_config option for -N. -----Original Message----- From: openssh-unix-dev [mailto:openssh-unix-dev-bounces+scott_n=xypro.com at mindrot.org] On Behalf Of Scott Neugroschl Sent: Tuesday, August 09, 2016 1:04 PM To: Volker Diels-Grabsch; openssh-unix-dev at mindrot.org Subject: RE: Equivalent ssh_config

https://bugzilla.mindrot.org/show_bug.cgi?id=3714 Bug ID: 3714 Summary: sftp fails in one direction Product: Portable OpenSSH Version: 9.2p1 Hardware: ARM64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: sftp Assignee: unassigned-bugs at mindrot.org

We recently upgraded to openss 5.8p2 from a somewhat older version. This broke openssh login to ScreenOS devices. These devices don't support PTY allocation. Apparently, ssh now reacts to PTY allocation failure by failing the login. This is a change from the previous behavior. The simple workaround is ssh -T $device. I see in the ChangeLog that some device would hang with PTY allocation

Dear OpenSSH developers, Is there an equivalent ssh_config setting for the command line option ssh -N ... ? I want to connect to a server that doesn't provide an interactive shell but allows for port forwarding only. I'd love to configure this into my ~/.ssh/config as follows: Host foo Hostname ... Port ... User ... LocalForward ...

https://bugzilla.mindrot.org/show_bug.cgi?id=1815 Summary: RemoteCommand and PseudoTTY config options Product: Portable OpenSSH Version: 5.1p1 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: ssh AssignedTo: unassigned-bugs at mindrot.org ReportedBy:

Hi, AFAICT, there is no .ssh/config option for disabling pseudo-tty allocation. It would be nice to have one. Context: we're using gitolite in our project, and it sets things up to run a command with "no-pty". Every once in a while, users will try to ssh to the machine to see that things are working, and when they see the "PTY allocation request failed on channel 0"

I'm running a 5.0p1 derivative SSH server (that for various reasons I can not upgrade), on a host system that does not support PTYs. Attempts to connect to that sshd via sftp are failing due to an inability to allocate a pty. I can't really see a reason that an sftp session requires a pty. Is this addressed in later versions? Should I patch my system to avoid even trying to

https://bugzilla.mindrot.org/show_bug.cgi?id=3762 Bug ID: 3762 Summary: ForkAfterAuthentication doesn't work with Windows native SSH Product: Portable OpenSSH Version: 9.5p1 Hardware: Other OS: Windows 10 Status: NEW Severity: normal Priority: P5 Component: ssh

https://bugzilla.mindrot.org/show_bug.cgi?id=1815 Tisza Gerg? <gtisza at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gtisza at gmail.com --- Comment #5 from Tisza Gerg? <gtisza at gmail.com> --- One possible use case for

OpenSSH 6.1 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches,

OpenSSH 6.1 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches,

OpenSSH 5.9 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches,

OpenSSH 5.9 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches,

https://bugzilla.mindrot.org/show_bug.cgi?id=1986 Bug 1986 depends on bug 2023, which changed state. Bug 2023 Summary: MACs hmac-sha2-256-96 and hmac-sha2-512-96 rejected from new RFC https://bugzilla.mindrot.org/show_bug.cgi?id=2023 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW

Hi, OpenSSH 6.1 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This release contains a couple of new features and bug fixes. Snapshot releases for portable OpenSSH are available from http://www.mindrot.org/openssh_snap/ The OpenBSD version is available in CVS HEAD: http://www.openbsd.org/anoncvs.html Portable OpenSSH is also available