Displaying 20 results from an estimated 1000 matches similar to: "Channels API and ~& question"
2002 Feb 04
1
forkoff()
Please review the function below, forkoff(), meant to be used in
clientloop.c instead of daemon() and the code in process_escapes().
The intention is to make ~D ( like ~& but also detach) possible and to
make it possible for ssh -f (or ssh -f -f - see other thread on this)
to detach, not just forkoff().
I also intend to use the same detach technique in a feature patch for
the hang-on-exit
2002 Feb 05
0
New forkoff() and chan_wont_read/write() API
Markus,
How's this patch?
- a chan_wont_read()/chan_wont_write() API is added that is very much
like chan_read_failed()/chan_write_failed(), but for the debug
messages and chan_wont_*() don't ever call error()
The 3.0.2p1 channel_pre_x11_open() uses chan_*_failed() but looks
like it ought to use chan_wont_*() instead :)
- forkoff() no longer fakes EOF for SSHv2 (still
2014 Feb 06
2
Timing out a channel exec 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
2002 Jul 31
18
so-called-hang-on-exit
so, should this go into 3.5?
Index: serverloop.c
===================================================================
RCS file: /home/markus/cvs/ssh/serverloop.c,v
retrieving revision 1.103
diff -u -r1.103 serverloop.c
--- serverloop.c 24 Jun 2002 14:33:27 -0000 1.103
+++ serverloop.c 12 Jul 2002 16:34:20 -0000
@@ -388,6 +388,11 @@
buffer_append(&stderr_buffer, buf, len);
}
}
+ /*
2002 Jan 11
1
X11 forwarding, -f, error handling
I'd like a feature whereby ssh puts itself in the background after the
first successful X11 (or other port) forwarding.
The reason for this is simple: error handling.
If the application fails to open the X display and exits, then the
client can still exit with the application's exit code. But if the
application opens the X display successfully, then it can just display
any errors by
2002 Feb 01
1
FEATURE: -f -f - fork after successful open of fwd port/display/agent
Background
==========
"ssh -f ..." causes ssh to fork into the background when userauth
successfully completes.
WHAT
===
With this patch "ssh -f -f ..." causes ssh to fork into the background
when the first forwarded port/x11 display/agent is successfully opened.
WHY
===
This feature makes launching remote X11 apps more reliable: when ssh
exits it must have exited because
2001 Jul 22
1
[patch] ignore SSH2_MSG_IGNORE packets
Hi,
protocolkeepalives sends ssh_msg_ignore, which the ssh2 server handles
incorrectly (i.e. it produces some output to syslog, instead of
ignoring the packet):
Jul 9 11:58:07 ren sshd[16580]: error: Hm, dispatch protocol error:
type 32 plen 4
This patch implements a highly advanced function to ignore these
packets ;)
Matthew
-------------- next part --------------
An embedded and
2001 Oct 26
2
SSHv2 sshd exit criteria
When should sshd disconnect an SSHv2 connection?
Markus Friedl says "for protocol v2 the client decides when to close the
connection."
In principle, I agree, because SSHv2 supports multiple sessions over the
same connection, with the client able to launch new sessions anytime
then it should be upto the client.
But this would be a major cultural change for most users, and would
break
2007 Mar 23
7
4.6p1 chan_read_failed error
The 4.6p1 sshd is logging this error during remote commands or file
transfers:
error: channel 0: chan_read_failed for istate 3
Platform is Solaris 8, 4.6p1 + OpenSSL 0.9.8d.
The commands and transfers work correctly, so the error message appears
to be spurious. The error message does not appear when processing logins.
Otherwise 4.6p1 is running without any apparent problems. This error
2010 Sep 13
15
[Bug 1818] New: SSH2_MSG_CHANNEL_FAILURE on closed channel
https://bugzilla.mindrot.org/show_bug.cgi?id=1818
Summary: SSH2_MSG_CHANNEL_FAILURE on closed channel
Product: Portable OpenSSH
Version: 5.1p1
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: sshd
AssignedTo: unassigned-bugs at mindrot.org
ReportedBy:
2002 May 17
2
[Fwd: Re: X-windows security in Gnome]
The "integration" of SSH with apps is already there.
Read the OpenSSH [or other SSH implementation's] man pages and the SSHv2 specs. RTFM!
Essentially SSH supports tunneling of X11 traffic. The SSH daemon is responsible for creating a local X11 display endpoint and setting the DISPLAY environment variable appropriately, then the apps you run in SSH sessions with X11 forwarding do
2002 May 17
1
[Fwd: Re: X-windows security in Gnome]
What else can possibly be done to integrate SSH and apps? I mean, it works, doesn't it?
Jim's message was unclear - I was left with the impression that Jim was not aware of the existing X11 forwarding in SSH.
Cheers,
Nico
--
> -----Original Message-----
> From: Gregory Leblanc [mailto:gleblanc at linuxweasel.com]
> Sent: Friday, May 17, 2002 5:33 PM
> To: OpenSSH Devel
2002 Jul 12
0
[Bug 273] sshd hangs on shell exit if user spawned child with/bin/nohup
Perhaps the man page should be fixed then, because neither
rsh nor rlogin provide any kind of port forwarding, or X11
forwarding, etc...
Also, the comparison between ssh and rsh is more appropriate
if you're talking about SSHv1 and much less so if you're
talking about SSHv2.
Nico
--
> -----Original Message-----
> From: Eric Garff [mailto:egarff at omniture.com]
> Sent:
2000 Jan 07
2
possible clue on tcp forwarding problems
When I encounter the problem with TCP port forwarding locking up, I'll
see this on the client window (if I haven't invoked ssh with -q):
chan_shutdown_read failed for #1/fd6: Transport endpoint is not connected
chan_shutdown_read failed for #1/fd6: Transport endpoint is not connected
This is with Blowfish encryption. I have to kill and restart the client
when this happens.
Phil
2001 Feb 22
3
intermittent stderr
The command "ssh ls -l /doesnotexist" gives various responses:
Running from a 200 MHz PentiumPro with dsa key added to ssh-agent:
Mistakes worst to fast machine:
To a faster 600 MHz dual processor i686 600 MHz machine:
ls: /doesnotexist: No such file or directory -- correct
nothing at all -- wrong
ls: select: Bad file descriptor -- wrong
2002 Jun 07
2
SIGCHLD may be inherited blocked
So, we just found some ugly behaviour of OpenSSH on Solaris.
Sometimes, it seems, sshd gets started with SIGCHLD blocked, this,
apparently, being the setting of sshd's parent (a shell no doubt);
signal blocking is inherited across exec*(). I don't know exactly which
shell, or what really is at fault, but it happens.
The problem is that the code in collect_children() first blocks SIGCHLD
2001 Oct 31
2
OpenStep (NeXT) and TTY modes
OpenStep, apparently, does not initialize new pty/tty modes to a sane
default.
I'm thinking this code snippet, added to tty_parse_modes() before the
for(;;) loop should suffice:
#ifdef HAVE_NEXT
tio.c_oflag |= ONLCR;
tio.c_lflag |= ECHO;
#endif /* HAVE_NEXT */
Also, I've noticed that "ssh -t next_host stty" gives different output
than an interactive session to the same
2007 Apr 08
11
Error message after upgraing the openssh 4.6P1
Hi,
We have upgraded the openssh 4.6P1 on Solaris 8 servers. After upgrade
we get the below error message whenever we execute the remote commands
using ssh. Please let me know what the fix is for this.
Apr 8 03:03:43 dvsrv10 sshd[25379]: [ID 800047 auth.info] Accepted
publickey for osteam from 10.0.93.31 port 35856 ssh2
Apr 8 03:03:50 dvsrv10 sshd[25381]: [ID 800047 auth.error] error:
2001 Oct 25
2
SIGCHLD race *trivial* patch
Yes, this is a patch against an older version of OpenSSH with other
stuff anyways, BUT, it's so TRIVIAL(*), that you can see how it would
apply to newer versions (which I've not tried).
Here's the gist: server_loop2() has a race condition with respect to
reception of SIGCHLD and checking/setting child_terminated. This patch
does two things: wait_until_can_do_something() adds a 1
2000 Oct 24
3
openssh-SNAP-20001016
Using openssh-SNAP-20001016 all of our problems with hanging connections
have gone away (woohoo!), and it seems to be working flawlessly, but I am
seeing messages like this in syslog:
Oct 24 16:57:48 dhumb301 sshd[17752]: error: channel 0: internal error: we
do not read, but chan_read_failed for istate 8
Oct 24 16:57:59 dhumb301 sshd[17771]: error: select: Bad file descriptor
Oct 24 16:58:30