search for: ssh_msg_channel_request

raf wrote: > Not knowing the details of each user's login shell is > precisely the reason that ssh couldn't ever do the > quoting itself. The footgun is unrelated to shells. The SSH_MSG_CHANNEL_REQUEST protocol message for "exec" (RFC 4254) channels which are used to run a single remote command contains exactly one string for the command. sshd (see bottom of do_child() in session.c) runs that command string as: remote_users_shell -c command //Peter

...6:35:34PM +0000, Peter Stuge <peter at stuge.se> wrote: > raf wrote: > > Not knowing the details of each user's login shell is > > precisely the reason that ssh couldn't ever do the > > quoting itself. > > The footgun is unrelated to shells. > > The SSH_MSG_CHANNEL_REQUEST protocol message for "exec" (RFC 4254) > channels which are used to run a single remote command contains > exactly one string for the command. > > sshd (see bottom of do_child() in session.c) runs that command string as: > > remote_users_shell -c command I'm aware...

...ttp://www.openssh.org/txt/draft-ietf-secsh-connect-15.txt says that |4.9 Signals | | A signal can be delivered to the remote process/service using the | following message. Some systems may not implement signals, in which | case they SHOULD ignore this message. | | byte SSH_MSG_CHANNEL_REQUEST | uint32 recipient channel | string "signal" | boolean FALSE | string signal name without the "SIG" prefix. and it seems to me that sshd of OpenSSH has ignored this request. Is my recognition correct? If so, is there a plat to implement it? I...

.... Furthermore, this appears to be stalling the other commands as well. (More experimentation is needed on this point.) - SSH_MSG_DISCONNECT tears down the whole session, killing *all* the commands. I could do this, but now I have to restart all the other commands that get trashed. - I could try a SSH_MSG_CHANNEL_REQUEST "signal" and send SIGINT, SIGTERM, SIGABRT, etc, but I don't see a handler for "signal" in the server loop. I've crawled the source for a few hours, but haven't come up with any ideas more productive than the non-options above. I could use a clue or two as to other...

https://bugzilla.mindrot.org/show_bug.cgi?id=1395 Summary: "session_input_channel_req: no session" should be a debug message Classification: Unclassified Product: Portable OpenSSH Version: 4.7p1 Platform: All OS/Version: All Status: NEW Keywords: patch Severity: minor

...t when I look at the trace from libssh2, packet type 4 received, => SSH_MSG_DEBUG packet type 91 received, => SSH_MSG_CHANNEL_OPEN_CONFIRMATION packet type 93 received, => SSH_MSG_CHANNEL_WINDOW_ADJUST packet type 99 received, => SSH_MSG_CHANNEL_SUCCESS packet type 98 received, => SSH_MSG_CHANNEL_REQUEST packet type 96 received, => SSH_MSG_CHANNEL_EOF packet type 97 received, => SSH_MSG_CHANNEL_CLOSE ==> why ? and in the log sshd, I've some strange line : Jul 7 11:52:16 TOTO sshd[19553]: debug1: session_exit_message: release channel 0 Jul 7 11:52:16 TOTO sshd[19553]: debug2: chann...

...t; error is printed out by the client) the exchange gets successfully completed. All the files that have to be transferred are transferred all right, with no data missing in the transferred files. More to the point: The traces show that the server started the closing phase by sending an exit-status SSH_MSG_CHANNEL_REQUEST message followed by an SSH_MSG_CHANNEL_EOF message and an SSH_MSG_CHANNEL_CLOSE message, to which the OpenSSH client at L replies with an SSH_MSG_CHANNEL_CLOSE message of its own: The session is closed correctly, as far as the server in S is concerned. Second, if I modify ssh.c in the OpenSSH code...

I have coded a patch witch allows to forward environment variables from the client to the server. To specify forwarding in your ssh client add the option ForwardEnv varname # forward varname with value # as in environment of the # ssh client. If variable is # not defined in the environment # of the ssh client nothing will # be forwarded. ForwardEnv varname=value # forward

Hi, After I exec a process in a ssh channel, I would like to send it a signal. According to the ssh specs, I'd send a SSH_MSG_CHANNEL_REQUEST message across the channel with a "signal" string. But, it doesn't seem that openssh supports this. I searched around and found http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=104295745607575&w=2 from a couple years ago. Is there any particular reason why this hasn't...

