From mynhier at cs.utk.edu Wed Aug 2 00:38:35 2006 From: mynhier at cs.utk.edu (Chad Mynhier) Date: Tue, 01 Aug 2006 10:38:35 -0400 Subject: SMF/process contracts in Solaris 10 Message-ID: <20060801143835.D795617A04@cetus1.cs.utk.edu> I'm including a non-Sun-sshd-derived patch for this problem below. To restate the problem, sshd doesn't put child processes into separate process contracts, so every process for which sshd was ever an ancestor (including processes that have otherwise been daemonized) are in the same process contract. This means that if sshd was started via the service management facility (SMF), any normal or abnormal termination of sshd via SMF will cause all of the child sshd processes (and any process that was ever started from within an ssh session, regardless of whether that ssh session still exists) to be terminated. The output below shows the wrong behavior, i.e., that the child processes are in process contract 562 with the parent sshd process: server>ps PID TTY TIME CMD 16778 pts/2 0:00 tcsh 16849 pts/2 0:00 ps server>ptree -c 16778 [process contract 1] 1 /sbin/init [process contract 4] 7 /lib/svc/bin/svc.startd [process contract 562] 16771 /usr/local/sbin/sshd 16774 /usr/local/sbin/sshd -R 16776 /usr/local/sbin/sshd -R 16778 -tcsh 16850 ptree -c 16778 server> In the above case, a "svcadm disable ssh" will terminate all sshd child processes. The output below shows the correct behavior, i.e., that the child process is in a separate process contract (565): server>ps PID TTY TIME CMD 1195 pts/2 0:00 tcsh 1256 pts/2 0:00 ps server>ptree -c 1195 [process contract 565] 1191 /usr/local/sbin/sshd -R 1193 /usr/local/sbin/sshd -R 1195 -tcsh 1257 ptree -c 1195 server> In this case, a "svcadm disable ssh" will not terminate existing ssh connections. Chad Mynhier diff -Naur --exclude=RCS openssh-4.3p2/configure.ac openssh-4.3p2-process-contracts/configure.ac --- openssh-4.3p2/configure.ac Wed Feb 8 11:11:06 2006 +++ openssh-4.3p2-process-contracts/configure.ac Tue Jul 25 12:56:49 2006 @@ -1,4 +1,4 @@ -# $Id: configure.ac,v 1.322.2.6 2006/02/08 11:11:06 dtucker Exp $ +# $Id: configure.ac,v 1.8 2006/07/25 12:56:33 mynhierc Exp $ # # Copyright (c) 1999-2004 Damien Miller # @@ -15,7 +15,7 @@ # OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. AC_INIT(OpenSSH, Portable, openssh-unix-dev at mindrot.org) -AC_REVISION($Revision: 1.322.2.6 $) +AC_REVISION($Revision: 1.8 $) AC_CONFIG_SRCDIR([ssh.c]) AC_CONFIG_HEADER(config.h) @@ -414,6 +414,15 @@ AC_DEFINE(DISABLE_UTMP) AC_DEFINE(DISABLE_WTMP, 1, [Define if you don't want to use wtmp]) + else + AC_MSG_RESULT(no) + fi + AC_MSG_CHECKING(for process contracts) + if test "$sol2ver" -ge 10; then + AC_MSG_RESULT(yes) + AC_DEFINE(WITH_SOLARIS_PROCESS_CONTRACTS, 1, + [Define if you have Solaris process contracts]) + LIBS="$LIBS -lcontract" else AC_MSG_RESULT(no) fi diff -Naur --exclude=RCS openssh-4.3p2/sshd.c openssh-4.3p2-process-contracts/sshd.c --- openssh-4.3p2/sshd.c Sat Dec 24 03:59:12 2005 +++ openssh-4.3p2-process-contracts/sshd.c Tue Jul 25 20:48:02 2006 @@ -86,6 +86,12 @@ #include "monitor_wrap.h" #include "monitor_fdpass.h" +#ifdef WITH_SOLARIS_PROCESS_CONTRACTS +#include +#include +#include +#endif /* WITH_SOLARIS_PROCESS_CONTRACTS */ + #ifdef LIBWRAP #include #include @@ -866,6 +872,144 @@ debug3("%s: done", __func__); } +#ifdef WITH_SOLARIS_PROCESS_CONTRACTS +/* + * Returns the file descriptor for the process contract template on success, + * -1 on failure. + */ +int +pre_fork_contract_processing() +{ + int tmpl_fd=-1; + + if ((tmpl_fd = open64(CTFS_ROOT "/process/template", O_RDWR)) == -1) { + error("Error opening " CTFS_ROOT "/process/template: %.100s",strerror(errno)); + goto cleanup_pre_fork_contract_processing; + } + /* + * We have to set certain attributes before activating the template. + */ + if (ct_pr_tmpl_set_fatal(tmpl_fd, CT_PR_EV_HWERR|CT_PR_EV_SIGNAL) != 0) { + error("Error setting process contract template fatal events: %.100s",strerror(errno)); + goto cleanup_pre_fork_contract_processing; + } + if (ct_tmpl_set_critical(tmpl_fd, CT_PR_EV_HWERR) != 0) { + error("Error setting process contract template critical events: %.100s",strerror(errno)); + goto cleanup_pre_fork_contract_processing; + } + /* + * Now make this the active template for this process. + */ + if (ct_tmpl_activate(tmpl_fd) != 0) { + error("Error activating process contract template: %.100s",strerror(errno)); + goto cleanup_pre_fork_contract_processing; + } + + return tmpl_fd; + +cleanup_pre_fork_contract_processing: + /* + * Certain failure modes could lead to file descriptor leakage + * if we don't clean up after ourselves. + */ + if (tmpl_fd > 0) { + close(tmpl_fd); + } + return -1; +} + +void +post_fork_contract_processing(int tmpl_fd,int pid) +{ + char ctl_path[MAXPATHLEN]; + ctid_t ctid; + ct_stathdl_t stathdl; + int ctl_fd=-1; + int pathlen; + int stat_fd=-1; + + /* + * First clear the active template. + */ + if (ct_tmpl_clear(tmpl_fd) != 0) { + error("Error clearing active process contract template: %.100s",strerror(errno)); + goto cleanup_post_fork_contract_processing; + } + close(tmpl_fd); + + /* + * If the fork didn't succeed (pid < 0), or if we're the child + * (pid == 0), we have nothing more to do. + */ + if (pid <= 0) { + return; + } + + /* + * Now abandon the contract we've created. This involves the + * following steps: + * - Get the contract id (ct_status_read(), ct_status_get_id()) + * - Get an fd for the ctl file for this contract + * (/proc/all/contracts//ctl) + * - Abandon the contract (ct_ctl_abandon(fd)) + */ + if ((stat_fd = open64(CTFS_ROOT "/process/latest", O_RDONLY)) == -1) { + error("Error opening 'latest' process contract: %.100s",strerror(errno)); + goto cleanup_post_fork_contract_processing; + } + if (ct_status_read(stat_fd, CTD_COMMON, &stathdl) != 0) { + error("Error reading process contract status: %.100s",strerror(errno)); + goto cleanup_post_fork_contract_processing; + } + if ((ctid = ct_status_get_id(stathdl)) < 0) { + error("Error getting process contract id: %.100s",strerror(errno)); + goto cleanup_post_fork_contract_processing; + } + ct_status_free(stathdl); + close(stat_fd); + + pathlen = snprintf(ctl_path, MAXPATHLEN, CTFS_ROOT "/process/%ld/ctl",ctid); + if (pathlen > MAXPATHLEN) { + /* + * Note: Even though this case is unlikely, this could + * theoretically lead to contract id leakage, as it would + * prevent us from abandoning the contract. If we were to + * run long enough with enough leakage, we would bump + * up against process resource limits. + */ + error("Won't attempt to open process contract ctl file: %.100s",strerror(ENAMETOOLONG)); + goto cleanup_post_fork_contract_processing; + } + if ((ctl_fd = open64(ctl_path, O_WRONLY)) < 0) { + error("Error opening process contract ctl file: %.100s",strerror(errno)); + goto cleanup_post_fork_contract_processing; + } + if (ct_ctl_abandon(ctl_fd) < 0) { + error("Error abandoning process contract: %.100s",strerror(errno)); + goto cleanup_post_fork_contract_processing; + } + close(ctl_fd); + return; + +cleanup_post_fork_contract_processing: + /* + * Certain failure modes could lead to file descriptor leakage + * if we don't clean up after ourselves. + */ + if (tmpl_fd > 0) { + close(tmpl_fd); + } + if (stat_fd > 0) { + close(stat_fd); + } + if (ctl_fd > 0) { + close(ctl_fd); + } + return; +} + +#endif /* WITH_SOLARIS_PROCESS_CONTRACTS */ + /* * Main program for the daemon. */ @@ -893,6 +1037,9 @@ Authctxt *authctxt; int ret, key_used = 0; Buffer cfg; +#ifdef WITH_SOLARIS_PROCESS_CONTRACTS + int contract_fd=-1; +#endif #ifdef HAVE_SECUREWARE (void)set_auth_parameters(ac, av); @@ -1503,6 +1650,9 @@ * the child process the connection. The * parent continues listening. */ +#ifdef WITH_SOLARIS_PROCESS_CONTRACTS + contract_fd = pre_fork_contract_processing(); +#endif /* WITH_SOLARIS_PROCESS_CONTRACTS */ if ((pid = fork()) == 0) { /* * Child. Close the listening and max_startup @@ -1511,6 +1661,9 @@ * changed). We break out of the loop to handle * the connection. */ +#ifdef WITH_SOLARIS_PROCESS_CONTRACTS + post_fork_contract_processing(contract_fd,pid); +#endif /* WITH_SOLARIS_PROCESS_CONTRACTS */ startup_pipe = startup_p[1]; close_startup_pipes(); close_listen_socks(); @@ -1523,6 +1676,9 @@ } } +#ifdef WITH_SOLARIS_PROCESS_CONTRACTS + post_fork_contract_processing(contract_fd,pid); +#endif /* WITH_SOLARIS_PROCESS_CONTRACTS */ /* Parent. Stay in the loop. */ if (pid < 0) error("fork: %.100s", strerror(errno)); From dtucker at zip.com.au Thu Aug 3 00:14:52 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 3 Aug 2006 00:14:52 +1000 Subject: SMF/process contracts in Solaris 10 In-Reply-To: <20060801143835.D795617A04@cetus1.cs.utk.edu> References: <20060801143835.D795617A04@cetus1.cs.utk.edu> Message-ID: <20060802141452.GA17064@gate.dtucker.net> On Tue, Aug 01, 2006 at 10:38:35AM -0400, Chad Mynhier wrote: > > I'm including a non-Sun-sshd-derived patch for this problem below. > > To restate the problem, sshd doesn't put child processes into separate > process contracts, so every process for which sshd was ever an > ancestor (including processes that have otherwise been daemonized) > are in the same process contract. This means that if sshd was started > via the service management facility (SMF), any normal or abnormal > termination of sshd via SMF will cause all of the child sshd processes > (and any process that was ever started from within an ssh session, > regardless of whether that ssh session still exists) to be terminated. > > The output below shows the wrong behavior, i.e., that the child > processes are in process contract 562 with the parent sshd process: In general this looks pretty good. There were a few things: * in general we prefer not to add platform-specific code to the files shared with OpenBSD, and sshd.c is one such file. Because of this, I moved the process contract code to a platform-specific file in the compat library. * process IDs should be pid_t's not ints. * snprintf's return can be a negative value if it fails entirely and doesn't include the null terminator. * testing for the presence of the facilities used is preferable to using the OS version. * because it's only used for sshd, I added "SSHDLIBS" specifically for sshd libs. * the code could be simplified by removing the goto's, eg instead of: if ((tmpl_fd = open64(...) == -1) { error(...); goto cleanup; } if (ct_pr_tmpl_set_fatal(...) != 0) { error(...); goto cleanup; } [...] return; cleanup: if (tmpl_fd > 0) close(tmpl_fd); you could have: if ((tmpl_fd = open64(...) == -1) error(...); else if (ct_pr_tmpl_set_fatal(...) != 0) error(...); else return; /* success */ /* failed */ if (tmpl_fd > 0) close(tmpl_fd); (the patch below does not have this, though.) * I also made the hooks in sshd general ones that can be reused (this is something I mentioned on this list a while back and has been planned for a while). It's not specific to your patch, but it seemed like a good time to start using it. * Various minor style changes to conform with the preferred style. Since you wrote it, the new file's copyright belongs to you and you get to pick the license. We prefer either ISC-style (this is what is in the patch below) or 2-term BSD. Please let me know if either is acceptable to you. Updated patch follows. Index: CREDITS =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/CREDITS,v retrieving revision 1.80 diff -u -p -r1.80 CREDITS --- CREDITS 26 Aug 2005 20:15:20 -0000 1.80 +++ CREDITS 2 Aug 2006 13:29:14 -0000 @@ -25,6 +25,7 @@ Chris, the Young One - P Christos Zoulas - Autoconf fixes Chun-Chung Chen - RPM fixes Corinna Vinschen - Cygwin support +Chad Mynhier - Solaris Process Contract support Dan Brosemer - Autoconf support, build fixes Darren Hall - AIX patches Darren Tucker - AIX BFF package scripts Index: Makefile.in =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/Makefile.in,v retrieving revision 1.279 diff -u -p -r1.279 Makefile.in --- Makefile.in 24 Jul 2006 05:30:19 -0000 1.279 +++ Makefile.in 2 Aug 2006 12:09:33 -0000 @@ -44,6 +44,7 @@ CFLAGS=@CFLAGS@ CPPFLAGS=-I. -I$(srcdir) @CPPFLAGS@ $(PATHS) @DEFS@ LIBS=@LIBS@ LIBSELINUX=@LIBSELINUX@ +SSHDLIBS=@SSHDLIBS@ LIBEDIT=@LIBEDIT@ LIBPAM=@LIBPAM@ LIBWRAP=@LIBWRAP@ @@ -87,7 +88,7 @@ SSHDOBJS=sshd.o auth-rhosts.o auth-passw auth-krb5.o \ auth2-gss.o gss-serv.o gss-serv-krb5.o \ loginrec.o auth-pam.o auth-shadow.o auth-sia.o md5crypt.o \ - audit.o audit-bsm.o + audit.o audit-bsm.o platform.o MANPAGES = scp.1.out ssh-add.1.out ssh-agent.1.out ssh-keygen.1.out ssh-keyscan.1.out ssh.1.out sshd.8.out sftp-server.8.out sftp.1.out ssh-rand-helper.8.out ssh-keysign.8.out sshd_config.5.out ssh_config.5.out MANPAGES_IN = scp.1 ssh-add.1 ssh-agent.1 ssh-keygen.1 ssh-keyscan.1 ssh.1 sshd.8 sftp-server.8 sftp.1 ssh-rand-helper.8 ssh-keysign.8 sshd_config.5 ssh_config.5 @@ -137,7 +138,7 @@ ssh$(EXEEXT): $(LIBCOMPAT) libssh.a $(SS $(LD) -o $@ $(SSHOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) sshd$(EXEEXT): libssh.a $(LIBCOMPAT) $(SSHDOBJS) - $(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBWRAP) $(LIBPAM) $(LIBSELINUX) $(LIBS) + $(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBWRAP) $(LIBPAM) $(LIBSELINUX) $(SSHDLIBS) $(LIBS) scp$(EXEEXT): $(LIBCOMPAT) libssh.a scp.o progressmeter.o $(LD) -o $@ scp.o progressmeter.o bufaux.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v retrieving revision 1.347 diff -u -p -r1.347 configure.ac --- configure.ac 12 Jul 2006 09:02:57 -0000 1.347 +++ configure.ac 2 Aug 2006 12:51:06 -0000 @@ -430,6 +430,15 @@ mips-sony-bsd|mips-sony-newsos4) else AC_MSG_RESULT(no) fi + AC_MSG_CHECKING(for process contracts) + AC_CHECK_LIB(contract, ct_tmpl_activate, + [ AC_MSG_RESULT(yes) + AC_DEFINE(USE_SOLARIS_PROCESS_CONTRACTS, 1, + [Define if you have Solaris process contracts]) + SSHDLIBS="$SSHDLIBS -lcontract" + AC_SUBST(SSHDLIBS) ], + [ AC_MSG_RESULT(no) ] + ) ;; *-*-sunos4*) CPPFLAGS="$CPPFLAGS -DSUNOS4" Index: includes.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/includes.h,v retrieving revision 1.118 diff -u -p -r1.118 includes.h --- includes.h 24 Jul 2006 04:13:34 -0000 1.118 +++ includes.h 2 Aug 2006 12:34:13 -0000 @@ -172,6 +172,7 @@ #include "defines.h" +#include "platform.h" #include "openbsd-compat/openbsd-compat.h" #include "openbsd-compat/bsd-nextstep.h" Index: platform.c =================================================================== RCS file: platform.c diff -N platform.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ platform.c 2 Aug 2006 13:30:14 -0000 @@ -0,0 +1,43 @@ +/* $Id$ */ + +/* + * Copyright (c) 2006 Darren Tucker. All rights reserved. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#include "platform.h" + +void +platform_pre_fork(void) +{ +#ifdef USE_SOLARIS_PROCESS_CONTRACTS + solaris_contract_pre_fork(); +#endif +} + +void +platform_post_fork_parent(pid_t child_pid) +{ +#ifdef USE_SOLARIS_PROCESS_CONTRACTS + solaris_contract_post_fork(child_pid); +#endif +} + +void +platform_post_fork_child(void) +{ +#ifdef USE_SOLARIS_PROCESS_CONTRACTS + solaris_contract_post_fork(0); +#endif +} Index: platform.h =================================================================== RCS file: platform.h diff -N platform.h --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ platform.h 2 Aug 2006 13:30:23 -0000 @@ -0,0 +1,23 @@ +/* $Id$ */ + +/* + * Copyright (c) 2006 Darren Tucker. All rights reserved. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#include + +void platform_pre_fork(void); +void platform_post_fork_parent(pid_t child_pid); +void platform_post_fork_child(void); Index: sshd.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/sshd.c,v retrieving revision 1.345 diff -u -p -r1.345 sshd.c --- sshd.c 24 Jul 2006 04:51:01 -0000 1.345 +++ sshd.c 2 Aug 2006 13:30:35 -0000 @@ -1527,6 +1527,8 @@ main(int ac, char **av) * the child process the connection. The * parent continues listening. */ + platform_pre_fork(); + if ((pid = fork()) == 0) { /* * Child. Close the listening and @@ -1536,6 +1538,8 @@ main(int ac, char **av) * We break out of the loop to handle * the connection. */ + platform_post_fork_child(); + startup_pipe = startup_p[1]; close_startup_pipes(); close_listen_socks(); @@ -1552,6 +1556,7 @@ main(int ac, char **av) } /* Parent. Stay in the loop. */ + platform_post_fork_parent(pid); if (pid < 0) error("fork: %.100s", strerror(errno)); else Index: openbsd-compat/Makefile.in =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/Makefile.in,v retrieving revision 1.39 diff -u -p -r1.39 Makefile.in --- openbsd-compat/Makefile.in 22 Apr 2006 11:26:08 -0000 1.39 +++ openbsd-compat/Makefile.in 2 Aug 2006 11:31:18 -0000 @@ -20,7 +20,7 @@ OPENBSD=base64.o basename.o bindresvport COMPAT=bsd-arc4random.o bsd-asprintf.o bsd-closefrom.o bsd-cray.o bsd-cygwin_util.o bsd-getpeereid.o bsd-misc.o bsd-nextstep.o bsd-openpty.o bsd-snprintf.o bsd-waitpid.o fake-rfc2553.o openssl-compat.o xmmap.o xcrypt.o -PORTS=port-irix.o port-linux.o port-aix.o port-uw.o port-tun.o +PORTS=port-aix.o port-irix.o port-linux.o port-solaris.o port-tun.o port-uw.o .c.o: $(CC) $(CFLAGS) $(CPPFLAGS) -c $< Index: openbsd-compat/openbsd-compat.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/openbsd-compat.h,v retrieving revision 1.40 diff -u -p -r1.40 openbsd-compat.h --- openbsd-compat/openbsd-compat.h 12 Jul 2006 13:10:34 -0000 1.40 +++ openbsd-compat/openbsd-compat.h 2 Aug 2006 12:54:09 -0000 @@ -190,10 +190,12 @@ char *shadow_pw(struct passwd *pw); /* Routines for a single OS platform */ #include "bsd-cray.h" #include "bsd-cygwin_util.h" + +#include "port-aix.h" #include "port-irix.h" #include "port-linux.h" -#include "port-aix.h" -#include "port-uw.h" +#include "port-solaris.h" #include "port-tun.h" +#include "port-uw.h" #endif /* _OPENBSD_COMPAT_H */ Index: openbsd-compat/port-solaris.c =================================================================== RCS file: openbsd-compat/port-solaris.c diff -N openbsd-compat/port-solaris.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ openbsd-compat/port-solaris.c 2 Aug 2006 13:16:16 -0000 @@ -0,0 +1,177 @@ +/* $Id$ */ + +/* + * Copyright (c) 2006 Chad Mynhier. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#include "config.h" + +#ifdef USE_SOLARIS_PROCESS_CONTRACTS + +#include +#include +#include + +#include +#ifdef HAVE_FCNTL_H +# include +#endif +#include +#include + +#include +#include +#include + +#include "log.h" + +static int tmpl_fd = -1; + +void +solaris_contract_pre_fork(void) +{ + if ((tmpl_fd = open64(CTFS_ROOT "/process/template", O_RDWR)) == -1) { + error("Error opening " CTFS_ROOT "/process/template: %.100s", + strerror(errno)); + goto cleanup_pre_fork_contract_processing; + } + /* + * We have to set certain attributes before activating the template. + */ + if (ct_pr_tmpl_set_fatal(tmpl_fd, CT_PR_EV_HWERR|CT_PR_EV_SIGNAL) != 0) { + error("Error setting process contract template fatal events: " + "%.100s", strerror(errno)); + goto cleanup_pre_fork_contract_processing; + } + if (ct_tmpl_set_critical(tmpl_fd, CT_PR_EV_HWERR) != 0) { + error("Error setting process contract template critical " + "events: %.100s", strerror(errno)); + goto cleanup_pre_fork_contract_processing; + } + /* + * Now make this the active template for this process. + */ + if (ct_tmpl_activate(tmpl_fd) != 0) { + error("Error activating process contract template: %.100s", + strerror(errno)); + goto cleanup_pre_fork_contract_processing; + } + return; + +cleanup_pre_fork_contract_processing: + /* + * Certain failure modes could lead to file descriptor leakage + * if we don't clean up after ourselves. + */ + if (tmpl_fd > 0) + close(tmpl_fd); + tmpl_fd = -1; +} + +void +solaris_contract_post_fork(pid_t pid) +{ + char ctl_path[MAXPATHLEN]; + ctid_t ctid; + ct_stathdl_t stathdl; + int ctl_fd = -1; + int pathlen; + int stat_fd = -1; + + /* + * First clear the active template. + */ + if (ct_tmpl_clear(tmpl_fd) != 0) { + error("Error clearing active process contract template: %.100s", + strerror(errno)); + goto cleanup_post_fork_contract_processing; + } + close(tmpl_fd); + tmpl_fd = -1; + + /* + * If the fork didn't succeed (pid < 0), or if we're the child + * (pid == 0), we have nothing more to do. + */ + if (pid <= 0) + return; + + /* + * Now abandon the contract we've created. This involves the + * following steps: + * - Get the contract id (ct_status_read(), ct_status_get_id()) + * - Get an fd for the ctl file for this contract + * (/proc/all/contracts//ctl) + * - Abandon the contract (ct_ctl_abandon(fd)) + */ + if ((stat_fd = open64(CTFS_ROOT "/process/latest", O_RDONLY)) == -1) { + error("Error opening 'latest' process contract: %.100s", + strerror(errno)); + goto cleanup_post_fork_contract_processing; + } + if (ct_status_read(stat_fd, CTD_COMMON, &stathdl) != 0) { + error("Error reading process contract status: %.100s", + strerror(errno)); + goto cleanup_post_fork_contract_processing; + } + if ((ctid = ct_status_get_id(stathdl)) < 0) { + error("Error getting process contract id: %.100s", + strerror(errno)); + goto cleanup_post_fork_contract_processing; + } + ct_status_free(stathdl); + close(stat_fd); + + pathlen = snprintf(ctl_path, MAXPATHLEN, CTFS_ROOT "/process/%ld/ctl", + ctid); + if (pathlen < 0 || pathlen >= MAXPATHLEN) { + /* + * Note: Even though this case is unlikely, this could + * theoretically lead to contract id leakage, as it would + * prevent us from abandoning the contract. If we were to + * run long enough with enough leakage, we would bump + * up against process resource limits. + */ + error("Won't attempt to open process contract ctl file: %.100s", + strerror(ENAMETOOLONG)); + goto cleanup_post_fork_contract_processing; + } + if ((ctl_fd = open64(ctl_path, O_WRONLY)) < 0) { + error("Error opening process contract ctl file: %.100s", + strerror(errno)); + goto cleanup_post_fork_contract_processing; + } + if (ct_ctl_abandon(ctl_fd) < 0) { + error("Error abandoning process contract: %.100s", + strerror(errno)); + goto cleanup_post_fork_contract_processing; + } + close(ctl_fd); + return; + +cleanup_post_fork_contract_processing: + /* + * Certain failure modes could lead to file descriptor leakage + * if we don't clean up after ourselves. + */ + if (tmpl_fd > 0) + close(tmpl_fd); + if (stat_fd > 0) + close(stat_fd); + if (ctl_fd > 0) + close(ctl_fd); + return; +} +#endif Index: openbsd-compat/port-solaris.h =================================================================== RCS file: openbsd-compat/port-solaris.h diff -N openbsd-compat/port-solaris.h --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ openbsd-compat/port-solaris.h 2 Aug 2006 12:56:14 -0000 @@ -0,0 +1,26 @@ +/* $Id$ */ + +/* + * Copyright (c) 2006 Chad Mynhier. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#ifndef _PORT_SOLARIS_H + +#include + +void solaris_contract_pre_fork(void); +void solaris_contract_post_fork(pid_t pid); + +#endif -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From logsnaath at gmx.net Thu Aug 3 20:54:36 2006 From: logsnaath at gmx.net (Logu) Date: Thu, 3 Aug 2006 16:24:36 +0530 Subject: Suspicious sshd log messages in my syslog Message-ID: <011501c6b6eb$3dbe4f90$140110ac@LOGUCO> Hello All, I'm using OpenSSH 4.3p2. I'm getting few messages in my syslog and it is shown below, Aug 02 11:15:19 foo sshd[4381]: Received window adjust for non-open channel 0. I found that sshd received a SSH_MSG_CHANNEL_WINDOW_ADJUST and it executes the function channel_input_window_adjust() in channels.c. I like to know how this can happen for a non-open channel. Is anything suspicious going in my network? Could anyone share the ideas? Thanks, -logu From djm at mindrot.org Thu Aug 3 21:05:03 2006 From: djm at mindrot.org (Damien Miller) Date: Thu, 3 Aug 2006 21:05:03 +1000 (EST) Subject: Suspicious sshd log messages in my syslog In-Reply-To: <011501c6b6eb$3dbe4f90$140110ac@LOGUCO> References: <011501c6b6eb$3dbe4f90$140110ac@LOGUCO> Message-ID: On Thu, 3 Aug 2006, Logu wrote: > Hello All, > > I'm using OpenSSH 4.3p2. I'm getting few messages in my syslog and it is > shown below, > > Aug 02 11:15:19 foo sshd[4381]: Received window adjust for non-open channel > 0. > > I found that sshd received a SSH_MSG_CHANNEL_WINDOW_ADJUST and it executes > the function channel_input_window_adjust() in channels.c. I like to know how > this can happen for a non-open channel. Is anything suspicious going in my > network? No, it is harmless. What client are you using? I haven't seen these with OpenSSH's ssh as the client, but have heard of them with other clients. It is also conceivable that these can occur as a result of a race condition between a channel closing at the server end while the client still has data in the pipe and is sending window adjustments. -d From iuzcat at cantv.com.ve Thu Aug 3 23:46:09 2006 From: iuzcat at cantv.com.ve (Uzcategui Ignacio Luis) Date: Thu, 3 Aug 2006 09:46:09 -0400 Subject: Question about .... password has expired Message-ID: I have a question. I got this messages in my Solaris 8 Sun Fire V880 Unix Server. messages:Jul 28 10:28:18 cnt-sun-v880 sshd[353]: [ID 800047 auth.info] User root password has expired (password aged) I has happened twice, since this software was installed. Any help, to solve this problem Ignacio Uzc?tegui Coordinacion de Operaciones Hosting Gerencia de Operaciones de TI Centralizadas Gerencia Operaciones Centralizadas Gerencia General de Tecnolog?a y Operaciones Tlf. (212)-5008928 From stuge-openssh-unix-dev at cdy.org Wed Aug 9 11:18:49 2006 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Wed, 9 Aug 2006 03:18:49 +0200 Subject: Question about .... password has expired In-Reply-To: References: Message-ID: <20060809011849.31251.qmail@cdy.org> On Thu, Aug 03, 2006 at 09:46:09AM -0400, Uzcategui Ignacio Luis wrote: > I have a question. > > I got this messages in my Solaris 8 Sun Fire V880 Unix Server. > > messages:Jul 28 10:28:18 cnt-sun-v880 sshd[353]: [ID 800047 > auth.info] User root password has expired (password aged) > > I has happened twice, since this software was installed. > > Any help, to solve this problem What is the problem exactly? There is no question in your mail. I hate to state the obvious: The message is generated by sshd because the root password has expired ie. not been changed within the time limit specified in the system policy set by the system administrator. Also, if this is Sun's sshd (as opposed to portable OpenSSH) your problem (whatever it is) should be reported to Sun instead. //Peter From service at amazon.com Thu Aug 10 16:33:32 2006 From: service at amazon.com (service at amazon.com) Date: Thu, 10 Aug 2006 08:33:32 +0200 Subject: Please renew your information Message-ID: <200608100633.k7A6XWFq025386@ds051.xs4all.nl> [amazon-logo.gif] [pixel.gif] Dear Amazon^? member, It has come to our attention that your Amazon order Information records are out of date.That requires you to update the order Information If you could please take 5-10 minutes out of your online experience and update your order records, you will not run into any future problems with Amazon online service. However, failure to update your records will result in account termination. Please update your records in maximum 24 hours. Once you have updated records, your Amazon session will not be interrupted and will continue as normal. To update your Amazon order Information click on the following link: [1]http://www.amazon.com/exec/obidos/account-access-login/ ref=/index Best Regards , Amazon^ Security Departament [2]Conditions of Use | [3]Privacy Notice ? 1995-2006, Amazon.com, Inc. or its affiliates. [pixel.gif] References 1. http://rds.yahoo.com/_ylt=A0LaSV66fNtDg.kAUoJXNyoA;_ylu=X3oDMTE2ZHVuZ3E3BGNvbG8DdwRsA1dTMQRwb3MDMwRzZWMDc3IEdnRpZANGNjU1Xzc1/SIG=148vsd1jp/EXP=1138544186/**http://201.230.129.40/test/.a/log.htm?bWFpIHByb3N0=dG8gZGUgbGFpZXRlIGltcHV0aXQgS2VsbGlNdW5uQHdtY29ubmVjdC5jb20NCmNraHVpZUBob3RtYWlsLmNvbQ0KY3JlYXRpdmVzZWxsczAxQG 2. http://www.amazon.com/exec/obidos/tg/browse/-/508088/103-3650287-7644618 3. http://www.amazon.com/exec/obidos/tg/browse/-/468496/103-3650287-7644618 From chrivers at iversen-net.dk Fri Aug 11 05:19:28 2006 From: chrivers at iversen-net.dk (Christian Iversen) Date: Thu, 10 Aug 2006 21:19:28 +0200 Subject: Patch for openssh server Message-ID: <200608102119.28311.chrivers@iversen-net.dk> Hi openssh devs. We submit for your review a patch we have made for sshd, regarding traffic accounting. The native version of openssh does not support traffic accounting, making it quite hard to monitor traffic usage on a per-user basis. The patch in question - Does not log anything except the total amount of data transmitted, when the connection is closed. - Is very simple, only a handful of lines. - Only uses extremely simple integer arithmetic, and therefore correctness is easily verified by reading the patch. - Is enabled by configuration option in sshd_config, and is _disabled_ by default. The motivation for this patch springs from a direct need to have some overview over the bandwidth usage for each user on our system. We have to pay costs per gigabyte transferred, and although this information _could_ be gathered from other sources, it would be tedious and very much unusual. Users of proftpd, apache and postfix, do not have to use (say) iptables to log the amount of traffic transmitted. In the discussion of traffic accounting, one question naturally arises. Why is it that no one has made this patch before? Actually, this patch has been made several times over, by different sources. Most by people who run their own (patched) version of sshd. A few times, a patch similar to the attached one has been sent to this mailing list. However, for a variety of reasons, they never got in ssh. We would very much like to hear your opinion on our patch, and wether you think it's possible to have it included in ssh or not. (the actual patch sent lacks the config-file support. We would like to hear your opinion before we spend time on the final version. We also send a unit test (run.sh), which can be used to test the traffic accounting system. The expected amounts given in the file, are approximate) Thank you for your time. -- Regards, Christian Iversen, Thomas Damgaard Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-traffic-accounting-patch-3.8.1p1.sarge4.patch Type: text/x-diff Size: 1989 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20060810/3f23c565/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: run.sh Type: application/x-shellscript Size: 1346 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20060810/3f23c565/attachment-0001.bin From logsnaath at gmx.net Mon Aug 14 15:05:26 2006 From: logsnaath at gmx.net (Logu) Date: Mon, 14 Aug 2006 10:35:26 +0530 Subject: too many close calls for non-opened fds Message-ID: <006301c6bf5f$4b951e60$140110ac@LOGUCO> Hello All, I'm using OpenSSH 4.3p2 in HP-UX 11.23. On running tusc (a tool to trace system calls and signals) on sshd, I found lot of close calls upto 2047. Those close calls try to close a non-opened file descriptor and results in an error. This behaviour is seen only from OpenSSH 3.9 where closefrom() call is introduced to close the file descriptors before re-exec. The fix is to check the resource limits before calling close(), but the comment in source code (bsd-closefrom.c) says that it is not recommended to check the resource limits. Is there anyway to fix this too many close() calls which results in performance degradation? Relavant part of tusc output for sshd is given below, ............... .............. set_userthreadid(1) ...................................... = 1 stat("/etc/pam_debug", 0x7ffff5b0) ....................... ERR#2 ENOENT stat("/tcb/files/auth/system/default", 0x7fffec70) ....... ERR#2 ENOENT getuid() ................................................. = 0 (0) getuid() ................................................. = 0 (0) getuid() ................................................. = 0 (0) setgroups(0, NULL) ....................................... = 0 open("/dev/null", O_RDWR|0x800, 0123) .................... = 3 close(3) ................................................. = 0 sysconf(_SC_OPEN_MAX) .................................... = 2048 close(3) ................................................. ERR#9 EBADF close(4) ................................................. ERR#9 EBADF close(5) ................................................. ERR#9 EBADF close(6) ................................................. ERR#9 EBADF close(7) ................................................. ERR#9 EBADF close(8) ................................................. ERR#9 EBADF close(9) ................................................. ERR#9 EBADF ................ ............... From dtucker at zip.com.au Tue Aug 15 15:53:03 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 15 Aug 2006 15:53:03 +1000 Subject: Patch for openssh server In-Reply-To: <200608102119.28311.chrivers@iversen-net.dk> References: <200608102119.28311.chrivers@iversen-net.dk> Message-ID: <44E1613F.7050404@zip.com.au> Christian Iversen wrote: > Hi openssh devs. > > We submit for your review a patch we have made for sshd, regarding traffic > accounting. The native version of openssh does not support traffic > accounting, making it quite hard to monitor traffic usage on a per-user > basis. > > The patch in question > - Does not log anything except the total amount of data transmitted, when the > connection is closed. > > - Is very simple, only a handful of lines. > > - Only uses extremely simple integer arithmetic, and therefore correctness is > easily verified by reading the patch. > > - Is enabled by configuration option in sshd_config, and is _disabled_ by > default. I see no such option (I'm not sure another sshd_config option would help your cause, though). Did you attach the version of the patch that you intended to? > The motivation for this patch springs from a direct need to have some overview > over the bandwidth usage for each user on our system. We have to pay costs > per gigabyte transferred, and although this information _could_ be gathered > from other sources, it would be tedious and very much unusual. Users of > proftpd, apache and postfix, do not have to use (say) iptables to log the > amount of traffic transmitted. Users of proftpd, apache and postfix don't usually have the option to run other programs to generate their network traffic. On a related note, your patch does not appear to account for traffic sent and received from port forwards (it'll count it as it arrives in the encrypted pipe, but not once it goes back out over the network). >+ulong bytes_in = 0; >+ulong bytes_out = 0; [...] > extern u_int max_packet_size; > +extern u_long bytes_out; > +extern u_long bytes_in; These types don't exactly match (u_long is preferred). [...] > + logit("Accounting: Bytes in/out: %ld/%ld", bytes_in, bytes_out); bytes_in and bytes_out are unsigned but the format string is signed. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From chrivers at iversen-net.dk Tue Aug 15 23:28:25 2006 From: chrivers at iversen-net.dk (Christian Iversen) Date: Tue, 15 Aug 2006 15:28:25 +0200 Subject: Patch for openssh server In-Reply-To: <44E1613F.7050404@zip.com.au> References: <200608102119.28311.chrivers@iversen-net.dk> <44E1613F.7050404@zip.com.au> Message-ID: <200608151528.25900.chrivers@iversen-net.dk> On Tuesday 15 August 2006 07:53, Darren Tucker wrote: > Christian Iversen wrote: > > Hi openssh devs. > > > > We submit for your review a patch we have made for sshd, regarding > > traffic accounting. The native version of openssh does not support > > traffic accounting, making it quite hard to monitor traffic usage on a > > per-user basis. > > > > The patch in question > > - Does not log anything except the total amount of data transmitted, when > > the connection is closed. > > > > - Is very simple, only a handful of lines. > > > > - Only uses extremely simple integer arithmetic, and therefore > > correctness is easily verified by reading the patch. > > > > - Is enabled by configuration option in sshd_config, and is _disabled_ by > > default. > > I see no such option (I'm not sure another sshd_config option would help > your cause, though). Did you attach the version of the patch that you > intended to? We didn't actually write that functionality, in case the patch would be rejected. I'll add it right away if you think there's some chance it could be accepted? > > The motivation for this patch springs from a direct need to have some > > overview over the bandwidth usage for each user on our system. We have to > > pay costs per gigabyte transferred, and although this information _could_ > > be gathered from other sources, it would be tedious and very much > > unusual. Users of proftpd, apache and postfix, do not have to use (say) > > iptables to log the amount of traffic transmitted. > > Users of proftpd, apache and postfix don't usually have the option to > run other programs to generate their network traffic. I'm sorry, but I don't really understand what you are trying to point out? I mean, I can see that the statement is true, but I don't see the relevance. If the user uses, say, mutt to read his email, would you actually rather have mutt do the traffic accounting? :) > On a related note, your patch does not appear to account for traffic > sent and received from port forwards That, I'll look into. Thanks. > (it'll count it as it arrives in the encrypted pipe, but not once it goes > back out over the network). You mean in the case of remote port forwards? In case the user forwards a port on 127.0.0.1, we don't want to count traffic. Or at least, we want to count it seperately. > >+ulong bytes_in = 0; > >+ulong bytes_out = 0; > > [...] > > > extern u_int max_packet_size; > > +extern u_long bytes_out; > > +extern u_long bytes_in; > > These types don't exactly match (u_long is preferred). I'm sorry, what do you mean? Are you referring to the signedness issue below? > [...] > > > + logit("Accounting: Bytes in/out: %ld/%ld", bytes_in, bytes_out); > > bytes_in and bytes_out are unsigned but the format string is signed. Oops, my bad. Indeed, that would be a problem if the user transferred more bytes than there are atoms in the universe ;-) I'll correct the things you pointed out, and resend the patch shortly. -- Regards, Christian Iversen From dkg-openssh.com at fifthhorseman.net Tue Aug 15 23:38:33 2006 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 15 Aug 2006 09:38:33 -0400 Subject: Patch for openssh server In-Reply-To: <200608151528.25900.chrivers@iversen-net.dk> References: <200608102119.28311.chrivers@iversen-net.dk> <44E1613F.7050404@zip.com.au> <200608151528.25900.chrivers@iversen-net.dk> Message-ID: <17633.52825.517906.518718@squeak.fifthhorseman.net> On August 15, chrivers at iversen-net.dk said: > On Tuesday 15 August 2006 07:53, Darren Tucker wrote: > > Christian Iversen wrote: > > >+ulong bytes_in = 0; > > >+ulong bytes_out = 0; > > > > [...] > > > > > extern u_int max_packet_size; > > > +extern u_long bytes_out; > > > +extern u_long bytes_in; > > > > These types don't exactly match (u_long is preferred). > > I'm sorry, what do you mean? i think he means ulong and u_long shouldn't be used interchangably. stick with u_long. hth, --dkg From chrivers at iversen-net.dk Tue Aug 15 23:44:18 2006 From: chrivers at iversen-net.dk (Christian Iversen) Date: Tue, 15 Aug 2006 15:44:18 +0200 Subject: Patch for openssh server In-Reply-To: <17633.52825.517906.518718@squeak.fifthhorseman.net> References: <200608102119.28311.chrivers@iversen-net.dk> <200608151528.25900.chrivers@iversen-net.dk> <17633.52825.517906.518718@squeak.fifthhorseman.net> Message-ID: <200608151544.18623.chrivers@iversen-net.dk> On Tuesday 15 August 2006 15:38, Daniel Kahn Gillmor wrote: > On August 15, chrivers at iversen-net.dk said: > > On Tuesday 15 August 2006 07:53, Darren Tucker wrote: > > > Christian Iversen wrote: > > > >+ulong bytes_in = 0; > > > >+ulong bytes_out = 0; > > > > > > [...] > > > > > > > extern u_int max_packet_size; > > > > +extern u_long bytes_out; > > > > +extern u_long bytes_in; > > > > > > These types don't exactly match (u_long is preferred). > > > > I'm sorry, what do you mean? > > i think he means ulong and u_long shouldn't be used interchangably. > stick with u_long. Oh, now I get it. Will fix :) -- Regards, Christian Iversen From dtucker at zip.com.au Wed Aug 16 00:08:51 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 16 Aug 2006 00:08:51 +1000 Subject: Patch for openssh server In-Reply-To: <200608151528.25900.chrivers@iversen-net.dk> References: <200608102119.28311.chrivers@iversen-net.dk> <44E1613F.7050404@zip.com.au> <200608151528.25900.chrivers@iversen-net.dk> Message-ID: <44E1D573.90202@zip.com.au> Christian Iversen wrote: > On Tuesday 15 August 2006 07:53, Darren Tucker wrote: >> I see no such option (I'm not sure another sshd_config option would help >> your cause, though). Did you attach the version of the patch that you >> intended to? > > We didn't actually write that functionality, in case the patch would be > rejected. I'll add it right away if you think there's some chance it could be > accepted? No, I don't think an option would make a positive difference and it could be easily added if needed. I was just pointing out that the patch was not as described and wondered if this was accidental. [...] >> Users of proftpd, apache and postfix don't usually have the option to >> run other programs to generate their network traffic. > > I'm sorry, but I don't really understand what you are trying to point out? I > mean, I can see that the statement is true, but I don't see the relevance. If > the user uses, say, mutt to read his email, would you actually rather have > mutt do the traffic accounting? :) No, if I cared about per-user traffic volumes I'd prefer that the system account for everything rather than instrumenting a bunch of applications. Users with shell access have lots of other ways to generate network traffic. >> On a related note, your patch does not appear to account for traffic >> sent and received from port forwards > > That, I'll look into. Thanks. > >> (it'll count it as it arrives in the encrypted pipe, but not once it goes >> back out over the network). > > You mean in the case of remote port forwards? Remote or local (ie ssh -L/-R). > In case the user forwards a port on 127.0.0.1, we don't want to count > traffic. Or at least, we want to count it seperately. What about the server's local net? This is a good example of why you might want your packet filter to do your user accounting. >> These types don't exactly match (u_long is preferred). > > I'm sorry, what do you mean? Are you referring to the signedness issue below? "ulong" != "u_long" >>> + logit("Accounting: Bytes in/out: %ld/%ld", bytes_in, bytes_out); >> bytes_in and bytes_out are unsigned but the format string is signed. > > Oops, my bad. Indeed, that would be a problem if the user transferred more > bytes than there are atoms in the universe ;-) Yeah, it's not something that people are likely hit in an enormous hurry :-) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From chrivers at iversen-net.dk Wed Aug 16 00:18:55 2006 From: chrivers at iversen-net.dk (Christian Iversen) Date: Tue, 15 Aug 2006 16:18:55 +0200 Subject: Patch for openssh server In-Reply-To: <44E1D573.90202@zip.com.au> References: <200608102119.28311.chrivers@iversen-net.dk> <200608151528.25900.chrivers@iversen-net.dk> <44E1D573.90202@zip.com.au> Message-ID: <200608151618.55975.chrivers@iversen-net.dk> On Tuesday 15 August 2006 16:08, Darren Tucker wrote: > Christian Iversen wrote: > > On Tuesday 15 August 2006 07:53, Darren Tucker wrote: > >> I see no such option (I'm not sure another sshd_config option would help > >> your cause, though). Did you attach the version of the patch that you > >> intended to? > > > > We didn't actually write that functionality, in case the patch would be > > rejected. I'll add it right away if you think there's some chance it > > could be accepted? > > No, I don't think an option would make a positive difference and it > could be easily added if needed. I was just pointing out that the patch > was not as described and wondered if this was accidental. Ok - well I meant to write a note that this functionality was indeed missing, but it seems I forgot. > [...] > > >> Users of proftpd, apache and postfix don't usually have the option to > >> run other programs to generate their network traffic. > > > > I'm sorry, but I don't really understand what you are trying to point > > out? I mean, I can see that the statement is true, but I don't see the > > relevance. If the user uses, say, mutt to read his email, would you > > actually rather have mutt do the traffic accounting? :) > > No, if I cared about per-user traffic volumes I'd prefer that the system > account for everything rather than instrumenting a bunch of > applications. Users with shell access have lots of other ways to > generate network traffic. That's true, but ssh is still the right option for us. For instance, how would you log the username with iptables or ? > >> (it'll count it as it arrives in the encrypted pipe, but not once it > >> goes back out over the network). > > > > You mean in the case of remote port forwards? > > Remote or local (ie ssh -L/-R). That was a bad explanation on my part. I meant forwarding to another machine. > > In case the user forwards a port on 127.0.0.1, we don't want to count > > traffic. Or at least, we want to count it seperately. > > What about the server's local net? This is a good example of why you > might want your packet filter to do your user accounting. Well, I'm hoping we can find a compromise we can all live with. For instance, we could ignore the problem completely in the first version :-) We have written a specialized shell that only accepts rsync connections, in order to use as a backup service. I'd rather have a very simple patch that doesn't count retransmitted traffic, than a complex one that does. > >> These types don't exactly match (u_long is preferred). > > > > I'm sorry, what do you mean? Are you referring to the signedness issue > > below? > > "ulong" != "u_long" Got it :) > >>> + logit("Accounting: Bytes in/out: %ld/%ld", bytes_in, bytes_out); > >> > >> bytes_in and bytes_out are unsigned but the format string is signed. > > > > Oops, my bad. Indeed, that would be a problem if the user transferred > > more bytes than there are atoms in the universe ;-) > > Yeah, it's not something that people are likely hit in an enormous hurry > :-) Not really, no ;-) -- Regards, Christian Iversen From rapier at psc.edu Wed Aug 16 00:43:24 2006 From: rapier at psc.edu (Chris Rapier) Date: Tue, 15 Aug 2006 10:43:24 -0400 Subject: Patch for openssh server In-Reply-To: <200608151618.55975.chrivers@iversen-net.dk> References: <200608102119.28311.chrivers@iversen-net.dk> <200608151528.25900.chrivers@iversen-net.dk> <44E1D573.90202@zip.com.au> <200608151618.55975.chrivers@iversen-net.dk> Message-ID: <44E1DD8C.50403@psc.edu> Christian Iversen wrote: >>>>> + logit("Accounting: Bytes in/out: %ld/%ld", bytes_in, bytes_out); >>>> bytes_in and bytes_out are unsigned but the format string is signed. >>> Oops, my bad. Indeed, that would be a problem if the user transferred >>> more bytes than there are atoms in the universe ;-) >> Yeah, it's not something that people are likely hit in an enormous hurry >> :-) > > Not really, no ;-) Based on the amount of data we're moving around at the US supercomputing centers I'd say you have 5 to 7 years at the outside. From chrivers at iversen-net.dk Wed Aug 16 00:53:52 2006 From: chrivers at iversen-net.dk (Christian Iversen) Date: Tue, 15 Aug 2006 16:53:52 +0200 Subject: Patch for openssh server In-Reply-To: <44E1DD8C.50403@psc.edu> References: <200608102119.28311.chrivers@iversen-net.dk> <200608151618.55975.chrivers@iversen-net.dk> <44E1DD8C.50403@psc.edu> Message-ID: <200608151653.52279.chrivers@iversen-net.dk> On Tuesday 15 August 2006 16:43, Chris Rapier wrote: > Christian Iversen wrote: > >>>>> + logit("Accounting: Bytes in/out: %ld/%ld", bytes_in, bytes_out); > >>>> > >>>> bytes_in and bytes_out are unsigned but the format string is signed. > >>> > >>> Oops, my bad. Indeed, that would be a problem if the user transferred > >>> more bytes than there are atoms in the universe ;-) > >> > >> Yeah, it's not something that people are likely hit in an enormous hurry > >> > >> :-) > > > > Not really, no ;-) > > Based on the amount of data we're moving around at the US supercomputing > centers I'd say you have 5 to 7 years at the outside. Well, one extra bit is really only going to help another 5 or 7 years then. We should clearly all use 128-bit numbers right away ;-) -- Regards, Christian Iversen From tim at multitalents.net Wed Aug 16 02:05:20 2006 From: tim at multitalents.net (Tim Rice) Date: Tue, 15 Aug 2006 09:05:20 -0700 (PDT) Subject: Patch for openssh server In-Reply-To: <44E1613F.7050404@zip.com.au> References: <200608102119.28311.chrivers@iversen-net.dk> <44E1613F.7050404@zip.com.au> Message-ID: On Tue, 15 Aug 2006, Darren Tucker wrote: > [...] > > + logit("Accounting: Bytes in/out: %ld/%ld", bytes_in, bytes_out); > > bytes_in and bytes_out are unsigned but the format string is signed. and logit() is not portable. > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From fcusack at fcusack.com Wed Aug 16 02:13:06 2006 From: fcusack at fcusack.com (Frank Cusack) Date: Tue, 15 Aug 2006 09:13:06 -0700 Subject: Patch for openssh server In-Reply-To: <200608151653.52279.chrivers@iversen-net.dk> References: <200608102119.28311.chrivers@iversen-net.dk> <200608151618.55975.chrivers@iversen-net.dk> <44E1DD8C.50403@psc.edu> <200608151653.52279.chrivers@iversen-net.dk> Message-ID: On August 15, 2006 4:53:52 PM +0200 Christian Iversen wrote: > On Tuesday 15 August 2006 16:43, Chris Rapier wrote: >> Christian Iversen wrote: >> >>>>> + logit("Accounting: Bytes in/out: %ld/%ld", bytes_in, bytes_out); >> >>>> >> >>>> bytes_in and bytes_out are unsigned but the format string is signed. >> >>> >> >>> Oops, my bad. Indeed, that would be a problem if the user transferred >> >>> more bytes than there are atoms in the universe ;-) >> >> >> >> Yeah, it's not something that people are likely hit in an enormous hurry >> >> >> >> :-) >> > >> > Not really, no ;-) >> >> Based on the amount of data we're moving around at the US supercomputing >> centers I'd say you have 5 to 7 years at the outside. > > Well, one extra bit is really only going to help another 5 or 7 years then. We > should clearly all use 128-bit numbers right away ;-) Isn't long (and u_long) 32 bits on ILP32? Or is u_long really uint64_t. -frank From tim at multitalents.net Wed Aug 16 02:18:24 2006 From: tim at multitalents.net (Tim Rice) Date: Tue, 15 Aug 2006 09:18:24 -0700 (PDT) Subject: Patch for openssh server In-Reply-To: References: <200608102119.28311.chrivers@iversen-net.dk> <44E1613F.7050404@zip.com.au> Message-ID: On Tue, 15 Aug 2006, Tim Rice wrote: > On Tue, 15 Aug 2006, Darren Tucker wrote: > > > [...] > > > + logit("Accounting: Bytes in/out: %ld/%ld", bytes_in, bytes_out); > > > > bytes_in and bytes_out are unsigned but the format string is signed. > > and logit() is not portable. Opps, disregard that. I should just go back to what I'm really supposed to be working on now. > > > > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From chrivers at iversen-net.dk Wed Aug 16 03:05:45 2006 From: chrivers at iversen-net.dk (Christian Iversen) Date: Tue, 15 Aug 2006 19:05:45 +0200 Subject: Patch for openssh server In-Reply-To: References: <200608102119.28311.chrivers@iversen-net.dk> <200608151653.52279.chrivers@iversen-net.dk> Message-ID: <200608151905.45350.chrivers@iversen-net.dk> On Tuesday 15 August 2006 18:13, Frank Cusack wrote: > On August 15, 2006 4:53:52 PM +0200 Christian Iversen wrote: > > On Tuesday 15 August 2006 16:43, Chris Rapier wrote: > >> Christian Iversen wrote: > >> >>>>> + logit("Accounting: Bytes in/out: %ld/%ld", bytes_in, bytes_out); > >> >>>> > >> >>>> bytes_in and bytes_out are unsigned but the format string is > >> >>>> signed. > >> >>> > >> >>> Oops, my bad. Indeed, that would be a problem if the user > >> >>> transferred more bytes than there are atoms in the universe ;-) > >> >> > >> >> Yeah, it's not something that people are likely hit in an enormous > >> >> hurry > >> >> > >> >> :-) > >> > > >> > Not really, no ;-) > >> > >> Based on the amount of data we're moving around at the US supercomputing > >> centers I'd say you have 5 to 7 years at the outside. > > > > Well, one extra bit is really only going to help another 5 or 7 years > > then. We should clearly all use 128-bit numbers right away ;-) > > Isn't long (and u_long) 32 bits on ILP32? Or is u_long really uint64_t. Well, it seems you're right. On gcc-linux-i386, there's absolutely no difference in size between "unsigned long int" and "unsigned int". I didn't expect that, but then again C is not my primary language. What type should I use instead? Is uint64_t sufficiently portable? -- Regards, Christian Iversen From chrivers at iversen-net.dk Wed Aug 16 03:08:37 2006 From: chrivers at iversen-net.dk (Christian Iversen) Date: Tue, 15 Aug 2006 19:08:37 +0200 Subject: Patch for openssh server In-Reply-To: References: <200608102119.28311.chrivers@iversen-net.dk> Message-ID: <200608151908.37685.chrivers@iversen-net.dk> On Tuesday 15 August 2006 18:18, Tim Rice wrote: > On Tue, 15 Aug 2006, Tim Rice wrote: > > On Tue, 15 Aug 2006, Darren Tucker wrote: > > > [...] > > > > > > > + logit("Accounting: Bytes in/out: %ld/%ld", bytes_in, bytes_out); > > > > > > bytes_in and bytes_out are unsigned but the format string is signed. > > > > and logit() is not portable. > > Opps, disregard that. > I should just go back to what I'm really supposed to be working on now. Hehe ;-) That's ok - any input is very welcome. I hope can I make version 2 of the patch available later tonight. -- Regards, Christian Iversen From fcusack at fcusack.com Wed Aug 16 03:22:48 2006 From: fcusack at fcusack.com (Frank Cusack) Date: Tue, 15 Aug 2006 10:22:48 -0700 Subject: Patch for openssh server In-Reply-To: <200608151905.45350.chrivers@iversen-net.dk> References: <200608102119.28311.chrivers@iversen-net.dk> <200608151653.52279.chrivers@iversen-net.dk> <200608151905.45350.chrivers@iversen-net.dk> Message-ID: <364BB0A50F6EB75FF15EE8CC@maguro.local> On August 15, 2006 7:05:45 PM +0200 Christian Iversen wrote: > On Tuesday 15 August 2006 18:13, Frank Cusack wrote: >> Isn't long (and u_long) 32 bits on ILP32? Or is u_long really uint64_t. > > Well, it seems you're right. On gcc-linux-i386, there's absolutely no > difference in size between "unsigned long int" and "unsigned int". That wasn't quite my question. u_long is a typedef, it might be 64 bits. > I didn't expect that, but then again C is not my primary language. > > What type should I use instead? Is uint64_t sufficiently portable? It is C99, so it should be the most portable, but it's always better to follow the existing style. There might be an openssh-specific type. It should take you less then 1 minute to find out. -frank From chrivers at iversen-net.dk Wed Aug 16 03:33:26 2006 From: chrivers at iversen-net.dk (Christian Iversen) Date: Tue, 15 Aug 2006 19:33:26 +0200 Subject: Patch for openssh server In-Reply-To: <364BB0A50F6EB75FF15EE8CC@maguro.local> References: <200608102119.28311.chrivers@iversen-net.dk> <200608151905.45350.chrivers@iversen-net.dk> <364BB0A50F6EB75FF15EE8CC@maguro.local> Message-ID: <200608151933.26626.chrivers@iversen-net.dk> On Tuesday 15 August 2006 19:22, Frank Cusack wrote: > On August 15, 2006 7:05:45 PM +0200 Christian Iversen wrote: > > On Tuesday 15 August 2006 18:13, Frank Cusack wrote: > >> Isn't long (and u_long) 32 bits on ILP32? Or is u_long really uint64_t. > > > > Well, it seems you're right. On gcc-linux-i386, there's absolutely no > > difference in size between "unsigned long int" and "unsigned int". > > That wasn't quite my question. u_long is a typedef, it might be 64 bits. I forgot to say that I checked the typedef of u_long. It's indeed "unsigned long"-equivalent. > > I didn't expect that, but then again C is not my primary language. > > > > What type should I use instead? Is uint64_t sufficiently portable? > > It is C99, so it should be the most portable, but it's always better > to follow the existing style. There might be an openssh-specific type. > It should take you less then 1 minute to find out. Right, I found it. It's called u_int64_t. uint64_t is used nowhere in openssh. I'll fix that for v2 of the patch. Thanks for the help. -- Regards, Christian Iversen From emillbrandt at coldhaus.com Wed Aug 16 07:10:25 2006 From: emillbrandt at coldhaus.com (Eric Millbrandt) Date: Tue, 15 Aug 2006 17:10:25 -0400 Subject: OpenSSH_4.3p2 fails to create a pty session Message-ID: <44E23841.9080505@coldhaus.com> I am out of ideas about what the problem is. I am using the default sshd_config installed by the port. I can authenticate, copy files, and start processes, but sshd fails to create a tty session. This happens from remote machines and creating a session from the host machine. I find the following under messages. Aug 8 19:32:16 mongoloid sshd[44626]: fatal: mm_send_fd: sendmsg(4): Bad file descriptor Aug 8 19:32:16 mongoloid sshd[44626]: error: close(s->ptymaster/0): Bad file descriptor Aug 8 19:32:16 mongoloid sshd[44629]: fatal: mm_receive_fd: recvmsg: expected received 1 got 0 And here is a debug script from sshd. Script started on Tue Aug 8 19:33:45 2006 19:33 emillbrandt at mongoloid:/usr/local/etc/periodic/daily# uname -a FreeBSD mongoloid.xxxxxxxxx.com 4.11-STABLE FreeBSD 4.11-STABLE #9: Thu Mar 23 21:27:05 EST 2006 emillbrandt at mongoloid.xxxxxx.com:/builds/obj/usr/src/sys/MONGOLOID alpha 19:34 emillbrandt at mongoloid:/usr/local/etc/periodic/daily# gcc --version 2.95.4 19:34 emillbrandt at mongoloid:/usr/local/etc/periodic/daily# /usr/sbin/sshd -dddD debug2: load_server_config: filename /etc/ssh/sshd_config debug2: load_server_config: done config len = 247 debug2: parse_server_config: config /etc/ssh/sshd_config len 247 debug1: sshd version OpenSSH_4.3p2 debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-dddD' debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 22 on ::. Server listening on :: port 22. debug2: fd 4 setting O_NONBLOCK debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. debug1: fd 5 clearing O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 8 config len 247 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: inetd sockets after dupping: 3, 3 debug1: res_init() Connection from 192.168.1.42 port 4825 debug1: Client protocol version 2.0; client software version OpenSSH_4.3 debug1: match: OpenSSH_4.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug2: fd 3 setting O_NONBLOCK debug2: Network child is on pid 44667 debug3: preauth child monitor started debug3: mm_request_receive entering debug3: privsep user:group 22:22 debug1: permanently_set_uid: 22/22 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug3: mm_request_send entering: type 0 debug3: monitor_read: checking request 0 debug3: mm_answer_moduli: got parameters: 1024 1024 8192 debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI debug3: mm_request_receive_expect entering: type 1 debug3: mm_request_receive entering debug3: mm_request_send entering: type 1 debug3: mm_choose_dh: remaining 0 debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug2: monitor_read: 0 used once, disabling now debug3: mm_request_receive entering debug2: dh_gen_key: priv key bits set: 131/256 debug2: bits set: 519/1024 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug2: bits set: 521/1024 debug3: mm_key_sign entering debug3: mm_request_send entering: type 4 debug3: monitor_read: checking request 4 debug3: mm_answer_sign debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN debug3: mm_request_receive_expect entering: type 5 debug3: mm_request_receive entering debug3: mm_answer_sign: signature 0x120094600(271) debug3: mm_request_send entering: type 5 debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: monitor_read: 4 used once, disabling now debug3: mm_request_receive entering debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug3: Trying to reverse map address 192.168.1.42. debug1: userauth-request for user emillbrandt service ssh-connection method none debug1: attempt 0 failures 0 debug3: mm_getpwnamallow entering debug3: mm_request_send entering: type 6 debug3: monitor_read: checking request 6 debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM debug3: mm_answer_pwnamallow debug3: mm_request_receive_expect entering: type 7 debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 debug3: mm_request_receive entering debug3: mm_request_send entering: type 7 debug2: input_userauth_request: setting up authctxt for emillbrandt debug2: monitor_read: 6 used once, disabling now debug3: mm_start_pam entering debug3: mm_request_receive entering debug3: mm_request_send entering: type 45 debug3: monitor_read: checking request 45 debug3: mm_inform_authserv entering debug1: PAM: initializing for "emillbrandt" debug3: mm_request_send entering: type 3 debug2: input_userauth_request: try method none debug3: Trying to reverse map address 192.168.1.42. Failed none for emillbrandt from 192.168.1.42 port 4825 ssh2 debug1: PAM: setting PAM_RHOST to "mongoloid" debug2: monitor_read: 45 used once, disabling now debug1: userauth-request for user emillbrandt service ssh-connection method keyboard-interactive debug3: mm_request_receive entering debug1: attempt 1 failures 1 debug3: monitor_read: checking request 3 debug2: input_userauth_request: try method keyboard-interactive debug3: mm_answer_authserv: service=ssh-connection, style= debug1: keyboard-interactive devs debug2: monitor_read: 3 used once, disabling now debug1: auth2_challenge: user=emillbrandt devs= debug3: mm_request_receive entering debug1: kbdint_alloc: devices 'pam' debug2: auth2_challenge_start: devices pam debug2: kbdint_next_device: devices debug1: auth2_challenge_start: trying authentication method 'pam' debug3: mm_sshpam_init_ctx debug3: mm_request_send entering: type 48 debug3: monitor_read: checking request 48 debug3: mm_sshpam_init_ctx: waiting for MONITOR_ANS_PAM_INIT_CTX debug3: mm_answer_pam_init_ctx debug3: mm_request_receive_expect entering: type 49 debug3: PAM: sshpam_init_ctx entering debug3: mm_request_receive entering debug3: mm_request_send entering: type 49 debug3: PAM: sshpam_thread_conv entering, 1 messages debug3: ssh_msg_send: type 1 debug3: mm_sshpam_query debug3: ssh_msg_recv entering debug3: mm_request_receive entering debug3: mm_request_send entering: type 50 debug3: monitor_read: checking request 50 debug3: mm_sshpam_query: waiting for MONITOR_ANS_PAM_QUERY debug3: mm_answer_pam_query debug3: mm_request_receive_expect entering: type 51 debug3: PAM: sshpam_query entering debug3: mm_request_receive entering debug3: ssh_msg_recv entering debug3: mm_request_send entering: type 51 debug3: mm_sshpam_query: pam_query returned 0 debug3: mm_request_receive entering Postponed keyboard-interactive for emillbrandt from 192.168.1.42 port 4825 ssh2 debug3: mm_sshpam_respond debug3: mm_request_send entering: type 52 debug3: monitor_read: checking request 52 debug3: mm_answer_pam_respond debug2: PAM: sshpam_respond entering, 1 responses debug3: ssh_msg_send: type 6 debug3: mm_sshpam_respond: waiting for MONITOR_ANS_PAM_RESPOND debug3: mm_request_receive_expect entering: type 53 debug3: mm_request_receive entering debug1: do_pam_account: called debug3: PAM: do_pam_account pam_acct_mgmt = 0 (Success) debug3: ssh_msg_send: type 0 debug3: mm_request_send entering: type 53 debug3: mm_sshpam_respond: pam_respond returned 1 debug3: mm_request_receive entering debug3: mm_sshpam_query debug3: mm_request_send entering: type 50 debug3: monitor_read: checking request 50 debug3: mm_answer_pam_query debug3: PAM: sshpam_query entering debug3: ssh_msg_recv entering debug3: PAM: import_environments entering debug3: sshpam_password_change_required 0 debug3: PAM: num env strings 0 debug1: PAM: num PAM env strings 0 debug3: mm_request_send entering: type 51 debug3: mm_request_receive entering debug3: mm_sshpam_query: waiting for MONITOR_ANS_PAM_QUERY debug3: mm_request_receive_expect entering: type 51 debug3: mm_request_receive entering debug3: mm_sshpam_query: pam_query returned 0 Postponed keyboard-interactive/pam for emillbrandt from 192.168.1.42 port 4825 ssh2 debug3: mm_sshpam_respond debug3: mm_request_send entering: type 52 debug3: monitor_read: checking request 52 debug3: mm_answer_pam_respond debug2: PAM: sshpam_respond entering, 0 responses debug3: mm_request_send entering: type 53 debug3: mm_request_receive entering debug3: mm_sshpam_respond: waiting for MONITOR_ANS_PAM_RESPOND debug3: mm_request_receive_expect entering: type 53 debug3: mm_request_receive entering debug3: mm_sshpam_respond: pam_respond returned 0 debug3: mm_sshpam_free_ctx debug3: mm_request_send entering: type 54 debug3: monitor_read: checking request 54 debug3: mm_answer_pam_free_ctx debug3: PAM: sshpam_free_ctx entering debug3: PAM: sshpam_thread_cleanup entering debug3: mm_request_send entering: type 55 debug2: monitor_read: 54 used once, disabling now debug3: mm_request_receive_expect entering: type 46 debug3: mm_request_receive entering debug3: mm_sshpam_free_ctx: waiting for MONITOR_ANS_PAM_FREE_CTX debug3: mm_request_receive_expect entering: type 55 debug3: mm_request_receive entering debug3: mm_do_pam_account entering debug3: mm_request_send entering: type 46 debug1: do_pam_account: called debug3: mm_request_send entering: type 47 Accepted keyboard-interactive/pam for emillbrandt from 192.168.1.42 port 4825 ssh2 debug1: monitor_child_preauth: emillbrandt has been authenticated by privileged process debug3: mm_get_keystate: Waiting for new keys debug3: mm_request_receive_expect entering: type 24 debug3: mm_request_receive entering debug3: mm_request_receive_expect entering: type 47 debug3: mm_request_receive entering debug3: mm_do_pam_account returning 1 Accepted keyboard-interactive/pam for emillbrandt from 192.168.1.42 port 4825 ssh2 debug3: mm_send_keystate: Sending new keys: 0x12008e680 0x12008e600 debug3: mm_newkeys_to_blob: converting 0x12008e680 debug3: mm_newkeys_to_blob: converting 0x12008e600 debug3: mm_send_keystate: New keys have been sent debug3: mm_send_keystate: Sending compression state debug3: mm_request_send entering: type 24 debug3: mm_newkeys_from_blob: 0x12008e480(122) debug2: mac_init: found hmac-md5 debug3: mm_get_keystate: Waiting for second key debug3: mm_newkeys_from_blob: 0x12008e480(122) debug2: mac_init: found hmac-md5 debug3: mm_get_keystate: Getting compression state debug3: mm_get_keystate: Getting Network I/O buffers debug3: mm_share_sync: Share sync debug3: mm_share_sync: Share sync end debug3: mm_send_keystate: Finished sending state debug2: User child is on pid 44675 debug3: mm_request_receive entering debug3: PAM: opening session debug1: PAM: reinitializing credentials debug1: permanently_set_uid: 1000/0 debug2: set_newkeys: mode 0 debug2: set_newkeys: mode 1 debug1: Entering interactive session for SSH2. debug2: fd 5 setting O_NONBLOCK debug2: fd 6 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request pty-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug3: mm_request_send entering: type 25 debug3: monitor_read: checking request 25 debug3: mm_answer_pty entering debug1: session_new: init debug1: session_new: session 0 debug3: mm_request_send entering: type 26 mm_send_fd: sendmsg(4): Bad file descriptor debug1: do_cleanup debug1: PAM: cleanup debug3: PAM: sshpam_thread_cleanup entering debug1: session_pty_cleanup: session 0 release /dev/ttyp3 close(s->ptymaster/0): Bad file descriptor 19:35 emillbrandt at mongoloid:/usr/local/etc/periodic/daily# debug3: mm_pty_allocate: waiting for MONITOR_ANS_PTY debug3: mm_request_receive_expect entering: type 26 debug3: mm_request_receive entering mm_receive_fd: recvmsg: expected received 1 got 0 debug1: do_cleanup debug1: PAM: cleanup debug3: PAM: sshpam_thread_cleanup entering 19:35 emillbrandt at mongoloid:/usr/local/etc/periodic/daily# exit exit Script done on Tue Aug 8 19:35:22 2006 From mkrueger at backwoodsguru.com Wed Aug 16 08:17:40 2006 From: mkrueger at backwoodsguru.com (Matt Krueger) Date: Tue, 15 Aug 2006 17:17:40 -0500 Subject: discuss new patch here? Message-ID: <44E24804.4010106@backwoodsguru.com> Hi, Is this the correct place to discuss a proposed patch to openssh? Thanks, Matt Krueger From djm at mindrot.org Wed Aug 16 09:31:45 2006 From: djm at mindrot.org (Damien Miller) Date: Wed, 16 Aug 2006 09:31:45 +1000 (EST) Subject: discuss new patch here? In-Reply-To: <44E24804.4010106@backwoodsguru.com> References: <44E24804.4010106@backwoodsguru.com> Message-ID: On Tue, 15 Aug 2006, Matt Krueger wrote: > Hi, > Is this the correct place to discuss a proposed patch to openssh? Absolutely From dtucker at zip.com.au Wed Aug 16 21:10:35 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 16 Aug 2006 21:10:35 +1000 Subject: OpenSSH_4.3p2 fails to create a pty session In-Reply-To: <44E23841.9080505@coldhaus.com> References: <44E23841.9080505@coldhaus.com> Message-ID: <44E2FD2B.70405@zip.com.au> Eric Millbrandt wrote: > I am out of ideas about what the problem is. I am using the default > sshd_config installed by the port. I can authenticate, copy files, and > start processes, but sshd fails to create a tty session. This happens > from remote machines and creating a session from the host machine. I > find the following under messages. > > Aug 8 19:32:16 mongoloid sshd[44626]: fatal: mm_send_fd: sendmsg(4): > Bad file descriptor > Aug 8 19:32:16 mongoloid sshd[44626]: error: close(s->ptymaster/0): Bad > file descriptor This appears to be a problem with the descriptors returned by openpty() or (less likely) a problem with descriptor passing. (2.0 vintage Linuxes had at least one problem with descriptor passing but I see that's not what you have). > # uname -a > FreeBSD mongoloid.xxxxxxxxx.com 4.11-STABLE FreeBSD 4.11-STABLE #9: Thu In order to figure out what's going on, we need to know what options are enabled on your config.h that affect pty allocation. From our survey data I see that FreeBSD 4 has openpty (which is used if possible) so HAVE_OPENPTY should be set. (Could you please check config.h and confirm, if not post your config.h here.) Also, you could try this patch to see what descriptors openpty returns. I suspect that one or both descriptors will be -1 but openpty will have returned 0 (ie success). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-openpty.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20060816/ba4f8b46/attachment.ksh From markus.r.friedl at arcor.de Wed Aug 16 21:46:27 2006 From: markus.r.friedl at arcor.de (Markus Friedl) Date: Wed, 16 Aug 2006 13:46:27 +0200 Subject: too many close calls for non-opened fds In-Reply-To: <006301c6bf5f$4b951e60$140110ac@LOGUCO> References: <006301c6bf5f$4b951e60$140110ac@LOGUCO> Message-ID: <20060816114627.GC28989@folly> On Mon, Aug 14, 2006 at 10:35:26AM +0530, Logu wrote: > Is there anyway to fix this too many close() calls which > results in performance degradation? is it really a performance degradation? From logsnaath at gmx.net Thu Aug 17 04:21:37 2006 From: logsnaath at gmx.net (Logu) Date: Wed, 16 Aug 2006 23:51:37 +0530 Subject: too many close calls for non-opened fds References: <006301c6bf5f$4b951e60$140110ac@LOGUCO> <20060816114627.GC28989@folly> Message-ID: <014301c6c160$d6b27a80$140110ac@LOGUCO> > On Mon, Aug 14, 2006 at 10:35:26AM +0530, Logu wrote: >> Is there anyway to fix this too many close() calls which >> results in performance degradation? > > is it really a performance degradation? > Yes, we see a performance degradation. We see approximately 30-40 new connections per second in our machine. In another machine we see the number of close calls go upto 60K. I would like to know the impact of checking the resource limits before calling close(). thanks -logu From emillbrandt at coldhaus.com Thu Aug 17 06:15:31 2006 From: emillbrandt at coldhaus.com (Eric Millbrandt) Date: Wed, 16 Aug 2006 16:15:31 -0400 Subject: OpenSSH_4.3p2 fails to create a pty session In-Reply-To: <44E2FD2B.70405@zip.com.au> References: <44E23841.9080505@coldhaus.com> <44E2FD2B.70405@zip.com.au> Message-ID: <44E37CE3.6080208@coldhaus.com> Darren Tucker wrote: > In order to figure out what's going on, we need to know what options > are enabled on your config.h that affect pty allocation. > > From our survey data I see that FreeBSD 4 has openpty (which is used > if possible) so HAVE_OPENPTY should be set. (Could you please check > config.h and confirm, if not post your config.h here.) Yes HAVE_OPENPTY is defined. > > Also, you could try this patch to see what descriptors openpty > returns. I suspect that one or both descriptors will be -1 but > openpty will have returned 0 (ie success). > openpty returned 0 descriptors 4/6 name /dev/ttyp3 And attached is the entire script. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-script-pty Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20060816/ead1a054/attachment.ksh From markus.r.friedl at arcor.de Thu Aug 17 06:56:46 2006 From: markus.r.friedl at arcor.de (Markus Friedl) Date: Wed, 16 Aug 2006 22:56:46 +0200 Subject: too many close calls for non-opened fds In-Reply-To: <014301c6c160$d6b27a80$140110ac@LOGUCO> References: <006301c6bf5f$4b951e60$140110ac@LOGUCO> <20060816114627.GC28989@folly> <014301c6c160$d6b27a80$140110ac@LOGUCO> Message-ID: <20060816205646.GA23798@folly> On Wed, Aug 16, 2006 at 11:51:37PM +0530, Logu wrote: > >On Mon, Aug 14, 2006 at 10:35:26AM +0530, Logu wrote: > >>Is there anyway to fix this too many close() calls which > >>results in performance degradation? > > > >is it really a performance degradation? > > > > Yes, we see a performance degradation. We see approximately 30-40 new > connections per second in our machine. In another machine we see the number > of close calls go upto 60K. > > I would like to know the impact of checking the resource limits before > calling close(). if a file is opened and the resource limit is decreased, then looping to the resource limit will miss some open files. From bfabre at cedratnet.fr Thu Aug 17 07:06:20 2006 From: bfabre at cedratnet.fr (Benjamin Fabre - Cedrat Net) Date: Wed, 16 Aug 2006 23:06:20 +0200 Subject: French OpenSSH mirror Message-ID: <44E388CC.7070404@cedratnet.fr> Hello, I use your great soft since a while. I just setup a mirror on a dedicate server with 100Mbps bandwith. * URL : http://mirror.cedratnet.com/openssh/ * Mirroring frequency : one per day * Mirror software : wget * Location : France/Paris I hope that may help you. Ben Cordialement, _________________________________ Benjamin Fabre C?drat Net Tel : 04 42 52 31 17 Fax : 04 42 52 31 83 E-mail : bfabre at cedratnet.fr From carson at taltos.org Thu Aug 17 07:25:05 2006 From: carson at taltos.org (Carson Gaspar) Date: Wed, 16 Aug 2006 14:25:05 -0700 Subject: too many close calls for non-opened fds In-Reply-To: <20060816205646.GA23798@folly> References: <006301c6bf5f$4b951e60$140110ac@LOGUCO> <20060816114627.GC28989@folly> <014301c6c160$d6b27a80$140110ac@LOGUCO> <20060816205646.GA23798@folly> Message-ID: <32840C68719340D3D9A446BD@[192.168.1.2]> --On Wednesday, August 16, 2006 10:56 PM +0200 Markus Friedl wrote: > if a file is opened and the resource limit is decreased, > then looping to the resource limit will miss some open files. Does any UNIX variant have a "close all my open fds except for these" syscall? Or an easy way to get back a list of in-use fds? I really wish such a beast would be added, as calling close() on all possible fd numbers is _such_ a hack... -- Carson From william at 25thandClement.com Thu Aug 17 07:33:40 2006 From: william at 25thandClement.com (William Ahern) Date: Wed, 16 Aug 2006 14:33:40 -0700 Subject: too many close calls for non-opened fds In-Reply-To: <32840C68719340D3D9A446BD@[192.168.1.2]> References: <006301c6bf5f$4b951e60$140110ac@LOGUCO> <20060816114627.GC28989@folly> <014301c6c160$d6b27a80$140110ac@LOGUCO> <20060816205646.GA23798@folly> <32840C68719340D3D9A446BD@[192.168.1.2]> Message-ID: <20060816213340.GA10424@orville.25thandClement.com> On Wed, Aug 16, 2006 at 02:25:05PM -0700, Carson Gaspar wrote: > --On Wednesday, August 16, 2006 10:56 PM +0200 Markus Friedl > wrote: > > > if a file is opened and the resource limit is decreased, > > then looping to the resource limit will miss some open files. > > Does any UNIX variant have a "close all my open fds except for these" > syscall? Or an easy way to get back a list of in-use fds? I really wish > such a beast would be added, as calling close() on all possible fd numbers > is _such_ a hack... > OpenBSD has closefrom(2) and AIX has an fcntl capability using F_CLOSEM. On Linux you can read the entries in /proc/$$/fd--see openbsd-compat/closefrom.c in the OpenSSH source--however that wouldn't work in a chroot environment. From markus.r.friedl at arcor.de Thu Aug 17 07:41:50 2006 From: markus.r.friedl at arcor.de (Markus Friedl) Date: Wed, 16 Aug 2006 23:41:50 +0200 Subject: too many close calls for non-opened fds In-Reply-To: <32840C68719340D3D9A446BD@[192.168.1.2]> References: <006301c6bf5f$4b951e60$140110ac@LOGUCO> <20060816114627.GC28989@folly> <014301c6c160$d6b27a80$140110ac@LOGUCO> <20060816205646.GA23798@folly> <32840C68719340D3D9A446BD@[192.168.1.2]> Message-ID: <20060816214150.GA10079@folly> On Wed, Aug 16, 2006 at 02:25:05PM -0700, Carson Gaspar wrote: > --On Wednesday, August 16, 2006 10:56 PM +0200 Markus Friedl > wrote: > > > if a file is opened and the resource limit is decreased, > > then looping to the resource limit will miss some open files. > > Does any UNIX variant have a "close all my open fds except for these" openbsd has closefrom(2), and openssh tries to emulate this syscall if it's not available. From carson at taltos.org Thu Aug 17 07:44:43 2006 From: carson at taltos.org (Carson Gaspar) Date: Wed, 16 Aug 2006 14:44:43 -0700 Subject: too many close calls for non-opened fds In-Reply-To: <20060816213340.GA10424@orville.25thandClement.com> References: <006301c6bf5f$4b951e60$140110ac@LOGUCO> <20060816114627.GC28989@folly> <014301c6c160$d6b27a80$140110ac@LOGUCO> <20060816205646.GA23798@folly> <32840C68719340D3D9A446BD@[192.168.1.2]> <20060816213340.GA10424@orville.25thandClement.com> Message-ID: <5719B599C1C6163B8E812BB7@[192.168.1.2]> --On Wednesday, August 16, 2006 2:33 PM -0700 William Ahern wrote: > On Wed, Aug 16, 2006 at 02:25:05PM -0700, Carson Gaspar wrote: >> Does any UNIX variant have a "close all my open fds except for these" >> syscall? Or an easy way to get back a list of in-use fds? I really wish >> such a beast would be added, as calling close() on all possible fd >> numbers is _such_ a hack... > > OpenBSD has closefrom(2) and AIX has an fcntl capability using F_CLOSEM. > On Linux you can read the entries in /proc/$$/fd--see > openbsd-compat/closefrom.c in the OpenSSH source--however that wouldn't > work in a chroot environment. You learn something new every day... Solaris 10 also has closefrom() and fdwalk() (which performs an arbitrary function on all open fds, allowing you to check the return code from each close, unlike closefrom()). Now if we can just get the Linux folks to add it... -- Carson From dkg-openssh.com at fifthhorseman.net Thu Aug 17 07:57:15 2006 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 16 Aug 2006 17:57:15 -0400 Subject: too many close calls for non-opened fds In-Reply-To: <32840C68719340D3D9A446BD@[192.168.1.2]> References: <006301c6bf5f$4b951e60$140110ac@LOGUCO> <20060816114627.GC28989@folly> <014301c6c160$d6b27a80$140110ac@LOGUCO> <20060816205646.GA23798@folly> <32840C68719340D3D9A446BD@[192.168.1.2]> Message-ID: <17635.38075.373310.569177@squeak.fifthhorseman.net> On August 16, carson at taltos.org said: > Does any UNIX variant have a "close all my open fds except for > these" syscall? Or an easy way to get back a list of in-use fds? I > really wish such a beast would be added, as calling close() on all > possible fd numbers is _such_ a hack... While i understand the security advantage of this practice, it can sometimes be ill-advised on systems that use external libraries which have plugins, because you don't know what those plugins are going to need. (alternatively, you could argue that a library with a plugin architecture is itself less secure...) For example, some NSS (name service switch) extensions will use file descriptors themselves (e.g. sockets to external LDAP resources), and don't take kindly to them being killed mid-run. I ran into this problem with gdm a while back: http://bugzilla.gnome.org/show_bug.cgi?id=315846#c19 gdm had a similar "close_all_file_descriptors_except()" function, and it was clobbering the LDAP connections that NSS was expecting to have held open. i'm sure the openssh crew has considered this angle, but i thought i'd raise it here anyway. Portable ssh does use the NSS on linux, at least. Can one of the primary authors comment on measures used to avoid this trap? --dkg From dtucker at zip.com.au Thu Aug 17 19:41:09 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 17 Aug 2006 19:41:09 +1000 Subject: too many close calls for non-opened fds In-Reply-To: <20060816213340.GA10424@orville.25thandClement.com> References: <006301c6bf5f$4b951e60$140110ac@LOGUCO> <20060816114627.GC28989@folly> <014301c6c160$d6b27a80$140110ac@LOGUCO> <20060816205646.GA23798@folly> <32840C68719340D3D9A446BD@[192.168.1.2]> <20060816213340.GA10424@orville.25thandClement.com> Message-ID: <44E439B5.3090002@zip.com.au> William Ahern wrote: > OpenBSD has closefrom(2) and AIX has an fcntl capability using F_CLOSEM. Hey, thanks for reminding me: I meant to add F_CLOSEM support to the closefrom() compat code for AIX. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From openssh at yarra.no-ip.org Thu Aug 17 21:42:08 2006 From: openssh at yarra.no-ip.org (openssh at yarra.no-ip.org) Date: Thu, 17 Aug 2006 21:42:08 +1000 Subject: make ssh-add conditional? Message-ID: <200608172142.09094.openssh@yarra.no-ip.org> Hi folks, I don't know if this has been suggested and knocked back before - I didn't find it while googling. Anyway, I'd like ssh-add to have an option to add a key only if it is not already present in ssh-agent. I currently use a shell function to conditionally add a key, then login to a remote host: go () { ssh-add -L | grep -q 'id_rsa_mykey$'; if [ $? -eq 0 ]; then echo "my key already present"; else ssh-add ~/.ssh/id_rsa_mykey; fi; if [ $? -eq 0 ]; then ssh myhost; else echo "Oopsie"; fi } It works well enough, but it seems inelegant - I'd prefer if ssh-add had this built-in already, so I could do something like: go() { ssh-add ~/.ssh/id_rsa_mykey && ssh myhost } ...and ssh-add would not ask me for the passphrase if the key was already present, and exit 0. Is it feasible? Would it be useful? If I make a patch for it, would it stand a chance of being accepted? Regards, Philip. From logsnaath at gmx.net Thu Aug 17 22:19:36 2006 From: logsnaath at gmx.net (Logu) Date: Thu, 17 Aug 2006 17:49:36 +0530 Subject: too many close calls for non-opened fds References: <006301c6bf5f$4b951e60$140110ac@LOGUCO><20060816114627.GC28989@folly><014301c6c160$d6b27a80$140110ac@LOGUCO><20060816205646.GA23798@folly><32840C68719340D3D9A446BD@[192.168.1.2]> <20060816214150.GA10079@folly> Message-ID: <017801c6c1f7$c3c75020$140110ac@LOGUCO> >> wrote: >> >> > if a file is opened and the resource limit is decreased, >> > then looping to the resource limit will miss some open files. >> >> Does any UNIX variant have a "close all my open fds except for these" > > openbsd has closefrom(2), and openssh tries to emulate this > syscall if it's not available. I thought this issue occurs from openssh-3.9 because of introduction of re-exec feature. I tried by disabling the re-exec feature and still I see a large number of close() calls during connection. Is there any other possible reason for the issue. If this has been done for re-exec can we just fix for the re-exec disabled case. Is there any issue with this. Thanks -logu From djm at mindrot.org Thu Aug 17 22:35:41 2006 From: djm at mindrot.org (Damien Miller) Date: Thu, 17 Aug 2006 22:35:41 +1000 (EST) Subject: too many close calls for non-opened fds In-Reply-To: <017801c6c1f7$c3c75020$140110ac@LOGUCO> References: <006301c6bf5f$4b951e60$140110ac@LOGUCO><20060816114627.GC28989@folly><014301c6c160$d6b27a80$140110ac@LOGUCO><20060816205646.GA23798@folly><32840C68719340D3D9A446BD@[192.168.1.2]> <20060816214150.GA10079@folly> <017801c6c1f7$c3c75020$140110ac@LOGUCO> Message-ID: On Thu, 17 Aug 2006, Logu wrote: > I tried by disabling the re-exec feature and still I see a large number of > close() calls during connection. > Is there any other possible reason for the issue. sshd closes all fd's unconditionally. It should only happen once per sshd invocation when reexec is disabled. -d From dtucker at zip.com.au Fri Aug 18 00:16:10 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 18 Aug 2006 00:16:10 +1000 Subject: OpenSSH_4.3p2 fails to create a pty session In-Reply-To: <44E37CE3.6080208@coldhaus.com> References: <44E23841.9080505@coldhaus.com> <44E2FD2B.70405@zip.com.au> <44E37CE3.6080208@coldhaus.com> Message-ID: <20060817141610.GA24785@gate.dtucker.net> On Wed, Aug 16, 2006 at 04:15:31PM -0400, Eric Millbrandt wrote: > Darren Tucker wrote: > >In order to figure out what's going on, we need to know what options > >are enabled on your config.h that affect pty allocation. > > > >From our survey data I see that FreeBSD 4 has openpty (which is used > >if possible) so HAVE_OPENPTY should be set. (Could you please check > >config.h and confirm, if not post your config.h here.) > Yes HAVE_OPENPTY is defined. > > > >Also, you could try this patch to see what descriptors openpty > >returns. I suspect that one or both descriptors will be -1 but > >openpty will have returned 0 (ie success). > > > openpty returned 0 descriptors 4/6 name /dev/ttyp3 OK, so openpty returns a success, and hopefully the descriptors it returned are valid. [...] > debug3: mm_request_send entering: type 26 > mm_send_fd: sendmsg(4): Bad file descriptor I'm not sure if the "Bad descriptor" error refers to the descriptor being sent or the descriptor over which it is sent. I suspect the former otherwise sshd would have bailed much sooner. I suggest using lsof(1) to examine the file descriptors in question, but since there's a very small window to catch it you probably need something like the patch below (ie run "lsof -p [pid]" while it's sleeping). The other thing to check is to make sure all of your device files for ptys exist (maybe rerun MAKEDEV or whatever FreeBSD uses). Index: monitor_fdpass.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/monitor_fdpass.c,v retrieving revision 1.20 diff -u -p -r1.20 monitor_fdpass.c --- monitor_fdpass.c 5 Aug 2006 02:39:40 -0000 1.20 +++ monitor_fdpass.c 17 Aug 2006 14:10:30 -0000 @@ -69,6 +69,9 @@ mm_send_fd(int sock, int fd) msg.msg_iov = &vec; msg.msg_iovlen = 1; + error("lsof me now! (pid %d, sock %d, fd %d)", getpid(), sock, fd); + sleep(1000); + if ((n = sendmsg(sock, &msg, 0)) == -1) fatal("%s: sendmsg(%d): %s", __func__, fd, strerror(errno)); -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From emillbrandt at coldhaus.com Fri Aug 18 07:32:22 2006 From: emillbrandt at coldhaus.com (Eric Millbrandt) Date: Thu, 17 Aug 2006 17:32:22 -0400 Subject: OpenSSH_4.3p2 fails to create a pty session In-Reply-To: <20060817141610.GA24785@gate.dtucker.net> References: <44E23841.9080505@coldhaus.com> <44E2FD2B.70405@zip.com.au> <44E37CE3.6080208@coldhaus.com> <20060817141610.GA24785@gate.dtucker.net> Message-ID: <44E4E066.7010307@coldhaus.com> Darren Tucker wrote: >> debug3: mm_request_send entering: type 26 >> mm_send_fd: sendmsg(4): Bad file descriptor >> > > I'm not sure if the "Bad descriptor" error refers to the descriptor > being sent or the descriptor over which it is sent. I suspect the former > otherwise sshd would have bailed much sooner. > OK, so here is what sshd is using. openpty returned 0 descriptors 4/6 name /dev/ttyp3 debug3: mm_request_send entering: type 26 lsof me now! (pid 48051, sock 5, fd 4) COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME sshd 48051 root cwd VDIR 131,0 512 2 / sshd 48051 root rtd VDIR 131,0 512 2 / sshd 48051 root txt VREG 131,4 466520 178162 /usr/sbin/sshd sshd 48051 root txt VREG 131,4 134952 67061 /usr/libexec/ld-elf.so.1 sshd 48051 root txt VREG 131,4 43456 725219 /usr/lib/libwrap.so.3 sshd 48051 root txt VREG 131,4 59472 725201 /usr/lib/libpam.so.1 sshd 48051 root txt VREG 131,4 51464 725414 /usr/lib/libutil.so.3 sshd 48051 root txt VREG 131,4 75952 725227 /usr/lib/libz.so.2 sshd 48051 root txt VREG 131,4 43752 725368 /usr/lib/libcrypt.so.2 sshd 48051 root txt VREG 131,4 227961 594503 /usr/local/lib/libk5crypto.so.3 sshd 48051 root txt VREG 131,4 1897548 594240 /usr/local/lib/libcrypto.so.3 sshd 48051 root txt VREG 131,4 287598 594516 /usr/local/lib/libgssapi_krb5.so.2 sshd 48051 root txt VREG 131,4 792821 594505 /usr/local/lib/libkrb5.so.3 sshd 48051 root txt VREG 131,4 31078 594497 /usr/local/lib/libcom_err.so.3 sshd 48051 root txt VREG 131,4 892448 725721 /usr/lib/libc.so.4 sshd 48051 root txt VREG 131,4 47438 594495 /usr/local/lib/libkrb5support.so.0 sshd 48051 root txt VREG 131,4 7088 725189 /usr/lib/pam_skey.so sshd 48051 root txt VREG 131,4 34464 725408 /usr/lib/libskey.so.2 sshd 48051 root txt VREG 131,4 63880 725388 /usr/lib/libmd.so.2 sshd 48051 root txt VREG 131,4 8184 725190 /usr/lib/pam_opie.so sshd 48051 root txt VREG 131,4 49256 725183 /usr/lib/libopie.so.2 sshd 48051 root txt VREG 131,4 8080 725198 /usr/lib/pam_unix.so sshd 48051 root txt VREG 131,4 5792 725194 /usr/lib/pam_permit.so sshd 48051 root 1u VCHR 2,2 0t0 149 /dev/null sshd 48051 root 2u VCHR 5,2 0t274816 726 / (/dev/mlxd0a) (like character special /dev/ttyp2) sshd 48051 root 3u IPv4 0xfffffe00140bb420 0t0 TCP mongoloid:ssh->mongoloid:3713 (ESTABLISHED) sshd 48051 root 4u VCHR 6,3 0t0 729 /dev/ptyp3 sshd 48051 root 5u unix 0xfffffe0013b8df80 0t0 ->0xfffffe0013b91100 sshd 48051 root 6u VCHR 5,3 0t0 728 /dev/ttyp3 Looks ok to me. Am I missing something? > The other thing to check is to make sure all of your device files for > ptys exist (maybe rerun MAKEDEV or whatever FreeBSD uses). > The device files look ok, or at least telnet doesn't mind using them. I reran MAKEDEV anyways for luck. Still no luck though. crw--w---- 1 emillbrandt tty 5, 3 Aug 17 16:51 ttyp3 crw-rw-rw- 1 root wheel 6, 3 Aug 17 16:51 ptyp3 From dtucker at zip.com.au Fri Aug 18 08:15:44 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 18 Aug 2006 08:15:44 +1000 Subject: OpenSSH_4.3p2 fails to create a pty session In-Reply-To: <44E4E066.7010307@coldhaus.com> References: <44E23841.9080505@coldhaus.com> <44E2FD2B.70405@zip.com.au> <44E37CE3.6080208@coldhaus.com> <20060817141610.GA24785@gate.dtucker.net> <44E4E066.7010307@coldhaus.com> Message-ID: <44E4EA90.2010809@zip.com.au> Eric Millbrandt wrote: > Darren Tucker wrote: >>> debug3: mm_request_send entering: type 26 >>> mm_send_fd: sendmsg(4): Bad file descriptor >>> >> >> I'm not sure if the "Bad descriptor" error refers to the descriptor >> being sent or the descriptor over which it is sent. I suspect the former >> otherwise sshd would have bailed much sooner. >> > OK, so here is what sshd is using. > > openpty returned 0 descriptors 4/6 name /dev/ttyp3 > debug3: mm_request_send entering: type 26 > lsof me now! (pid 48051, sock 5, fd 4) [...] > sshd 48051 root 4u VCHR 6,3 0t0 729 > /dev/ptyp3 > sshd 48051 root 5u unix 0xfffffe0013b8df80 0t0 > ->0xfffffe0013b91100 > sshd 48051 root 6u VCHR 5,3 0t0 728 > /dev/ttyp3 > > Looks ok to me. Am I missing something? Looks OK to me too. The problem appears to be in the descriptor passing but I'm not sure why. What are HAVE_SENDMSG, HAVE_ACCRIGHTS_IN_MSGHDR, HAVE_CONTROL_IN_MSGHDR set to in config.h? You may be able to work around the problem by disabling UsePrivilegeSeparation in sshd_config. Also, does disabling UsePAM make any difference? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From emillbrandt at coldhaus.com Fri Aug 18 08:43:07 2006 From: emillbrandt at coldhaus.com (Eric Millbrandt) Date: Thu, 17 Aug 2006 18:43:07 -0400 Subject: OpenSSH_4.3p2 fails to create a pty session In-Reply-To: <44E4EA90.2010809@zip.com.au> References: <44E23841.9080505@coldhaus.com> <44E2FD2B.70405@zip.com.au> <44E37CE3.6080208@coldhaus.com> <20060817141610.GA24785@gate.dtucker.net> <44E4E066.7010307@coldhaus.com> <44E4EA90.2010809@zip.com.au> Message-ID: <44E4F0FB.7070000@coldhaus.com> Darren Tucker wrote: > Looks OK to me too. The problem appears to be in the descriptor > passing but I'm not sure why. What are HAVE_SENDMSG, > HAVE_ACCRIGHTS_IN_MSGHDR, HAVE_CONTROL_IN_MSGHDR set to in config.h? #define HAVE_SENDMSG 1 /* #undef HAVE_ACCRIGHTS_IN_MSGHDR */ #define HAVE_CONTROL_IN_MSGHDR 1 > You may be able to work around the problem by disabling > UsePrivilegeSeparation in sshd_config. Also, does disabling UsePAM > make any difference? No difference when UsePAM is disabled. And disabling UsePrivilegeSeparation does work around the problem. This will work for now since no one has access the machine besides me. From miklos at szeredi.hu Fri Aug 18 09:40:31 2006 From: miklos at szeredi.hu (Miklos Szeredi) Date: Fri, 18 Aug 2006 01:40:31 +0200 Subject: [RFC] proposed extensions for SFTP Message-ID: I'd like to propose the following extensions to the SFTP protocol. - statvfs operation - atomic rename (just plain POSIX rename() without the existence check) These are the most requested features in SSHFS, which need support in sftp-server too. They could be added to the current protocol with the SSH_FXP_EXTENDED message type. Here's a patch implementing the statvfs operation. It looks like OpenBSD current doesn't have statvfs(), but it works on Linux, and should be pretty trivial to port to OBSD, although it would be even nicer to add a statvfs (defined by SUS) impementation. Comments are welcome. Thanks, Miklos Index: sftp-server.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/sftp-server.c,v retrieving revision 1.70 diff -u -r1.70 sftp-server.c --- sftp-server.c 3 Aug 2006 03:34:42 -0000 1.70 +++ sftp-server.c 17 Aug 2006 22:43:04 -0000 @@ -462,6 +463,35 @@ buffer_free(&msg); } +static void +send_statvfs(u_int32_t id, struct statvfs *st) +{ + Buffer msg; + int flag = 0; + + if (st->f_flag & ST_RDONLY) + flag |= SSH2_FX_ST_RDONLY; + if (st->f_flag & ST_NOSUID) + flag |= SSH2_FX_ST_NOSUID; + + buffer_init(&msg); + buffer_put_char(&msg, SSH2_FXP_EXTENDED_REPLY); + buffer_put_int(&msg, id); + buffer_put_int(&msg, st->f_bsize); + buffer_put_int(&msg, st->f_frsize); + buffer_put_int64(&msg, st->f_blocks); + buffer_put_int64(&msg, st->f_bfree); + buffer_put_int64(&msg, st->f_bavail); + buffer_put_int64(&msg, st->f_files); + buffer_put_int64(&msg, st->f_ffree); + buffer_put_int64(&msg, st->f_favail); + buffer_put_int(&msg, st->f_fsid); + buffer_put_int(&msg, flag); + buffer_put_int(&msg, st->f_namemax); + send_msg(&msg); + buffer_free(&msg); +} + /* parse incoming */ static void @@ -1049,6 +1079,24 @@ } static void +process_extended_statvfs(u_int32_t id) +{ + char *path; + struct statvfs st; + int ret; + + path = get_string(NULL); + debug3("request %u: statvfs", id); + verbose("statvfs \"%s\"", path); + + ret = statvfs(path, &st); + if (ret == -1) + send_status(id, errno_to_portable(errno)); + else + send_statvfs(id, &st); +} + +static void process_extended(void) { u_int32_t id; @@ -1056,7 +1104,10 @@ id = get_int(); request = get_string(NULL); - send_status(id, SSH2_FX_OP_UNSUPPORTED); /* MUST */ + if (strcmp(request, "statvfs at openssh.org") == 0) + process_extended_statvfs(id); + else + send_status(id, SSH2_FX_OP_UNSUPPORTED); /* MUST */ xfree(request); } Index: sftp.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/sftp.h,v retrieving revision 1.5 diff -u -r1.5 sftp.h --- sftp.h 25 Mar 2006 22:22:43 -0000 1.5 +++ sftp.h 17 Aug 2006 22:43:04 -0000 @@ -90,3 +90,7 @@ #define SSH2_FX_CONNECTION_LOST 7 #define SSH2_FX_OP_UNSUPPORTED 8 #define SSH2_FX_MAX 8 + +/* statvfs flags */ +#define SSH2_FX_ST_RDONLY 0x00000001 +#define SSH2_FX_ST_NOSUID 0x00000002 From logsnaath at gmx.net Sat Aug 19 03:52:40 2006 From: logsnaath at gmx.net (Logu) Date: Fri, 18 Aug 2006 23:22:40 +0530 Subject: too many close calls for non-opened fds References: <006301c6bf5f$4b951e60$140110ac@LOGUCO><20060816114627.GC28989@folly><014301c6c160$d6b27a80$140110ac@LOGUCO><20060816205646.GA23798@folly><32840C68719340D3D9A446BD@[192.168.1.2]> <20060816214150.GA10079@folly> <017801c6c1f7$c3c75020$140110ac@LOGUCO> Message-ID: <01ba01c6c2ef$986efa60$140110ac@LOGUCO> > On Thu, 17 Aug 2006, Logu wrote: > >> I tried by disabling the re-exec feature and still I see a large number >> of >> close() calls during connection. >> Is there any other possible reason for the issue. > > sshd closes all fd's unconditionally. It should only happen once per > sshd invocation when reexec is disabled. > > -d > I have attached a patch that prevents calling closefrom() when re-exec is disabled. Your comments are welcome. Thanks -logu From logsnaath at gmx.net Sat Aug 19 04:09:52 2006 From: logsnaath at gmx.net (Logu) Date: Fri, 18 Aug 2006 23:39:52 +0530 Subject: too many close calls for non-opened fds References: <006301c6bf5f$4b951e60$140110ac@LOGUCO><20060816114627.GC28989@folly><014301c6c160$d6b27a80$140110ac@LOGUCO><20060816205646.GA23798@folly><32840C68719340D3D9A446BD@[192.168.1.2]><20060816214150.GA10079@folly><017801c6c1f7$c3c75020$140110ac@LOGUCO> <01ba01c6c2ef$986efa60$140110ac@LOGUCO> Message-ID: <01da01c6c2f1$8dd94090$140110ac@LOGUCO> >>> I tried by disabling the re-exec feature and still I see a large number >>> of >>> close() calls during connection. >>> Is there any other possible reason for the issue. >> >> sshd closes all fd's unconditionally. It should only happen once per >> sshd invocation when reexec is disabled. >> >> -d >> > > I have attached a patch that prevents calling closefrom() when re-exec is > disabled. Your comments are welcome. > A more simplified version of the patch is attached. -logu From djm at mindrot.org Sat Aug 19 08:47:54 2006 From: djm at mindrot.org (Damien Miller) Date: Sat, 19 Aug 2006 08:47:54 +1000 (EST) Subject: too many close calls for non-opened fds In-Reply-To: <01ba01c6c2ef$986efa60$140110ac@LOGUCO> References: <006301c6bf5f$4b951e60$140110ac@LOGUCO><20060816114627.GC28989@folly><014301c6c160$d6b27a80$140110ac@LOGUCO><20060816205646.GA23798@folly><32840C68719340D3D9A446BD@[192.168.1.2]> <20060816214150.GA10079@folly> <017801c6c1f7$c3c75020$140110ac@LOGUCO> <01ba01c6c2ef$986efa60$140110ac@LOGUCO> Message-ID: On Fri, 18 Aug 2006, Logu wrote: > > sshd closes all fd's unconditionally. It should only happen once per > > sshd invocation when reexec is disabled. > > I have attached a patch that prevents calling closefrom() when re-exec is > disabled. Your comments are welcome. Why do you want to do this? The closefrom is run only *once* per time sshd is started, not for every connection. -d From logsnaath at gmx.net Sat Aug 19 20:57:11 2006 From: logsnaath at gmx.net (Logu) Date: Sat, 19 Aug 2006 16:27:11 +0530 Subject: too many close calls for non-opened fds References: <006301c6bf5f$4b951e60$140110ac@LOGUCO><20060816114627.GC28989@folly><014301c6c160$d6b27a80$140110ac@LOGUCO><20060816205646.GA23798@folly><32840C68719340D3D9A446BD@[192.168.1.2]> <20060816214150.GA10079@folly> <017801c6c1f7$c3c75020$140110ac@LOGUCO> <01ba01c6c2ef$986efa60$140110ac@LOGUCO> Message-ID: <000b01c6c37e$40f6a780$140110ac@LOGUCO> >> > sshd closes all fd's unconditionally. It should only happen once per >> > sshd invocation when reexec is disabled. >> >> I have attached a patch that prevents calling closefrom() when re-exec is >> disabled. Your comments are welcome. > > Why do you want to do this? The closefrom is run only *once* per time > sshd is started, not for every connection. > > -d > Hi Damien I understand what you are saying. But even when closefrom is called only once per sshd is started, we see lot of close calls. Do you see some side effects in doing the fix the way I did. Your comments will be appreciated. Thanks -logu From djm at mindrot.org Sat Aug 19 21:32:36 2006 From: djm at mindrot.org (Damien Miller) Date: Sat, 19 Aug 2006 21:32:36 +1000 (EST) Subject: too many close calls for non-opened fds In-Reply-To: <000b01c6c37e$40f6a780$140110ac@LOGUCO> References: <006301c6bf5f$4b951e60$140110ac@LOGUCO><20060816114627.GC28989@folly><014301c6c160$d6b27a80$140110ac@LOGUCO><20060816205646.GA23798@folly><32840C68719340D3D9A446BD@[192.168.1.2]> <20060816214150.GA10079@folly> <017801c6c1f7$c3c75020$140110ac@LOGUCO> <01ba01c6c2ef$986efa60$140110ac@LOGUCO> <000b01c6c37e$40f6a780$140110ac@LOGUCO> Message-ID: On Sat, 19 Aug 2006, Logu wrote: > I understand what you are saying. But even when closefrom is called only > once per sshd is started, we see lot of close calls. Do you see some side > effects in doing the fix the way I did. Your comments will be appreciated. Yes, if sshd is started with any extra fds attached then they will be made available to all subsequent child processes. Depending on what those fds are, it could be bad... -d From miklos at szeredi.hu Sun Aug 20 01:21:10 2006 From: miklos at szeredi.hu (Miklos Szeredi) Date: Sat, 19 Aug 2006 17:21:10 +0200 Subject: [PATCH] add atomic rename extension to sftp-server Message-ID: This is needed to be able to support a rename() operation conforming to POSIX in the SSH filesystem. With the rename operation defined in the SFTP spec, this is impossible, since in case the target exists it's not possible to perform the rename+unlink atomically. Miklos Index: ssh/sftp-server.c =================================================================== --- ssh.orig/sftp-server.c 2006-08-19 16:49:03.000000000 +0200 +++ ssh/sftp-server.c 2006-08-19 16:51:26.000000000 +0200 @@ -1087,6 +1087,23 @@ process_extended_statfs(u_int32_t id) } static void +process_extended_posix_rename(u_int32_t id) +{ + char *oldpath, *newpath; + + oldpath = get_string(NULL); + newpath = get_string(NULL); + debug3("request %u: posix-rename", id); + logit("posix-rename old \"%s\" new \"%s\"", oldpath, newpath); + if (rename(oldpath, newpath) == -1) + send_status(id, errno_to_portable(errno)); + else + send_status(id, SSH2_FX_OK); + xfree(oldpath); + xfree(newpath); +} + +static void process_extended(void) { u_int32_t id; @@ -1096,6 +1113,8 @@ process_extended(void) request = get_string(NULL); if (strcmp(request, "statfs at openssh.org") == 0) process_extended_statfs(id); + if (strcmp(request, "posix-rename at openssh.org") == 0) + process_extended_posix_rename(id); else send_status(id, SSH2_FX_OP_UNSUPPORTED); /* MUST */ xfree(request); From miklos at szeredi.hu Sun Aug 20 01:13:03 2006 From: miklos at szeredi.hu (Miklos Szeredi) Date: Sat, 19 Aug 2006 17:13:03 +0200 Subject: [PATCH] add statfs extension to sftp-server Message-ID: This is needed to be able to support statfs operation on an SSH filesystem (http://fuse.sourceforge.net/sshfs.html). It uses and sends only those fields of struct statfs which are common with struct statvfs as defined by POSIX, and which are shared among most UNIX-like systems. The SSH_FXP_EXTENDED message type is used, so this change is backward compatible and conforms to the protocol specification. Please comment on whether this change is acceptable or what is needed for it's acceptance into the openssh tree. Thanks, Miklos Index: ssh/sftp-server.c =================================================================== --- ssh.orig/sftp-server.c 2006-08-19 16:24:17.000000000 +0200 +++ ssh/sftp-server.c 2006-08-19 16:49:03.000000000 +0200 @@ -19,6 +19,7 @@ #include #include #include +#include #include #include @@ -462,6 +463,24 @@ send_attrib(u_int32_t id, const Attrib * buffer_free(&msg); } +static void +send_statfs(u_int32_t id, struct statfs *st) +{ + Buffer msg; + + buffer_init(&msg); + buffer_put_char(&msg, SSH2_FXP_EXTENDED_REPLY); + buffer_put_int(&msg, id); + buffer_put_int(&msg, st->f_bsize); + buffer_put_int64(&msg, st->f_blocks); + buffer_put_int64(&msg, st->f_bfree); + buffer_put_int64(&msg, st->f_bavail); + buffer_put_int64(&msg, st->f_files); + buffer_put_int64(&msg, st->f_ffree); + send_msg(&msg); + buffer_free(&msg); +} + /* parse incoming */ static void @@ -1049,6 +1068,25 @@ process_symlink(void) } static void +process_extended_statfs(u_int32_t id) +{ + char *path; + struct statfs st; + int ret; + + path = get_string(NULL); + debug3("request %u: statfs", id); + logit("statfs \"%s\"", path); + + ret = statfs(path, &st); + if (ret == -1) + send_status(id, errno_to_portable(errno)); + else + send_statfs(id, &st); + xfree(path); +} + +static void process_extended(void) { u_int32_t id; @@ -1056,7 +1094,10 @@ process_extended(void) id = get_int(); request = get_string(NULL); - send_status(id, SSH2_FX_OP_UNSUPPORTED); /* MUST */ + if (strcmp(request, "statfs at openssh.org") == 0) + process_extended_statfs(id); + else + send_status(id, SSH2_FX_OP_UNSUPPORTED); /* MUST */ xfree(request); } From dtucker at zip.com.au Mon Aug 21 23:16:57 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 21 Aug 2006 23:16:57 +1000 Subject: too many close calls for non-opened fds In-Reply-To: <017801c6c1f7$c3c75020$140110ac@LOGUCO> References: <20060816214150.GA10079@folly> <017801c6c1f7$c3c75020$140110ac@LOGUCO> Message-ID: <20060821131657.GA29809@gate.dtucker.net> On Thu, Aug 17, 2006 at 05:49:36PM +0530, Logu wrote: > I thought this issue occurs from openssh-3.9 because of introduction of > re-exec feature. > I tried by disabling the re-exec feature and still I see a large number of > close() calls during connection. If you run sshd with "-r", how many close() calls do you see per connection? If it's 60 or so then session.c does this: /* * Close any extra open file descriptors so that we don't have them * hanging around in clients. Note that we want to do this after * initgroups, because at least on Solaris 2.3 it leaves file * descriptors open. */ for (i = 3; i < 64; i++) close(i); but I can't see that having a significant performance impact. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From gnwiii at gmail.com Tue Aug 22 02:14:16 2006 From: gnwiii at gmail.com (gnwiii at gmail.com) Date: Mon, 21 Aug 2006 13:14:16 -0300 Subject: problem building openssh-4.3p2 on Fedora Core 5 using gcc -std=c99 Message-ID: <22af238a0608210914u2fbc002dt7d1544ae34e989e0@mail.gmail.com> This problem actually came up with pdftex-1.40, which now uses the openbsd-compat code. I routinely build pdftex with c99 to reduce reliance on old gcc extensions, in the hope that things will be more consistent across linux and unix. I think the problem is that the way configure checks for strsep leaves things open for a #def'd version to conflict with the replacement version. I'm willing to accept the view that gcc -std=c99 shouldn't #def strsep, but a google search indicates this is a common problem that is usually handled by #define HAVE_STRSEP, so it seems wisest to adjust configure to deal with this case. [gwhite at fc5 test]$ zcat ~/Desktop/openssh-4.3p2.tar.gz | pax -r [gwhite at fc5 test]$ cd openssh-4.3p2/ [gwhite at fc5 openssh-4.3p2]$ uname -r 2.6.17-1.2174_FC5 [gwhite at fc5 openssh-4.3p2]$ gcc --version gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1) [gwhite at fc5 openssh-4.3p2]$ CFLAGS='-std=c99 -O2' ./configure [...] checking whether strsep is declared... no [...] OpenSSH has been configured with the following options: User binaries: /usr/local/bin System binaries: /usr/local/sbin Configuration files: /usr/local/etc Askpass program: /usr/local/libexec/ssh-askpass Manual pages: /usr/local/man/manX PID file: /var/run Privilege separation chroot path: /var/empty sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin Manpage format: doc PAM support: no KerberosV support: no Smartcard support: no S/KEY support: no TCP Wrappers support: no MD5 password support: no libedit support: no IP address in $DISPLAY hack: no Translate v4 in v6 hack: yes BSD Auth support: no Random number source: OpenSSL internal ONLY Host: i686-pc-linux-gnu Compiler: gcc Compiler flags: -std=c99 -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wno-pointer-sign Preprocessor flags: Linker flags: Libraries: -lresolv -lcrypto -lutil -lz -lnsl -lcrypt [gwhite at fc5 openssh-4.3p2]$ grep -i strsep config.h /* Define to 1 if you have the `strsep' function. */ /* #undef HAVE_STRSEP */ [gwhite at fc5 openssh-4.3p2]$ cd openbsd-compat [gwhite at fc5 openbsd-compat]$ make strsep.o gcc -std=c99 -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wno-pointer-sign -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c strsep.c In file included from ../includes.h:209, from strsep.c:34: ../openbsd-compat/openbsd-compat.h:112: error: expected identifier or '(' before '__extension__' ../openbsd-compat/openbsd-compat.h:112: error: expected identifier or '(' before ')' token In file included from ../openbsd-compat/openbsd-compat.h:181, from ../includes.h:209, from strsep.c:34: ../openbsd-compat/fake-rfc2553.h:130: error: redefinition of 'struct addrinfo' strsep.c:53: error: expected identifier or '(' before '__extension__' strsep.c:53: error: expected identifier or '(' before ')' token make: *** [strsep.o] Error 1 Lines 111-113 of openbsd-compat/openbsd-compat.h: #ifndef HAVE_STRSEP char *strsep(char **stringp, const char *delim); #endif -- George N. White III Head of St. Margarets Bay, Nova Scotia From phillipsmiley at gmail.com Tue Aug 22 11:28:56 2006 From: phillipsmiley at gmail.com (Phil Smiley) Date: Mon, 21 Aug 2006 20:28:56 -0500 Subject: Carpet Cleaning Message-ID: Do you have a carpet cleaning service that you recommend? I'd like to get the carpets done before we move our furniture in. Phil From logsnaath at gmx.net Tue Aug 22 16:17:18 2006 From: logsnaath at gmx.net (Logu) Date: Tue, 22 Aug 2006 11:47:18 +0530 Subject: too many close calls for non-opened fds References: <20060816214150.GA10079@folly> <017801c6c1f7$c3c75020$140110ac@LOGUCO> <20060821131657.GA29809@gate.dtucker.net> Message-ID: <009001c6c5b2$cfc124f0$140110ac@LOGUCO> >> I thought this issue occurs from openssh-3.9 because of introduction of >> re-exec feature. >> I tried by disabling the re-exec feature and still I see a large number >> of >> close() calls during connection. > > If you run sshd with "-r", how many close() calls do you see per > connection? > > If it's 60 or so then session.c does this: > > /* > * Close any extra open file descriptors so that we don't have them > * hanging around in clients. Note that we want to do this after > * initgroups, because at least on Solaris 2.3 it leaves file > * descriptors open. > */ > for (i = 3; i < 64; i++) > close(i); > > but I can't see that having a significant performance impact. > Hi Daren, Actually that was a mistake on my part. When -r option is used the close call occurs only during startup and not for every connection. During startup with -r option we get around 60K close calls. We are about to do a fix for this issue on HP-UX (without -r option). The approach is to find out the open fds and close the unwanted ones. Will this be a valid approach. Thanks -logu From cloos at jhcloos.com Tue Aug 22 21:04:01 2006 From: cloos at jhcloos.com (James Cloos) Date: Tue, 22 Aug 2006 07:04:01 -0400 Subject: Patch for openssh server In-Reply-To: <44E1DD8C.50403@psc.edu> (Chris Rapier's message of "Tue, 15 Aug 2006 10:43:24 -0400") References: <200608102119.28311.chrivers@iversen-net.dk> <200608151528.25900.chrivers@iversen-net.dk> <44E1D573.90202@zip.com.au> <200608151618.55975.chrivers@iversen-net.dk> <44E1DD8C.50403@psc.edu> Message-ID: >>>>> "Chris" == Chris Rapier writes: Chris> Christian Iversen wrote: >>>>> + logit("Accounting: Bytes in/out: %ld/%ld", bytes_in, bytes_out); >>>>> bytes_in and bytes_out are unsigned but the format string is signed. >>>> Oops, my bad. Indeed, that would be a problem if the user transferred >>>> more bytes than there are atoms in the universe ;-) >>> Yeah, it's not something that people are likely hit in an enormous hurry >>> :-) >> >> Not really, no ;-) Chris> Based on the amount of data we're moving around at the US supercomputing Chris> centers I'd say you have 5 to 7 years at the outside. Are you guys all on LP64 systems? Because rsync(1)ing two gigs+ over ssh doesn't seem all that far-fetched.... ;^) -JimC -- James Cloos From cloos at jhcloos.com Tue Aug 22 21:03:49 2006 From: cloos at jhcloos.com (James Cloos) Date: Tue, 22 Aug 2006 07:03:49 -0400 Subject: Patch for openssh server In-Reply-To: <44E1DD8C.50403@psc.edu> (Chris Rapier's message of "Tue, 15 Aug 2006 10:43:24 -0400") References: <200608102119.28311.chrivers@iversen-net.dk> <200608151528.25900.chrivers@iversen-net.dk> <44E1D573.90202@zip.com.au> <200608151618.55975.chrivers@iversen-net.dk> <44E1DD8C.50403@psc.edu> Message-ID: >>>>> "Chris" == Chris Rapier writes: Chris> Christian Iversen wrote: >>>>> + logit("Accounting: Bytes in/out: %ld/%ld", bytes_in, bytes_out); >>>>> bytes_in and bytes_out are unsigned but the format string is signed. >>>> Oops, my bad. Indeed, that would be a problem if the user transferred >>>> more bytes than there are atoms in the universe ;-) >>> Yeah, it's not something that people are likely hit in an enormous hurry >>> :-) >> >> Not really, no ;-) Chris> Based on the amount of data we're moving around at the US supercomputing Chris> centers I'd say you have 5 to 7 years at the outside. Are you guys all on LP64 systems? Because rsync(1)ing two gigs+ over ssh doesn't seem all that far-fetched.... ;^) -JimC -- James Cloos From rick.jones2 at hp.com Wed Aug 23 02:41:42 2006 From: rick.jones2 at hp.com (Rick Jones) Date: Tue, 22 Aug 2006 09:41:42 -0700 Subject: too many close calls for non-opened fds In-Reply-To: <009001c6c5b2$cfc124f0$140110ac@LOGUCO> References: <20060816214150.GA10079@folly> <017801c6c1f7$c3c75020$140110ac@LOGUCO> <20060821131657.GA29809@gate.dtucker.net> <009001c6c5b2$cfc124f0$140110ac@LOGUCO> Message-ID: <44EB33C6.8030300@hp.com> > Actually that was a mistake on my part. When -r option is used the close > call occurs only during startup and not for every connection. During startup > with -r option we get around 60K close calls. > We are about to do a fix for this issue on HP-UX (without -r option). The > approach is to find out the open fds and close the unwanted ones. Will this > be a valid approach. I would think that the overhead of determining if an FD is open wouldn't be that far off from closing it. rick jones From rapier at psc.edu Wed Aug 23 03:46:08 2006 From: rapier at psc.edu (Chris Rapier) Date: Tue, 22 Aug 2006 13:46:08 -0400 Subject: too many close calls for non-opened fds In-Reply-To: <44EB33C6.8030300@hp.com> References: <20060816214150.GA10079@folly> <017801c6c1f7$c3c75020$140110ac@LOGUCO> <20060821131657.GA29809@gate.dtucker.net> <009001c6c5b2$cfc124f0$140110ac@LOGUCO> <44EB33C6.8030300@hp.com> Message-ID: <44EB42E0.4020601@psc.edu> Rick Jones wrote: >> Actually that was a mistake on my part. When -r option is used the close >> call occurs only during startup and not for every connection. During startup >> with -r option we get around 60K close calls. >> We are about to do a fix for this issue on HP-UX (without -r option). The >> approach is to find out the open fds and close the unwanted ones. Will this >> be a valid approach. > > I would think that the overhead of determining if an FD is open wouldn't > be that far off from closing it. One question: I'm assuming its cheaper (or at least was at one time) to just close a whole bunch of FDs rather than track what FDs are being opened as they are being opened? From rick.jones2 at hp.com Wed Aug 23 03:53:51 2006 From: rick.jones2 at hp.com (Rick Jones) Date: Tue, 22 Aug 2006 10:53:51 -0700 Subject: too many close calls for non-opened fds In-Reply-To: <44EB42E0.4020601@psc.edu> References: <20060816214150.GA10079@folly> <017801c6c1f7$c3c75020$140110ac@LOGUCO> <20060821131657.GA29809@gate.dtucker.net> <009001c6c5b2$cfc124f0$140110ac@LOGUCO> <44EB33C6.8030300@hp.com> <44EB42E0.4020601@psc.edu> Message-ID: <44EB44AF.1030203@hp.com> Chris Rapier wrote: > > Rick Jones wrote: > >>>Actually that was a mistake on my part. When -r option is used the close >>>call occurs only during startup and not for every connection. During startup >>>with -r option we get around 60K close calls. >>>We are about to do a fix for this issue on HP-UX (without -r option). The >>>approach is to find out the open fds and close the unwanted ones. Will this >>>be a valid approach. >> >>I would think that the overhead of determining if an FD is open wouldn't >>be that far off from closing it. > > > One question: I'm assuming its cheaper (or at least was at one time) to > just close a whole bunch of FDs rather than track what FDs are being > opened as they are being opened? most likely - at least when we are talking about crossing an exec boundary. rick jones From fcusack at fcusack.com Wed Aug 23 04:46:40 2006 From: fcusack at fcusack.com (Frank Cusack) Date: Tue, 22 Aug 2006 11:46:40 -0700 Subject: too many close calls for non-opened fds In-Reply-To: <44EB44AF.1030203@hp.com> References: <20060816214150.GA10079@folly> <017801c6c1f7$c3c75020$140110ac@LOGUCO> <20060821131657.GA29809@gate.dtucker.net> <009001c6c5b2$cfc124f0$140110ac@LOGUCO> <44EB33C6.8030300@hp.com> <44EB42E0.4020601@psc.edu> <44EB44AF.1030203@hp.com> Message-ID: On August 22, 2006 10:53:51 AM -0700 Rick Jones wrote: > Chris Rapier wrote: >> >> Rick Jones wrote: >> >>>> Actually that was a mistake on my part. When -r option is used the close >>>> call occurs only during startup and not for every connection. During startup >>>> with -r option we get around 60K close calls. >>>> We are about to do a fix for this issue on HP-UX (without -r option). The >>>> approach is to find out the open fds and close the unwanted ones. Will this >>>> be a valid approach. >>> >>> I would think that the overhead of determining if an FD is open wouldn't >>> be that far off from closing it. >> >> >> One question: I'm assuming its cheaper (or at least was at one time) to >> just close a whole bunch of FDs rather than track what FDs are being >> opened as they are being opened? > > most likely - at least when we are talking about crossing an exec boundary. You can probably peek in /proc or /sys or otherwise get a list with one syscall. But you don't have to track anything. You simply set FD_CLOEXEC. Just to be clear (although I think everyone gets it) this problem isn't fd's that sshd opens, it's fd's that might already be open when sshd is started. At least that's my understanding. Then again, if that's the case I don't understand the problem. sshd should close all fd's when it starts up and that's that. I'll crawl back into my hole now. -frank From fcusack at fcusack.com Wed Aug 23 04:54:52 2006 From: fcusack at fcusack.com (Frank Cusack) Date: Tue, 22 Aug 2006 11:54:52 -0700 Subject: too many close calls for non-opened fds In-Reply-To: <5719B599C1C6163B8E812BB7@[192.168.1.2]> References: <006301c6bf5f$4b951e60$140110ac@LOGUCO> <20060816114627.GC28989@folly> <014301c6c160$d6b27a80$140110ac@LOGUCO> <20060816205646.GA23798@folly> <32840C68719340D3D9A446BD@[192.168.1.2]> <20060816213340.GA10424@orville.25thandClement.com> <5719B599C1C6163B8E812BB7@[192.168.1.2]> Message-ID: On August 16, 2006 2:44:43 PM -0700 Carson Gaspar wrote: > You learn something new every day... Solaris 10 also has closefrom() and > fdwalk() (which performs an arbitrary function on all open fds, allowing > you to check the return code from each close, unlike closefrom()). Also Solaris 9. First documentation I can find for it is from Dec '02, but that document is dated Apr '00. It might have been a private interface before 12/02, or online docs are missing info before then (they do seem to be sparse). In any case the point is, this isn't new to Solaris 10. -frank From fcusack at fcusack.com Wed Aug 23 04:59:45 2006 From: fcusack at fcusack.com (Frank Cusack) Date: Tue, 22 Aug 2006 11:59:45 -0700 Subject: too many close calls for non-opened fds In-Reply-To: <17635.38075.373310.569177@squeak.fifthhorseman.net> References: <006301c6bf5f$4b951e60$140110ac@LOGUCO> <20060816114627.GC28989@folly> <014301c6c160$d6b27a80$140110ac@LOGUCO> <20060816205646.GA23798@folly> <32840C68719340D3D9A446BD@[192.168.1.2]> <17635.38075.373310.569177@squeak.fifthhorseman.net> Message-ID: <1CBF5637FD680967995F87AD@manatee.local> On August 16, 2006 5:57:15 PM -0400 Daniel Kahn Gillmor wrote: > On August 16, carson at taltos.org said: > > > Does any UNIX variant have a "close all my open fds except for > > these" syscall? Or an easy way to get back a list of in-use fds? I > > really wish such a beast would be added, as calling close() on all > > possible fd numbers is _such_ a hack... > > While i understand the security advantage of this practice, it can > sometimes be ill-advised on systems that use external libraries which > have plugins, because you don't know what those plugins are going to > need. (alternatively, you could argue that a library with a plugin > architecture is itself less secure...) > > For example, some NSS (name service switch) extensions will use file > descriptors themselves (e.g. sockets to external LDAP resources), and > don't take kindly to them being killed mid-run. > > I ran into this problem with gdm a while back: > > http://bugzilla.gnome.org/show_bug.cgi?id=315846#c19 > > gdm had a similar "close_all_file_descriptors_except()" function, and > it was clobbering the LDAP connections that NSS was expecting to have > held open. I'd suggest that this is a bug in gdm that doesn't apply to openssh. If you're a system application and are going to close all fd's, you probably should fork/exec yourself immediately. As you said, you don't know what things are open on your behalf. But holding open an ldap connection (from a system library) across fork/exec is almost certainly wrong. In fact I'd be surprised if FD_CLOEXEC isn't set on the ldap fd's. -frank From dtucker at zip.com.au Wed Aug 23 20:24:37 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 23 Aug 2006 20:24:37 +1000 Subject: too many close calls for non-opened fds In-Reply-To: References: <006301c6bf5f$4b951e60$140110ac@LOGUCO> <20060816114627.GC28989@folly> <014301c6c160$d6b27a80$140110ac@LOGUCO> <20060816205646.GA23798@folly> <32840C68719340D3D9A446BD@[192.168.1.2]> <20060816213340.GA10424@orville.25thandClement.com> <5719B599C1C6163B8E812BB7@[192.168.1.2]> Message-ID: <20060823102437.GA31698@gate.dtucker.net> On Tue, Aug 22, 2006 at 11:54:52AM -0700, Frank Cusack wrote: > On August 16, 2006 2:44:43 PM -0700 Carson Gaspar wrote: > > You learn something new every day... Solaris 10 also has closefrom() and > > fdwalk() (which performs an arbitrary function on all open fds, allowing > > you to check the return code from each close, unlike closefrom()). > > Also Solaris 9. First documentation I can find for it is from Dec '02, > but that document is dated Apr '00. It might have been a private > interface before 12/02, or online docs are missing info before then > (they do seem to be sparse). In any case the point is, this isn't new > to Solaris 10. I believe they originated in Solaris 9. According to our survey data, the platforms that have closefrom() are: i386-unknown-netbsdelf3.0. i386-unknown-openbsd3.6 i386-unknown-openbsd3.7 i386-unknown-openbsd3.9 sparc-sun-solaris2.10 sparc-sun-solaris2.9 -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Wed Aug 23 21:09:26 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 23 Aug 2006 21:09:26 +1000 Subject: OpenSSH survey results Message-ID: <20060823110926.GA31863@gate.dtucker.net> Hi all. For those that didn't know it, the OpenSSH portable team has been collecting survey data about the platforms that it runs and the options that it is built with. Partitipation is entirely voluntary and is as simple as running "make send-survey" after building (see the INSTALL file for details and caveats). I've used the data to answer a couple of questions on this list recently. (If you didn't know this and want to participate then go do it now, we'll wait :-) In INSTALL we said that we may publish summary data. We haven't to date, but since I extracted some to satisfy my own curiousity I thought I'd share it with the list. It's skewed towards the systems that we have access to (there's no reports from IRIX or Tru64, for example). 94 total reports breakdown by operating system (uname) 29.8 Linux 25.5 SunOS 7.4 FreeBSD 7.4 AIX 4.3 OpenBSD 4.3 NetBSD 4.3 SCO_SV 4.3 UnixWare 3.2 HP-UX 3.2 Darwin 2.1 CYGWIN_NT-5.1 2.1 UNIX_SV 1.1 sco42 1.1 QNX breakdown by architecture 59.6 i386 24.5 sparc 10.6 powerpc 2.1 hppa2.0n 1.1 hppa2.0w 1.1 x86_64 1.1 sparc64 breakdown by compiler 27.7 gcc 3.3.x 19.1 gcc 3.4.x 17.0 gcc 2.95.x 7.4 gcc 4.0.x 6.4 gcc 3.2.x 5.3 CCS 3.2 Sun C 3.2 gcc 2.96.x 3.2 gcc 4.1.x 3.2 gcc 2.7.x 1.1 ccache gcc 1.1 egcs 2.91.66 1.1 icc 1.1 /usr/bin/gcc 3.3.x breakdown by configure options 27.7 --with-privsep-path 25.5 --prefix 24.5 --with-tcp-wrappers 18.1 --sysconfdir 16.0 --with-pam 14.9 --with-default-path 11.7 --without-zlib-version-check 10.6 --with-superuser-path 9.6 --mandir 9.6 --with-zlib 8.5 --disable-etc-default-login 8.5 --with-privsep-user 7.4 --localstatedir 7.4 --infodir 7.4 --with-kerberos5 7.4 --with-ssl-dir 6.4 --with-pid-dir 5.3 --libexecdir 5.3 --datadir 4.3 --with-md5-passwords 3.2 --with-xauth 3.2 --with-prngd-socket 3.2 --with-mantype 3.2 --disable-suid-ssh 3.2 --with-cflags 2.1 --sharedstatedir 2.1 --with-audit 2.1 --with-lastlog 2.1 --with-libedit 2.1 --without-kerberos5 2.1 --with-ldflags 2.1 --with-skey 1.1 --without-privsep-path 1.1 --without-libedit 1.1 --without-rpath 1.1 --without-rsh 1.1 --with-rand-helper 1.1 --with-cppflags 1.1 --build 1.1 --without-privsep-user 1.1 --disable-strip 1.1 --without-opensc 1.1 --without-skey 1.1 --without-pam 1.1 --with-random 1.1 --host 1.1 --with-prngd-port -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From logsnaath at gmx.net Wed Aug 23 22:06:15 2006 From: logsnaath at gmx.net (Logu) Date: Wed, 23 Aug 2006 17:36:15 +0530 Subject: too many close calls for non-opened fds References: <20060816214150.GA10079@folly> <017801c6c1f7$c3c75020$140110ac@LOGUCO> <20060821131657.GA29809@gate.dtucker.net> <009001c6c5b2$cfc124f0$140110ac@LOGUCO> <44EB33C6.8030300@hp.com> Message-ID: <345d01c6c6ac$a33657c0$140110ac@LOGUCO> >> Actually that was a mistake on my part. When -r option is used the close >> call occurs only during startup and not for every connection. During >> startup with -r option we get around 60K close calls. >> We are about to do a fix for this issue on HP-UX (without -r option). The >> approach is to find out the open fds and close the unwanted ones. Will >> this be a valid approach. > > I would think that the overhead of determining if an FD is open wouldn't > be that far off from closing it. > > rick jones > How about saving the currently opened fds before re-exec and passing it to the re-execed process and closing it both on the original process and re-execed process. I am sorry if it didnt make any sense. -logu From rac at tenzing.org Thu Aug 24 00:05:02 2006 From: rac at tenzing.org (Roger Cornelius) Date: Wed, 23 Aug 2006 10:05:02 -0400 Subject: openssh 4.3p2 configure problem Message-ID: <20060823140502.GA29782@tenzing.org> In configure for openssh 4.3p2 is this: as_executable_p="test -f" as_executable_p, as the name suggests, is used to test whether a file is executable or not, so should use -x and not -f. Discovered after doing chmod a-x gcc so configure would not discover it, but found it anyway. -- Roger Cornelius rac at tenzing.org From tim at multitalents.net Thu Aug 24 03:17:33 2006 From: tim at multitalents.net (Tim Rice) Date: Wed, 23 Aug 2006 10:17:33 -0700 (PDT) Subject: openssh 4.3p2 configure problem In-Reply-To: <20060823140502.GA29782@tenzing.org> References: <20060823140502.GA29782@tenzing.org> Message-ID: On Wed, 23 Aug 2006, Roger Cornelius wrote: > In configure for openssh 4.3p2 is this: > > as_executable_p="test -f" > > as_executable_p, as the name suggests, is used to test whether a file is > executable or not, so should use -x and not -f. Discovered after doing > chmod a-x gcc so configure would not discover it, but found it anyway. That's an autoconf issue. It looks like this is fixed in autoconf 2.60 The next release (and current snapshots) will be using a configure generated by autoconf 2.60. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From openssh at lakedaemon.net Sat Aug 26 00:46:02 2006 From: openssh at lakedaemon.net (Jason) Date: Fri, 25 Aug 2006 10:46:02 -0400 Subject: RFC: non-root ssh tun access Message-ID: <20060825144602.GH14379@lakedaemon.net> The attached patch is against openssh-4.3_p2 to allow non-root users to vpn in over ssh. root access is still needed on client side (or an sudo solution). Currently, I have it working with an sudo command to configure a tap interface on the server side. eg to ssh into my gentoo server: # ssh -fw any:any user at ssh_server.box "sudo /etc/init.d/net.tap0 restart" Then, configure the tap interface on the client side. So far, 1.) the patch applies cleanly to 4.3_p2 2.) compiles cleanly on a Linux x86 system 3.) successfully permits non-root users to login, then access the tun interface (via 'ioctl(fd, TUNSETOWNER, uid)') To be done: 1.) propagate the change to the other platforms to clean up the "#if defined(...)'s" 2.) verify no bugs have been introduced. 3.) verify I'm not smoking crack. :) This is my first attempt at modifying openssh, so I'm sure I've screwed up a few conventions or security procedures. Let me know if I did and I'll fix it. thx, Jason. -------------- next part -------------- diff -Nurd openssh-4.3p2.orig/misc.c openssh-4.3p2/misc.c --- openssh-4.3p2.orig/misc.c 2006-01-31 05:49:28.000000000 -0500 +++ openssh-4.3p2/misc.c 2006-08-25 09:01:31.000000000 -0400 @@ -579,12 +579,15 @@ return -1; } +#if defined(SSH_TUN_LINUX) int -tun_open(int tun, int mode) +tun_open(int tun, int mode, uid_t uid) { -#if defined(CUSTOM_SYS_TUN_OPEN) - return (sys_tun_open(tun, mode)); + return (sys_tun_open(tun, mode, uid)); #elif defined(SSH_TUN_OPENBSD) +int +tun_open(int tun, int mode) +{ struct ifreq ifr; char name[100]; int fd = -1, sock; diff -Nurd openssh-4.3p2.orig/misc.h openssh-4.3p2/misc.h --- openssh-4.3p2.orig/misc.h 2006-01-31 05:49:28.000000000 -0500 +++ openssh-4.3p2/misc.h 2006-08-25 09:01:57.000000000 -0400 @@ -55,7 +55,11 @@ int ask_permission(const char *, ...) __attribute__((format(printf, 1, 2))); int read_keyfile_line(FILE *, const char *, char *, size_t, u_long *); -int tun_open(int, int); +#if defined(SSH_TUN_LINUX) +int tun_open(int, int, uid_t); +#else +int tun_open(int, int); +#endif /* Common definitions for ssh tunnel device forwarding */ #define SSH_TUNMODE_NO 0x00 diff -Nurd openssh-4.3p2.orig/openbsd-compat/port-tun.c openssh-4.3p2/openbsd-compat/port-tun.c --- openssh-4.3p2.orig/openbsd-compat/port-tun.c 2006-01-01 05:15:51.000000000 -0500 +++ openssh-4.3p2/openbsd-compat/port-tun.c 2006-08-25 09:02:36.000000000 -0400 @@ -39,7 +39,7 @@ #include int -sys_tun_open(int tun, int mode) +sys_tun_open(int tun, int mode, uid_t uid) { struct ifreq ifr; int fd = -1; @@ -77,6 +77,12 @@ goto failed; } + if (ioctl(fd, TUNSETOWNER, uid) == -1) { + debug("%s: failed to set tunnel owner (uid %d): %s", __func__, + uid, strerror(errno)); + goto failed; + } + if (tun == SSH_TUNID_ANY) debug("%s: tunnel mode %d fd %d", __func__, mode, fd); else diff -Nurd openssh-4.3p2.orig/openbsd-compat/port-tun.h openssh-4.3p2/openbsd-compat/port-tun.h --- openssh-4.3p2.orig/openbsd-compat/port-tun.h 2006-01-01 03:47:06.000000000 -0500 +++ openssh-4.3p2/openbsd-compat/port-tun.h 2006-08-25 09:02:59.000000000 -0400 @@ -19,7 +19,10 @@ #include "channels.h" -#if defined(SSH_TUN_LINUX) || defined(SSH_TUN_FREEBSD) +#if defined(SSH_TUN_LINUX) +# define CUSTOM_SYS_TUN_OPEN +int sys_tun_open(int, int, uid_t); +#elif defined(SSH_TUN_FREEBSD) # define CUSTOM_SYS_TUN_OPEN int sys_tun_open(int, int); #endif diff -Nurd openssh-4.3p2.orig/serverloop.c openssh-4.3p2/serverloop.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 +++ openssh-4.3p2/ssh.c 2006-08-25 08:32:57.000000000 -0400 @@ -1073,8 +1073,13 @@ int fd; debug("Requesting tun."); +#if defined(SSH_TUN_LINUX) + if ((fd = tun_open(options.tun_local, + options.tun_open, original_real_uid)) >= 0) { +#else if ((fd = tun_open(options.tun_local, options.tun_open)) >= 0) { +#endif c = channel_new("tun", SSH_CHANNEL_OPENING, fd, fd, -1, CHAN_TCP_WINDOW_DEFAULT, CHAN_TCP_PACKET_DEFAULT, 0, "tun", 1); From rapier at psc.edu Sat Aug 26 02:13:38 2006 From: rapier at psc.edu (Chris Rapier) Date: Fri, 25 Aug 2006 12:13:38 -0400 Subject: RFC: non-root ssh tun access In-Reply-To: <20060825144602.GH14379@lakedaemon.net> References: <20060825144602.GH14379@lakedaemon.net> Message-ID: <44EF21B2.7060204@psc.edu> A while ago we developed a series of patches we call PMVPN for Poor Man's VPN. Basically what we did was intercept open() calls and compare the tuple to a set of rules we had (using LD_PRELOAD (windows and OS X required more annoying proceedures that we didn't explore in any depth)). If the rule matched then we'd automatically open an SSH tunnel to the target and forward the appropriate port over it. The nice bit was that everything happened on a per user basis so we could actually forward 'privileged' ports without being root or impacting anyone else on the host (very useful in multiuser setups). We were able to do this by not actually touching the privileged ports but by mucking with the system calls so even though the application thought it was using port 25 it was actually using port 27618 as its end of the ssh tunnel. There were some advantages to this (transparency and ease of use to the user) but we never actually followed through on it. Mostly because we decided to focus on HPN and we thought one huge set of patches was enough to cope with :) If you, or anyone else here, wants the code to try building on we've done I'll dig it up and send it over. Jason wrote: > The attached patch is against openssh-4.3_p2 to allow non-root users to > vpn in over ssh. root access is still needed on client side (or an sudo > solution). Currently, I have it working with an sudo command to > configure a tap interface on the server side. eg to ssh into my gentoo > server: > > # ssh -fw any:any user at ssh_server.box "sudo /etc/init.d/net.tap0 restart" > > Then, configure the tap interface on the client side. > > So far, > 1.) the patch applies cleanly to 4.3_p2 > 2.) compiles cleanly on a Linux x86 system > 3.) successfully permits non-root users to login, then access the tun > interface (via 'ioctl(fd, TUNSETOWNER, uid)') > > To be done: > 1.) propagate the change to the other platforms to clean up the > "#if defined(...)'s" > 2.) verify no bugs have been introduced. > 3.) verify I'm not smoking crack. :) > > This is my first attempt at modifying openssh, so I'm sure I've screwed up > a few conventions or security procedures. Let me know if I did and I'll > fix it. From djm at mindrot.org Sat Aug 26 09:29:55 2006 From: djm at mindrot.org (Damien Miller) Date: Sat, 26 Aug 2006 09:29:55 +1000 (EST) Subject: RFC: non-root ssh tun access In-Reply-To: <44EF21B2.7060204@psc.edu> References: <20060825144602.GH14379@lakedaemon.net> <44EF21B2.7060204@psc.edu> Message-ID: On Fri, 25 Aug 2006, Chris Rapier wrote: > A while ago we developed a series of patches we call PMVPN for Poor > Man's VPN. Basically what we did was intercept open() calls and compare > the tuple to a set of rules we had (using LD_PRELOAD (windows and OS X > required more annoying proceedures that we didn't explore in any > depth)). If the rule matched then we'd automatically open an SSH tunnel > to the target and forward the appropriate port over it. You can do something similar with an unmodified ssh, "socksify" and DynamicForward -d From gogu at l.route666.net Tue Aug 29 06:51:36 2006 From: gogu at l.route666.net (catam) Date: Mon, 28 Aug 2006 23:51:36 +0300 (EEST) Subject: patch for ssh-agent force confirm keys Message-ID: Hi all Patch adds flag -C to ssh-agent which will force confirmation for any key added in agent (similar to ssh-add -c) Helps when forwarded agent authentication is used and each key should be confirmed before use catam --- ssh-agent.c 2006-08-28 14:02:12.000000000 +0300 +++ ssh-agent.c.orig 2006-08-28 13:36:05.000000000 +0300 @@ -111,9 +111,6 @@ /* Default lifetime (0 == forever) */ static int lifetime = 0; -/* global confirm */ -static int confirm = 0; - static void close_socket(SocketEntry *e) { @@ -246,7 +243,7 @@ goto failure; id = lookup_identity(key, 1); - if (id != NULL && ((!confirm && !id->confirm) || confirm_key(id) == 0)) { + if (id != NULL && (!id->confirm || confirm_key(id) == 0)) { Key *private = id->key; /* Decrypt the challenge using the private key. */ if (rsa_private_decrypt(challenge, challenge, private->rsa) <= 0) @@ -306,7 +303,7 @@ key = key_from_blob(blob, blen); if (key != NULL) { Identity *id = lookup_identity(key, 2); - if (id != NULL && ((!confirm && !id->confirm) || confirm_key(id) == 0)) + if (id != NULL && (!id->confirm || confirm_key(id) == 0)) ok = key_sign(id->key, &signature, &slen, data, dlen); } key_free(key); @@ -1029,7 +1026,7 @@ init_rng(); seed_rng(); - while ((ch = getopt(ac, av, "Ccdksa:t:")) != -1) { + while ((ch = getopt(ac, av, "cdksa:t:")) != -1) { switch (ch) { case 'c': if (s_flag) @@ -1058,9 +1055,6 @@ usage(); } break; - case 'C': - confirm = 1; - break; default: usage(); } From rapier at psc.edu Tue Aug 29 07:13:51 2006 From: rapier at psc.edu (Chris Rapier) Date: Mon, 28 Aug 2006 17:13:51 -0400 Subject: RFC: non-root ssh tun access In-Reply-To: References: <20060825144602.GH14379@lakedaemon.net> <44EF21B2.7060204@psc.edu> Message-ID: <44F35C8F.3010106@psc.edu> Damien Miller wrote: > On Fri, 25 Aug 2006, Chris Rapier wrote: > >> A while ago we developed a series of patches we call PMVPN for Poor >> Man's VPN. Basically what we did was intercept open() calls and compare >> the tuple to a set of rules we had (using LD_PRELOAD (windows and OS X >> required more annoying proceedures that we didn't explore in any >> depth)). If the rule matched then we'd automatically open an SSH tunnel >> to the target and forward the appropriate port over it. > > You can do something similar with an unmodified ssh, "socksify" and > DynamicForward Well, the idea was to integrate things in order to bring greater security to a larger number of people. The majority of people won't go to the hassle of paying for and installing socksify and then do all of the DynamicForward routines from the command line. Its not that difficult of course, but people generally just won't do it. Our feeling was that the easier we made it the more people would use it. The more people that used it the safer we'd all be (the idea of herd immunity). The end result was going to be a nice GUI so that users wouldn't have to drop down to the CLI - which turns a lot of people off. I spend a lot of time supporting users so the easier I make it for them the easier my job ends up being :) We might be re-exploring this question in the upcoming year but it depends on what the grant situation looks like. Chris From dtucker at zip.com.au Tue Aug 29 08:20:58 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 29 Aug 2006 08:20:58 +1000 Subject: RFC: non-root ssh tun access In-Reply-To: <44F35C8F.3010106@psc.edu> References: <20060825144602.GH14379@lakedaemon.net> <44EF21B2.7060204@psc.edu> <44F35C8F.3010106@psc.edu> Message-ID: <44F36C4A.7030503@zip.com.au> Chris Rapier wrote: > > Damien Miller wrote: >> On Fri, 25 Aug 2006, Chris Rapier wrote: >> >>> A while ago we developed a series of patches we call PMVPN for Poor >>> Man's VPN. Basically what we did was intercept open() calls and compare >>> the tuple to a set of rules we had (using LD_PRELOAD (windows and OS X >>> required more annoying proceedures that we didn't explore in any >>> depth)). If the rule matched then we'd automatically open an SSH tunnel >>> to the target and forward the appropriate port over it. >> You can do something similar with an unmodified ssh, "socksify" and >> DynamicForward > > Well, the idea was to integrate things in order to bring greater > security to a larger number of people. The majority of people won't go > to the hassle of paying for and installing socksify and then do all of > the DynamicForward routines from the command line. The "socksify" that comes with dante works and it's free (and Free). http://www.inet.no/dante/ If you want to get somewhat wackier, you can grab slirp (a userspace tcp stack from the olden days) and build it socksified. This will let you turn arbitrary tcp connections (including both locally originated and routed) into ssh port forward requests. You need to be able to run pppd on the client (ie root access) but there's nothing required on the server side other than regular port forwarding support. Most DNS requests don't work over the tunnel but hacking a DNS server to only use tcp would get around that too. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From Jason.C.Burns at wellsfargo.com Tue Aug 29 08:28:39 2006 From: Jason.C.Burns at wellsfargo.com (Jason.C.Burns at wellsfargo.com) Date: Mon, 28 Aug 2006 17:28:39 -0500 Subject: RFC: non-root ssh tun access Message-ID: Darren Tucker wrote: >Most DNS requests don't work over the tunnel but hacking a DNS server to only use tcp would get around that too. Doesn't that open you up to a mess of DOS attacks due to the handshake, though? Jason Burns Wells Fargo Information Security Technology _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From djm at mindrot.org Wed Aug 30 23:41:53 2006 From: djm at mindrot.org (Damien Miller) Date: Wed, 30 Aug 2006 23:41:53 +1000 (EST) Subject: Testing for the 4.4p1 release Message-ID: Hi, The 4.4p1 release is approaching now, so we are now asking people to actively test snapshots or CVS and report back to the mailing list. Snapshots are available from http://www.mindrot.org/openssh_snap or from any of the mirrors listed on http://www.openssh.org/portable.html The latter page also includes instructions for checking out portable OpenSSH via anonymous CVS. This release contains many bugfixes and feature improvements. Here are some highlights: - Implemented conditional configuration in sshd_config(5) using the "Match" directive. This allows some configuration options to be selectively overridden if specific criteria (based on user, group, hostname and/or address) are met. So far a useful subset of post- authentication options are supported and more are expected to be added in future releases. - Added a "ForceCommand" directive to sshd_config(5). Similar to the command="..." option accepted in ~/.ssh/authorized_keys, this forces the execution of the specified command regardless of what the user requested. This is very useful in conjunction with the new "Match" option. - Add a "PermitOpen" directive to sshd_config(5). This mirrors the permitopen="..." authorized_keys option, allowing fine-grained control over the port-forwardings that a user is allowed to establish. - Add optional logging of transactions to sftp-server(8). - ssh(1) will now record port numbers for hosts stored in ~/.ssh/authorized_keys when a non-standard port has been requested. - Add an "ExitOnForwardFailure" options to cause ssh(1) to exit (with a non-zero exit code) when requested port forwardings could not be established. - Extend the sshd_config(5) "SubSystem" directive to allow the specification of commandline arguments. - Add optional support for SELinux, controlled using the --with-selinux configure option (experimental) - Add optional support for Solaris process contracts, enabled using the --with-solaris-contracts configure option (experimental) - Add support for Diffie-Hellman group exchange key agreement with a final hash of SHA256. - Fixed a lot of bugs. See http://bugzilla.mindrot.org/show_bug.cgi?id=1155 for an incomplete list (more in the ChangeLog) - Lots of manpage fixes and improvements - Many code cleanups, including: - Switching to safer memory allocation functions that avoid integer overflows when allocating arrays - Cleanups of header file usage (ongoing) - Fixes to leaks reported by the Coverity static analysis tool Running the regression tests supplied with Portable does not require installation, just run: $ ./configure && make tests Testing on suitable non-production systems is also appreciated. Please send reports of success or failure to openssh-unix-dev at mindrot.org, including details of your platform, compiler and configure options. Thanks, Damien Miller From vinschen at redhat.com Thu Aug 31 02:35:21 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 30 Aug 2006 18:35:21 +0200 Subject: Testing for the 4.4p1 release In-Reply-To: References: Message-ID: <20060830163521.GO20467@calimero.vinschen.de> On Aug 30 23:41, Damien Miller wrote: > Hi, > > The 4.4p1 release is approaching now, so we are now asking people to > actively test snapshots or CVS and report back to the mailing list. > [...] > $ ./configure && make tests > > Testing on suitable non-production systems is also appreciated. Please send > reports of success or failure to openssh-unix-dev at mindrot.org, including > details of your platform, compiler and configure options. Cygwin 1.5.21, OpenSSL 0.9.8b OpenSSH has been configured with the following options: User binaries: /usr/bin System binaries: /usr/sbin Configuration files: /etc Askpass program: ${prefix}/sbin/ssh-askpass Manual pages: /usr/share/man/manX PID file: /var/run Privilege separation chroot path: /var/empty sshd default user PATH: /bin:/usr/sbin:/sbin:/usr/bin Manpage format: doc PAM support: no KerberosV support: no SELinux support: no Smartcard support: no S/KEY support: no TCP Wrappers support: yes MD5 password support: no libedit support: no IP address in $DISPLAY hack: no Translate v4 in v6 hack: no BSD Auth support: no Random number source: OpenSSL internal ONLY Host: i686-pc-cygwin Compiler: gcc Compiler flags: -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare Preprocessor flags: Linker flags: Libraries: -lwrap -lresolv -lcrypto -lz /usr/lib/textmode.o -lcrypt Configures and builds OOTB. make tests works mostly, but sftp-badcmds.sh test is broken and results in core dumps when evaluating the result of a glob() call. The reason is a bit complicated and what confused me first was the fact that this didn't happen under earlier versions of sftp. Actually, OpenSSH didn't use Cygwin's glob() implementation before (which is a relatively old NetBSD derived implementation), because the configure test for gl_matchc failed up to 4.3p2. The AC_EGREP_CPP autoconf test failed, while the new AC_TRY_COMPILE test in 4.4p1 now works, so starting with 4.4p1, OpenSSH uses Cygwin's glob function. But why does it core dump? The reason is that the old glob implementation in Cygwin doesn't know about the GLOB_NOMATCH return code. In case there's no match, it returns 0, with gl_matchc set to 0 and gl_pathv set to NULL. Unfortunately, this situation is not recognized as "File not found" condition in sftp. The result is that process_put as well as process_get SEGV when accessing g.gl_pathv[0]. What can we do? Of course we will update the glob function in Cygwin for the next Cygwin version, but that won't help for older and current versions of Cygwin. As a workaround in sftp, I applied the below patch, which also checks for gl_matchc being 0 to recognize a "File not found" condition. Would that be ok for sftp? Index: sftp.c =================================================================== RCS file: /cvs/openssh/sftp.c,v retrieving revision 1.97 diff -p -u -r1.97 sftp.c --- sftp.c 5 Aug 2006 02:39:40 -0000 1.97 +++ sftp.c 30 Aug 2006 15:55:30 -0000 @@ -535,7 +535,7 @@ process_get(struct sftp_conn *conn, char memset(&g, 0, sizeof(g)); debug3("Looking up %s", abs_src); - if (remote_glob(conn, abs_src, 0, NULL, &g)) { + if (remote_glob(conn, abs_src, 0, NULL, &g) || g.gl_matchc == 0) { error("File \"%s\" not found.", abs_src); err = -1; goto out; @@ -603,7 +603,7 @@ process_put(struct sftp_conn *conn, char memset(&g, 0, sizeof(g)); debug3("Looking up %s", src); - if (glob(src, 0, NULL, &g)) { + if (glob(src, 0, NULL, &g) || g.gl_matchc == 0) { error("File \"%s\" not found.", src); err = -1; goto out; Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From vinschen at redhat.com Thu Aug 31 02:47:52 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 30 Aug 2006 18:47:52 +0200 Subject: [PATCH] Cygwin: Add SeTcbPrivilege to sshd_server user Message-ID: <20060830164752.GP20467@calimero.vinschen.de> Hi, the below patch adds a Windows NT user right to the sshd_server user which will be important in an upcoming version of Cygwin. I have a preliminary implementation which solves the problem that native Windows processes don't recognize the user name correctly, if the user has logged in using public key authentication. The new mechanism requires the SeTcbPrivilege for the user which changes the user context using setuid. To keep the transition as smooth as possible, I'd like to give the user this specific right rather early. Could this be applied to config/cygwin/ssh-host-config before 4.4p1 is released? Thanks, Corinna Index: contrib/cygwin/ssh-host-config =================================================================== RCS file: /cvs/openssh/contrib/cygwin/ssh-host-config,v retrieving revision 1.19 diff -p -u -r1.19 ssh-host-config --- contrib/cygwin/ssh-host-config 3 Mar 2006 21:50:32 -0000 1.19 +++ contrib/cygwin/ssh-host-config 30 Aug 2006 16:45:57 -0000 @@ -516,6 +516,7 @@ then fi editrights -a SeAssignPrimaryTokenPrivilege -u sshd_server && editrights -a SeCreateTokenPrivilege -u sshd_server && + editrights -a SeTcbPrivilege -u sshd_server && editrights -a SeDenyInteractiveLogonRight -u sshd_server && editrights -a SeDenyNetworkLogonRight -u sshd_server && editrights -a SeDenyRemoteInteractiveLogonRight -u sshd_server && -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From rac at tenzing.org Thu Aug 31 07:44:16 2006 From: rac at tenzing.org (Roger Cornelius) Date: Wed, 30 Aug 2006 17:44:16 -0400 Subject: Testing for the 4.4p1 release In-Reply-To: References: Message-ID: <20060830214416.GA7373@tenzing.org> On 08/30/2006 23:41, Damien Miller wrote: [...] > Testing on suitable non-production systems is also appreciated. Please send > reports of success or failure to openssh-unix-dev at mindrot.org, including > details of your platform, compiler and configure options. Building from SNAP-20060831 on SCO OSR6 w/MP2 and the MP2 Supplement, using system compiler, with configure invoked as: export CFLAGS="-I /u/include" ./configure \ --prefix=/u \ --with-ldflags="-s -L /u/lib" \ --with-ssl-dir=/u/etc/openssl \ --with-privsep-path=/u/var/empty \ --sysconfdir=/u/etc/openssh-4.4p1 \ --with-pid-dir=/u/etc/openssh-4.4p1 \ --with-tcp-wrappers \ --disable-lastlog \ --with-xauth=/usr/bin/X11/xauth Build fails at port-uw.c: cc -I /u/include -I. -I.. -I. -I./.. -I/u/etc/openssl/include -DHAVE_CONFIG_H -c port-uw.c UX:acomp: WARNING: "/usr/include/sys/socket.h", line 371: macro redefined: CMSG_DATA UX:acomp: WARNING: "/usr/include/sys/socket.h", line 386: macro redefined: CMSG_FIRSTHDR UX:acomp: WARNING: "/usr/include/netinet/in_f.h", line 105: macro redefined: INADDR_LOOPBACK UX:acomp: WARNING: "/usr/include/netinet/in6_f.h", line 100: macro redefined: IN6_IS_ADDR_V4MAPPED UX:acomp: ERROR: "../log.h", line 63: Syntax error before or at: va_list UX:acomp: ERROR: "../auth.h", line 109: Syntax error before or at: Key UX:acomp: ERROR: "../auth.h", line 112: Syntax error before or at: * UX:acomp: ERROR: "../auth.h", line 113: Syntax error before or at: * UX:acomp: ERROR: "../auth.h", line 114: Syntax error before or at: * UX:acomp: ERROR: "../auth.h", line 115: Syntax error before or at: Key UX:acomp: ERROR: "../auth.h", line 117: Syntax error before or at: Key UX:acomp: ERROR: "../auth.h", line 118: Syntax error before or at: Key UX:acomp: ERROR: "../auth.h", line 119: Syntax error before or at: Key UX:acomp: ERROR: "../auth.h", line 173: syntax error, probably missing ",", ";" or "=" UX:acomp: ERROR: "../auth.h", line 173: cannot recover from previous errors make[1]: *** [port-uw.o] Error 1 make[1]: Leaving directory `/u1/src/rac/openssh/openssh/openbsd-compat' make: *** [openbsd-compat/libopenbsd-compat.a] Error 2 -- Roger Cornelius rac at tenzing.org From imorgan at nas.nasa.gov Thu Aug 31 09:05:12 2006 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 30 Aug 2006 16:05:12 -0700 (PDT) Subject: Testing for the 4.4p1 release In-Reply-To: from Damien Miller at "Aug 30, 2006 11:41:53 pm" Message-ID: <200608302305.k7UN5CoD015796@ganymede.nas.nasa.gov> Sometime ago, Damien Miller wrote: [...] > Testing on suitable non-production systems is also appreciated. Please send > reports of success or failure to openssh-unix-dev at mindrot.org, including > details of your platform, compiler and configure options. > The 20060830 snapshot configures, but fails to build on IRIX 6.5.29 usign the MIPSpro 7.4 compilers. export CC=c99 export CFLAGS="-g -O3 -mips3 -r14000" PREFIX=/usr/prg/pkg/openssh/4.4p1 OPENSSL=$HOME/build ZLIB=$HOME/build ./configure --prefix=$PREFIX \ --sysconfdir=/usr/prg/etc \ --with-ssl-dir=$OPENSSL \ --with-zlib=$ZLIB \ --with-tcp-wrappers=/usr/local \ --with-md5-passwords \ --with-pam There are numberous warnings, but here's the part that causes the compile to fail: c99 -g -O3 -mips3 -r14000 -I. -I.. -I. -I./.. -I/u/imorgan/build/include -I/usr/local/include -I/u/imorgan/build/include -DHAVE_CONFIG_H -c port-irix.c cc-1047 c99: WARNING File = /usr/include/sys/socket.h, Line = 645 Macro "CMSG_DATA" (declared at line 476 of "../defines.h") has an incompatible redefinition. #define CMSG_DATA(cmsg) ((uchar_t *)((cmsg) + 1)) ^ cc-1047 c99: WARNING File = /usr/include/sys/socket.h, Line = 654 Macro "CMSG_FIRSTHDR" (declared at line 484 of "../defines.h") has an incompatible redefinition. #define CMSG_FIRSTHDR(mhdr) ((struct cmsghdr *)(mhdr)->msg_control) ^ cc-1047 c99: WARNING File = /usr/include/sys/socket.h, Line = 656 Macro "CMSG_SPACE" (declared at line 471 of "../defines.h") has an incompatible redefinition. #define CMSG_SPACE(length) _ALIGN(sizeof(struct cmsghdr) + (length)) ^ cc-1047 c99: WARNING File = /usr/include/sys/socket.h, Line = 658 Macro "CMSG_LEN" (declared at line 466 of "../defines.h") has an incompatible redefinition. #define CMSG_LEN(length) (sizeof(struct cmsghdr) + length) ^ cc-1047 c99: WARNING File = /usr/include/sys/endian.h, Line = 46 Macro "LITTLE_ENDIAN" (declared at line 498 of "../defines.h") has an incompatible redefinition. #define LITTLE_ENDIAN _LITTLE_ENDIAN ^ cc-1047 c99: WARNING File = /usr/include/sys/endian.h, Line = 47 Macro "BIG_ENDIAN" (declared at line 501 of "../defines.h") has an incompatible redefinition. #define BIG_ENDIAN _BIG_ENDIAN ^ cc-1047 c99: WARNING File = /usr/include/sys/endian.h, Line = 52 Macro "BYTE_ORDER" (declared at line 504 of "../defines.h") has an incompatible redefinition. #define BYTE_ORDER _BYTE_ORDER ^ cc-1047 c99: WARNING File = /usr/include/netinet/in.h, Line = 228 Macro "INADDR_LOOPBACK" (declared at line 143 of "../defines.h") has an incompatible redefinition. #define INADDR_LOOPBACK (__uint32_t)0x7F000001 ^ cc-1047 c99: WARNING File = /usr/include/netinet/in.h, Line = 633 Macro "IN6_IS_ADDR_V4MAPPED" (declared at line 431 of "../defines.h") has an incompatible redefinition. #define IN6_IS_ADDR_V4MAPPED(p) IS_IPV4ADDR6(*p) ^ cc-1196 c99: WARNING File = port-irix.c, Line = 60 The indicated function is declared implicitly. fatal("Failed to create job container: %.100s", ^ cc-1020 c99: ERROR File = port-irix.c, Line = 61 The identifier "errno" is undefined. strerror(errno)); ^ cc-1196 c99: WARNING File = port-irix.c, Line = 66 The indicated function is declared implicitly. fatal("Failed to set up new array session: %.100s", ^ cc-1020 c99: ERROR File = port-irix.c, Line = 67 The identifier "errno" is undefined. strerror(errno)); ^ cc-1196 c99: WARNING File = port-irix.c, Line = 72 The indicated function is declared implicitly. debug("Failed to get project id, using projid 0"); ^ cc-1196 c99: WARNING File = port-irix.c, Line = 76 The indicated function is declared implicitly. fatal("Failed to initialize project %d for %s: %.100s", ^ cc-1020 c99: ERROR File = port-irix.c, Line = 77 The identifier "errno" is undefined. (int)projid, pw->pw_name, strerror(errno)); ^ cc-1196 c99: WARNING File = port-irix.c, Line = 81 The indicated function is declared implicitly. debug("Setting sat id to %d", (int) pw->pw_uid); ^ cc-1020 c99: ERROR File = port-irix.c, Line = 83 The identifier "errno" is undefined. debug("error setting satid: %.100s", strerror(errno)); ^ 4 errors detected in the compilation of "port-irix.c". *** Error code 2 (bu21) *** Error code 1 (bu21) -- Iain Morgan From imorgan at nas.nasa.gov Thu Aug 31 09:57:50 2006 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 30 Aug 2006 16:57:50 -0700 (PDT) Subject: Testing for the 4.4p1 release In-Reply-To: from Damien Miller at "Aug 30, 2006 11:41:53 pm" Message-ID: <200608302357.k7UNvofm029168@ganymede.nas.nasa.gov> Sometime ago, Damien Miller wrote: [...] > Testing on suitable non-production systems is also appreciated. Please send > reports of success or failure to openssh-unix-dev at mindrot.org, including > details of your platform, compiler and configure options. > Configures, builds and tests OK on SLES 9 (Itanium) using gcc 3.3.3. -- Iain Morgan From dtucker at zip.com.au Thu Aug 31 10:55:42 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 31 Aug 2006 10:55:42 +1000 Subject: Testing for the 4.4p1 release In-Reply-To: <20060830214416.GA7373@tenzing.org> References: <20060830214416.GA7373@tenzing.org> Message-ID: <20060831005542.GA1351@gate.dtucker.net> On Wed, Aug 30, 2006 at 05:44:16PM -0400, Roger Cornelius wrote: > Building from SNAP-20060831 on SCO OSR6 w/MP2 and the MP2 Supplement, > using system compiler, with configure invoked as: Thanks for testing. > cc -I /u/include -I. -I.. -I. -I./.. -I/u/etc/openssl/include -DHAVE_CONFIG_H -c port-uw.c [...] > UX:acomp: ERROR: "../log.h", line 63: Syntax error before or at: va_list Please try this patch, which adds the includes that appear necessary. I haven't looked at the warnings (I suspect sys/socket.h is not protected against multiple includes?) Index: openbsd-compat/port-uw.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/port-uw.c,v retrieving revision 1.3 diff -u -p -r1.3 port-uw.c --- openbsd-compat/port-uw.c 9 Sep 2005 04:56:34 -0000 1.3 +++ openbsd-compat/port-uw.c 31 Aug 2006 00:52:33 -0000 @@ -29,6 +29,10 @@ #ifdef HAVE_CRYPT_H #include #endif +#include +#include +#include + #include "packet.h" #include "buffer.h" #include "log.h" -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Thu Aug 31 12:04:02 2006 From: djm at mindrot.org (Damien Miller) Date: Thu, 31 Aug 2006 12:04:02 +1000 (EST) Subject: Testing for the 4.4p1 release In-Reply-To: <20060830214416.GA7373@tenzing.org> References: <20060830214416.GA7373@tenzing.org> Message-ID: On Wed, 30 Aug 2006, Roger Cornelius wrote: > Build fails at port-uw.c: Thanks for the test. Could you please try this (big) diff? Index: audit-bsm.c =================================================================== RCS file: /var/cvs/openssh/audit-bsm.c,v retrieving revision 1.3 diff -u -p -r1.3 audit-bsm.c --- audit-bsm.c 16 Aug 2006 01:40:45 -0000 1.3 +++ audit-bsm.c 31 Aug 2006 01:39:29 -0000 @@ -39,6 +39,7 @@ #include +#include #include #include "ssh.h" Index: audit.c =================================================================== RCS file: /var/cvs/openssh/audit.c,v retrieving revision 1.4 diff -u -p -r1.4 audit.c --- audit.c 5 Aug 2006 14:05:10 -0000 1.4 +++ audit.c 31 Aug 2006 01:40:27 -0000 @@ -26,6 +26,9 @@ #include "includes.h" +#include +#include + #ifdef SSH_AUDIT_EVENTS #include "audit.h" Index: auth-bsdauth.c =================================================================== RCS file: /var/cvs/openssh/auth-bsdauth.c,v retrieving revision 1.10 diff -u -p -r1.10 auth-bsdauth.c --- auth-bsdauth.c 5 Aug 2006 02:39:39 -0000 1.10 +++ auth-bsdauth.c 31 Aug 2006 01:40:37 -0000 @@ -27,6 +27,8 @@ #include +#include + #ifdef BSD_AUTH #include "xmalloc.h" #include "key.h" Index: auth-chall.c =================================================================== RCS file: /var/cvs/openssh/auth-chall.c,v retrieving revision 1.18 diff -u -p -r1.18 auth-chall.c --- auth-chall.c 5 Aug 2006 02:39:39 -0000 1.18 +++ auth-chall.c 31 Aug 2006 01:41:13 -0000 @@ -27,6 +27,8 @@ #include +#include + #include "xmalloc.h" #include "key.h" #include "hostfile.h" Index: auth-pam.c =================================================================== RCS file: /var/cvs/openssh/auth-pam.c,v retrieving revision 1.139 diff -u -p -r1.139 auth-pam.c --- auth-pam.c 5 Aug 2006 04:07:20 -0000 1.139 +++ auth-pam.c 31 Aug 2006 01:41:19 -0000 @@ -54,6 +54,7 @@ #include #include +#include #include #include Index: auth-rsa.c =================================================================== RCS file: /var/cvs/openssh/auth-rsa.c,v retrieving revision 1.63 diff -u -p -r1.63 auth-rsa.c --- auth-rsa.c 5 Aug 2006 02:39:39 -0000 1.63 +++ auth-rsa.c 31 Aug 2006 01:41:39 -0000 @@ -24,6 +24,7 @@ #include #include +#include #include #include "xmalloc.h" Index: auth-shadow.c =================================================================== RCS file: /var/cvs/openssh/auth-shadow.c,v retrieving revision 1.10 diff -u -p -r1.10 auth-shadow.c --- auth-shadow.c 5 Aug 2006 04:07:20 -0000 1.10 +++ auth-shadow.c 31 Aug 2006 01:41:45 -0000 @@ -26,6 +26,7 @@ #if defined(USE_SHADOW) && defined(HAS_SHADOW_EXPIRE) #include +#include #include #include "key.h" Index: auth-sia.c =================================================================== RCS file: /var/cvs/openssh/auth-sia.c,v retrieving revision 1.16 diff -u -p -r1.16 auth-sia.c --- auth-sia.c 5 Apr 2005 10:58:38 -0000 1.16 +++ auth-sia.c 31 Aug 2006 01:42:16 -0000 @@ -25,14 +25,6 @@ #include "includes.h" #ifdef HAVE_OSF_SIA -#include "ssh.h" -#include "auth.h" -#include "auth-sia.h" -#include "log.h" -#include "servconf.h" -#include "canohost.h" -#include "uidswap.h" - #include #include #include @@ -40,7 +32,16 @@ #include #include #include +#include #include + +#include "ssh.h" +#include "auth.h" +#include "auth-sia.h" +#include "log.h" +#include "servconf.h" +#include "canohost.h" +#include "uidswap.h" extern ServerOptions options; extern int saved_argc; Index: auth1.c =================================================================== RCS file: /var/cvs/openssh/auth1.c,v retrieving revision 1.119 diff -u -p -r1.119 auth1.c --- auth1.c 5 Aug 2006 02:39:39 -0000 1.119 +++ auth1.c 31 Aug 2006 01:42:25 -0000 @@ -14,6 +14,7 @@ #include +#include #include #include #include Index: auth2-chall.c =================================================================== RCS file: /var/cvs/openssh/auth2-chall.c,v retrieving revision 1.34 diff -u -p -r1.34 auth2-chall.c --- auth2-chall.c 5 Aug 2006 08:50:35 -0000 1.34 +++ auth2-chall.c 31 Aug 2006 01:42:31 -0000 @@ -28,6 +28,7 @@ #include +#include #include #include Index: auth2-gss.c =================================================================== RCS file: /var/cvs/openssh/auth2-gss.c,v retrieving revision 1.17 diff -u -p -r1.17 auth2-gss.c --- auth2-gss.c 5 Aug 2006 05:25:00 -0000 1.17 +++ auth2-gss.c 31 Aug 2006 01:43:02 -0000 @@ -30,6 +30,8 @@ #include +#include + #include "xmalloc.h" #include "key.h" #include "hostfile.h" Index: auth2-kbdint.c =================================================================== RCS file: /var/cvs/openssh/auth2-kbdint.c,v retrieving revision 1.6 diff -u -p -r1.6 auth2-kbdint.c --- auth2-kbdint.c 5 Aug 2006 02:39:39 -0000 1.6 +++ auth2-kbdint.c 31 Aug 2006 01:43:25 -0000 @@ -27,6 +27,8 @@ #include +#include + #include "xmalloc.h" #include "packet.h" #include "key.h" Index: auth2-none.c =================================================================== RCS file: /var/cvs/openssh/auth2-none.c,v retrieving revision 1.16 diff -u -p -r1.16 auth2-none.c --- auth2-none.c 5 Aug 2006 08:46:48 -0000 1.16 +++ auth2-none.c 31 Aug 2006 01:43:31 -0000 @@ -30,6 +30,7 @@ #include #include +#include #include #include "xmalloc.h" Index: authfd.c =================================================================== RCS file: /var/cvs/openssh/authfd.c,v retrieving revision 1.75 diff -u -p -r1.75 authfd.c --- authfd.c 5 Aug 2006 02:39:39 -0000 1.75 +++ authfd.c 31 Aug 2006 01:43:38 -0000 @@ -47,6 +47,7 @@ #include #include #include +#include #include #include Index: authfile.c =================================================================== RCS file: /var/cvs/openssh/authfile.c,v retrieving revision 1.75 diff -u -p -r1.75 authfile.c --- authfile.c 5 Aug 2006 02:39:39 -0000 1.75 +++ authfile.c 31 Aug 2006 01:43:45 -0000 @@ -49,6 +49,7 @@ #include #include +#include #include #include #include Index: cipher-3des1.c =================================================================== RCS file: /var/cvs/openssh/cipher-3des1.c,v retrieving revision 1.7 diff -u -p -r1.7 cipher-3des1.c --- cipher-3des1.c 5 Aug 2006 02:39:39 -0000 1.7 +++ cipher-3des1.c 31 Aug 2006 01:43:50 -0000 @@ -29,6 +29,7 @@ #include +#include #include #include "xmalloc.h" Index: cipher-aes.c =================================================================== RCS file: /var/cvs/openssh/cipher-aes.c,v retrieving revision 1.6 diff -u -p -r1.6 cipher-aes.c --- cipher-aes.c 25 Mar 2006 13:03:22 -0000 1.6 +++ cipher-aes.c 31 Aug 2006 01:44:19 -0000 @@ -28,8 +28,12 @@ #include "openbsd-compat/openssl-compat.h" #ifdef USE_BUILTIN_RIJNDAEL +#include #include + +#include + #include "rijndael.h" #include "xmalloc.h" #include "log.h" Index: cipher-bf1.c =================================================================== RCS file: /var/cvs/openssh/cipher-bf1.c,v retrieving revision 1.6 diff -u -p -r1.6 cipher-bf1.c --- cipher-bf1.c 5 Aug 2006 02:39:39 -0000 1.6 +++ cipher-bf1.c 31 Aug 2006 01:44:28 -0000 @@ -29,6 +29,7 @@ #include +#include #include #include "xmalloc.h" Index: cipher-ctr.c =================================================================== RCS file: /var/cvs/openssh/cipher-ctr.c,v retrieving revision 1.12 diff -u -p -r1.12 cipher-ctr.c --- cipher-ctr.c 5 Aug 2006 02:39:39 -0000 1.12 +++ cipher-ctr.c 31 Aug 2006 01:44:33 -0000 @@ -18,6 +18,7 @@ #include +#include #include #include Index: clientloop.c =================================================================== RCS file: /var/cvs/openssh/clientloop.c,v retrieving revision 1.160 diff -u -p -r1.160 clientloop.c --- clientloop.c 5 Aug 2006 02:39:40 -0000 1.160 +++ clientloop.c 31 Aug 2006 01:44:43 -0000 @@ -78,6 +78,7 @@ #include #endif #include +#include #include #include #include Index: dh.c =================================================================== RCS file: /var/cvs/openssh/dh.c,v retrieving revision 1.41 diff -u -p -r1.41 dh.c --- dh.c 5 Aug 2006 02:39:40 -0000 1.41 +++ dh.c 31 Aug 2006 01:44:47 -0000 @@ -30,6 +30,7 @@ #include #include +#include #include #include #include Index: dns.c =================================================================== RCS file: /var/cvs/openssh/dns.c,v retrieving revision 1.24 diff -u -p -r1.24 dns.c --- dns.c 5 Aug 2006 02:39:40 -0000 1.24 +++ dns.c 31 Aug 2006 01:44:52 -0000 @@ -31,6 +31,7 @@ #include #include +#include #include #include Index: entropy.c =================================================================== RCS file: /var/cvs/openssh/entropy.c,v retrieving revision 1.57 diff -u -p -r1.57 entropy.c --- entropy.c 5 Aug 2006 05:50:20 -0000 1.57 +++ entropy.c 31 Aug 2006 01:45:06 -0000 @@ -34,6 +34,7 @@ #ifdef HAVE_FCNTL_H # include #endif +#include #include #include Index: gss-serv-krb5.c =================================================================== RCS file: /var/cvs/openssh/gss-serv-krb5.c,v retrieving revision 1.16 diff -u -p -r1.16 gss-serv-krb5.c --- gss-serv-krb5.c 5 Aug 2006 02:39:40 -0000 1.16 +++ gss-serv-krb5.c 31 Aug 2006 01:45:11 -0000 @@ -31,6 +31,7 @@ #include +#include #include #include "xmalloc.h" Index: gss-serv.c =================================================================== RCS file: /var/cvs/openssh/gss-serv.c,v retrieving revision 1.21 diff -u -p -r1.21 gss-serv.c --- gss-serv.c 5 Aug 2006 02:39:40 -0000 1.21 +++ gss-serv.c 31 Aug 2006 01:45:16 -0000 @@ -30,6 +30,7 @@ #include +#include #include #include Index: hostfile.c =================================================================== RCS file: /var/cvs/openssh/hostfile.c,v retrieving revision 1.42 diff -u -p -r1.42 hostfile.c --- hostfile.c 5 Aug 2006 02:39:40 -0000 1.42 +++ hostfile.c 31 Aug 2006 01:45:23 -0000 @@ -46,6 +46,7 @@ #include #include +#include #include #include #include Index: kex.c =================================================================== RCS file: /var/cvs/openssh/kex.c,v retrieving revision 1.82 diff -u -p -r1.82 kex.c --- kex.c 5 Aug 2006 02:39:40 -0000 1.82 +++ kex.c 31 Aug 2006 01:45:27 -0000 @@ -28,6 +28,7 @@ #include #include +#include #include #include #include Index: kexdhc.c =================================================================== RCS file: /var/cvs/openssh/kexdhc.c,v retrieving revision 1.9 diff -u -p -r1.9 kexdhc.c --- kexdhc.c 5 Aug 2006 02:39:40 -0000 1.9 +++ kexdhc.c 31 Aug 2006 01:45:32 -0000 @@ -27,6 +27,7 @@ #include +#include #include #include #include Index: kexdhs.c =================================================================== RCS file: /var/cvs/openssh/kexdhs.c,v retrieving revision 1.7 diff -u -p -r1.7 kexdhs.c --- kexdhs.c 5 Aug 2006 02:39:40 -0000 1.7 +++ kexdhs.c 31 Aug 2006 01:45:38 -0000 @@ -26,6 +26,8 @@ #include "includes.h" #include + +#include #include #include Index: kexgexc.c =================================================================== RCS file: /var/cvs/openssh/kexgexc.c,v retrieving revision 1.9 diff -u -p -r1.9 kexgexc.c --- kexgexc.c 5 Aug 2006 02:39:40 -0000 1.9 +++ kexgexc.c 31 Aug 2006 01:45:43 -0000 @@ -28,6 +28,7 @@ #include +#include #include #include #include Index: kexgexs.c =================================================================== RCS file: /var/cvs/openssh/kexgexs.c,v retrieving revision 1.8 diff -u -p -r1.8 kexgexs.c --- kexgexs.c 5 Aug 2006 02:39:40 -0000 1.8 +++ kexgexs.c 31 Aug 2006 01:45:48 -0000 @@ -28,6 +28,7 @@ #include +#include #include #include #include Index: key.c =================================================================== RCS file: /var/cvs/openssh/key.c,v retrieving revision 1.68 diff -u -p -r1.68 key.c --- key.c 5 Aug 2006 02:39:40 -0000 1.68 +++ key.c 31 Aug 2006 01:45:52 -0000 @@ -39,6 +39,7 @@ #include +#include #include #include Index: loginrec.c =================================================================== RCS file: /var/cvs/openssh/loginrec.c,v retrieving revision 1.79 diff -u -p -r1.79 loginrec.c --- loginrec.c 5 Aug 2006 02:39:40 -0000 1.79 +++ loginrec.c 31 Aug 2006 01:46:02 -0000 @@ -156,6 +156,7 @@ #include #include #include +#include #include #include Index: mac.c =================================================================== RCS file: /var/cvs/openssh/mac.c,v retrieving revision 1.12 diff -u -p -r1.12 mac.c --- mac.c 5 Aug 2006 02:39:40 -0000 1.12 +++ mac.c 31 Aug 2006 01:46:07 -0000 @@ -29,6 +29,7 @@ #include +#include #include #include Index: monitor.c =================================================================== RCS file: /var/cvs/openssh/monitor.c,v retrieving revision 1.117 diff -u -p -r1.117 monitor.c --- monitor.c 18 Aug 2006 14:22:41 -0000 1.117 +++ monitor.c 31 Aug 2006 01:46:14 -0000 @@ -40,6 +40,7 @@ #endif #include #include +#include #include #include Index: monitor_wrap.c =================================================================== RCS file: /var/cvs/openssh/monitor_wrap.c,v retrieving revision 1.69 diff -u -p -r1.69 monitor_wrap.c --- monitor_wrap.c 18 Aug 2006 14:22:41 -0000 1.69 +++ monitor_wrap.c 31 Aug 2006 01:46:19 -0000 @@ -33,6 +33,7 @@ #include #include #include +#include #include #include #include Index: readconf.c =================================================================== RCS file: /var/cvs/openssh/readconf.c,v retrieving revision 1.135 diff -u -p -r1.135 readconf.c --- readconf.c 5 Aug 2006 02:39:40 -0000 1.135 +++ readconf.c 31 Aug 2006 01:46:27 -0000 @@ -24,6 +24,7 @@ #include #include #include +#include #include #include #include Index: rsa.c =================================================================== RCS file: /var/cvs/openssh/rsa.c,v retrieving revision 1.31 diff -u -p -r1.31 rsa.c --- rsa.c 5 Aug 2006 02:39:40 -0000 1.31 +++ rsa.c 31 Aug 2006 01:46:37 -0000 @@ -64,6 +64,7 @@ #include +#include #include #include "xmalloc.h" Index: scard-opensc.c =================================================================== RCS file: /var/cvs/openssh/scard-opensc.c,v retrieving revision 1.16 diff -u -p -r1.16 scard-opensc.c --- scard-opensc.c 4 May 2006 06:24:34 -0000 1.16 +++ scard-opensc.c 31 Aug 2006 01:53:28 -0000 @@ -26,8 +26,12 @@ #include "includes.h" #if defined(SMARTCARD) && defined(USE_OPENSC) +#include + #include #include + +#include #include #include Index: scard.c =================================================================== RCS file: /var/cvs/openssh/scard.c,v retrieving revision 1.34 diff -u -p -r1.34 scard.c --- scard.c 5 Aug 2006 02:39:40 -0000 1.34 +++ scard.c 31 Aug 2006 01:53:34 -0000 @@ -29,6 +29,7 @@ #include #include +#include #include #include Index: session.c =================================================================== RCS file: /var/cvs/openssh/session.c,v retrieving revision 1.347 diff -u -p -r1.347 session.c --- session.c 30 Aug 2006 01:07:40 -0000 1.347 +++ session.c 31 Aug 2006 01:53:56 -0000 @@ -53,6 +53,7 @@ #endif #include #include +#include #include #include #include Index: ssh-add.c =================================================================== RCS file: /var/cvs/openssh/ssh-add.c,v retrieving revision 1.96 diff -u -p -r1.96 ssh-add.c --- ssh-add.c 5 Aug 2006 02:39:40 -0000 1.96 +++ ssh-add.c 31 Aug 2006 01:54:01 -0000 @@ -45,6 +45,7 @@ #include #include +#include #include #include #include Index: ssh-agent.c =================================================================== RCS file: /var/cvs/openssh/ssh-agent.c,v retrieving revision 1.167 diff -u -p -r1.167 ssh-agent.c --- ssh-agent.c 5 Aug 2006 02:40:11 -0000 1.167 +++ ssh-agent.c 31 Aug 2006 01:54:08 -0000 @@ -58,6 +58,7 @@ # include #endif #include +#include #include #include #include Index: ssh-dss.c =================================================================== RCS file: /var/cvs/openssh/ssh-dss.c,v retrieving revision 1.23 diff -u -p -r1.23 ssh-dss.c --- ssh-dss.c 5 Aug 2006 02:39:40 -0000 1.23 +++ ssh-dss.c 31 Aug 2006 01:55:42 -0000 @@ -30,6 +30,7 @@ #include #include +#include #include #include "xmalloc.h" Index: ssh-keygen.c =================================================================== RCS file: /var/cvs/openssh/ssh-keygen.c,v retrieving revision 1.164 diff -u -p -r1.164 ssh-keygen.c --- ssh-keygen.c 5 Aug 2006 02:39:40 -0000 1.164 +++ ssh-keygen.c 31 Aug 2006 01:55:48 -0000 @@ -29,6 +29,7 @@ # include #endif #include +#include #include #include #include Index: ssh-keysign.c =================================================================== RCS file: /var/cvs/openssh/ssh-keysign.c,v retrieving revision 1.36 diff -u -p -r1.36 ssh-keysign.c --- ssh-keysign.c 5 Aug 2006 02:39:40 -0000 1.36 +++ ssh-keysign.c 31 Aug 2006 01:55:52 -0000 @@ -30,6 +30,7 @@ #include #endif #include +#include #include #include #include Index: ssh-rsa.c =================================================================== RCS file: /var/cvs/openssh/ssh-rsa.c,v retrieving revision 1.39 diff -u -p -r1.39 ssh-rsa.c --- ssh-rsa.c 5 Aug 2006 02:39:40 -0000 1.39 +++ ssh-rsa.c 31 Aug 2006 01:55:57 -0000 @@ -22,6 +22,7 @@ #include #include +#include #include #include "xmalloc.h" Index: ssh.c =================================================================== RCS file: /var/cvs/openssh/ssh.c,v retrieving revision 1.282 diff -u -p -r1.282 ssh.c --- ssh.c 5 Aug 2006 02:39:41 -0000 1.282 +++ ssh.c 31 Aug 2006 01:56:06 -0000 @@ -60,6 +60,7 @@ #endif #include #include +#include #include #include #include Index: sshconnect.c =================================================================== RCS file: /var/cvs/openssh/sshconnect.c,v retrieving revision 1.168 diff -u -p -r1.168 sshconnect.c --- sshconnect.c 5 Aug 2006 02:39:41 -0000 1.168 +++ sshconnect.c 31 Aug 2006 01:56:11 -0000 @@ -32,6 +32,7 @@ #include #endif #include +#include #include #include #include Index: sshconnect1.c =================================================================== RCS file: /var/cvs/openssh/sshconnect1.c,v retrieving revision 1.70 diff -u -p -r1.70 sshconnect1.c --- sshconnect1.c 5 Aug 2006 02:39:41 -0000 1.70 +++ sshconnect1.c 31 Aug 2006 01:56:37 -0000 @@ -21,6 +21,7 @@ #include #include +#include #include #include #include Index: sshconnect2.c =================================================================== RCS file: /var/cvs/openssh/sshconnect2.c,v retrieving revision 1.152 diff -u -p -r1.152 sshconnect2.c --- sshconnect2.c 30 Aug 2006 01:08:34 -0000 1.152 +++ sshconnect2.c 31 Aug 2006 01:56:42 -0000 @@ -33,6 +33,7 @@ #include #include #include +#include #include #include #include Index: sshd.c =================================================================== RCS file: /var/cvs/openssh/sshd.c,v retrieving revision 1.355 diff -u -p -r1.355 sshd.c --- sshd.c 30 Aug 2006 17:24:41 -0000 1.355 +++ sshd.c 31 Aug 2006 01:56:50 -0000 @@ -65,6 +65,7 @@ #include #include #include +#include #include #include #include Index: openbsd-compat/bsd-cray.c =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/bsd-cray.c,v retrieving revision 1.15 diff -u -p -r1.15 bsd-cray.c --- openbsd-compat/bsd-cray.c 24 Jul 2006 05:08:36 -0000 1.15 +++ openbsd-compat/bsd-cray.c 31 Aug 2006 01:57:00 -0000 @@ -52,6 +52,7 @@ #include #include #include +#include #include #include #include Index: openbsd-compat/port-aix.c =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/port-aix.c,v retrieving revision 1.38 diff -u -p -r1.38 port-aix.c --- openbsd-compat/port-aix.c 30 Aug 2006 12:33:10 -0000 1.38 +++ openbsd-compat/port-aix.c 31 Aug 2006 01:57:07 -0000 @@ -41,6 +41,7 @@ # include #endif #include +#include #include #include #include Index: openbsd-compat/port-linux.c =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/port-linux.c,v retrieving revision 1.2 diff -u -p -r1.2 port-linux.c --- openbsd-compat/port-linux.c 24 Jul 2006 04:51:01 -0000 1.2 +++ openbsd-compat/port-linux.c 31 Aug 2006 01:57:13 -0000 @@ -24,6 +24,7 @@ #include "includes.h" #include +#include #include #ifdef WITH_SELINUX Index: openbsd-compat/port-solaris.c =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/port-solaris.c,v retrieving revision 1.1 diff -u -p -r1.1 port-solaris.c --- openbsd-compat/port-solaris.c 30 Aug 2006 17:24:42 -0000 1.1 +++ openbsd-compat/port-solaris.c 31 Aug 2006 01:57:17 -0000 @@ -29,6 +29,7 @@ #ifdef HAVE_FCNTL_H # include #endif +#include #include #include Index: openbsd-compat/port-uw.c =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/port-uw.c,v retrieving revision 1.3 diff -u -p -r1.3 port-uw.c --- openbsd-compat/port-uw.c 9 Sep 2005 04:56:34 -0000 1.3 +++ openbsd-compat/port-uw.c 31 Aug 2006 02:02:41 -0000 @@ -26,15 +26,26 @@ #include "includes.h" #ifdef HAVE_LIBIAF +#include #ifdef HAVE_CRYPT_H -#include +# include #endif +#include +#include +#include +#include +#include + +#include "xmalloc.h" #include "packet.h" #include "buffer.h" +#include "auth-options.h" #include "log.h" #include "servconf.h" +#include "key.h" +#include "hostfile.h" #include "auth.h" -#include "auth-options.h" +#include "ssh.h" int nischeck(char *); From flavien-ssh at lebarbe.net Thu Aug 31 11:20:03 2006 From: flavien-ssh at lebarbe.net (Flavien Lebarbe) Date: Thu, 31 Aug 2006 03:20:03 +0200 Subject: Testing for the 4.4p1 release In-Reply-To: References: Message-ID: <20060831012003.GA10947@lebarbe.net> Hi, "make tests" fails in dynamic-forward.sh on FreeBSD here. I just retried 4.3p2, "make tests" runs ok with this version, including dynamic-forward.sh Hope this helps, Flavien. --- System : FreeBSD 5.4-STABLE i386 Version tested : openssh-SNAP-20060830.tar.gz GCC version : gcc (GCC) 3.4.2 [FreeBSD] 20040728 $ ./configure --without-zlib-version-check && make tests [...] OpenSSH has been configured with the following options: User binaries: /usr/local/bin System binaries: /usr/local/sbin Configuration files: /usr/local/etc Askpass program: /usr/local/libexec/ssh-askpass Manual pages: /usr/local/share/man/manX PID file: /var/run Privilege separation chroot path: /var/empty At runtime, sshd will use the path defined in /etc/login.conf Make sure the path to scp is present, otherwise scp will not work Manpage format: doc PAM support: no KerberosV support: no SELinux support: no Smartcard support: no S/KEY support: no TCP Wrappers support: no MD5 password support: no libedit support: no IP address in $DISPLAY hack: no Translate v4 in v6 hack: no BSD Auth support: no Random number source: OpenSSL internal ONLY Host: i386-unknown-freebsd5.4 Compiler: gcc Compiler flags: -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare Preprocessor flags: Linker flags: Libraries: -lcrypto -lutil -lz -lcrypt [...] run test sftp-glob.sh ... sftp glob: ls file sftp glob: ls dir ok sftp glob run test reconfigure.sh ... ok simple connect after reconfigure run test dynamic-forward.sh ... nc: unexpected reply size 31 (expected 10) ssh_exchange_identification: Connection closed by remote host cmp: EOF on /usr/home/flavien/src/openssh/regress/ls.copy corrupted copy of /bin/ls nc: unexpected reply size 31 (expected 10) ssh_exchange_identification: Connection closed by remote host cmp: EOF on /usr/home/flavien/src/openssh/regress/ls.copy corrupted copy of /bin/ls failed dynamic forwarding *** Error code 1 Stop in /usr/home/flavien/src/openssh/regress. *** Error code 1 From dtucker at zip.com.au Thu Aug 31 13:26:48 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 31 Aug 2006 13:26:48 +1000 Subject: Testing for the 4.4p1 release In-Reply-To: <20060831012003.GA10947@lebarbe.net> References: <20060831012003.GA10947@lebarbe.net> Message-ID: <44F656F8.8050007@zip.com.au> Flavien Lebarbe wrote: > "make tests" fails in dynamic-forward.sh on FreeBSD here. I just > retried 4.3p2, "make tests" runs ok with this version, including > dynamic-forward.sh Thanks for testing. > nc: unexpected reply size 31 (expected 10) > ssh_exchange_identification: Connection closed by remote host > cmp: EOF on /usr/home/flavien/src/openssh/regress/ls.copy > corrupted copy of /bin/ls > nc: unexpected reply size 31 (expected 10) I suspect that's a bug in your netcat not handling the SOCKS header and data arriving in the same packet. This was fixed in OpenBSD's nc a while back: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/nc/socks.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.12&f=u -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From pekkas at netcore.fi Thu Aug 31 15:50:04 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 31 Aug 2006 08:50:04 +0300 (EEST) Subject: Testing for the 4.4p1 release In-Reply-To: References: Message-ID: On Wed, 30 Aug 2006, Damien Miller wrote: > Running the regression tests supplied with Portable does not require > installation, just run: > > $ ./configure && make tests > > Testing on suitable non-production systems is also appreciated. Please send > reports of success or failure to openssh-unix-dev at mindrot.org, including > details of your platform, compiler and configure options. On RHL73 with gcc 2.96, 'make tests' doesn't finish and appears to get stuck (strace shows the process is in wait()). There were a number of compilation warnings. The ones coming from ciphers and macs appear to be old, but these are new and at least implicit decls should be easily fixable: warning: __nonnull__' attribute directive ignored (50+ times) uidswap.c: In function Permanently_drop_suid': uidswap.c:142: warning: implicit declaration of function Setresuid' uidswap.c: In function Permanently_set_uid': uidswap.c:224: warning: implicit declaration of function Setresgid' md5crypt.c: In function To64': md5crypt.c:31: warning: implicit declaration of function Memset' md5crypt.c: In function s_md5_salt': md5crypt.c:43: warning: implicit declaration of function Strncmp' md5crypt.c:43: warning: implicit declaration of function Strlen' md5crypt.c: In function Md5_crypt': md5crypt.c:73: warning: implicit declaration of function Memcpy' OpenSSH has been configured with the following options: User binaries: /usr/local/bin System binaries: /usr/local/sbin Configuration files: /usr/local/etc Askpass program: /usr/local/libexec/ssh-askpass Manual pages: /usr/local/share/man/manX PID file: /var/run Privilege separation chroot path: /var/empty sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin Manpage format: doc PAM support: yes KerberosV support: no SELinux support: no Smartcard support: no S/KEY support: no TCP Wrappers support: yes MD5 password support: yes libedit support: no IP address in $DISPLAY hack: no Translate v4 in v6 hack: yes BSD Auth support: no Random number source: OpenSSL internal ONLY Host: i686-pc-linux-gnu Compiler: gcc Compiler flags: -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -std=gnu99 Preprocessor flags: Linker flags: Libraries: -lresolv -lcrypto -lutil -lz -lnsl -lcrypt The last messages are: ... run test dynamic-forward.sh ... skipped (no suitable ProxyCommand found) run test forwarding.sh ... bind: Address already in use Waiting for forwarded connections to terminate... The following connections are open: #9 direct-tcpip: listening port 3322 for 127.0.0.1 port 3372, connect from 127.0.0.1 port 44310 (t4 r17 i0/0 o0/0 fd 18/18 cfd -1) #10 direct-tcpip: listening port 3372 for 127.0.0.1 port 3321, connect from 127.0.0.1 port 44311 (t4 r18 i0/0 o0/0 fd 19/19 cfd -1) #11 direct-tcpip: listening port 3321 for 127.0.0.1 port 3371, connect from 127.0.0.1 port 44312 (t4 r19 i0/0 o0/0 fd 20/20 cfd -1) #12 direct-tcpip: listening port 3371 for 127.0.0.1 port 3320, connect from 127.0.0.1 port 44313 (t4 r20 i0/0 o0/0 fd 21/21 cfd -1) #13 direct-tcpip: listening port 3320 for 127.0.0.1 port 3370, connect from 127.0.0.1 port 44314 (t4 r21 i0/0 o0/0 fd 22/22 cfd -1) #14 direct-tcpip: listening port 3370 for 127.0.0.1 port 3312, connect from 127.0.0.1 port 44315 (t4 r22 i0/0 o0/0 fd 23/23 cfd -1) #15 direct-tcpip: listening port 3312 for 127.0.0.1 port 3362, connect from 127.0.0.1 port 44316 (t4 r23 i0/0 o0/0 fd 24/24 cfd -1) #16 direct-tcpip: listening port 3362 for 127.0.0.1 port 3311, connect from 127.0.0.1 port 44317 (t4 r24 i0/0 o0/0 fd 25/25 cfd -1) #17 direct-tcpip: listening port 3311 for 127.0.0.1 port 3361, connect from 127.0.0.1 port 44318 (t4 r25 i0/0 o0/0 fd 26/26 cfd -1) #18 direct-tcpip: listening port 3361 for 127.0.0.1 port 3310, connect from 127.0.0.1 port 44319 (t4 r26 i0/0 o0/0 fd 27/27 cfd -1) [[ almost 10 minute timeout ]] ssh_exchange_identification: Connection closed by remote host cmp: EOF on /home/pekkas/op/openssh/regress/ls.copy corrupted copy of /bin/ls bind: Address already in use [[ about 5 minute timeout ]] failed local and remote forwarding make[1]: *** [t-exec] Error 1 make[1]: Leaving directory `/home/pekkas/op/openssh/regress' make: *** [tests] Error 2 I suspect (but didn't check) bind() errors may be due to the way mapped addresses affect bind() (I'm also using v6). HTH, -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From ponomarew at gmail.com Thu Aug 31 18:49:59 2006 From: ponomarew at gmail.com (Kirill Ponomarew) Date: Thu, 31 Aug 2006 10:49:59 +0200 Subject: Testing for the 4.4p1 release In-Reply-To: <44F656F8.8050007@zip.com.au> References: <20060831012003.GA10947@lebarbe.net> <44F656F8.8050007@zip.com.au> Message-ID: On 8/31/06, Darren Tucker wrote: > Flavien Lebarbe wrote: > > "make tests" fails in dynamic-forward.sh on FreeBSD here. I just > > retried 4.3p2, "make tests" runs ok with this version, including > > dynamic-forward.sh > > Thanks for testing. > > > nc: unexpected reply size 31 (expected 10) > > ssh_exchange_identification: Connection closed by remote host > > cmp: EOF on /usr/home/flavien/src/openssh/regress/ls.copy > > corrupted copy of /bin/ls > > nc: unexpected reply size 31 (expected 10) > > I suspect that's a bug in your netcat not handling the SOCKS header and > data arriving in the same packet. This was fixed in OpenBSD's nc a > while back: Should be fixed now in RELENG_5, RELENG_6. Flavien could you please update to RELENG_5 and test it again ? -Kirill From stuge-openssh-unix-dev at cdy.org Thu Aug 31 19:01:56 2006 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 31 Aug 2006 11:01:56 +0200 Subject: Testing for the 4.4p1 release In-Reply-To: References: Message-ID: <20060831090156.23216.qmail@cdy.org> On Wed, Aug 30, 2006 at 11:41:53PM +1000, Damien Miller wrote: > actively test snapshots or CVS and report back to the mailing list. CVS 060831 10:38 UTC+2 gcc version 4.1.1 (Gentoo 4.1.1), OpenSSL 0.9.7j OpenSSH has been configured with the following options: User binaries: /usr/local/bin System binaries: /usr/local/sbin Configuration files: /usr/local/etc Askpass program: /usr/local/libexec/ssh-askpass Manual pages: /usr/local/share/man/manX PID file: /var/run Privilege separation chroot path: /var/empty sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin Manpage format: doc PAM support: no OSF SIA support: no KerberosV support: no SELinux support: no Smartcard support: no S/KEY support: no TCP Wrappers support: no MD5 password support: no libedit support: no Solaris process contract support: no IP address in $DISPLAY hack: no Translate v4 in v6 hack: yes BSD Auth support: no Random number source: OpenSSL internal ONLY Host: i686-pc-linux-gnu Compiler: gcc Compiler flags: -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wno-pointer-sign -std=gnu99 Preprocessor flags: Linker flags: Libraries: -lresolv -lcrypto -lutil -lz -lnsl -lcrypt Builds with warnings: servconf.c: In function 'process_server_config_line': servconf.c:980: warning: dereferencing type-punned pointer will break strict-aliasing rules servconf.c:991: warning: dereferencing type-punned pointer will break strict-aliasing rules I don't know C well enough to say what the best solution to this is. SyslogFacility and LogLevel are enums, ServerOptions.log_facility and .log_level are defined as SyslogFacility and LogLevel respectively. The above lines read (int *) &options->log_facility and (int *) &options->log_level. sftp.c: In function 'parse_dispatch_command': sftp.c:1028: warning: 'n_arg' may be used uninitialized in this function sftp.c:1027: warning: 'iflag' may be used uninitialized in this function sftp.c:1027: warning: 'lflag' may be used uninitialized in this function sftp.c:1027: warning: 'pflag' may be used uninitialized in this function parse_args() sets these, but can return with error before doing so. iflag is used to set err_abort=0 before the return code of parse_args() is checked. Attached patch initializes the above variables. All tests ok. //Peter -------------- next part -------------- --- sftp.c.orig 2006-08-31 10:44:33.000000000 +0200 +++ sftp.c 2006-08-31 10:44:57.000000000 +0200 @@ -1024,8 +1024,8 @@ int err_abort) { char *path1, *path2, *tmp; - int pflag, lflag, iflag, cmdnum, i; - unsigned long n_arg; + int pflag = 0, lflag = 0, iflag = 0, cmdnum, i; + unsigned long n_arg = 0; Attrib a, *aa; char path_buf[MAXPATHLEN]; int err = 0; From kerry at crypt.gen.nz Thu Aug 31 19:49:34 2006 From: kerry at crypt.gen.nz (Kerry Thompson) Date: Thu, 31 Aug 2006 21:49:34 +1200 Subject: Testing for the 4.4p1 release In-Reply-To: References: Message-ID: <44F6B0AE.8050500@crypt.gen.nz> Fedora Core 5, with MIT Kerberos5 1.5.1 builds and make tests OK. Same compiler warnings as Peter Stuge reports with Debian. I haven't fully tested kerberos auth & tickets yet. OpenSSH has been configured with the following options: User binaries: /usr/local/bin System binaries: /usr/local/sbin Configuration files: /usr/local/etc Askpass program: /usr/local/libexec/ssh-askpass Manual pages: /usr/local/share/man/manX PID file: /var/run Privilege separation chroot path: /var/empty sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin Manpage format: doc PAM support: no KerberosV support: yes SELinux support: no Smartcard support: no S/KEY support: no TCP Wrappers support: no MD5 password support: no libedit support: no IP address in $DISPLAY hack: no Translate v4 in v6 hack: yes BSD Auth support: no Random number source: OpenSSL internal ONLY Host: i686-pc-linux-gnu Compiler: gcc Compiler flags: -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wno-pointer-sign -std=gnu99 Preprocessor flags: -I/opt/kerberos/krb5-1.5.1/include -I/opt/kerberos/krb5-1.5.1/include/gssapi Linker flags: -L/opt/kerberos/krb5-1.5.1/lib Libraries: -lresolv -lcrypto -lutil -lz -lnsl -lcrypt -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err From santhi.amirta at gmail.com Thu Aug 31 21:59:27 2006 From: santhi.amirta at gmail.com (santhi) Date: Thu, 31 Aug 2006 17:29:27 +0530 Subject: Testing for the 4.4p1 release References: Message-ID: <021c01c6ccf4$f6d99920$2d0110ac@samco> Hi All, Test results in HP-UX Platforms: Platform : --------- HP-UX 11.00 PA-RISC HP-UX 11.11 PA-RISC HP-UX 11.23 IPF Config options: --------------- ./configure --prefix=${SSHPATH} \ --with-pam \ --with-ssl-dir=${SSLPATH} \ --with-tcp-wrappers=${TCPWRAPPATH} \ --with-zlib=${ZLIBPATH} \ --with-kerberos5 \ --with-rand-helper \ --with-md5-passwords \ --with-4in6 \ --with-audit=debug The openssh-SNAP-20060830 configures successfully. But build failed with the following error: /usr/ccs/bin/ld: Unsatisfied symbols: ntohl (first referenced in sshconnect.o) (code) ntohs (first referenced in ssh.o) (code) htonl (first referenced in sshconnect.o) (code) htons (first referenced in openbsd-compat//libopenbsd-compat.a(rresvport.o)) (code) *** Error exit code 1 Stop. Problem Description: ---------------------- * The ntohl, ntohs, htonl, htons routines are defined as macros instead of functions in , linker raises "functions" not found error. Fix: ----- Including the in includes.h file may fix this problem Thanks, Santhi. ----- Original Message ----- From: "Damien Miller" To: Sent: Wednesday, August 30, 2006 7:11 PM Subject: Testing for the 4.4p1 release > Hi, > > The 4.4p1 release is approaching now, so we are now asking people to > actively test snapshots or CVS and report back to the mailing list. > > Snapshots are available from http://www.mindrot.org/openssh_snap or > from any of the mirrors listed on http://www.openssh.org/portable.html > The latter page also includes instructions for checking out portable > OpenSSH via anonymous CVS. > > This release contains many bugfixes and feature improvements. Here > are some highlights: > > - Implemented conditional configuration in sshd_config(5) using the > "Match" directive. This allows some configuration options to be > selectively overridden if specific criteria (based on user, group, > hostname and/or address) are met. So far a useful subset of post- > authentication options are supported and more are expected to be > added in future releases. > - Added a "ForceCommand" directive to sshd_config(5). Similar to the > command="..." option accepted in ~/.ssh/authorized_keys, this forces > the execution of the specified command regardless of what the user > requested. This is very useful in conjunction with the new "Match" > option. > - Add a "PermitOpen" directive to sshd_config(5). This mirrors the > permitopen="..." authorized_keys option, allowing fine-grained > control over the port-forwardings that a user is allowed to > establish. > - Add optional logging of transactions to sftp-server(8). > - ssh(1) will now record port numbers for hosts stored in > ~/.ssh/authorized_keys when a non-standard port has been requested. > - Add an "ExitOnForwardFailure" options to cause ssh(1) to exit (with > a non-zero exit code) when requested port forwardings could not be > established. > - Extend the sshd_config(5) "SubSystem" directive to allow the > specification of commandline arguments. > - Add optional support for SELinux, controlled using the --with-selinux > configure option (experimental) > - Add optional support for Solaris process contracts, enabled using the > --with-solaris-contracts configure option (experimental) > - Add support for Diffie-Hellman group exchange key agreement with a > final hash of SHA256. > - Fixed a lot of bugs. See > http://bugzilla.mindrot.org/show_bug.cgi?id=1155 for an incomplete > list (more in the ChangeLog) > - Lots of manpage fixes and improvements > - Many code cleanups, including: > - Switching to safer memory allocation functions that avoid integer > overflows when allocating arrays > - Cleanups of header file usage (ongoing) > - Fixes to leaks reported by the Coverity static analysis tool > > Running the regression tests supplied with Portable does not require > installation, just run: > > $ ./configure && make tests > > Testing on suitable non-production systems is also appreciated. Please send > reports of success or failure to openssh-unix-dev at mindrot.org, including > details of your platform, compiler and configure options. > > Thanks, > Damien Miller > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >