search for: the_authctxt

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

...p.c Thu Jan 29 08:56:11 2009 *************** *** 957,962 **** --- 957,968 ---- c = channel_connect_to(target, target_port, "direct-tcpip", "direct-tcpip"); + if (c == NULL){ + verbose("Tunnel denied: user '%s' from %s to %s:%d", the_authctxt->user, get_remote_ipaddr(), target, target_port); + } else { + verbose("Tunnel opened: user '%s' from %s to %s:%d", the_authctxt->user, get_remote_ipaddr(), target, target_port); + } + xfree(originator); xfree(target);

https://bugzilla.mindrot.org/show_bug.cgi?id=1850 Summary: Build fails when SELinux is enabled Product: Portable OpenSSH Version: 5.7p1 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: unassigned-bugs at mindrot.org ReportedBy:

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

Greetings. Attached is a patch that provides more logging information for example: Mar 19 08:34:54 secosr5 sshd[7667]: Accepted publickey of? vix at wormhole for root from 192.168.1.1 port 1256 ssh2 Mar 19 08:34:54 secosr5 sshd[7667]: executing command 'who' for? vix at wormhole as user root Mar 19 10:37:16 secosr5 sshd[7725]: Accepted publickey of? vix at wormhole for root from

...quot; +#include "auth.h" +#include "log.h" + +#ifdef WITH_SELINUX +#include <selinux/selinux.h> +#include <selinux/flask.h> +#include <selinux/context.h> +#include <selinux/get_context_list.h> +#include <selinux/get_default_type.h> +extern Authctxt *the_authctxt; + +static const security_context_t selinux_get_user_context(const char *name) { + security_context_t user_context=NULL; + if (get_default_context(name,NULL,&user_context)) { + if (security_getenforce() > 0) + fatal("Failed to get default security context for %s.", name); + el...

...p.c Thu Jan 29 08:56:11 2009 *************** *** 957,962 **** --- 957,968 ---- c = channel_connect_to(target, target_port, "direct-tcpip", "direct-tcpip"); + if (c == NULL){ + verbose("Tunnel denied: user '%s' from %s to %s:%d", the_authctxt->user, get_remote_ipaddr(), target, target_port); + } else { + verbose("Tunnel opened: user '%s' from %s to %s:%d", the_authctxt->user, get_remote_ipaddr(), target, target_port); + } + xfree(originator); xfree(target); -- Configure bugmail:...

http://bugzilla.mindrot.org/show_bug.cgi?id=125 alex.bell at bt.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alex.bell at bt.com ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the

...-894,6 +894,9 @@ c = channel_new("session", SSH_CHANNEL_LARVAL, -1, -1, -1, /*window size*/0, CHAN_SES_PACKET_DEFAULT, 0, "server-session", 1); + set_unlimited(&c->input,1); + set_unlimited(&c->output,1); + c->dynamic_window = 1; if (session_open(the_authctxt, c->self) != 1) { debug("session open failed, free channel %d", c->self); channel_free(c); diff -u openssh-3.8.1p1/ssh.c openssh-3.8.1p1-dynwindow/ssh.c --- openssh-3.8.1p1/ssh.c 2004-03-21 17:36:01.000000000 -0500 +++ openssh-3.8.1p1-dynwindow/ssh.c 2004-07-07 09:54:03.000000...

...oop.c --- openssh-4.3p2.orig/serverloop.c 2005-12-31 00:33:37.000000000 -0500 +++ openssh-4.3p2/serverloop.c 2006-08-25 08:24:58.000000000 -0400 @@ -941,7 +941,11 @@ goto done; tun = forced_tun_device; } - sock = tun_open(tun, mode); +#if defined(SSH_TUN_LINUX) + sock = tun_open(tun, mode, the_authctxt->pw->pw_uid); +#else + sock = tun_open(tun, mode); +#endif if (sock < 0) goto done; c = channel_new("tun", SSH_CHANNEL_OPEN, sock, sock, -1, diff -Nurd openssh-4.3p2.orig/ssh.c openssh-4.3p2/ssh.c --- openssh-4.3p2.orig/ssh.c 2005-12-31 00:33:37.000000000 -0500 +++ opens...

...-892,6 +892,9 @@ c = channel_new("session", SSH_CHANNEL_LARVAL, -1, -1, -1, /*window size*/0, CHAN_SES_PACKET_DEFAULT, 0, "server-session", 1); + set_unlimited(&c->input,1); + set_unlimited(&c->output,1); + c->dynamic_window = 1; if (session_open(the_authctxt, c->self) != 1) { debug("session open failed, free channel %d", c->self); channel_free(c); Only in ssh: serverloop.c~ Common subdirectories: src/usr.bin/ssh/sftp and ssh/sftp Common subdirectories: src/usr.bin/ssh/sftp-server and ssh/sftp-server Common subdirectories: src/usr....

...op.c Wed Jan 21 01:02:50 2004 +++ openssh-3.8.1p1-devs//serverloop.c Mon Feb 21 11:33:13 2005 @@ -867,7 +867,7 @@ originator, originator_port, target, target_port); /* XXX check permission */ - sock = channel_connect_to(target, target_port); + sock = channel_connect_to(target, target_port, the_authctxt); xfree(target); xfree(originator); if (sock < 0) -----Message d'origine----- De : Bucaille, Lionel Envoy? : mardi 22 f?vrier 2005 11:21 ? : 'openssh-unix-dev at mindrot.org' Objet : 3.8.1p1 option "permitopennet" added Hello, I send you a small patch about a &quo...

...000 @@ -200,9 +200,11 @@ u_int utmp_len = MAXHOSTNAMELEN; int *startup_pipes = NULL; int startup_pipe; /* in child */ +#ifdef USE_PRIVSEP /* variables used for privilege separation */ int use_privsep; struct monitor *pmonitor = NULL; +#endif /* global authentication context */ Authctxt *the_authctxt = NULL; @@ -308,9 +310,10 @@ grace_alarm_handler(int sig) { /* XXX no idea how fix this signal handler */ +#ifdef USE_PRIVSEP if (use_privsep && pmonitor != NULL && pmonitor->m_pid > 0) kill(pmonitor->m_pid, SIGALRM); - +#endif /* Log error and exit. */ fatal(...

Hi, SSH brute force attacks seem to enjoy increasing popularity. Call me an optimist or a misrouted kind of contributer to the community, but on our company server I actually go through the logs and report extreme cases to the providers of the originating IP's. With the increasing number of these attacks, however, I have now decided that it's better to move the SSHd to a different

Hi All. For various reasons, we're currently looking at extending (or even overhauling) the config parser used for sshd_config. Right now the syntax I'm looking at is a cumulative "Match" keyword that matches when all of the specified criteria are met. This would be similar the the Host directive used in ssh_config, although it's still limiting (eg you can't easily