search for: cleanup_exit

Hi! I'm investigating the seccomp filter in openssh and I wanted to know whether the following system calls should be added to the filter: 1. getgroups - do_authentication2->dispatch_run_fatal->sshpkt_fatal->logdie->cleanup_exit->do_cleanup->temporarily_use_uid->getgroups 2. setgroups - do_authentication2->ssh_dispatch_run_fatal->sshpkt_fatal->logdie->cleanup_exit->do_cleanup->temporarily_use_uid->initgroups->setgroups 3. unlink - do_authentication2->ssh_dispatch_run_fatal->ss...

...cleanup_socket, NULL) < 0) { int saved = errno; cleanup_socket(); packet_disconnect("socket: %.100s", strerror(saved)); *** ssh-agent.c Fri May 11 16:05:57 2001 --- ssh-agent.c.new Fri May 11 16:07:20 2001 *************** *** 860,866 **** perror("setsid"); cleanup_exit(1); } ! if (atexit(cleanup_socket) < 0) { perror("atexit"); cleanup_exit(1); } --- 860,870 ---- perror("setsid"); cleanup_exit(1); } ! /* This is bad...on_exit requires 2 parameters, whereas ! at_exit only takes one. Field 2 is ar...

https://bugzilla.mindrot.org/show_bug.cgi?id=2167 Bug ID: 2167 Summary: Connection remains when fork() fails. Product: Portable OpenSSH Version: 5.3p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: sshd Assignee: unassigned-bugs at

...amily = AF_UNIX; strlcpy(sunaddr.sun_path, socket_name, sizeof(sunaddr.sun_path)); +#ifdef HAVE_CYGWIN + prev_mask = umask(0177); +#endif if (bind(sock, (struct sockaddr *) & sunaddr, sizeof(sunaddr)) < 0) { perror("bind"); +#ifdef HAVE_CYGWIN + umask(prev_mask); +#endif cleanup_exit(1); } +#ifdef HAVE_CYGWIN + umask(prev_mask); +#endif if (listen(sock, 5) < 0) { perror("listen"); cleanup_exit(1); -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com

...@ -915,7 +915,7 @@ * resolve the bare hostname name using the system resolver's usual * search rules. */ - if (addrs == NULL) { + if (addrs == NULL && options.proxy_command == NULL) { if ((addrs = resolve_host(host, options.port, 1, cname, sizeof(cname))) == NULL) cleanup_exit(255); /* resolve_host logs the error */ -- Iain Morgan

...ssigned-bugs at mindrot.org Reporter: kavi at juniper.net Created attachment 2424 --> https://bugzilla.mindrot.org/attachment.cgi?id=2424&action=edit possible fix. sshd crashes with the core dump when used in high scale environment. The program crashes inside the function "cleanup_exit" at line if (use_privsep && privsep_is_preauth && pmonitor->m_pid > 1) It is always assumed here that pmonitor is always not NULL. However pmonitor can be null, in the execution sequence below: #0 0x0804e214 in cleanup_exit (i=255) at ../../../../../../src/crypto/op...

...----- Attachment #2536|0 |1 is obsolete| | --- Comment #54 from Damien Miller <djm at mindrot.org> --- Created attachment 2537 --> https://bugzilla.mindrot.org/attachment.cgi?id=2537&action=edit kill more packet.c fatal/cleanup_exit ... and kill some more fatal/cleanup_exit in packet.c There were more lurking than I thought :( -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug.

...t %d", ssh_remote_ipaddr(ssh), ssh_remote_port(ssh)); return -1; } - verbose("Read error from remote host %s port %d: %s", + logit("Read error from remote host %s port %d: %s", ssh_remote_ipaddr(ssh), ssh_remote_port(ssh), strerror(errno)); cleanup_exit(255);

...7 +708,7 @@ server_loop(pid_t pid, int fdin_arg, int &nalloc, max_time_milliseconds); if (received_sigterm) { - logit("Exiting on signal %d", received_sigterm); + logit("Exiting on signal %d", (int)received_sigterm); /* Clean up sessions, utmp, etc. */ cleanup_exit(255); } @@ -858,7 +858,7 @@ server_loop2(Authctxt *authctxt) &nalloc, 0); if (received_sigterm) { - logit("Exiting on signal %d", received_sigterm); + logit("Exiting on signal %d", (int)received_sigterm); /* Clean up sessions, utmp, etc. */ cleanup_...

Hi, ssh clients shows "closed by UNKNOWN" message when a socket is closed by a remote side while ssh is waiting for user's password: $ ssh user at localhost user at localhost's password: Connection closed by UNKNOWN When the packet_read_seqnr() calls get_remote_ipaddr(), a connection's socket is already closed and there's not been any other call of this function yet

...exist before command gets run from * the parent. */ - prev_mask = umask(0177); - sock = unix_listener(socket_name, SSH_LISTEN_BACKLOG, 0); - if (sock < 0) { - /* XXX - unix_listener() calls error() not perror() */ - *socket_name = '\0'; /* Don't unlink any existing file */ - cleanup_exit(1); + if (sock == 0) { + prev_mask = umask(0177); + sock = unix_listener(socket_name, SSH_LISTEN_BACKLOG, 0); + if (sock < 0) { + /* XXX - unix_listener() calls error() not perror() */ + *socket_name = '\0'; /* Don't unlink any existing file */ + cleanup_exit(1); + } + uma...

...tp = (fd_set *)xcalloc(howmany(active_state->connection_in + 1, NFDBITS), sizeof(fd_mask)); @@ -1087,6 +1101,7 @@ } } if (ret == 0) { + conntimedout = 1; logit("Connection to %.200s timed out while " "waiting to read", get_remote_ipaddr()); cleanup_exit(255); @@ -1098,11 +1113,12 @@ sizeof(buf), &cont); } while (len == 0 && cont); if (len == 0) { + connclosed = 1; /* if anybody wants to know */ logit("Connection closed by %.200s", get_remote_ipaddr()); cleanup_exit(255); } if (len < 0) - fa...

Hi, sifting through my system's logs, I noticed many break-in attempts by rogue ssh clients trying long lists of common passwords. For some time now I pondered different approaches to counter these, but could not come up with a solution that really satisfied me. I finally reached the conclusion that any countermeasures required support in sshd itself, and created the attached patch. If

...d by A.B.D.26 (exit status 255) I ran this at two different times of day, and got the same host in that last "Connection closed" error. As the error is non-specific, here's the backtrace: #0 0x00007ffff6802d50 in _exit () from /lib64/libc.so.6 #1 0x00007ffff7fc2048 in cleanup_exit (i=255) at ../cleanup.c:31 #2 0x00007ffff7f9fa99 in ssh_packet_read_seqnr (ssh=0x7ffff86f4520, typep=0x7fffffffde0f "", seqnr_p=0x7fffffffde10) at ../packet.c:1330 #3 0x00007ffff7fa69f5 in ssh_dispatch_run (ssh=0x7ffff86f4520, mode=0, done=0x7ffff8207178, ctxt=0x...

...eceive from the EPIPE errno check: void mm_request_receive(int sock, struct sshbuf *m) { u_char buf[4], *p = NULL; u_int msg_len; int r; debug3_f("entering"); if (atomicio(read, sock, buf, sizeof(buf)) != sizeof(buf)) { if (errno == EPIPE) cleanup_exit(255); fatal_f("read: %s", strerror(errno)); } Questions: - Is this the expected exit point of `sshd -i` ? - If so, is there a reason to return a failure exit status? Thanks! Donald -- Donald Buczek buczek at molgen.mpg.de Tel: +49 30 8413 1433

On Thu, May 30, 2024 at 6:02?PM Opty <opty77 at gmail.com> wrote: > On Thu, May 30, 2024 at 3:03?AM Damien Miller <djm at mindrot.org> wrote: > > On Wed, 29 May 2024, Opty wrote: > > > On Mon, May 27, 2024 at 4:18?AM Damien Miller <djm at mindrot.org> wrote: > > > > Yeah, you're adding a new thing that will be logged. IMO you should > >

...; - verbose("Read error from remote host %s port %d: %s", > + logit("Read error from remote host %s port %d: %s", > ssh_remote_ipaddr(ssh), ssh_remote_port(ssh), > strerror(errno)); > cleanup_exit(255); Indeed I am. What now? Should PuTTY change its 'perfectly OK to unceremoniously slam the connection shut when you're done' attitude? Regards, Opty

https://bugzilla.mindrot.org/show_bug.cgi?id=1118 --- Comment #4 from Colin Watson <cjwatson at debian.org> 2010-03-02 02:50:08 EST --- Created an attachment (id=1803) --> (https://bugzilla.mindrot.org/attachment.cgi?id=1803) debug() and cleanup_exit() on signal rather than fatal() -- Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

I'm seeing something similar to bug 1179 (https://bugzilla.mindrot.org/show_bug.cgi?id=1179), even with the reordered IP options check. For some reason, getsockopt is returning an IP options of length 2, value 00 00. Would Mark Weindling's original patch (https://bugzilla.mindrot.org/attachment.cgi?id=1105) break anything if I incorporated it? Platform: HP NonStop S7000 series

...> https://bugzilla.mindrot.org/attachment.cgi?id=2432&action=edit proposed fix ssh-agent sometimes forks child processes. For example, ask_permission() may fork a child process to execute an askpass program. If it fails to execute, the child process exits using fatal(), which in turn calls cleanup_exit(), and the latter calls cleanup_socket(). As result, an error in child process causes unintended UNIX-domain socket removal. The fix is to record pid of the process that is responsible for socket cleanup, and skip this cleanup for other processes. -- You are receiving this mail because: You are...