similar to: SCP client prints out "lost connection" error message occasionally

I don't see a problem, my MTU is at the default value = 1500, but 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

I am using the ssh port forwarding feature. My configuration is as follows: On my server machine, running sshd, and app1. On my client machine, running ssh (client) and app2. The client connects to the server requesting remote port forwarding from port X on the server machine to port Y on the client machine. app2 is listening on port Y on the client machine. app1 connects to port X

At work we have a large collection of scripts to move log and config files around. These depend on commercial (F-Secure) ssh/scp, as it supports the -u option to delete the source file after (successful) copying. That is the sole reason we can't run openssh on our 150+ unix boxes. I have attached a patch below, which adds the -u option to delete the source file after copying, provided there

Hi a fellow debian developer pointed it out to me, that ssh itself does not check the username that is provided for login into a remote host, but that scp checks it. I could verify that the current openssh code from cvs still has a check for the username in scp.c but not in ssh.c. So I created the attached small patch to remove the username check from scp. I hope ?t's correct and that you

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

https://bugzilla.mindrot.org/show_bug.cgi?id=1384 Summary: OpenSSH clients causing deadlocks Classification: Unclassified Product: Portable OpenSSH Version: 4.7p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: bitbucket at mindrot.org

Hi, I have a question about signal forwarding support in sshd of OpenSSH. http://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

Is anyone aware of a method to force termination of a single channel without waiting for the associated process to complete? I have a use case where my client submits several commands to be executed over the same session at the same time on separate channels. In some cases (cough df), one or more those commands may hang indefinitely. I detect that the command is not finishing in a reasonable

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

On Mon, May 29, 2023 at 06: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)

Hi, I have made a patch which improves scp utility. It adds two new features: rate limit and resume support. With rate limit it's possible to limit transfer speed. Resume allows to continue file transfer where it was last interrupted. Also the progress meter was improved. Here is my patch, please send comments about it and what I can do better if there is something to fix. ---

Hi, Martijn sent the following patch to me in private and agreed that i post it here. In any other program in OpenBSD base, i'd probably agree with the basic approach. Regarding OpenSSH, however, i worry whether wcwidth(3) can be used. While wcwidth(3) is POSIX, it is not ISO C. Does OpenSSH target platforms that don't provide wcwidth(3)? If so, do you think the problem can be solved

Hi, using both OpenSSH_2.5.1p1 (compiled myself) and openssh-2.9p1-23.i386.rpm from ftp.suse.com 7.2_update I get the following "leak" : using `scp' I tried to copy a file from a local floppy disk to a remote system, but the disk had an read error and scp didn't get any real data from floppy: turtle koenig > scp /media/floppy/file.c harald:file.c

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

Good day time! Using openssh with a serial attached terminal figures with a problem with flow control when serial terminal has printer connected to it etc. because ssh disables xon/xoff on associated terminal. At present ssh client always disables xon/xoff on associated terminal device, regarding of it's previous state, e.g. ixon and ixoff options were set or not. By searching the google

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

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

Hello, I have noticed that since release 5.x of openssh, the scp command rejects remote user names with white spaces. (We have such user names on Windows hosts) For instance: $ scp myfile "my user"@machine:. used to work with openssh-4.2p1 and fails with 5.2p1 and 5.3p1: my user: invalid user name. I have traced this down to revision 1.129 of scp.c which now calls okname(). OTOH,

http://bugzilla.mindrot.org/show_bug.cgi?id=1173 Summary: scp reports lost connection for very large files Product: Portable OpenSSH Version: 4.3p2 Platform: HPPA OS/Version: HP-UX Status: NEW Severity: normal Priority: P2 Component: scp AssignedTo: bitbucket at mindrot.org ReportedBy:

Thanks. Unfortunately, that made no difference. On Fri, Nov 30, 2018 at 1:20 PM Thomas Durand <tom at rezoo.org> wrote: > Exactly - I removed then with > *find* . -name "dovecot.index*" -type f -delete > > There is no need to restart dovecot. IMAP client will be forced to resync > all the emails from the server. > > > Le 28 nov. 2018 ? 23:20, JCA