...sy and quick/dirty method was to remove IXON & IXOFF flags from sshtty.c:enter_raw_mode(), but it can easily brake transparency. Another standart method to use was a must. According to IETF RFC4254 ssh server can provide client an idea of doing the control flow at the client side. A special SSH_MSG_CHANNEL_REQUEST message with "xon-xoff" string MUST be used, and client MAY ignore this message. This feature is not implemented in OpenSSH, nor in client nor in the server. As we have a great need in using software flow control on the local side with ssh connection to server, i have decided to impl...

OpenSSH clients (in all releases I have been able to test with, including 4.7p1) when talking protocol version 2 seem to be sending SSH_MSG_CHANNEL_REQUEST messages with the want_reply field set to 0. This leads to a problem when the server they interact with does not support the service being requested. If the channel request is for, say, command execution, and the server does not support such a capability, a standards-compliant server won't...

https://bugzilla.mindrot.org/show_bug.cgi?id=1346 --- Comment #38 from Damien Miller <djm at mindrot.org> --- So we could define a channel request that could be interpreted by the server to attempt to set the locale-related environment variables. How about something like: byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "locale at openssh.com" string language string charset Where language might be "en_GB" and charset might be "UTF-8". From this the server could somehow search the local locale database for a good fit....

...Severity: normal Priority: P2 Component: ssh AssignedTo: bitbucket at mindrot.org ReportedBy: jca at newtonesque.kicks-ass.net OpenSSH clients (in all releases I have been able to test with, including 4.7p1) when talking protocol version 2 seem to be sending SSH_MSG_CHANNEL_REQUEST messages with the want_reply field set to 0. This leads to a problem when the server they interact with does not support the service being requested. If the channel request is for, say, command execution, and the server does not support such a capability, a standards-compliant server won't...

When forwarding a Unix-domain socket, the remote socket path must be absolute (otherwise the forwarding fails later). However, guessing absolute path on the remote end is sometimes not straightforward, because the file system location may vary for many reasons, including the system installation, the choices of NFS mount points, or the remote user ID. To allow ssh clients to request remote socket

On Sat, May 27, 2023 at 12:08:43AM +0200, Thorsten Glaser <t.glaser at tarent.de> wrote: > On Fri, 26 May 2023, Mingye Wang (Artoria2e5) wrote: > > > ssh(1) currently affords an argument-passing functionality, but as the manpage > > states, all arguments are simply concatenated by space. > > How else would it do that? The arguments are processed by the > shell

https://bugzilla.mindrot.org/show_bug.cgi?id=2094 Bug ID: 2094 Summary: Executing commands via ssh on a remote host has different parameter passing properties Classification: Unclassified Product: Portable OpenSSH Version: 6.2p1 Hardware: Other OS: OpenBSD Status: NEW Severity:

...er talk with the server. The bug shows up on WindosXp/Cygwin and on Linux. I am not sure if this bug should be assigned to 'sshd' or 'sftp-server'. Steps to reproduce the bug: 1. open connection to a sshd server 2. exchange keys and authenticate user 3. open a ssh channel 4. send SSH_MSG_CHANNEL_REQUEST for sftp subsystem 5. observe how the server responds with - SSH_MSG_CHANNEL_WINDOWS_ADJUST - -----> SSH_MSG_CHANNEL_FAILURE <-------- (a bug?) 6. continue talking with the sftp server as if nothing happened (I can do everything I would expect to: ls, get, put, etc.) Verbose log fr...

https://bugzilla.mindrot.org/show_bug.cgi?id=2283 Bug ID: 2283 Summary: option to execute command without shell Product: Portable OpenSSH Version: 6.6p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: sshd Assignee: unassigned-bugs at

On 2020-01-11 01:38, Darren Tucker wrote: > The command you give is always handled on the server by your shell in some > fashion. It has to be, because SSH only specifies an opaque string for the > remote command, so without doing so you would not be able to specify > arguments at all. It's not obvious why does it have to be this way. ssh sends the command as an array of

...OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: bitbucket at mindrot.org ReportedBy: dazuma at gmail.com It does not appear that sshd in OpenSSH implements section 6.9 of rfc 4254. That is, sending SSH_MSG_CHANNEL_REQUEST with type "signal" for a channel, has no effect. This is being reproduced with a custom client, connecting to OpenSSH 4.7p1 sshd running on Linux (Fedora 8 package openssh-4.7p1-4.fc8). I opened a channel, started a simple long-running remote process (e.g. sleep) with an "exec"...