From dan at D00M.integrate.com.ru Sat May 1 00:28:41 2004 From: dan at D00M.integrate.com.ru (Dan Yefimov) Date: Fri, 30 Apr 2004 18:28:41 +0400 (MSD) Subject: openssh continues to process dash arguements after hostname In-Reply-To: <6EB9C81B-9A73-11D8-8807-0003934F6406@mac.com> Message-ID: On 29 Apr 2004, at 23:55:57, John Davidorff Pell wrote: > Who? > Me, for example, and many other people I'm familiar with. > > On 27 Apr 2004, at 18:39, Markus Friedl wrote: > > > too many people are using: > > > > $ ssh host -l user > > -- Sincerely Your, Dan. From pspencer at fields.utoronto.ca Sat May 1 01:12:26 2004 From: pspencer at fields.utoronto.ca (Philip Spencer) Date: Fri, 30 Apr 2004 11:12:26 -0400 (EDT) Subject: openssh continues to process dash arguements after hostname In-Reply-To: Message-ID: It is also common to alias "ssh host" to a single command for convenience, e.g. alias foo "ssh somehost" so one can log in to host somehost by simply typing foo To log in as another user one then naturally types foo -l user which translates into "ssh somehost -l user". Besides thinking of "ssh host" as a single unit, it is also common to think of the hostname as being like an argument to ssh, as distinct from the command to be executed, so based on the principle that arguments can be entered in any order one expects that (or at least I expect that) "ssh -l user host command" and "ssh host -l user command" should be equivalent, just as "ssh -x -C ..." and "ssh -C -x ..." are equivalent. These two psychological habits -- thinking of "ssh host" as a single unit, and/or thinking of "host" as an argument to ssh which can be interchanged with the other arguments -- are in my opinion so common that for openssh to do anything other than it does now would break things for many, many people. Just an opinion from a lurker on the list... --------------------------------------------+------------------------------- Philip Spencer pspencer at fields.utoronto.ca | Director of Computing Services Room 336 (416)-348-9710 ext3036 | The Fields Institute for 222 College St, Toronto ON M5T 3J1 Canada | Research in Mathematical Sciences On Fri, 30 Apr 2004, Dan Yefimov wrote: > On 29 Apr 2004, at 23:55:57, John Davidorff Pell wrote: > > > Who? > > > Me, for example, and many other people I'm familiar with. > > > > > On 27 Apr 2004, at 18:39, Markus Friedl wrote: > > > > > too many people are using: > > > > > > $ ssh host -l user From tim at multitalents.net Sat May 1 06:12:35 2004 From: tim at multitalents.net (Tim Rice) Date: Fri, 30 Apr 2004 13:12:35 -0700 (PDT) Subject: buildpkg.sh enhancements Message-ID: I've made some changes to buildpkg.sh to make it easier for package builders to add their local changes. I'd like people that use buildpkg.sh to test and comment on these changes before I commit them to CVS. None of the defaults have changed. Some of the patch is is just moving chunks of code to a different location to make some of the enhancements work. Some things you may find usefull: New variables you can put in your config.local REMOVE_FAKE_ROOT_WHEN_DONE Remove fake root dir when done. SYSVINITSTART System V init start level SYSVINITSTOPT System V init start level POST_MAKE_INSTALL_FIXES Name of script to run after "make install" POST_PROTOTYPE_EDITS Name of script to run after prototype is made PKG_PREINSTALL_LOCAL Local preinstall additions PKG_POSTINSTALL_LOCAL Local postinstall additions PKG_PREREMOVE_LOCAL Local preremove additions PKG_POSTREMOVE_LOCAL Local postremove additions PKG_REQUEST_LOCAL Local request additions I've moved OPENSSHD_IN up so it can be overriden by your config.local $srcdir is now available to scripts Start to add support for OpenSerever. (not done yet) I've always intended for this script to work on any system that has the pkgadd/pkgrm tools. We now build an empty depend file that you can add to. We now build a postremove file. If you link buildpkg.sh to justpkg.sh you can use justpkg.sh to do a pkgmk, pkgtrans from the bits already installed instead of removing $FAKE_ROOT and starting from scratch. Enjoy. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- buildpkg.sh 2004-01-22 16:10:03.000000000 -0800 +++ /usr/local/src/networking/openssh-3.8/buildpkg.sh 2004-04-30 11:09:40.232352018 -0700 @@ -11,6 +11,8 @@ # Options for building the package # You can create a config.local with your customized options # +REMOVE_FAKE_ROOT_WHEN_DONE=yes +# # uncommenting TEST_DIR and using # configure --prefix=/var/tmp --with-privsep-path=/var/tmp/empty # and @@ -27,6 +29,22 @@ #PERMIT_ROOT_LOGIN=no #X11_FORWARDING=yes #USR_LOCAL_IS_SYMLINK=yes +# System V init run levels +SYSVINITSTART=S98 +SYSVINITSTOPT=K30 +# We will source these if they exist +POST_MAKE_INSTALL_FIXES=./pkg_post_make_install_fixes.sh +POST_PROTOTYPE_EDITS=./pkg_post_prototype_edit.sh +# We'll be one level deeper looking for these +PKG_PREINSTALL_LOCAL=../pkg-preinstall.local +PKG_POSTINSTALL_LOCAL=../pkg-postinstall.local +PKG_PREREMOVE_LOCAL=../pkg-preremove.local +PKG_POSTREMOVE_LOCAL=../pkg-postremove.local +PKG_REQUEST_LOCAL=../pkg-request.local +# end of sourced files +# +OPENSSHD_IN=`dirname $0`/opensshd.in +# # list of system directories we do NOT want to change owner/group/perms # when installing our package SYSTEM_DIR="/etc \ @@ -63,6 +81,10 @@ # We may need to build as root so we make sure PATH is set up # only set the path if it's not set already +[ -d /opt/bin ] && { + echo $PATH | grep ":/opt/bin" > /dev/null 2>&1 + [ $? -ne 0 ] && PATH=$PATH:/opt/bin +} [ -d /usr/local/bin ] && { echo $PATH | grep ":/usr/local/bin" > /dev/null 2>&1 [ $? -ne 0 ] && PATH=$PATH:/usr/local/bin @@ -82,22 +104,11 @@ # we will look for config.local to override the above options [ -s ./config.local ] && . ./config.local -## Start by faking root install -echo "Faking root install..." START=`pwd` -OPENSSHD_IN=`dirname $0`/opensshd.in FAKE_ROOT=$START/package -[ -d $FAKE_ROOT ] && rm -fr $FAKE_ROOT -mkdir $FAKE_ROOT -${MAKE} install-nokeys DESTDIR=$FAKE_ROOT -if [ $? -gt 0 ] -then - echo "Fake root install failed, stopping." - exit 1 -fi ## Fill in some details, like prefix and sysconfdir -for confvar in prefix exec_prefix bindir sbindir libexecdir datadir mandir sysconfdir piddir +for confvar in prefix exec_prefix bindir sbindir libexecdir datadir mandir sysconfdir piddir srcdir do eval $confvar=`grep "^$confvar=" Makefile | cut -d = -f 2` done @@ -118,6 +129,10 @@ ## Extract common info requires for the 'info' part of the package. VERSION=`./ssh -V 2>&1 | sed -e 's/,.*//'` +ARCH=`uname -m` +DEF_MSG="\n" +OS_VER=`uname -v` +SCRIPT_SHELL=/sbin/sh UNAME_S=`uname -s` case ${UNAME_S} in SunOS) UNAME_S=Solaris @@ -125,10 +140,25 @@ RCS_D=yes DEF_MSG="(default: n)" ;; - *) ARCH=`uname -m` - DEF_MSG="\n" ;; + SCO_SV) UNAME_S=OpenServer + OS_VER=`uname -X | grep Release | sed -e 's/^Rel.*3.2v//'` + SCRIPT_SHELL=/bin/sh + ;; esac +case `basename $0` in + buildpkg.sh) +## Start by faking root install +echo "Faking root install..." +[ -d $FAKE_ROOT ] && rm -fr $FAKE_ROOT +mkdir $FAKE_ROOT +${MAKE} install-nokeys DESTDIR=$FAKE_ROOT +if [ $? -gt 0 ] +then + echo "Fake root install failed, stopping." + exit 1 +fi + ## Setup our run level stuff while we are at it. mkdir -p $FAKE_ROOT${TEST_DIR}/etc/init.d @@ -155,6 +185,9 @@ [ -f $FAKE_ROOT/${sysconfdir}/ssh_prng_cmds ] && \ mv $FAKE_ROOT/${sysconfdir}/ssh_prng_cmds $FAKE_ROOT/${sysconfdir}/ssh_prng_cmds.default +# local tweeks here +[ -s "${POST_MAKE_INSTALL_FIXES}" ] && . ${POST_MAKE_INSTALL_FIXES} + cd $FAKE_ROOT ## Ok, this is outright wrong, but it will work. I'm tired of pkgmk @@ -175,12 +208,35 @@ CATEGORY="Security,application" BASEDIR=/ CLASSES="none" +PSTAMP="${UNAME_S} ${OS_VER} ${ARCH} `date '+%d%b%Y %H:%M'`" +_EOF + +## Build empty depend file that may get updated by $POST_PROTOTYPE_EDITS +echo "Building depend file..." +touch depend + +## Build space file +echo "Building space file..." +cat > space << _EOF +# extra space required by start/stop links added by installf in postinstall +$TEST_DIR/etc/rc0.d/${SYSVINITSTOPT}${SYSVINIT_NAME} 0 1 +$TEST_DIR/etc/rc1.d/${SYSVINITSTOPT}${SYSVINIT_NAME} 0 1 +$TEST_DIR/etc/rc2.d/${SYSVINITSTART}${SYSVINIT_NAME} 0 1 _EOF +[ "$RCS_D" = yes ] && \ +echo "$TEST_DIR/etc/rcS.d/${SYSVINITSTOPT}${SYSVINIT_NAME} 0 1" >> space ## Build preinstall file echo "Building preinstall file..." cat > preinstall << _EOF -#! /sbin/sh +#! ${SCRIPT_SHELL} +# +_EOF + +# local preinstall changes here +[ -s "${PKG_PREINSTALL_LOCAL}" ] && . ${PKG_PREINSTALL_LOCAL} + +cat >> preinstall << _EOF # [ "\${PRE_INS_STOP}" = "yes" ] && ${TEST_DIR}/etc/init.d/${SYSVINIT_NAME} stop exit 0 @@ -189,7 +245,7 @@ ## Build postinstall file echo "Building postinstall file..." cat > postinstall << _EOF -#! /sbin/sh +#! ${SCRIPT_SHELL} # [ -f \${PKG_INSTALL_ROOT}${sysconfdir}/ssh_config ] || \\ cp -p \${PKG_INSTALL_ROOT}${sysconfdir}/ssh_config.default \\ @@ -214,21 +270,27 @@ if [ "\${USE_SYM_LINKS}" = yes ] then [ "$RCS_D" = yes ] && \ -installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rcS.d/K30${SYSVINIT_NAME}=../init.d/${SYSVINIT_NAME} s - installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rc0.d/K30${SYSVINIT_NAME}=../init.d/${SYSVINIT_NAME} s - installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rc1.d/K30${SYSVINIT_NAME}=../init.d/${SYSVINIT_NAME} s - installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rc2.d/S98${SYSVINIT_NAME}=../init.d/${SYSVINIT_NAME} s +installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rcS.d/${SYSVINITSTOPT}${SYSVINIT_NAME}=../init.d/${SYSVINIT_NAME} s + installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rc0.d/${SYSVINITSTOPT}${SYSVINIT_NAME}=../init.d/${SYSVINIT_NAME} s + installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rc1.d/${SYSVINITSTOPT}${SYSVINIT_NAME}=../init.d/${SYSVINIT_NAME} s + installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rc2.d/${SYSVINITSTART}${SYSVINIT_NAME}=../init.d/${SYSVINIT_NAME} s else [ "$RCS_D" = yes ] && \ -installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rcS.d/K30${SYSVINIT_NAME}=$TEST_DIR/etc/init.d/${SYSVINIT_NAME} l - installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rc0.d/K30${SYSVINIT_NAME}=$TEST_DIR/etc/init.d/${SYSVINIT_NAME} l - installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rc1.d/K30${SYSVINIT_NAME}=$TEST_DIR/etc/init.d/${SYSVINIT_NAME} l - installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rc2.d/S98${SYSVINIT_NAME}=$TEST_DIR/etc/init.d/${SYSVINIT_NAME} l +installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rcS.d/${SYSVINITSTOPT}${SYSVINIT_NAME}=$TEST_DIR/etc/init.d/${SYSVINIT_NAME} l + installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rc0.d/${SYSVINITSTOPT}${SYSVINIT_NAME}=$TEST_DIR/etc/init.d/${SYSVINIT_NAME} l + installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rc1.d/${SYSVINITSTOPT}${SYSVINIT_NAME}=$TEST_DIR/etc/init.d/${SYSVINIT_NAME} l + installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rc2.d/${SYSVINITSTART}${SYSVINIT_NAME}=$TEST_DIR/etc/init.d/${SYSVINIT_NAME} l fi # If piddir doesn't exist we add it. (Ie. --with-pid-dir=/var/opt/ssh) [ -d $piddir ] || installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR$piddir d 755 root sys +_EOF + +# local postinstall changes here +[ -s "${PKG_POSTINSTALL_LOCAL}" ] && . ${PKG_POSTINSTALL_LOCAL} + +cat >> postinstall << _EOF installf -f ${PKGNAME} # Use chroot to handle PKG_INSTALL_ROOT @@ -290,9 +352,29 @@ ## Build preremove file echo "Building preremove file..." cat > preremove << _EOF -#! /sbin/sh +#! ${SCRIPT_SHELL} # ${TEST_DIR}/etc/init.d/${SYSVINIT_NAME} stop +_EOF + +# local preremove changes here +[ -s "${PKG_PREREMOVE_LOCAL}" ] && . ${PKG_PREREMOVE_LOCAL} + +cat >> preremove << _EOF +exit 0 +_EOF + +## Build postremove file +echo "Building postremove file..." +cat > postremove << _EOF +#! ${SCRIPT_SHELL} +# +_EOF + +# local postremove changes here +[ -s "${PKG_POSTREMOVE_LOCAL}" ] && . ${PKG_POSTREMOVE_LOCAL} + +cat >> postremove << _EOF exit 0 _EOF @@ -300,6 +382,59 @@ echo "Building request file..." cat > request << _EOF trap 'exit 3' 15 + +_EOF + +[ -x /usr/bin/ckyorn ] || cat >> request << _EOF + +ckyorn() { +# for some strange reason OpenServer has no ckyorn +# We build a striped down version here + +DEFAULT=n +PROMPT="Yes or No [yes,no,?,quit]" +HELP_PROMPT=" Enter y or yes if your answer is yes; n or no if your answer is no." +USAGE="usage: ckyorn [options] +where options may include: + -d default + -h help + -p prompt +" + +if [ \$# != 0 ] +then + while getopts d:p:h: c + do + case \$c in + h) HELP_PROMPT="\$OPTARG" ;; + d) DEFAULT=\$OPTARG ;; + p) PROMPT=\$OPTARG ;; + \\?) echo "\$USAGE" 1>&2 + exit 1 ;; + esac + done + shift \`expr \$OPTIND - 1\` +fi + +while true +do + echo "\${PROMPT}\\c " 1>&2 + read key + [ -z "\$key" ] && key=\$DEFAULT + case \$key in + [n,N]|[n,N][o,O]|[y,Y]|[y,Y][e,E][s,S]) echo "\${key}\\c" + exit 0 ;; + \\?) echo \$HELP_PROMPT 1>&2 ;; + q|quit) echo "q\\c" 1>&2 + exit 3 ;; + esac +done + +} + +_EOF + +cat >> request << _EOF USE_SYM_LINKS=no PRE_INS_STOP=no POST_INS_START=no @@ -338,26 +473,23 @@ PRE_INS_STOP='\$PRE_INS_STOP' POST_INS_START='\$POST_INS_START' ! -exit 0 _EOF -## Build space file -echo "Building space file..." -cat > space << _EOF -# extra space required by start/stop links added by installf in postinstall -$TEST_DIR/etc/rc0.d/K30${SYSVINIT_NAME} 0 1 -$TEST_DIR/etc/rc1.d/K30${SYSVINIT_NAME} 0 1 -$TEST_DIR/etc/rc2.d/S98${SYSVINIT_NAME} 0 1 +# local request changes here +[ -s "${PKG_REQUEST_LOCAL}" ] && . ${PKG_REQUEST_LOCAL} + +cat >> request << _EOF +exit 0 + _EOF -[ "$RCS_D" = yes ] && \ -echo "$TEST_DIR/etc/rcS.d/K30${SYSVINIT_NAME} 0 1" >> space ## Next Build our prototype echo "Building prototype file..." cat >mk-proto.awk << _EOF - BEGIN { print "i pkginfo"; print "i preinstall"; \\ - print "i postinstall"; print "i preremove"; \\ + BEGIN { print "i pkginfo"; print "i depend"; \\ + print "i preinstall"; print "i postinstall"; \\ + print "i preremove"; print "i postremove"; \\ print "i request"; print "i space"; \\ split("$SYSTEM_DIR",sys_files); } { @@ -378,9 +510,27 @@ } ## Step back a directory and now build the package. -echo "Building package.." cd .. +# local prototype tweeks here +[ -s "${POST_PROTOTYPE_EDITS}" ] && . ${POST_PROTOTYPE_EDITS} + +echo "Building package.." pkgmk -d ${FAKE_ROOT} -f $FAKE_ROOT/prototype -o -echo | pkgtrans -os ${FAKE_ROOT} ${START}/$PKGNAME-$UNAME_S-$ARCH-$VERSION.pkg -rm -rf $FAKE_ROOT +echo | pkgtrans -os ${FAKE_ROOT} ${START}/$PKGNAME-$VERSION-$UNAME_S-$ARCH.pkg + ;; + + justpkg.sh) +rm -fr ${FAKE_ROOT}/${PKGNAME} +grep -v "^PSTAMP=" $FAKE_ROOT/pkginfo > $$tmp +mv $$tmp $FAKE_ROOT/pkginfo +cat >> $FAKE_ROOT/pkginfo << _EOF +PSTAMP="${UNAME_S} ${OS_VER} ${ARCH} `date '+%d%b%Y %H:%M'`" +_EOF +pkgmk -d ${FAKE_ROOT} -f $FAKE_ROOT/prototype -o +echo | pkgtrans -os ${FAKE_ROOT} ${START}/$PKGNAME-$VERSION-$UNAME_S-$ARCH.pkg + ;; + +esac + +[ "${REMOVE_FAKE_ROOT_WHEN_DONE}" = yes ] && rm -rf $FAKE_ROOT From ldblist at ldb-jab.org Sat May 1 12:26:47 2004 From: ldblist at ldb-jab.org (LDB) Date: Fri, 30 Apr 2004 22:26:47 -0400 Subject: Subscription Message-ID: <40930AE7.4060700@ldb-jab.org> Is this list closed? I cannot seem to get a response from the automated mailer. Thanks, LDB From dank at kegel.com Sun May 2 17:41:37 2004 From: dank at kegel.com (Dan Kegel) Date: Sun, 02 May 2004 00:41:37 -0700 Subject: Connection caching? Message-ID: <4094A631.3050609@kegel.com> Hey all, on the distcc mailing list, a thread about load balancing got a bit out of hand, and we started thinking about moving fsh-like connection caching into ssh itself to get rid of the overhead of starting up the python interpreter to run rsh. (Interestingly, mit's "rex", described at http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-884.pdf, considers connection caching one of the advantages it has over ssh.) Here are a few ideas, not quite boiled down to a proposal yet. You'd run a local agent (maybe not ssh-agent, since that deals with keys and wants to stay svelte, but in any case something that is started just like ssh-agent and leaves its socket name and pid in the environment) which could keep connections open for a while to recently accessed machines so that new sessions could be opened instantly instead of requiring new cryptographic handshaking. (I suppose perhaps you could cache the result of the handshake rather than caching the actual connection, kind of like ssl does, but that doesn't sound like the ssh way of doing things.) If ssh noticed the connection cache was there (i.e. its variable is set in the environment), it would tell the cache where it wanted to connect to, and the cache would pass back an already- connected fd ready to go. The tricky part is, how would the client pass back the fd when it's finished with the command? Simplest would be for the client to just close the connection. Then the connection cache would be more like a connection prefetcher; it would have to start connections before being asked for them. Alternately, if all traffic was actually sent via the local agent, it could just keep the same TCP connection open to the remote host no matter how many streams were active, and just multiplex them all. That means one extra copy of the data, but it does get rid of the need for any psychic powers on the part of the local agent. And (bonus!) it kind of means that all the smarts are in the local agent, and apps can just talk directly to it instead of forking an ssh (or loading an ssh library). It might also be easy for this agent to do simple load balancing, i.e. if the hostname given is the name of a cluster of ssh servers rather than a real server, it should give the command to the least loaded of the servers. That would come in handy for distcc, and would keep people from trying to use distcc for a general purpose job distributor :-) OK, glad I got that off my chest. Maybe if I sleep on it, I'll realize which way to go with it. - Dan From djm at mindrot.org Sun May 2 19:13:46 2004 From: djm at mindrot.org (Damien Miller) Date: Sun, 02 May 2004 19:13:46 +1000 Subject: Connection caching? In-Reply-To: <4094A631.3050609@kegel.com> References: <4094A631.3050609@kegel.com> Message-ID: <4094BBCA.8090205@mindrot.org> Dan Kegel wrote: > Hey all, > on the distcc mailing list, a thread about load balancing > got a bit out of hand, and we started thinking about > moving fsh-like connection caching into ssh itself > to get rid of the overhead of starting up the python > interpreter to run rsh. > (Interestingly, mit's "rex", described at > http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-884.pdf, > considers connection caching one of the advantages it has over ssh.) The SSH protocol already includes the necessary capabilities to implement this, and I have been wanting to do this for a little while (but have obviously not gotten around to it). One you have established a SSH transport, you can fire off lots of sessions (command, shell or subsystem) which have independant lifespans. Our client only supports a single such session, but Our sshd already has this capability and I believe that the ssh.com windows client supports multiple connections against OpenSSH sshd. To implement this in OpenSSH's ssh, I was thinking about adding an argument to get ssh to listen on a unix domain socket after authentication. Additional sessions could be established by connecting to this socket, using SCM_RIGHTS messages to pass the std{in,out,err} fds to the connected ssh. It would probably be easiest to modify ssh to be the client, as it already does most of the buffering, etc. This wouldn't add much complexity to ssh, just a little bit of logic to deal with the control socket - we already have most of the infrastructure in the event loop to deal with multiple connections. This would be a good medium-sized project for someone to sink their teeth into :) -d From gert at greenie.muc.de Sun May 2 21:15:25 2004 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 2 May 2004 13:15:25 +0200 Subject: Connection caching? In-Reply-To: <4094BBCA.8090205@mindrot.org>; from djm@mindrot.org on Sun, May 02, 2004 at 07:13:46PM +1000 References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> Message-ID: <20040502131525.M26458@greenie.muc.de> Hi, On Sun, May 02, 2004 at 07:13:46PM +1000, Damien Miller wrote: > One you have established a SSH transport, you can fire off lots of > sessions (command, shell or subsystem) which have independant > lifespans. Our client only supports a single such session, but > Our sshd already has this capability and I believe that the > ssh.com windows client supports multiple connections against > OpenSSH sshd. Putty also supports this. Quite impressive, actually. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From dtucker at zip.com.au Sun May 2 22:46:23 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 02 May 2004 22:46:23 +1000 Subject: Connection caching? In-Reply-To: <20040502131525.M26458@greenie.muc.de> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <20040502131525.M26458@greenie.muc.de> Message-ID: <4094ED9F.3000008@zip.com.au> Gert Doering wrote: > On Sun, May 02, 2004 at 07:13:46PM +1000, Damien Miller wrote: > >>One you have established a SSH transport, you can fire off lots of >>sessions (command, shell or subsystem) which have independant >>lifespans. > > Putty also supports this. Quite impressive, actually. lsh does too (lshg/lsh -G). Hmm, someone really ought to hack it into ssh(1) ... -- 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 cmadams at hiwaay.net Mon May 3 00:22:45 2004 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 2 May 2004 09:22:45 -0500 Subject: Connection caching? In-Reply-To: <4094BBCA.8090205@mindrot.org> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> Message-ID: <20040502142245.GA1009771@hiwaay.net> Once upon a time, Damien Miller said: > One you have established a SSH transport, you can fire off lots of > sessions (command, shell or subsystem) which have independant > lifespans. Our client only supports a single such session, but > Our sshd already has this capability and I believe that the > ssh.com windows client supports multiple connections against > OpenSSH sshd. The Perl Net::SSH module supports this (although the Net::SFTP module doesn't support using an open Net::SSH connection). This is very useful when scripting things, as you only have to deal with opening a connection and authenticating once. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From dank at kegel.com Mon May 3 04:05:12 2004 From: dank at kegel.com (Dan Kegel) Date: Sun, 02 May 2004 11:05:12 -0700 Subject: Connection caching? In-Reply-To: <4094BBCA.8090205@mindrot.org> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> Message-ID: <40953858.8070405@kegel.com> Damien Miller wrote: >>on the distcc mailing list, a thread about load balancing >>got a bit out of hand, and we started thinking about >>moving fsh-like connection caching into ssh itself > > The SSH protocol already includes the necessary capabilities to > implement this Yes, we noticed. > One you have established a SSH transport, you can fire off lots of > sessions (command, shell or subsystem) which have independant > lifespans. Our client only supports a single such session, but > Our sshd already has this capability and I believe that the > ssh.com windows client supports multiple connections against > OpenSSH sshd. > > To implement this in OpenSSH's ssh, I was thinking about adding > an argument to get ssh to listen on a unix domain socket after > authentication. > > Additional sessions could be established by connecting to this > socket, using SCM_RIGHTS messages to pass the std{in,out,err} fds > to the connected ssh. It would probably be easiest to modify ssh > to be the client, as it already does most of the buffering, etc. Yep. That would help in many situations (for instance, in using ssh as a transport for remote gcc regression testing, which fires off zillions of short jobs to a single remote system). To use it with distcc would be a bit messier. Let's say there are 16 machines in the distcc cluster. Do we really want the user to have to fire off 16 ssh commands and leave them all running in the background? If so, what unix domain address would each one listen on? There are nasty limits on unix domain socket naming if you want to be portable to all unix systems, so we might not be able to put the hostname of the remote system into the socket address. Would it be possible to pass a new hostname to that unix domain socket, and have it fire up a new physical connection, too, such that a single copy of ssh could support simultaneous connections to all the machines in the distcc cluster? That would simplify the addressing question, and would make using this with a large cluster a lot easier, too. - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change From djm at mindrot.org Mon May 3 07:45:16 2004 From: djm at mindrot.org (Damien Miller) Date: Mon, 3 May 2004 07:45:16 +1000 (EST) Subject: Connection caching? In-Reply-To: <40953858.8070405@kegel.com> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> Message-ID: On Sun, 2 May 2004, Dan Kegel wrote: > Would it be possible to pass a new hostname to that unix domain > socket, and have it fire up a new physical connection, too, > such that a single copy of ssh could support simultaneous connections > to all the machines in the distcc cluster? That would simplify > the addressing question, and would make using this with a large > cluster a lot easier, too. I don't much like the idea of a single ssh instance representing multiple client to server connections. It would add a fair bit of complexity to ssh for (IMO) little benefit. As for the naming issue, using predictable names in a safe directory could resolve that problem. Something like "ControlSocket ~/.ssh/control-%h" (%h = hostname) would allow something like distcc to programatically detect whether a new connection is required. If one really wants a single interface to multiple sessions, then one could implement a separate mux daemon that does the above. -d From dank at kegel.com Mon May 3 08:48:07 2004 From: dank at kegel.com (Dan Kegel) Date: Sun, 02 May 2004 15:48:07 -0700 Subject: Connection caching? In-Reply-To: References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> Message-ID: <40957AA7.9000003@kegel.com> Damien Miller wrote: > As for the naming issue, using predictable names in a safe > directory could resolve that problem. Something like > "ControlSocket ~/.ssh/control-%h" (%h = hostname) would allow something > like distcc to programatically detect whether a new connection is > required. I seem to recall that unix domain sockets are a portability nightmare if you try to use long pathnames, but I guess you guys are doing it already with names like that, so maybe the systems where it was a problem are so obsolete nobody cares anymore... > If one really wants a single interface to multiple sessions, then one > could implement a separate mux daemon that does the above. Yes, and it could have whatever load balancing semantics one wants. By the way, it'd be nice not only to be able to open a new login session, but also to open up a connection to a port on the remote machine. (For instance, to a distccd running remotely.) Ideally the protocol to use over the unix domain socket would be documented so apps could use it directly rather than via the ssh wrapper if they felt the need. - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change From djm at mindrot.org Mon May 3 09:24:48 2004 From: djm at mindrot.org (Damien Miller) Date: Mon, 03 May 2004 09:24:48 +1000 Subject: Connection caching? In-Reply-To: <40957AA7.9000003@kegel.com> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <40957AA7.9000003@kegel.com> Message-ID: <40958340.8050803@mindrot.org> Dan Kegel wrote: > Damien Miller wrote: > > I seem to recall that unix domain sockets are a portability > nightmare if you try to use long pathnames, but I guess > you guys are doing it already with names like that, so > maybe the systems where it was a problem are so obsolete > nobody cares anymore... I'm not aware of any problems that we have run into, but that doesn't mean they don't exist. In any case, I don't think we should design for the lowest common denominator. > By the way, it'd be nice not only to be able to open a new > login session, but also to open up a connection to a port > on the remote machine. (For instance, to a distccd running > remotely.) You can do that now with port-forwarding, no? -d From dank at kegel.com Mon May 3 09:34:39 2004 From: dank at kegel.com (Dan Kegel) Date: Sun, 02 May 2004 16:34:39 -0700 Subject: Connection caching? In-Reply-To: <40958340.8050803@mindrot.org> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <40957AA7.9000003@kegel.com> <40958340.8050803@mindrot.org> Message-ID: <4095858F.1000305@kegel.com> Damien Miller wrote: >>By the way, it'd be nice not only to be able to open a new >>login session, but also to open up a connection to a port >>on the remote machine. (For instance, to a distccd running >>remotely.) > > You can do that now with port-forwarding, no? Yes, but I'm talking about doing it by talking over a unix domain socket to the already-running ssh rather than by starting a new ssh. My app would ideally connect to the unix domain socket, send some command meaning 'please connect me to port 3869 on host xxx', and get back an fd connected to that port. - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change From mouring at etoh.eviladmin.org Mon May 3 10:18:22 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sun, 2 May 2004 19:18:22 -0500 (CDT) Subject: Connection caching? In-Reply-To: <4095858F.1000305@kegel.com> Message-ID: On Sun, 2 May 2004, Dan Kegel wrote: > Damien Miller wrote: > >>By the way, it'd be nice not only to be able to open a new > >>login session, but also to open up a connection to a port > >>on the remote machine. (For instance, to a distccd running > >>remotely.) > > > > You can do that now with port-forwarding, no? > > Yes, but I'm talking about doing it by talking over a unix domain socket > to the already-running ssh rather than by starting a new ssh. > My app would ideally connect to the unix domain socket, > send some command meaning 'please connect me to port 3869 on host xxx', > and get back an fd connected to that port. OpenSSH already supports dynamic port forwarding to some degree. man ssh [..] ~C Open command line (only useful for adding port forwardings using the -L and -R options). Don't see why such ~ commands shouldn't work under this concept. - Ben From dwmw2 at infradead.org Mon May 3 10:31:00 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 03 May 2004 01:31:00 +0100 Subject: Connection caching? In-Reply-To: References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> Message-ID: <1083544260.4383.694.camel@imladris.demon.co.uk> On Mon, 2004-05-03 at 07:45 +1000, Damien Miller wrote: > I don't much like the idea of a single ssh instance representing multiple > client to server connections. It would add a fair bit of complexity to > ssh for (IMO) little benefit. Surely it shouldn't be much complexity? Doing it anywhere _but_ in ssh(1) will just lead to it being duplicated repeatedly, surely? Doing it in SSH, we can add an option which instructs the client to leave a connection open and daemonize itself, and an option which instructs the client to look for the unix domain socket created by such a daemon. > As for the naming issue, using predictable names in a safe > directory could resolve that problem. Something like > "ControlSocket ~/.ssh/control-%h" (%h = hostname) would allow something > like distcc to programatically detect whether a new connection is > required. You also want to include the username, and possibly also the _local_ IP address used for the connection in question. Or you have to deal with dynamic IP addresses somehow -- perhaps by means of keepalive. Fsh screws that up, and it's a PITA. -- dwmw2 From djm at mindrot.org Mon May 3 10:47:36 2004 From: djm at mindrot.org (Damien Miller) Date: Mon, 03 May 2004 10:47:36 +1000 Subject: Connection caching? In-Reply-To: <1083544260.4383.694.camel@imladris.demon.co.uk> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> Message-ID: <409596A8.7000204@mindrot.org> David Woodhouse wrote: > On Mon, 2004-05-03 at 07:45 +1000, Damien Miller wrote: > >>I don't much like the idea of a single ssh instance representing multiple >>client to server connections. It would add a fair bit of complexity to >>ssh for (IMO) little benefit. > > Surely it shouldn't be much complexity? Doing it anywhere _but_ in > ssh(1) will just lead to it being duplicated repeatedly, surely? I think that my words were ambiguous: I don't think that a single ssh process should represent multiple connections to *different* servers. Does that address your concern? > Doing it in SSH, we can add an option which instructs the client to > leave a connection open and daemonize itself, and an option which > instructs the client to look for the unix domain socket created by such > a daemon. That is exactly what I propose: start a ssh to a server, then use a client-side listening socket to run multiple sessions to that server over the transport. > You also want to include the username, I don't think you would want to put the control files anywhere other than a mode 0700 directory owned by the user who started the connection. We enforce similar restrictions on keys and (in -current) .ssh/config. Given this, I don't see a need for putting the username in there. > and possibly also the _local_ IP > address used for the connection in question. Or you have to deal with > dynamic IP addresses somehow -- perhaps by means of keepalive. Fsh > screws that up, and it's a PITA. ssh will terminate when the address changes, so what does this buy you? We do app-level keepalives: {Client,Server}Alive{Count,Max}. We just need to ensure that a terminating ssh cleans up its control socket gracefully. Anything that wants to make use of this facility could just do something like: [ -s ~/.ssh/ctl-$host ] || ssh -nNfo ControlSock=~/.ssh/ctl-$host $host I.e ensure that the socket is ready, or start a new connection. -d From dwmw2 at infradead.org Mon May 3 10:56:38 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 03 May 2004 01:56:38 +0100 Subject: Connection caching? In-Reply-To: <409596A8.7000204@mindrot.org> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> Message-ID: <1083545797.4383.702.camel@imladris.demon.co.uk> On Mon, 2004-05-03 at 10:47 +1000, Damien Miller wrote: > I think that my words were ambiguous: I don't think that a single ssh > process should represent multiple connections to *different* servers. > > Does that address your concern? Yes it does; thanks. > > Doing it in SSH, we can add an option which instructs the client to > > leave a connection open and daemonize itself, and an option which > > instructs the client to look for the unix domain socket created by such > > a daemon. > > That is exactly what I propose: start a ssh to a server, then use a > client-side listening socket to run multiple sessions to that server > over the transport. Are you familiar with fsh? You connect once and it leaves a daemon running. You connect again and it's fast. There's a configurable timeout. I think that model of operation -- not having to _explicitly_ start the daemon -- is ideal. > > You also want to include the username, > > I don't think you would want to put the control files anywhere other > than a mode 0700 directory owned by the user who started the > connection. We enforce similar restrictions on keys and (in -current) > .ssh/config. Given this, I don't see a need for putting the username in > there. Remote username, not local username. > > and possibly also the _local_ IP > > address used for the connection in question. Or you have to deal with > > dynamic IP addresses somehow -- perhaps by means of keepalive. Fsh > > screws that up, and it's a PITA. > > ssh will terminate when the address changes, so what does this buy you? I've seen that fail to happen with fsh being used as a wrapper. Perhaps it's just that fsh isn't noticing that ssh died; I need to investigate further. I haven't investigated much. TBH I'd rather just withhold a proportion of the extortionate amount I pay my telco for GPRS until they start providing a service where I can at least expect to keep the same IP address if I reconnect within seconds of being disconnected. :) > We do app-level keepalives: {Client,Server}Alive{Count,Max}. We just > need to ensure that a terminating ssh cleans up its control socket > gracefully. Anything that wants to make use of this facility could > just do something like: > > [ -s ~/.ssh/ctl-$host ] || ssh -nNfo ControlSock=~/.ssh/ctl-$host $host > > I.e ensure that the socket is ready, or start a new connection. That logic surely wants to be in ssh(1) ? If there's a socket, use it. Else create one. -- dwmw2 From dan at doxpara.com Mon May 3 11:21:59 2004 From: dan at doxpara.com (Dan Kaminsky) Date: Sun, 02 May 2004 18:21:59 -0700 Subject: Connection caching? In-Reply-To: <1083545797.4383.702.camel@imladris.demon.co.uk> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <1083545797.4383.702.camel@imladris.demon.co.uk> Message-ID: <40959EB7.50709@doxpara.com> >I haven't investigated much. TBH I'd rather just withhold a proportion >of the extortionate amount I pay my telco for GPRS until they start >providing a service where I can at least expect to keep the same IP >address if I reconnect within seconds of being disconnected. :) > > > ROCKS helps with this (IP independent sockets). --Dan From Jefferson.Ogata at noaa.gov Mon May 3 15:12:16 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Mon, 03 May 2004 01:12:16 -0400 Subject: Connection caching? In-Reply-To: <4095858F.1000305@kegel.com> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <40957AA7.9000003@kegel.com> <40958340.8050803@mindrot.org> <4095858F.1000305@kegel.com> Message-ID: <4095D4B0.6090206@noaa.gov> Dan Kegel wrote: > Damien Miller wrote: >> You can do that now with port-forwarding, no? > > Yes, but I'm talking about doing it by talking over a unix domain socket > to the already-running ssh rather than by starting a new ssh. > My app would ideally connect to the unix domain socket, > send some command meaning 'please connect me to port 3869 on host xxx', > and get back an fd connected to that port. Sounds like you want ssh to be a VPN. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From dtucker at zip.com.au Mon May 3 15:23:53 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 03 May 2004 15:23:53 +1000 Subject: Connection caching? In-Reply-To: <4095D4B0.6090206@noaa.gov> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <40957AA7.9000003@kegel.com> <40958340.8050803@mindrot.org> <4095858F.1000305@kegel.com> <4095D4B0.6090206@noaa.gov> Message-ID: <4095D769.6020700@zip.com.au> Jefferson Ogata wrote: > Sounds like you want ssh to be a VPN. You can already use ssh as a "poor-man's VPN" if you use "ssh -D" and a socksified IP stack, eg Hummingbird's stack for Windows or a platform with built-in SOCKS support, such as AIX 4.3.2 and up (and Mac OS X?). It's normally a hell of a lot easier to make work over proxies (compared to, say, IPSEC). -- 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 dmeranda at iac.net Mon May 3 15:45:52 2004 From: dmeranda at iac.net (Deron Meranda) Date: Mon, 03 May 2004 01:45:52 -0400 Subject: Corrupted MAC on input In-Reply-To: <4091E67F.4070409@zip.com.au> References: <200404291839.i3TIdkHK003753@iac.net> <4091E67F.4070409@zip.com.au> Message-ID: <4095DC90.6010409@iac.net> Darren Tucker wrote: > If the encrypted packets are identical but decrypt differently that > sounds like a problem in the crypto itself. Which algorithm were you > using? Are you using the HP ANSI C compiler to compile OpenSSL? No, I used gcc 3.3 for everything except for one hand-coded assembly file "crypto/bn/asm/pa-risc2.s" for which I used HP's assembler. My ssh sessions are all SSH version 2, and negotiate the AES crypto algorithm. My OpenSSL binaries passed all self-tests, and I also use the same libraries with Apache. And since I use Mozilla, the AES algos also get a good workout in the context of the webserver. I've yet to see any type of peculiar behavior, except for the MAC errors in OpenSSH. I should also mention that I also use this same ssh server all day long while at work (on the same 100 Mbps LAN). I work it really hard there and NEVER see any problem. But all the corrupted MAC errors I've seen only occur while working from home, over an ADSL connection. I can't explain how that may make any difference. I did recently encounter a couple more cases of a corrupted MAC. This time I was using PuTTY 0.54 under Win 98SE, and the server is "OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004" running under HP-UX 11.0. I did not have any sort of debugging enabled this time, but I may have noticed another pattern. I only seem to get a corrupted MAC when a burst of traffic occurs, never when just typing or something slow. Also it seems to occur more readily when the data stream contains a lot of repetitive patterns. For example, when listing the contents of a huge tar file in which the pathnames all have the same long prefix. This got me thinking that perhaps this could also be a compression issue. I do have compression turned on. I have no idea if this is correct or not, but it's another observation for what it's worth. BTW, my server-side OpenSSH is linked against zlib 1.2.1, compiled with gcc 3.3 at -O3 optimization level. I hope this doesn't lead us in a misleading direction, but it's just not repeatable enough for me to get good debug data. Also my occurances of MAC errors may or may not be related to those reported by the first poster. Deron From gert at greenie.muc.de Mon May 3 17:13:54 2004 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 3 May 2004 09:13:54 +0200 Subject: Corrupted MAC on input In-Reply-To: <4095DC90.6010409@iac.net>; from dmeranda@iac.net on Mon, May 03, 2004 at 01:45:52AM -0400 References: <200404291839.i3TIdkHK003753@iac.net> <4091E67F.4070409@zip.com.au> <4095DC90.6010409@iac.net> Message-ID: <20040503091354.D8438@greenie.muc.de> Hi, On Mon, May 03, 2004 at 01:45:52AM -0400, Deron Meranda wrote: > I should also mention that I also use this same ssh server > all day long while at work (on the same 100 Mbps LAN). I work > it really hard there and NEVER see any problem. But all the > corrupted MAC errors I've seen only occur while working from home, > over an ADSL connection. I can't explain how that may make any > difference. It could either be bit errors on the line (unlikely, 'cause TCP's checksum should notice that) or "overly smart" NAT in the ADSL router, changing bits of the outgoing packets for whatever reason. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From djm at mindrot.org Mon May 3 17:37:59 2004 From: djm at mindrot.org (Damien Miller) Date: Mon, 03 May 2004 17:37:59 +1000 Subject: Corrupted MAC on input In-Reply-To: <20040503091354.D8438@greenie.muc.de> References: <200404291839.i3TIdkHK003753@iac.net> <4091E67F.4070409@zip.com.au> <4095DC90.6010409@iac.net> <20040503091354.D8438@greenie.muc.de> Message-ID: <4095F6D7.70604@mindrot.org> Gert Doering wrote: > It could either be bit errors on the line (unlikely, 'cause TCP's checksum > should notice that) or "overly smart" NAT in the ADSL router, changing > bits of the outgoing packets for whatever reason. I think that many of these are likely to be dumb NAT. E.g. the oft-reported Linksys router problem. Given that everyone is using the same underpowered chipsets and consumer firmware from the few large electronics manufacturers, it wouldn't be surprising if these bugs affected several other vendors. Could people who are seeing these problems please check their NIC error and checksum counters to see if they are experiencing a large number of errors? I wonder also, if any of these issues are NAT/state timeout related. If you are suffering from this problem, try turning on the {Client,Server}Keepalive{Count,Max} options and see if it helps. Another possibility is bugs relating to rekeying in openssh - these would be more likely to be triggered on long transfers or otherwise busy connections. This can be ruled out if people can reproduce the problem when connected with "ssh -v". This will produce a little more output, include messages when rekeying occurs. -d From dtucker at zip.com.au Mon May 3 17:51:10 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 03 May 2004 17:51:10 +1000 Subject: Corrupted MAC on input In-Reply-To: <4095DC90.6010409@iac.net> References: <200404291839.i3TIdkHK003753@iac.net> <4091E67F.4070409@zip.com.au> <4095DC90.6010409@iac.net> Message-ID: <4095F9EE.7010009@zip.com.au> Deron Meranda wrote: > Darren Tucker wrote: > >> If the encrypted packets are identical but decrypt differently that >> sounds like a problem in the crypto itself. Which algorithm were you >> using? Are you using the HP ANSI C compiler to compile OpenSSL? > > No, I used gcc 3.3 for everything except for one hand-coded > assembly file "crypto/bn/asm/pa-risc2.s" for which I used > HP's assembler. My ssh sessions are all SSH version 2, and > negotiate the AES crypto algorithm. OpenSSL will automatically build that when configured with the HP ANSI C compiler, right? If so, that's a common point (but it the bignum stuff isn't used during the the session unless it gets rekeyed...) Can you try it without that? I know it's significantly slower, but there's been some speedups on the OpenSSH which should help compensate: http://www.openssh.com/faq.html#3.3 > My OpenSSL binaries passed all self-tests, and I also use > the same libraries with Apache. And since I use Mozilla, the > AES algos also get a good workout in the context of the webserver. > I've yet to see any type of peculiar behavior, except for the > MAC errors in OpenSSH. Do any of the others use hmac-md5? Perhaps you can try alternative MAC and cipher algorigthms? > I should also mention that I also use this same ssh server > all day long while at work (on the same 100 Mbps LAN). I work > it really hard there and NEVER see any problem. But all the > corrupted MAC errors I've seen only occur while working from home, > over an ADSL connection. I can't explain how that may make any > difference. I've only once had problems with MAC failures over my ADSL link, and it seemed to correspond to an equipment failure upstream. MAC failures got more and more frequent over the course of several hours (other traffic was affected too, but I noticed ssh first), then the link went offline completely for several hours. When it came back up, it was fine again. > I did not have any sort of debugging enabled this time, but I > may have noticed another pattern. I only seem to get a > corrupted MAC when a burst of traffic occurs, never when just > typing or something slow. Also it seems to occur more readily > when the data stream contains a lot of repetitive patterns. [...] > This got me thinking that perhaps this could also be a > compression issue. I do have compression turned on. Good thought, but the MAC is computed on the compressed data, so it's applied after compression for sending, and checked before decompression, so I don't think SSH's compression is the cause. I could buy flaky link compression somewhere on the path if you had compression off. Anyway thanks for the info, it's given some more food for though. -- 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 Sergio.Gelato at astro.su.se Mon May 3 18:50:59 2004 From: Sergio.Gelato at astro.su.se (Sergio Gelato) Date: Mon, 3 May 2004 10:50:59 +0200 Subject: Connection caching? In-Reply-To: <1083545797.4383.702.camel@imladris.demon.co.uk> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <1083545797.4383.702.camel@imladris.demon.co.uk> Message-ID: <20040503085057.GB1239@hanuman.astro.su.se> * David Woodhouse [2004-05-03 01:56:38 +0100]: > On Mon, 2004-05-03 at 10:47 +1000, Damien Miller wrote: > > > You also want to include the username, > > > > I don't think you would want to put the control files anywhere other > > than a mode 0700 directory owned by the user who started the > > connection. We enforce similar restrictions on keys and (in -current) > > .ssh/config. Given this, I don't see a need for putting the username in > > there. > > Remote username, not local username. While you're at it, include also the port number sshd is running on (if different from 22, at least). Same reason as for the remote username. From vinschen at redhat.com Mon May 3 19:09:07 2004 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 3 May 2004 11:09:07 +0200 Subject: Connection caching? In-Reply-To: <4095858F.1000305@kegel.com> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <40957AA7.9000003@kegel.com> <40958340.8050803@mindrot.org> <4095858F.1000305@kegel.com> Message-ID: <20040503090907.GC2201@cygbert.vinschen.de> On May 2 16:34, Dan Kegel wrote: > Damien Miller wrote: > >>By the way, it'd be nice not only to be able to open a new > >>login session, but also to open up a connection to a port > >>on the remote machine. (For instance, to a distccd running > >>remotely.) > > > >You can do that now with port-forwarding, no? > > Yes, but I'm talking about doing it by talking over a unix domain socket > to the already-running ssh rather than by starting a new ssh. > My app would ideally connect to the unix domain socket, > send some command meaning 'please connect me to port 3869 on host xxx', > and get back an fd connected to that port. Unfortunately this would exclude Cygwin since file descriptor passing over unix domain socket is not implemented. And it's not easy to implement. Corinna -- Corinna Vinschen Cygwin Co-Project Leader Red Hat, Inc. From Jefferson.Ogata at noaa.gov Tue May 4 03:05:42 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Mon, 03 May 2004 13:05:42 -0400 Subject: Connection caching? In-Reply-To: <409596A8.7000204@mindrot.org> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> Message-ID: <40967BE6.7050908@noaa.gov> Damien Miller wrote: > David Woodhouse wrote: >>On Mon, 2004-05-03 at 07:45 +1000, Damien Miller wrote: >>Doing it in SSH, we can add an option which instructs the client to >>leave a connection open and daemonize itself, and an option which >>instructs the client to look for the unix domain socket created by such >>a daemon. > > That is exactly what I propose: start a ssh to a server, then use a > client-side listening socket to run multiple sessions to that server > over the transport. This idea makes me uncomfortable -- it provides a mechanism for completely bypassing authentication once someone compromises a user account. At least with ssh-agent, you still have the option of removing the public key from the authorized_keys files on remote hosts to disable future authentications. But with this multiplexed session business, an intruder doesn't even need to authenticate if an established session exists. Abuse of pubkey authentication is bad enough -- the scope of abuse of this kind of feature could get very ugly. Please, if someone decides to implement this, make sure it can be disabled on the server. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From djm at mindrot.org Tue May 4 09:58:28 2004 From: djm at mindrot.org (Damien Miller) Date: Tue, 04 May 2004 09:58:28 +1000 Subject: Connection caching? In-Reply-To: <40967BE6.7050908@noaa.gov> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> Message-ID: <4096DCA4.5070304@mindrot.org> Jefferson Ogata wrote: > Abuse of pubkey authentication is bad enough -- the scope of abuse of this kind > of feature could get very ugly. Please, if someone decides to implement this, > make sure it can be disabled on the server. The server has had this ability since version 2.x. Our client support is what is missing. -d From Jefferson.Ogata at noaa.gov Tue May 4 10:04:52 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Mon, 03 May 2004 20:04:52 -0400 Subject: Connection caching? In-Reply-To: <4096DCA4.5070304@mindrot.org> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> Message-ID: <4096DE24.5010004@noaa.gov> Damien Miller wrote: > Jefferson Ogata wrote: >>Abuse of pubkey authentication is bad enough -- the scope of abuse of this kind >>of feature could get very ugly. Please, if someone decides to implement this, >>make sure it can be disabled on the server. > > The server has had this ability since version 2.x. Our client support is > what is missing. My previous comment was poorly worded. I understand from other postings that the server has the capability for multiple sessions. I'm saying please provide a server option to disable that. Are you saying there exists such an option? To be clear: while the openssh server may have supported this feature for a long time, adding the feature to the openssh client will make it much more likely to be used. I'm inclined to require authentication for every user each time a session is requested, and I wish to be able to set that requirement on the ssh server. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From djm at mindrot.org Tue May 4 10:20:54 2004 From: djm at mindrot.org (Damien Miller) Date: Tue, 04 May 2004 10:20:54 +1000 Subject: Connection caching? In-Reply-To: <4096DE24.5010004@noaa.gov> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> Message-ID: <4096E1E6.40706@mindrot.org> Jefferson Ogata wrote: > My previous comment was poorly worded. I understand from other postings > that the server has the capability for multiple sessions. I'm saying > please provide a server option to disable that. Are you saying there > exists such an option? No such option exists, unless you include "Protocol=1" :) I don't think an option makes sense anyway. If you have the ability to compromise a client, then you can execute such an attack right now. This is, of course, just talk until someone steps forward to help out with the implementation. -d From Jefferson.Ogata at noaa.gov Tue May 4 10:37:30 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Mon, 03 May 2004 20:37:30 -0400 Subject: Connection caching? In-Reply-To: <4096E1E6.40706@mindrot.org> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> Message-ID: <4096E5CA.5040007@noaa.gov> Damien Miller wrote: > Jefferson Ogata wrote: >>My previous comment was poorly worded. I understand from other postings >>that the server has the capability for multiple sessions. I'm saying >>please provide a server option to disable that. Are you saying there >>exists such an option? > > No such option exists, unless you include "Protocol=1" :) > > I don't think an option makes sense anyway. If you have the ability > to compromise a client, then you can execute such an attack right now. I don't know what you mean. If the client doesn't support the option, all you can do is take over an existing session -- say, via ptrace or pty hijacking -- and this would be difficult to pull off in general, especially undetected. In any case, this is a totally different attack that can be mitigated in other ways. It's hard enough to keep lazy users from eliminating any challenge from normal pubkey authentication by using ssh-agent or unpassphrased private keys. But there are ways to force clients to be intelligent for authentication. It's a different ball of wax once you start allowing a single authentication phase provide a perpetual stream of sessions. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From dmeranda at iac.net Tue May 4 10:55:24 2004 From: dmeranda at iac.net (Deron Meranda) Date: Mon, 03 May 2004 20:55:24 -0400 Subject: Corrupted MAC on input In-Reply-To: <4095F9EE.7010009@zip.com.au> References: <200404291839.i3TIdkHK003753@iac.net> <4091E67F.4070409@zip.com.au> <4095DC90.6010409@iac.net> <4095F9EE.7010009@zip.com.au> Message-ID: <4096E9FC.7090602@iac.net> Darren Tucker wrote: > OpenSSL will automatically build [pa-risc2.o] when configured > with the HP ANSI C compiler, right? Yes it will...as long as you stick with 32-bit mode. You also used to also have to use static libraries only, but the more recent sources (as of 0.9.7b) now allow the *.o to be PIC, so you can use in shared libraries too. > the bignum stuff isn't used during the the session unless > it gets rekeyed... From what I've discovered the bignum stuff (in particular the hand-coded assembly routines) are only used in any significant way when performing RSA encryption and when generating Diffie- Hellman keypairs. So yes, for SSH that would either occur during the initial session setup, or during rekeying. I only use RSA keys with ssh. I don't use DSA at all. I also only use key-based authentication, never password. I don't think that matters once you're in. And I can tell you that from a year ago when I was seriously trying to debug this problem, I did verify that session rekeying was not involved in any way with the corrupted MACs occurances. That was actually one of the first things I checked because it seemed so obvious. > Do any of the others [Apache, etc.] use hmac-md5? Probably not, I think most things negotiate hmac-sha1. Before I try changing a bunch of settings and stuff, I need to try to see if I can more predictably trigger this error. Note that I am going through a Linksys router. It is a BEFSR41 firmware "1.44.2, Dec 13 2002". I may try to upgrade it. I'm also going through a pair of Linux iptables-based firewalls near the server side, one of which is NATing. I have no idea what other network labyrinths lie between. It certainly could be a network/hardware issue. But what could cause a MAC error, while surviving the TCP checksum? Also, another observation, aside from using HP-UX on the server, I have only witnessed this problem when using an Athlon-based PC for the client (an older 800 MHz Slot-A model). But it is multi-OS, and I've seen the MAC error under both Windows 98SE (with PuTTY), as well as under Linux using OpenSSH client. I wonder if there may be an Athlon client-side issue? More datapoints would certainly help. Who else has seen these MAC errors? If I can figure out a way to reliably make these occur perhaps I can provide much more solid input rather than the wild guesses I seem to be making now. Deron Meranda From djm at mindrot.org Tue May 4 11:00:00 2004 From: djm at mindrot.org (Damien Miller) Date: Tue, 04 May 2004 11:00:00 +1000 Subject: Connection caching? In-Reply-To: <4096E5CA.5040007@noaa.gov> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> Message-ID: <4096EB10.8000700@mindrot.org> Jefferson Ogata wrote: > It's hard enough to keep lazy users from eliminating any challenge from > normal pubkey authentication by using ssh-agent or unpassphrased private > keys. But there are ways to force clients to be intelligent for > authentication. It's a different ball of wax once you start allowing a > single authentication phase provide a perpetual stream of sessions. Like I said: the control socket would be subject to similar checks that we perform for other sockets (e.g. ssh-agent). I.e it must live in a secure directory and we can enforce getpeerid checks to ensure that it is the same user connecting each time. I suppose we could also optionally do explicit confirmation via ssh-askpass, like we do with ssh-add's -c option. -d From Jefferson.Ogata at noaa.gov Tue May 4 11:49:44 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Mon, 03 May 2004 21:49:44 -0400 Subject: Connection caching? In-Reply-To: <4096EB10.8000700@mindrot.org> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> Message-ID: <4096F6B8.7070202@noaa.gov> Damien Miller wrote: > Jefferson Ogata wrote: >>It's hard enough to keep lazy users from eliminating any challenge from >>normal pubkey authentication by using ssh-agent or unpassphrased private >>keys. But there are ways to force clients to be intelligent for >>authentication. It's a different ball of wax once you start allowing a >>single authentication phase provide a perpetual stream of sessions. > > Like I said: the control socket would be subject to similar checks that > we perform for other sockets (e.g. ssh-agent). I.e it must live in a > secure directory and we can enforce getpeerid checks to ensure that > it is the same user connecting each time. Um, I feel like you're missing the point. I can prevent users from using ssh-agent by not providing the binary and by not giving them write access to any exec filesystem. I can also require authentication mechanisms on the server side that ssh-agent cannot answer, e.g. one-time passwords. The mechanism under discussion is not amenable to any of these controls. Once someone authenticates once, if that user's remote session is compromised, the intruder can piggyback over any established ssh connection and there is absolutely no way I can force the intruder to authenticate. Do you understand? You're advocating a mechanism that renders one-time passwords useless against a remote client compromise. That's fine for you, but not for me: I need to be able to turn that off on the ssh server. > I suppose we could also optionally do explicit confirmation via > ssh-askpass, like we do with ssh-add's -c option. I don't understand. What would we ask for with ssh-askpass? -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From djm at mindrot.org Tue May 4 12:09:20 2004 From: djm at mindrot.org (Damien Miller) Date: Tue, 04 May 2004 12:09:20 +1000 Subject: Connection caching? In-Reply-To: <4096F6B8.7070202@noaa.gov> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> Message-ID: <4096FB50.4060909@mindrot.org> Jefferson Ogata wrote: > Um, I feel like you're missing the point. I can prevent users from using > ssh-agent by not providing the binary and by not giving them write access to any > exec filesystem. I can also require authentication mechanisms on the server side > that ssh-agent cannot answer, e.g. one-time passwords. The mechanism under > discussion is not amenable to any of these controls. Once someone authenticates > once, if that user's remote session is compromised, the intruder can piggyback > over any established ssh connection and there is absolutely no way I can force > the intruder to authenticate. Do you understand? You're advocating a mechanism > that renders one-time passwords useless against a remote client compromise. You miss the point: these controls are useless now, if they depend on the integrity of an uncontrolled client. > That's fine for you, but not for me: I need to be able to turn that off on the > ssh server. So write a patch. -d From dtucker at zip.com.au Tue May 4 12:09:41 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 04 May 2004 12:09:41 +1000 Subject: Corrupted MAC on input In-Reply-To: <4096E9FC.7090602@iac.net> References: <200404291839.i3TIdkHK003753@iac.net> <4091E67F.4070409@zip.com.au> <4095DC90.6010409@iac.net> <4095F9EE.7010009@zip.com.au> <4096E9FC.7090602@iac.net> Message-ID: <4096FB65.1010401@zip.com.au> Deron Meranda wrote: > Note that I am going through a Linksys router. It is a BEFSR41 > firmware "1.44.2, Dec 13 2002". The Linksys should be your prime suspect: http://bugzilla.mindrot.org/show_bug.cgi?id=510 According to other reports 1.43.1 works OK. > It certainly could > be a network/hardware issue. But what could cause a MAC error, > while surviving the TCP checksum? Well, the TCP checksum is only 16 bits, so one error in 65536 is going to go undetected (the chance of it going undetected by the MAC is somewhat smaller :-). Also, the checksum is on the TCP header and data, so if the device is messing with with the header (eg changing the source IP/port for NAT) then it will have to recompute the TCP checksum. If a corruption occurs to the packet data before that step then the recomputed checksum on the corrupted packet will be correct. > Also, another observation, aside from using HP-UX on the server, > I have only witnessed this problem when using an Athlon-based > PC for the client (an older 800 MHz Slot-A model). But it is > multi-OS, and I've seen the MAC error under both Windows 98SE > (with PuTTY), as well as under Linux using OpenSSH client. I > wonder if there may be an Athlon client-side issue? Maybe a flaky memory, network card or cabling? > More datapoints would certainly help. Who else has seen these > MAC errors? I've opened a bug[1] to capture the details. If anyone is experiencing them, please add a brief summary to the bug. [1] http://bugzilla.mindrot.org/show_bug.cgi?id=860 -- 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 mouring at etoh.eviladmin.org Tue May 4 12:13:03 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 3 May 2004 21:13:03 -0500 (CDT) Subject: Connection caching? In-Reply-To: <4096E5CA.5040007@noaa.gov> Message-ID: On Mon, 3 May 2004, Jefferson Ogata wrote: > Damien Miller wrote: > > Jefferson Ogata wrote: > >>My previous comment was poorly worded. I understand from other postings > >>that the server has the capability for multiple sessions. I'm saying > >>please provide a server option to disable that. Are you saying there > >>exists such an option? > > > > No such option exists, unless you include "Protocol=1" :) > > > > I don't think an option makes sense anyway. If you have the ability > > to compromise a client, then you can execute such an attack right now. > > I don't know what you mean. If the client doesn't support the option, > all you can do is take over an existing session -- say, via ptrace or > pty hijacking -- and this would be difficult to pull off in general, > especially undetected. In any case, this is a totally different attack > that can be mitigated in other ways. > What stops it from happening now? Net::SSH supports it, and Windows SSH clients support it. Because the server supports you may be at risk no matter if OpenSSH's client supports it or not. I mean honestly.. =) Has this never cross your mind before that a user on a Windows box or a self-owned UNIX box could be doing this? The world is not made up of OpenSSH clients only. =) I hate to rain on all our dreams, but that is the reality of the matter. Besides, as what Damien stated this is all academic until someone writes a patch to support this feature. - Ben From jmknoble at pobox.com Tue May 4 12:43:04 2004 From: jmknoble at pobox.com (Jim Knoble) Date: Mon, 3 May 2004 22:43:04 -0400 Subject: Corrupted MAC on input In-Reply-To: <4096E9FC.7090602@iac.net> References: <200404291839.i3TIdkHK003753@iac.net> <4091E67F.4070409@zip.com.au> <4095DC90.6010409@iac.net> <4095F9EE.7010009@zip.com.au> <4096E9FC.7090602@iac.net> Message-ID: <20040504024304.GC22753@crawfish.ais.com> Circa 2004-05-03 20:55:24 -0400 dixit Deron Meranda: : Note that I am going through a Linksys router. It is a BEFSR41 : firmware "1.44.2, Dec 13 2002". I may try to upgrade it. This is the first thing i would recommend. I've experienced exactly the same MAC corruption using OpenSSH through a BEFSR41 with that firmware; a later firmware (1.45.7, 2003-07-31) fixed the problem. Beware and write down all your configuration settings; this one caused a factory reset after installation, if memory serves. This (slightly reformatted) changelog entry may be a telltale: Ver #. Date Description ------------------------------------------------------------------------ 1.45.7 Jul 31,2003 [...] 3.Fixed fragmented packets arriving out of order Good luck. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) ..................................................................... :"The methods now being used to merchandise the political candidate : : as though he were a deodorant positively guarantee the electorate : : against ever hearing the truth about anything." --Aldous Huxley : :...................................................................: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 256 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040503/c937d003/attachment.bin From Jefferson.Ogata at noaa.gov Tue May 4 12:58:49 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Mon, 03 May 2004 22:58:49 -0400 Subject: Connection caching? In-Reply-To: <4096FB50.4060909@mindrot.org> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> Message-ID: <409706E9.2060700@noaa.gov> Damien Miller wrote: > Jefferson Ogata wrote: >>Um, I feel like you're missing the point. I can prevent users from using >>ssh-agent by not providing the binary and by not giving them write access to any >>exec filesystem. I can also require authentication mechanisms on the server side >>that ssh-agent cannot answer, e.g. one-time passwords. The mechanism under >>discussion is not amenable to any of these controls. Once someone authenticates >>once, if that user's remote session is compromised, the intruder can piggyback >>over any established ssh connection and there is absolutely no way I can force >>the intruder to authenticate. Do you understand? You're advocating a mechanism >>that renders one-time passwords useless against a remote client compromise. > > You miss the point: these controls are useless now, if they depend on > the integrity of an uncontrolled client. I wouldn't agree that they're useless, but they're clearly incomplete, hence the /need/ for a configuration directive. >>That's fine for you, but not for me: I need to be able to turn that off on the >>ssh server. > > So write a patch. It disappoints me that you guys have so little concern about providing controllable authentication mechanisms. You really just don't get how dumb it is to have implemented this feature in the server /without/ having provided a configuration directive to control it, do you? As for writing a patch, I wrote a patch ("Requiring multiple auth mechanisms") a few weeks ago and submitted it to the list. I didn't get one useful bit of feedback, or any indication whatever that the maintainers even understood the purpose of the patch. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From mouring at etoh.eviladmin.org Tue May 4 13:33:03 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 3 May 2004 22:33:03 -0500 (CDT) Subject: Connection caching? In-Reply-To: <409706E9.2060700@noaa.gov> Message-ID: On Mon, 3 May 2004, Jefferson Ogata wrote: [..] > As for writing a patch, I wrote a patch ("Requiring multiple auth mechanisms") a > few weeks ago and submitted it to the list. I didn't get one useful bit of > feedback, or any indication whatever that the maintainers even understood the > purpose of the patch. > Looking back a whole month and I see nothing. You sure it even made it to the list? - Ben From djm at mindrot.org Tue May 4 13:48:10 2004 From: djm at mindrot.org (Damien Miller) Date: Tue, 04 May 2004 13:48:10 +1000 Subject: Connection caching? In-Reply-To: <409706E9.2060700@noaa.gov> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> Message-ID: <4097127A.5010501@mindrot.org> Jefferson Ogata wrote: > Damien Miller wrote: > >>You miss the point: these controls are useless now, if they depend on >>the integrity of an uncontrolled client. > > I wouldn't agree that they're useless, but they're clearly incomplete, hence the > /need/ for a configuration directive. We are going in circles. You don't seem to want to understand that if you don't trust the client, then no amount of server configuration is going to prevent them from being taken over. > It disappoints me that you guys have so little concern about providing > controllable authentication mechanisms. You really just don't get how dumb it is > to have implemented this feature in the server /without/ having provided a > configuration directive to control it, do you? No, obviously I don't. Neither, obviously, did any of the authors of the SSH v.2 protocol where this capability is pretty much mandated by the spec. On the other hand, maybe we just understand the implications of allowing an uncontrolled client to authenticate better than you. Please think this through before throwing more insults around. > As for writing a patch, I wrote a patch ("Requiring multiple auth mechanisms") a > few weeks ago and submitted it to the list. I didn't get one useful bit of > feedback, or any indication whatever that the maintainers even understood the > purpose of the patch. We have lives outside of OpenSSH and sometimes we are too busy to jump when you expect us to. Especially for patches against a 2 year old version. Please post your patch to bugzilla, a service that is provided so things like that don't get lost. -d From dtucker at zip.com.au Tue May 4 14:36:52 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 04 May 2004 14:36:52 +1000 Subject: Connection caching? In-Reply-To: <409706E9.2060700@noaa.gov> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> Message-ID: <40971DE4.1000607@zip.com.au> Jefferson Ogata wrote: > Damien Miller wrote: > >> Jefferson Ogata wrote: [...] >>> You're advocating a mechanism that renders one-time passwords useless >>> against a remote client compromise. >> >> You miss the point: these controls are useless now, if they depend on >> the integrity of an uncontrolled client. > > I wouldn't agree that they're useless, but they're clearly incomplete, > hence the /need/ for a configuration directive. Let's imagine for a moment that the server restricts each client to only one session. If the client is compromised, there's still nothing to stop it from jamming, eg, "xterm -display my.evil.com:6000" into the command line. Or pretending the connection was terminated and hijacking the session outright. What it boils down to is that once a client is authenticated, the server is trusting it with the credentials of the user it allowed to log in. >>> That's fine for you, but not for me: I need to be able to turn that >>> off on the ssh server. >> >> So write a patch. > > It disappoints me that you guys have so little concern about providing > controllable authentication mechanisms. You really just don't get how > dumb it is to have implemented this feature in the server /without/ > having provided a configuration directive to control it, do you? There's a limit to what the server can enforce. How, for example, could it prevent a user from posting their passwordless private key to Usenet? Or writing their passwords on Post-It notes and sticking them on their monitor? Pointing a webcam at their SecurID token? I'm sure you'll agree that these are insecure behaviours. > As for writing a patch, I wrote a patch ("Requiring multiple auth > mechanisms") a few weeks ago and submitted it to the list. I didn't get > one useful bit of feedback, or any indication whatever that the > maintainers even understood the purpose of the patch. I looked at it in conjunction with bug #701 (which is the "PermitRootLogin without-password" thing). It occurred to me that a more general mechanism could be a better solution for both. As usual, I got sidetracked. -- 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 Jefferson.Ogata at noaa.gov Tue May 4 14:43:45 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Tue, 04 May 2004 00:43:45 -0400 Subject: Connection caching? In-Reply-To: References: Message-ID: <40971F81.8010109@noaa.gov> Ben Lindstrom wrote: > On Mon, 3 May 2004, Jefferson Ogata wrote: > [..] >>As for writing a patch, I wrote a patch ("Requiring multiple auth mechanisms") a >>few weeks ago and submitted it to the list. I didn't get one useful bit of >>feedback, or any indication whatever that the maintainers even understood the >>purpose of the patch. > > Looking back a whole month and I see nothing. You sure it even made it to > the list? I'm sure, though I should have been clear that it wasn't a patch for this specific item -- it was a patch to provide a way to use another feature of the ssh2 protocol: the ability to run multiple authentication phases for a single session. I posted it 2004/04/07 1439Z. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From Jefferson.Ogata at noaa.gov Tue May 4 15:11:53 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Tue, 04 May 2004 01:11:53 -0400 Subject: Connection caching? In-Reply-To: <4097127A.5010501@mindrot.org> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <4097127A.5010501@mindrot.org> Message-ID: <40972619.8030503@noaa.gov> Damien Miller wrote: > Jefferson Ogata wrote: >>Damien Miller wrote: >>>You miss the point: these controls are useless now, if they depend on >>>the integrity of an uncontrolled client. >> >>I wouldn't agree that they're useless, but they're clearly incomplete, hence the >>/need/ for a configuration directive. > > We are going in circles. You don't seem to want to understand that if > you don't trust the client, then no amount of server configuration is > going to prevent them from being taken over. And you don't seem to want to understand that at least one-time password authentication renders the authentication process itself secure. But when you provide a mechanism that extends a single authentication into unlimited sessions you lose the opportunity to control the scope of a compromise. I can set up a secure ssh gateway that requires pubkey or OTP auth to get in, and OTP to get out to the secure network. I can make the client secure on the gateway, and prevent users from adding code on the gateway. I can disable port, X, and agent forwarding on the gateway. That's a pretty strong setup even if the remote client is compromised; the worst case is that a very talented intruder /might/ hijack a single session at the remote end, and that would be detectable. Moreover, most intruders are too stupid or lazy to even try to take over an existing session. Just because a user can still theoretically tunnel his own protocol through all that doesn't mean it isn't obvious that there should be a server control for it. A user can tunnel X without help from sshd -- that doesn't mean we don't have a X11Forwarding directive. Are you really going to say you don't see the danger of a single authentication session providing a tunnel for unlimited shells, with /no way/ to disable that behavior? You don't see how that makes it harder to mitigate the scope of a remote compromise? >>It disappoints me that you guys have so little concern about providing >>controllable authentication mechanisms. You really just don't get how dumb it is >>to have implemented this feature in the server /without/ having provided a >>configuration directive to control it, do you? > > No, obviously I don't. Neither, obviously, did any of the authors of > the SSH v.2 protocol where this capability is pretty much mandated > by the spec. If the spec truly mandates this silliness, that doesn't mean it isn't clearly wise to provide a mechanism to disable it. > On the other hand, maybe we just understand the implications of > allowing an uncontrolled client to authenticate better than you. Please > think this through before throwing more insults around. I have thought it through. And I've got plenty of real world experience in dealing with web-of-trust intrusions involving openssh. Making it easier for lazy users to bypass authentication doesn't help -- particularly if you don't provide a directive to control it on the server end. In the real world, sysadmins have to provide shells to remote bozo users. They need every control imaginable to keep compromises contained to the utmost degree possible. There is no perfect defense, but there is also no such thing as a perfect attacker. >>As for writing a patch, I wrote a patch ("Requiring multiple auth mechanisms") a >>few weeks ago and submitted it to the list. I didn't get one useful bit of >>feedback, or any indication whatever that the maintainers even understood the >>purpose of the patch. > > We have lives outside of OpenSSH and sometimes we are too busy to > jump when you expect us to. Especially for patches against a 2 year > old version. The patch was against the version distributed by Red Hat. For many people, that's a convenience. I offered to update it if it would make any difference. Sounds like it might have, but I didn't hear anything either way. > Please post your patch to bugzilla, a service that is provided so > things like that don't get lost. Well, that's actual feedback, finally. Thanks for the suggestion. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From Jefferson.Ogata at noaa.gov Tue May 4 15:36:15 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Tue, 04 May 2004 01:36:15 -0400 Subject: Connection caching? In-Reply-To: <40971DE4.1000607@zip.com.au> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> Message-ID: <40972BCF.3030909@noaa.gov> Darren Tucker wrote: > Jefferson Ogata wrote: >> Damien Miller wrote: >>> Jefferson Ogata wrote: >>>> You're advocating a mechanism that renders one-time passwords >>>> useless against a remote client compromise. >>> >>> You miss the point: these controls are useless now, if they depend on >>> the integrity of an uncontrolled client. >> >> I wouldn't agree that they're useless, but they're clearly incomplete, >> hence the /need/ for a configuration directive. > > Let's imagine for a moment that the server restricts each client to only > one session. If the client is compromised, there's still nothing to > stop it from jamming, eg, "xterm -display my.evil.com:6000" into the > command line. Or pretending the connection was terminated and hijacking > the session outright. The former is what OTP is supposed to prevent. The latter requires an attacker of unusual skill. > What it boils down to is that once a client is authenticated, the server > is trusting it with the credentials of the user it allowed to log in. I keep mentioning OTP here... >> It disappoints me that you guys have so little concern about providing >> controllable authentication mechanisms. You really just don't get how >> dumb it is to have implemented this feature in the server /without/ >> having provided a configuration directive to control it, do you? > > > There's a limit to what the server can enforce. How, for example, could > it prevent a user from posting their passwordless private key to Usenet? > Or writing their passwords on Post-It notes and sticking them on their > monitor? Pointing a webcam at their SecurID token? I'm sure you'll > agree that these are insecure behaviours. Lazy users will do some of those things. But they won't typically scan a hardcopy S/KEY password list in and post it on a web page. If they do, they're not being lazy any more. Access control is supposed to be about authentication /and/ authorization. Authentication is ultimately your sole defense against intrusion. When authentication is compromised, authorization is your control on the scope of the compromise. What we have here is degraded control over authorization, and apparently it's been that way for some time. It is a reasonable expectation for an admin to be able to say: one authentication authorizes one session. If the admin wants to relax that control, fine, but it needs to be discretionary. >> As for writing a patch, I wrote a patch ("Requiring multiple auth >> mechanisms") a few weeks ago and submitted it to the list. I didn't >> get one useful bit of feedback, or any indication whatever that the >> maintainers even understood the purpose of the patch. > > I looked at it in conjunction with bug #701 (which is the > "PermitRootLogin without-password" thing). It occurred to me that a > more general mechanism could be a better solution for both. As usual, I > got sidetracked. That's certainly understandable. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From dtucker at zip.com.au Tue May 4 16:54:41 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 04 May 2004 16:54:41 +1000 Subject: Connection caching? In-Reply-To: <40972BCF.3030909@noaa.gov> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <40972BCF.3030909@noaa.gov> Message-ID: <40973E31.3050509@zip.com.au> Jefferson Ogata wrote: > Darren Tucker wrote: > >> Jefferson Ogata wrote: >> >>> Damien Miller wrote: >>> >>>> Jefferson Ogata wrote: >>>> >>>>> You're advocating a mechanism that renders one-time passwords >>>>> useless against a remote client compromise. >>>> >>>> >>>> You miss the point: these controls are useless now, if they depend on >>>> the integrity of an uncontrolled client. >>> >>> >>> I wouldn't agree that they're useless, but they're clearly >>> incomplete, hence the /need/ for a configuration directive. >> >> >> Let's imagine for a moment that the server restricts each client to >> only one session. If the client is compromised, there's still nothing >> to stop it from jamming, eg, "xterm -display my.evil.com:6000" into >> the command line. Or pretending the connection was terminated and >> hijacking the session outright. > > > The former is what OTP is supposed to prevent. Unless your OTP authenticates exactly one *command*, it won't stop a compromised client from injecting an extra command into an already authenticated login session. Your original statement was "You're advocating a mechanism that renders one-time password useless against a remote client compromise." What I'm saying is that even with your proposed modification, it's still useless against remote client compromise. > The latter requires an attacker of unusual skill. Not necessarily. Trivial example: set the user's login shell to "screen" on the machine running the ssh client, let them log in then kill their incoming TCP connection and resume their screen session. >> What it boils down to is that once a client is authenticated, the >> server is trusting it with the credentials of the user it allowed to >> log in. > > > I keep mentioning OTP here... See above. A compromised client can do nasty things after OTP authentication, whether it's limited to a single session or otherwise. [examples of insecure behaviour by users] > Lazy users will do some of those things. But they won't typically scan a > hardcopy S/KEY password list in and post it on a web page. If they do, > they're not being lazy any more. That's true. My point was that they can if they want to and the server can't stop it. Even with the changes you propose, a compromised client can run commands on the server after authentication and the server can't stop it. > Access control is supposed to be about authentication /and/ authorization. > Authentication is ultimately your sole defense against intrusion. When > authentication is compromised, authorization is your control on the > scope of the compromise. What we have here is degraded control over > authorization, and apparently it's been that way for some time. No, all we have here is another way for a user to do something that they can already do (ie run commands on the server). > It is a reasonable expectation for an admin to be able to say: one > authentication authorizes one session. If the admin wants to relax that > control, fine, but it needs to be discretionary. If "session" == "SSH session" that's what you've got now. What we're disagreeing about is the value of making additional restrictions within a single SSH session, for the reasons listed above. -- 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 Jefferson.Ogata at noaa.gov Tue May 4 17:27:12 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Tue, 04 May 2004 03:27:12 -0400 Subject: Connection caching? In-Reply-To: <40973E31.3050509@zip.com.au> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <40972BCF.3030909@noaa.gov> <40973E31.3050509@zip.com.au> Message-ID: <409745D0.406@noaa.gov> Darren Tucker wrote: > Jefferson Ogata wrote: >> The former is what OTP is supposed to prevent. > > Unless your OTP authenticates exactly one *command*, it won't stop a > compromised client from injecting an extra command into an already > authenticated login session. > > Your original statement was "You're advocating a mechanism that renders > one-time password useless against a remote client compromise." What I'm > saying is that even with your proposed modification, it's still useless > against remote client compromise. You wrote "useless", where the correct wording would be "useful but not totally secure." > > The latter requires an attacker of unusual skill. > > Not necessarily. Trivial example: set the user's login shell to > "screen" on the machine running the ssh client, let them log in then > kill their incoming TCP connection and resume their screen session. All of your scenarios (change user shell, hack client, etc.) are substantially more complex than: 1. Get user shell somehow. 2. ssh to anywhere the user is /already logged into/ without a passphrase, one-time password, fixed password, or /any authentication token whatsoever/. Do this as many times as you like. In this scenario, the user could have authenticated a month ago. You seem to be assuming the attacker will have many opportunities to piggyback on live authentications, while I'm concerned about latent sessions providing a way to bypass authentication altogether. >> I keep mentioning OTP here... > > See above. A compromised client can do nasty things after OTP > authentication, whether it's limited to a single session or otherwise. Again, these scenarios require a window for the intruder to prepare an attack, and require modification of system configure or user profile, either of which might be detected, and in any case, the user has to authenticate /after/ the attacker has done his thing. Any attempt to hijack an already authenticated session after the fact requires, as I said, an advanced attacker, not just some idiot who can type "ssh bozo at victim" and get in because bozo logged in to victim six weeks ago and left a shell running. >> Lazy users will do some of those things. But they won't typically scan >> a hardcopy S/KEY password list in and post it on a web page. If they >> do, they're not being lazy any more. > > That's true. My point was that they can if they want to and the server > can't stop it. Even with the changes you propose, a compromised client > can run commands on the server after authentication and the server can't > stop it. No, the server can't stop it completely. But a user's being able to exceed the limitations of sshd because he has an unrestricted shell is vastly different from sshd not providing hooks to limit authorization. >> It is a reasonable expectation for an admin to be able to say: one >> authentication authorizes one session. If the admin wants to relax >> that control, fine, but it needs to be discretionary. > > If "session" == "SSH session" that's what you've got now. What we're > disagreeing about is the value of making additional restrictions within > a single SSH session, for the reasons listed above. By session, I mean a remote shell or command (albeit composite) invocation, obviously. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From kumaresh_ind at gmx.net Tue May 4 20:05:15 2004 From: kumaresh_ind at gmx.net (Kumaresh) Date: Tue, 4 May 2004 15:35:15 +0530 Subject: Error with USE_POSIX_THREADS and OpenSSH-3.8p1 Message-ID: <040a01c431bf$54711c30$230110ac@kurco> Hello, I am using OpenSSH-3.8p1 on HP-UX machine with USE_POSIX_THREADS option. This is for making the kerberos credentials file to be created in the system with PAM. In OpenSSH versions 3.5 when authentication is done with pam kerberos, a /tmp/krb5cc_X_Y file is created on the server side. But the KRB5CCNAME variable is not set by default. So, after we manually set this environment variable, the klist command get the keys from this file. But, in OpenSSH-3.7 and 3.8, this is not working. That is, the /tmp/krb5cc_X_Y file is not created. That is., in normal build [without POSIX_THREADS], when the system is authenticated with PAM-Kerberos, the "/tmp/krb5cc_X_Y" file is not created and the KRB5CCNAME env variable is not set. So, klist is not working. In order to make this success, based on mailing list discussions we got that that pam_authenticate() function is being called in forked process and based on the recommendation in the list, we enabled USE_POSIX_THREADS and we got the following buffer error on the server side when ssh connection is attempted. This is not the case with OpenSSH-3.7.1p2. It works when USE_POSIX_THREADS is enabled.But, 3.8p1 closed with this error in the server side. ------ debug3: pam_password_change_required 0 debug3: PAM: num env strings 0 buffer_get: trying to get more bytes 4 than in buffer 0 debug1: do_cleanup debug1: PAM: cleanup debug3: PAM: sshpam_thread_cleanup entering ------- To fix this, we have done some changes in auth-pam.c and session.c [1]. We are not sure that this is the exact fix for this though this works for PAM_Kerberos and PAM_unix with normal mode. But, in trusted mode, with PAM_UNIX, the password change prompt is being asked for the first login and it succeedes until the password is changed. Once the password is changed, the connection hangs at channel read/write. We can see some pty related error in the server side, and the error we see is ----- debug1: Allocating pty. openpty: Bad file number session_pty_req: session 0 alloc failed ----- We have attached the debug statements for ssh and sshd [2]. There are some statements in that those we have added for debugging purpose. This is for information. Anybody else tried USE_POSIX_THREADS in OpenSSH-3.8p1 and PAM-unix in trusted mode. Any help will be much appreciated. Attachments: ========= [1] - sshd_ssh_pam_debug_apr29.txt [2] - diff_with_use+posix_threads_ssh38.txt Thanks, Kumar. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sshd_ssh_pam_debug_apr29.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040504/a2b5043c/attachment.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff_with_use_posix_threads_ssh38.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040504/a2b5043c/attachment-0001.txt From dtucker at zip.com.au Tue May 4 20:28:02 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 04 May 2004 20:28:02 +1000 Subject: Error with USE_POSIX_THREADS and OpenSSH-3.8p1 In-Reply-To: <040a01c431bf$54711c30$230110ac@kurco> References: <040a01c431bf$54711c30$230110ac@kurco> Message-ID: <40977032.5050909@zip.com.au> Kumaresh wrote: > This is not the case with > OpenSSH-3.7.1p2. It works when USE_POSIX_THREADS is enabled.But, 3.8p1 > closed with this error in the server side. > debug3: pam_password_change_required 0 > debug3: PAM: num env strings 0 > buffer_get: trying to get more bytes 4 than in buffer 0 This is already fixed in 3.8.1p1. > debug1: Allocating pty. > openpty: Bad file number I don't know why openpty() is failing. Does the same thing happen with 3.8.1p1? > Anybody else tried USE_POSIX_THREADS in OpenSSH-3.8p1 and PAM-unix in > trusted mode. I've never tried that. > + if ((cp = getenv("KRB5CCNAME")) != NULL) { > + child_set_env(&env, &envsize, "KRB5CCNAME", cp); > + copy_environment(&cp, &env, &envsize); Since we're now clearing KRB5CCNAME when sshd starts, I'm wondering if we should just move the existing KRB5CCNAME block from inside the #ifdef _AIX block and run it for all platforms. That way any platform that sets it will copy it to the child, but any that don't (which should be most of them) will not. -- 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 Tue May 4 20:46:43 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 04 May 2004 20:46:43 +1000 Subject: Error with USE_POSIX_THREADS and OpenSSH-3.8p1 In-Reply-To: <040a01c431bf$54711c30$230110ac@kurco> References: <040a01c431bf$54711c30$230110ac@kurco> Message-ID: <40977493.40609@zip.com.au> Kumaresh wrote: > debug1: Allocating pty. > openpty: Bad file number Please try running it with this patch in debug mode, it should give a better idea with openpty (which is a compatibility function on HP-UX) is failing. -- 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-hpux-openptydebug.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040504/6c8d86c9/attachment.ksh From dot at dotat.at Tue May 4 20:52:02 2004 From: dot at dotat.at (Tony Finch) Date: Tue, 04 May 2004 11:52:02 +0100 Subject: Connection caching? In-Reply-To: <20040502131525.M26458@greenie.muc.de> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <4094BBCA.8090205@mindrot.org> Message-ID: Gert Doering wrote: >On Sun, May 02, 2004 at 07:13:46PM +1000, Damien Miller wrote: >> One you have established a SSH transport, you can fire off lots of >> sessions (command, shell or subsystem) which have independant >> lifespans. > >Putty also supports this. Quite impressive, actually. You are wrong. http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/ssh2-generality.html The "duplicate session" function opens a new connection. Tony. -- f.a.n.finch http://dotat.at/ PORTLAND PLYMOUTH: SOUTHWEST VEERING NORTHWEST 5 TO 7, OCCASIONALLY GALE 8, PERHAPS SEVERE GALE 9 LATER IN PLYMOUTH. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD. From kumaresh_ind at gmx.net Tue May 4 21:17:05 2004 From: kumaresh_ind at gmx.net (Kumaresh) Date: Tue, 4 May 2004 16:47:05 +0530 Subject: Error with USE_POSIX_THREADS and OpenSSH-3.8p1 References: <040a01c431bf$54711c30$230110ac@kurco> <40977493.40609@zip.com.au> Message-ID: <114001c431c9$62e35670$230110ac@kurco> > Kumaresh wrote: > > debug1: Allocating pty. > > openpty: Bad file number > > Please try running it with this patch in debug mode, it should give a > better idea with openpty (which is a compatibility function on HP-UX) is > failing. Thanks for the patch. I have already tried this and found that grantpt() failed. grantpt() returns "-1". Regards, Kumar From dtucker at zip.com.au Tue May 4 21:50:09 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 04 May 2004 21:50:09 +1000 Subject: Error with USE_POSIX_THREADS and OpenSSH-3.8p1 In-Reply-To: <114001c431c9$62e35670$230110ac@kurco> References: <040a01c431bf$54711c30$230110ac@kurco> <40977493.40609@zip.com.au> <114001c431c9$62e35670$230110ac@kurco> Message-ID: <40978371.3090508@zip.com.au> Kumaresh wrote: > I have already tried this and found that grantpt() failed. grantpt() returns > "-1". And from the debugging, we know that the errno is EBADF (Bad file number). From the grantpt man page (HP-UX 11.00): Failure may result under the following conditions: o The file descriptor specified by the fildes parameter is not an open file descriptor. o The file descriptor specified by the fildes parameter is not associated with a STREAMS master pty device. o The corresponding slave pty device cannot be accessed. Now #1 can't be true, otherwise openpty would have failed after the open(). #2 should not be true either, since it was only just opened. And if it was #3 I would have expected EACCES. What's the perms on /dev/ptmx? Maybe you could run ssh -D under tusc (which is an unsupported truss/strace equivalent for HPUX) for clues abour what it's doing? BTW, what HP-UX version are you using? -- 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 gert at greenie.muc.de Tue May 4 22:00:23 2004 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 4 May 2004 14:00:23 +0200 Subject: Connection caching? In-Reply-To: ; from dot@dotat.at on Tue, May 04, 2004 at 11:52:02AM +0100 References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <4094BBCA.8090205@mindrot.org> <20040502131525.M26458@greenie.muc.de> Message-ID: <20040504140023.K3896@greenie.muc.de> Hi, On Tue, May 04, 2004 at 11:52:02AM +0100, Tony Finch wrote: > >Putty also supports this. Quite impressive, actually. > > You are wrong. > > http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/ssh2-generality.html > > The "duplicate session" function opens a new connection. Hmmm. I was sure I didn't have to re-authenticate when I tried this last time. But seems I was wrong. In that case: sorry for spreading nonsense. I will need to try this again as soon as I can find a windows machine. gert -- Gert Doering Mobile communications ... right now writing from * RIPE48 / Amsterdam * From kumaresh_ind at gmx.net Tue May 4 22:16:07 2004 From: kumaresh_ind at gmx.net (Kumaresh) Date: Tue, 4 May 2004 17:46:07 +0530 Subject: Error with USE_POSIX_THREADS and OpenSSH-3.8p1 References: <040a01c431bf$54711c30$230110ac@kurco> <40977032.5050909@zip.com.au> Message-ID: <001e01c431d1$99f1c0e0$230110ac@kurco> > Kumaresh wrote: > > > This is not the case with > > OpenSSH-3.7.1p2. It works when USE_POSIX_THREADS is enabled.But, 3.8p1 > > closed with this error in the server side. > > debug3: pam_password_change_required 0 > > debug3: PAM: num env strings 0 > > buffer_get: trying to get more bytes 4 than in buffer 0 > > This is already fixed in 3.8.1p1. Yes. Thanks. 3.8.1p1 succcessfully works with my requirement. And I can see the "ifndef USE_POSIX_THREADS" definition in the import_environments() function in auth-pam.c and I suspect this is the key. I am not sure, but yet to get the complete diff of the source. Thanks again. > I don't know why openpty() is failing. Does the same thing happen with > 3.8.1p1? > > > Anybody else tried USE_POSIX_THREADS in OpenSSH-3.8p1 and PAM-unix in > > trusted mode. > > I've never tried that. > > > + if ((cp = getenv("KRB5CCNAME")) != NULL) { > > + child_set_env(&env, &envsize, "KRB5CCNAME", cp); > > + copy_environment(&cp, &env, &envsize); > > Since we're now clearing KRB5CCNAME when sshd starts, I'm wondering if > we should just move the existing KRB5CCNAME block from inside the #ifdef > _AIX block and run it for all platforms. That way any platform that > sets it will copy it to the child, but any that don't (which should be > most of them) will not. I am using HP-UX 11.23 and this code has to be out of AIX or atleast can be included for HP-UX also. Because, the env variable is being set only if this code is in place and USE_POSIX_THREADS. So, I believe this is required for HP-UX. Regards, Kumar From stuge-openssh-unix-dev at cdy.org Tue May 4 22:31:46 2004 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Tue, 4 May 2004 14:31:46 +0200 Subject: Connection caching? In-Reply-To: <409745D0.406@noaa.gov> <40972BCF.3030909@noaa.gov> <409706E9.2060700@noaa.gov> References: <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> Message-ID: <20040504123146.GC3056@foo.birdnet.se> On Mon, May 03, 2004 at 10:58:49PM -0400, Jefferson Ogata wrote: > It disappoints me that you guys have so little concern about providing > controllable authentication mechanisms. You really just don't get how dumb > it is to have implemented this feature in the server /without/ having > provided a configuration directive to control it, do you? >From draft-ietf-secsh-architecture-15.txt: 9.4 Connection protocol 9.4.1 End point security End point security is assumed by the connection protocol. If the server has been compromised, any terminal sessions, port forwarding, or systems accessed on the host are compromised. There are no mitigating factors for this. If the client end point has been compromised, and the server fails to stop the attacker at the authentication protocol, all services exposed (either as subsystems or through forwarding) will be vulnerable to attack. Implementors SHOULD provide mechanisms for administrators to control which services are exposed to limit the vulnerability of other services. These controls might include controlling which machines and ports can be target in 'port-forwarding' operations, which users are allowed to use interactive shell facilities, or which users are allowed to use exposed subsystems. >From draft-ietf-secsh-connect-18.txt: 5. Channel Mechanism All terminal sessions, forwarded connections, etc. are channels. Either side may open a channel. Multiple channels are multiplexed into a single connection. (Sorry for pasting so much into this thread..) On Tue, May 04, 2004 at 01:36:15AM -0400, Jefferson Ogata wrote: > >>I wouldn't agree that they're useless, but they're clearly incomplete, > >>hence the /need/ for a configuration directive. > > > >Let's imagine for a moment that the server restricts each client to only > >one session. If the client is compromised, there's still nothing to > >stop it from jamming, eg, "xterm -display my.evil.com:6000" into the > >command line. Or pretending the connection was terminated and hijacking > >the session outright. > > The former is what OTP is supposed to prevent. The latter requires an > attacker of unusual skill. Compared to breaking the SSH authentication I don't think it requires all that much skill. This is getting political, but if your attacker wants in, he can get it. I realize you don't want to protect against attackers, rather against lazy users but that would IMHO be solved by crond as with most other cleaning-up. :) > >What it boils down to is that once a client is authenticated, the > >server is trusting it with the credentials of the user it allowed > >to log in. > > I keep mentioning OTP here... Please read up on the above mentioned secsh drafts, OTP can be used for authentication of one SSHv2 session, which in turn can carry multiple channels where a shell or a command is executed in each. > >There's a limit to what the server can enforce. How, for example, could > >it prevent a user from posting their passwordless private key to Usenet? > > Or writing their passwords on Post-It notes and sticking them on their > >monitor? Pointing a webcam at their SecurID token? I'm sure you'll > >agree that these are insecure behaviours. > > Lazy users will do some of those things. But they won't typically scan a > hardcopy S/KEY password list in and post it on a web page. If they do, > they're not being lazy any more. Right. With SSHv2 plus the ssh-session-agent all the attacker (sorry, lazy user) has to do is to hijack the socket instead of the terminal. I lack statistics to back this, but I think the terminal is easier to reach, because of human error. > Access control is supposed to be about authentication /and/ authorization. > Authentication is ultimately your sole defense against intrusion. When > authentication is compromised, authorization is your control on the scope > of the compromise. What we have here is degraded control over > authorization, and apparently it's been that way for some time. Yep, ever since support for multiple channels in SSHv2 was added. > It is a reasonable expectation for an admin to be able to say: one > authentication authorizes one session. If the admin wants to relax that > control, fine, but it needs to be discretionary. I'm not sure I read the SSHv2 drafts the same way.. They could of course be improved, just like everything else, but if you want to help with that (please do!) I'd suggest the ietf-secsh mailing list instead of openssh-unix-dev. On Tue, May 04, 2004 at 03:27:12AM -0400, Jefferson Ogata wrote: > >Unless your OTP authenticates exactly one *command*, it won't stop a > >compromised client from injecting an extra command into an already > >authenticated login session. > > > >Your original statement was "You're advocating a mechanism that renders > >one-time password useless against a remote client compromise." What I'm > >saying is that even with your proposed modification, it's still useless > >against remote client compromise. > > You wrote "useless", where the correct wording would be "useful but not > totally secure." SSHv2 puts all the security in the Transport Layer, anything on top of that shouldn't try to impose more restrictions except for, as quoted above, which users are allowed access to what services. > > > The latter requires an attacker of unusual skill. > > > >Not necessarily. Trivial example: set the user's login shell to > >"screen" on the machine running the ssh client, let them log in then > >kill their incoming TCP connection and resume their screen session. > > All of your scenarios (change user shell, hack client, etc.) are > substantially more complex than: > > 1. Get user shell somehow. This is substantially complex on most all systems I know. I admit I don't know all of the systems out there, though. [..] > In this scenario, the user could have authenticated a month ago. You > seem to be assuming the attacker will have many opportunities to > piggyback on live authentications, while I'm concerned about latent > sessions providing a way to bypass authentication altogether. So make sure users log out using e.g. crond? > Again, these scenarios require a window for the intruder to prepare an > attack, and require modification of system configure or user profile, > either of which might be detected, and in any case, the user has to > authenticate /after/ the attacker has done his thing. Any attempt to > hijack an already authenticated session after the fact requires, as I > said, an advanced attacker, not just some idiot who can type "ssh > bozo at victim" and get in because bozo logged in to victim six weeks ago > and left a shell running. Publish a system policy and kick the bozo out after a day. :) > No, the server can't stop it completely. But a user's being able to > exceed the limitations of sshd because he has an unrestricted shell > is vastly different from sshd not providing hooks to limit > authorization. It's not a bug, it's a feature, hehe. > >>It is a reasonable expectation for an admin to be able to say: one > >>authentication authorizes one session. If the admin wants to relax > >>that control, fine, but it needs to be discretionary. > > > >If "session" == "SSH session" that's what you've got now. What we're > >disagreeing about is the value of making additional restrictions > >within a single SSH session, for the reasons listed above. > > By session, I mean a remote shell or command (albeit composite) > invocation, obviously. Not so obvious if you work a lot with the SSH protocol, since the conecpt of a session is standardized there. It seems that what you really want is some kind of system where the user has to authenticate before every action she takes. This could be accomplished with a custom shell, or an application server, or... I'm not sure it really should be done with sshd? It compares well with chroot()ing sftp users.. //Peter From dtucker at zip.com.au Tue May 4 22:32:26 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 04 May 2004 22:32:26 +1000 Subject: Error with USE_POSIX_THREADS and OpenSSH-3.8p1 In-Reply-To: <001e01c431d1$99f1c0e0$230110ac@kurco> References: <040a01c431bf$54711c30$230110ac@kurco> <40977032.5050909@zip.com.au> <001e01c431d1$99f1c0e0$230110ac@kurco> Message-ID: <40978D5A.9050407@zip.com.au> Kumaresh wrote: > I am using HP-UX 11.23 and this code has to be out of AIX or atleast can be > included for HP-UX also. Because, the env variable is being set only if this > code is in place and USE_POSIX_THREADS. So, I believe this is required for > HP-UX. The attached patch is what I'm thinking of. (It would also fix bug #445). USE_POSIX_THREAD will probably go away as soon as there is a better fix for the krb/PAM issue, see: http://bugzilla.mindrot.org/show_bug.cgi?id=688 -- 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-krb5ccname.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040504/67cdaf2e/attachment.ksh From stuge-openssh-unix-dev at cdy.org Tue May 4 22:32:42 2004 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Tue, 4 May 2004 14:32:42 +0200 Subject: Connection caching? In-Reply-To: <20040504140023.K3896@greenie.muc.de> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <4094BBCA.8090205@mindrot.org> <20040502131525.M26458@greenie.muc.de> <20040504140023.K3896@greenie.muc.de> Message-ID: <20040504123242.GD3056@foo.birdnet.se> On Tue, May 04, 2004 at 02:00:23PM +0200, Gert Doering wrote: > > The "duplicate session" function opens a new connection. > > Hmmm. I was sure I didn't have to re-authenticate when I tried this > last time. Maybe you had pageant running with your key? :) //Peter From chris at obelix.hedonism.cx Wed May 5 04:23:12 2004 From: chris at obelix.hedonism.cx (Christian Vogel) Date: Tue, 4 May 2004 20:23:12 +0200 Subject: Connection caching? In-Reply-To: <409745D0.406@noaa.gov>; from Jefferson.Ogata@noaa.gov on Tue, May 04, 2004 at 03:27:12AM -0400 References: <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <40972BCF.3030909@noaa.gov> <40973E31.3050509@zip.com.au> <409745D0.406@noaa.gov> Message-ID: <20040504202312.B9389@obelix.frop.org> Hi Jefferson, hi openssh-unix-dev, On Tue, May 04, 2004 at 03:27:12AM -0400, Jefferson Ogata wrote: > > If "session" == "SSH session" that's what you've got now. What we're > > disagreeing about is the value of making additional restrictions within > > a single SSH session, for the reasons listed above. > By session, I mean a remote shell or command (albeit composite) invocation, > obviously. Isn't a configuration option "MaxNumberOfChannels" exactly what you are looking for Jefferson? Set it to 1 and it would do what you expect, disabling the use of more than one concurrent session. Seems easy to implement to me, would that be accepted by the maintainers? Is my view of the ssh-protocol to naive? :-) This could have either semantic of: - allow only N concurrent channels at a time - limit the creation of channels in one session to N Chris -- Windows (ms): Will install needless data on whole system From grif at cs.ucr.edu Wed May 5 13:14:06 2004 From: grif at cs.ucr.edu (grif at cs.ucr.edu) Date: Wed, 5 May 2004 00:14:06 -0300 Subject: approved excel document Message-ID: <20040505032142.30E1827C187@shitei.mindrot.org> Your document. From Jefferson.Ogata at noaa.gov Wed May 5 15:56:22 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Wed, 05 May 2004 01:56:22 -0400 Subject: Connection caching? In-Reply-To: <20040504202312.B9389@obelix.frop.org> References: <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <40972BCF.3030909@noaa.gov> <40973E31.3050509@zip.com.au> <409745D0.406@noaa.gov> <20040504202312.B9389@obelix.frop.org> Message-ID: <40988206.2000602@noaa.gov> Christian Vogel wrote: > Hi Jefferson, hi openssh-unix-dev, Hi, Christian... > Isn't a configuration option "MaxNumberOfChannels" exactly what you are looking for > Jefferson? Set it to 1 and it would do what you expect, disabling the use of more than > one concurrent session. Seems easy to implement to me, would that be accepted > by the maintainers? Is my view of the ssh-protocol to naive? :-) > > This could have either semantic of: > > - allow only N concurrent channels at a time > - limit the creation of channels in one session to N I was thinking something along those lines. But I believe port forwarding, X11 forwarding, agent forwarding, and perhaps other activities each consume a "channel" throughout the life of an established ssh session. What's really needed is a limit on the number of shell channels allowed in a single ssh session. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From johnpell at mac.com Wed May 5 16:07:59 2004 From: johnpell at mac.com (John Davidorff Pell) Date: Tue, 4 May 2004 23:07:59 -0700 Subject: Connection caching? In-Reply-To: <40972BCF.3030909@noaa.gov> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <40972BCF.3030909@noaa.gov> Message-ID: <8F64D0AB-9E5A-11D8-98D1-0003934F6406@mac.com> Can I ask you (or someone else) to define "session"? I can think of a number of reasons that a single shell/pipe can carry many different "sessions". Just trying to follow the discussion, and this part is a little confusing. :-) JP On 3 May 2004, at 22:36, Jefferson Ogata wrote: > It is a reasonable expectation for an admin to be able to say: one > authentication authorizes one session. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2426 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040504/aa2467b7/attachment.bin From Jefferson.Ogata at noaa.gov Wed May 5 16:27:25 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Wed, 05 May 2004 02:27:25 -0400 Subject: Connection caching? In-Reply-To: <20040504123146.GC3056@foo.birdnet.se> References: <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <20040504123146.GC3056@foo.birdnet.se> Message-ID: <4098894D.1070705@noaa.gov> Peter Stuge wrote: > On Mon, May 03, 2004 at 10:58:49PM -0400, Jefferson Ogata wrote: >>It disappoints me that you guys have so little concern about providing >>controllable authentication mechanisms. You really just don't get how dumb >>it is to have implemented this feature in the server /without/ having >>provided a configuration directive to control it, do you? > >>From draft-ietf-secsh-architecture-15.txt: > > 9.4 Connection protocol > > 9.4.1 End point security > > End point security is assumed by the connection protocol. If the > server has been compromised, any terminal sessions, port forwarding, > or systems accessed on the host are compromised. There are no > mitigating factors for this. That statement is simply untrue. We can certainly imagine, and no doubt find, a trusted system where the compromise of a user's login does not lead to any ability for an intruder to interfere with, eavesdrop on, or modify established sessions belonging to that user -- a system where perhaps ptrace is disabled and ptys are chowned to root or unlinked after opening, and where no process memory image is available. The intruder might still change the behavior of future logins by the user, but not any already existing ones. In this case, perhaps an intruder can arrange that, the next time the user authenticates to a remote system, the intruder can take control of the new session. But meanwhile there is a real opportunity for the compromise to be discovered /before/ it results in a remote compromise via a new ssh shell channel. ...Unless the ssh server supports creating new shell sessions over an already authenticated session. With the functionality currently under debate, as soon as an intruder gets into a user account, he can immediately get onto any system for which a "cached connection" is available. A limit within sshd on the number of shell channels per ssh session mitigates against this attack. > If the client end point has been compromised, and the server fails to > stop the attacker at the authentication protocol, all services > exposed (either as subsystems or through forwarding) will be > vulnerable to attack. Implementors SHOULD provide mechanisms for > administrators to control which services are exposed to limit the > vulnerability of other services. Which is, in fact, what I am asking for. > These controls might include controlling which machines and ports can > be target in 'port-forwarding' operations, which users are allowed to > use interactive shell facilities, or which users are allowed to use > exposed subsystems. I would certain read that to allow limiting the number of shell channels per successful authentication. >>From draft-ietf-secsh-connect-18.txt: > > 5. Channel Mechanism > > All terminal sessions, forwarded connections, etc. are channels. > Either side may open a channel. Multiple channels are multiplexed > into a single connection. > > (Sorry for pasting so much into this thread..) > > On Tue, May 04, 2004 at 01:36:15AM -0400, Jefferson Ogata wrote: >>>>I wouldn't agree that they're useless, but they're clearly incomplete, >>>>hence the /need/ for a configuration directive. >>> >>>Let's imagine for a moment that the server restricts each client to only >>>one session. If the client is compromised, there's still nothing to >>>stop it from jamming, eg, "xterm -display my.evil.com:6000" into the >>>command line. Or pretending the connection was terminated and hijacking >>>the session outright. >> >>The former is what OTP is supposed to prevent. The latter requires an >>attacker of unusual skill. > > Compared to breaking the SSH authentication I don't think it requires > all that much skill. This is getting political, but if your attacker > wants in, he can get it. I realize you don't want to protect against > attackers, rather against lazy users but that would IMHO be solved by > crond as with most other cleaning-up. :) Suggestion noted, but shouldn't be necessary. More later... >>>What it boils down to is that once a client is authenticated, the >>>server is trusting it with the credentials of the user it allowed >>>to log in. >> >>I keep mentioning OTP here... > > Please read up on the above mentioned secsh drafts, OTP can be used for > authentication of one SSHv2 session, which in turn can carry multiple > channels where a shell or a command is executed in each. In the model currently used by the openssh client, only one channel is used for a shell session; other channels are used for port, X11, etc. forwarding. Given that this is the way the openssh client behaves now, I can't see how it's any great horror to allow the server to enforce the current behavior. >>>There's a limit to what the server can enforce. How, for example, could >>>it prevent a user from posting their passwordless private key to Usenet? >>>Or writing their passwords on Post-It notes and sticking them on their >>>monitor? Pointing a webcam at their SecurID token? I'm sure you'll >>>agree that these are insecure behaviours. >> >>Lazy users will do some of those things. But they won't typically scan a >>hardcopy S/KEY password list in and post it on a web page. If they do, >>they're not being lazy any more. > > Right. With SSHv2 plus the ssh-session-agent all the attacker (sorry, > lazy user) has to do is to hijack the socket instead of the terminal. > I lack statistics to back this, but I think the terminal is easier to > reach, because of human error. I don't think hijacking the socket works -- key exchange runs before authentication. The attacker needs to know the shared key to do anything useful with the hijacked socket. >>Access control is supposed to be about authentication /and/ authorization. >>Authentication is ultimately your sole defense against intrusion. When >>authentication is compromised, authorization is your control on the scope >>of the compromise. What we have here is degraded control over >>authorization, and apparently it's been that way for some time. > > Yep, ever since support for multiple channels in SSHv2 was added. > >>It is a reasonable expectation for an admin to be able to say: one >>authentication authorizes one session. If the admin wants to relax that >>control, fine, but it needs to be discretionary. > > I'm not sure I read the SSHv2 drafts the same way.. They could of > course be improved, just like everything else, but if you want to help > with that (please do!) I'd suggest the ietf-secsh mailing list instead > of openssh-unix-dev. Suggestion noted. > On Tue, May 04, 2004 at 03:27:12AM -0400, Jefferson Ogata wrote: >>>Unless your OTP authenticates exactly one *command*, it won't stop a >>>compromised client from injecting an extra command into an already >>>authenticated login session. >>> >>>Your original statement was "You're advocating a mechanism that renders >>>one-time password useless against a remote client compromise." What I'm >>>saying is that even with your proposed modification, it's still useless >>>against remote client compromise. >> >>You wrote "useless", where the correct wording would be "useful but not >>totally secure." > > SSHv2 puts all the security in the Transport Layer, anything on top > of that shouldn't try to impose more restrictions except for, as quoted > above, which users are allowed access to what services. I don't read it the way you do. Let's suppose a user logs into a system that allows X11 forwarding and has a 256 per-process file descriptor hard limit. The user proceeds to forward 255 X11 connections, using up all the available descriptors. I somehow doubt sshd has a suitable architecture to provide any more channels in this situation. We would accept that the next attempt to allocate a channel would fail on account of a hard resource limit being imposed by OS policy. So why would compliance with ssh v2 demand that the ssh server cannot give the admin a means to impose a resource limit on the number of shell channels? >>>>The latter requires an attacker of unusual skill. >>> >>>Not necessarily. Trivial example: set the user's login shell to >>>"screen" on the machine running the ssh client, let them log in then >>>kill their incoming TCP connection and resume their screen session. >> >>All of your scenarios (change user shell, hack client, etc.) are >>substantially more complex than: >> >>1. Get user shell somehow. > > This is substantially complex on most all systems I know. I admit I > don't know all of the systems out there, though. But it's assumed in all scenarios. I just put it in so there would be two steps rather than just one. > [..] > >>In this scenario, the user could have authenticated a month ago. You >>seem to be assuming the attacker will have many opportunities to >>piggyback on live authentications, while I'm concerned about latent >>sessions providing a way to bypass authentication altogether. > > So make sure users log out using e.g. crond? Again, shouldn't have to. Besides, no matter how short an idle time we allow, there is still a window for an attack to be successful. >>Again, these scenarios require a window for the intruder to prepare an >>attack, and require modification of system configure or user profile, >>either of which might be detected, and in any case, the user has to >>authenticate /after/ the attacker has done his thing. Any attempt to >>hijack an already authenticated session after the fact requires, as I >>said, an advanced attacker, not just some idiot who can type "ssh >>bozo at victim" and get in because bozo logged in to victim six weeks ago >>and left a shell running. > > Publish a system policy and kick the bozo out after a day. :) If only... :^) Still -- one day attack window. >>No, the server can't stop it completely. But a user's being able to >>exceed the limitations of sshd because he has an unrestricted shell >>is vastly different from sshd not providing hooks to limit >>authorization. > > It's not a bug, it's a feature, hehe. That's what they all say. :^) >>>>It is a reasonable expectation for an admin to be able to say: one >>>>authentication authorizes one session. If the admin wants to relax >>>>that control, fine, but it needs to be discretionary. >>> >>>If "session" == "SSH session" that's what you've got now. What we're >>>disagreeing about is the value of making additional restrictions >>>within a single SSH session, for the reasons listed above. >> >>By session, I mean a remote shell or command (albeit composite) >>invocation, obviously. > > Not so obvious if you work a lot with the SSH protocol, since the > conecpt of a session is standardized there. I think the context was clear here, and yes, I've referred to ssh sessions elsewhere. But I'm trying to be tighter with the terminology so there aren't any more misunderstandings. > It seems that what you really want is some kind of system where the > user has to authenticate before every action she takes. This could be > accomplished with a custom shell, or an application server, or... I want the user to have to authenticate to get a new shell. But now that you mention it, it's an interesting idea to require authentication for each port forwarding action. Not sure there's any way to prompt in the existing paradigm tho. > I'm not sure it really should be done with sshd? It compares well with > chroot()ing sftp users.. I think it's more general than that. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From Jefferson.Ogata at noaa.gov Wed May 5 16:29:40 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Wed, 05 May 2004 02:29:40 -0400 Subject: Connection caching? In-Reply-To: <8F64D0AB-9E5A-11D8-98D1-0003934F6406@mac.com> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <40972BCF.3030909@noaa.gov> <8F64D0AB-9E5A-11D8-98D1-0003934F6406@mac.com> Message-ID: <409889D4.2070106@noaa.gov> John Davidorff Pell wrote: > Can I ask you (or someone else) to define "session"? I can think of a > number of reasons that a single shell/pipe can carry many different > "sessions". > > Just trying to follow the discussion, and this part is a little > confusing. :-) > > On 3 May 2004, at 22:36, Jefferson Ogata wrote: > >> It is a reasonable expectation for an admin to be able to say: one >> authentication authorizes one session. It is a reasonable expectation for an admin to be able to say: one successful authentication authorizes only one shell channel. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From johnpell at mac.com Wed May 5 17:15:00 2004 From: johnpell at mac.com (John Davidorff Pell) Date: Wed, 5 May 2004 00:15:00 -0700 Subject: Connection caching? In-Reply-To: <409889D4.2070106@noaa.gov> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <40972BCF.3030909@noaa.gov> <8F64D0AB-9E5A-11D8-98D1-0003934F6406@mac.com> <409889D4.2070106@noaa.gov> Message-ID: I agree with you, but in the interests of expanding my own understanding, I'm going to play devil's advocate. If the client is compromised, then the attacker can easily use the existing shell channel: by breaking into the ptys, by hijacking the process, or by taking control of the actual physical terminal, among other ways. Some require advanced attacks, some require strolling over to the so-and-so's desk before so-and-so's screen saver picks up. At this point, one command can easily add an alternate private-key to the remote account, and thus provide outside, unrestricted, unmonitored access. One can also issue one command to do immediate damage ("rm -rf ~ &"). In order to hijack a "cached" connection, one must have (local) shell access as user 'foo' (or root), to execute "ssh bar at existing.conneciton". In order to hijack an existing, non-cached connection, one must have local shell access as user 'foo', to execute one of the many tools that can "hijack" a pty. At this point, there is little-to-no expectation of security. The difference? In one case the command is simple and obvious. In the other, the attacker must use a command that takes over an existing pty, which is sometimes already present on the system. specifically, I'm thinking of something like GNU Screen or even something a little more specific. Something like that is not hard to write, especially if we're talking about an insecure client system. You're advocating security through obscurity. If the attacker does not know how to hijack an existing pty, then he/she will likely not be able to do any damage on the remote system besides obvious "lets screw with foo's files" which he/she can do on the local system anyway. This is foo's problem, not the server's. If the "hijacker" can hijack the pty, then the server is in a much more vulnerable position and is in the same position now as it would be after a 2nd shell "session" over the already-authenticated connection. :-) JP On 4 May 2004, at 23:29, Jefferson Ogata wrote: > It is a reasonable expectation for an admin to be able to say: one > successful authentication authorizes only one shell channel. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2426 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040505/47d4ab2d/attachment.bin From Jefferson.Ogata at noaa.gov Wed May 5 18:31:15 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Wed, 05 May 2004 04:31:15 -0400 Subject: Connection caching? In-Reply-To: References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <40972BCF.3030909@noaa.gov> <8F64D0AB-9E5A-11D8-98D1-0003934F6406@mac.com> <409889D4.2070106@noaa.gov> Message-ID: <4098A653.9070801@noaa.gov> John Davidorff Pell wrote: > I agree with you, but in the interests of expanding my own > understanding, I'm going to play devil's advocate. Fine. > If the client is compromised, then the attacker can easily use the > existing shell channel: by breaking into the ptys, by hijacking the > process, or by taking control of the actual physical terminal, among > other ways. Some require advanced attacks, some require strolling over > to the so-and-so's desk before so-and-so's screen saver picks up. At > this point, one command can easily add an alternate private-key to the > remote account, and thus provide outside, unrestricted, unmonitored > access. One can also issue one command to do immediate damage ("rm -rf ~ > &"). You're making a lot of assumptions. Let's go through one more scenario, and please read and understand this carefully: Suppose we set up ssh as a secure gateway. sshd is chrooted with the only writable filesystem (/tmp) mounted noexec. Users' home directories are read-only. No one can add binaries to the system, and users can execute only the programs I provide in the chroot hierarchy. Once a user logs in to the chrooted sshd, he can ssh from there to a secure system, but has to authenticate a second time to do so. Now suppose an intruder somehow intercepts a user's password or private key for accessing the gateway, and then logs in to the gateway. Without "connection caching", the intruder can go no further. He can play around on the gateway with the few commands available, but he doesn't have a pty-hijacking program and there's no way for him to add one. The user's home directory is read-only so he can't modify the user's .profile to alias ssh to something else. So the intruder can't get onto the secure system, and the compromise is contained. Now you add connection caching, and the compromise is no longer contained. If the user is legitimately logged from the gateway into the secure system, the intruder can now log in to the secure system, as many times as he likes. > In order to hijack a "cached" connection, one must have (local) shell > access as user 'foo' (or root), to execute "ssh > bar at existing.conneciton". In order to hijack an existing, non-cached > connection, one must have local shell access as user 'foo', to execute > one of the many tools that can "hijack" a pty. At this point, there is > little-to-no expectation of security. In order to hijack an existing, non-cached connection, an attacker needs a lot more resources, as I hope you can see from the example above. > The difference? In one case the command is simple and obvious. In the > other, the attacker must use a command that takes over an existing pty, > which is sometimes already present on the system. And if it's not present on the system, the admin should still be able to protect himself. > specifically, I'm thinking of something like GNU Screen or even > something a little more specific. Something like that is not hard to > write, especially if we're talking about an insecure client system. screen doesn't let you take over just any session -- the session has to be run under screen in the first place. Again, as I've mentioned elsewhere in the thread: there are environments other than the traditional UNIX model with ptys owned by the user and the ability for user processes to inspect or modify the VM of a peer process. It is not reasonable when designing the protocol of what is supposed to be a "secure shell" program to make assumptions about how easy or hard it is to attack the process model of the host platform. It can be made hard, and the "secure shell" program shouldn't undermine one's efforts to harden the rest of the system. > You're advocating security through obscurity. If the attacker does not > know how to hijack an existing pty, then he/she will likely not be able > to do any damage on the remote system besides obvious "lets screw with > foo's files" which he/she can do on the local system anyway. This is > foo's problem, not the server's. If the "hijacker" can hijack the pty, > then the server is in a much more vulnerable position and is in the same > position now as it would be after a 2nd shell "session" over the > already-authenticated connection. I'm advocating doing whatever is possible to mitigate the spread of a compromise, or at least giving the sysadmin the tools he or she needs to do so. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From kumaresh_ind at gmx.net Wed May 5 21:45:30 2004 From: kumaresh_ind at gmx.net (Kumaresh) Date: Wed, 5 May 2004 17:15:30 +0530 Subject: Error with USE_POSIX_THREADS and OpenSSH-3.8p1 References: <040a01c431bf$54711c30$230110ac@kurco> <40977032.5050909@zip.com.au> <001e01c431d1$99f1c0e0$230110ac@kurco> <40978D5A.9050407@zip.com.au> Message-ID: <051f01c43296$82b37a20$230110ac@kurco> > Kumaresh wrote: > > I am using HP-UX 11.23 and this code has to be out of AIX or atleast can be > > included for HP-UX also. Because, the env variable is being set only if this > > code is in place and USE_POSIX_THREADS. So, I believe this is required for > > HP-UX. > > The attached patch is what I'm thinking of. (It would also fix bug #445). > > USE_POSIX_THREAD will probably go away as soon as there is a better fix > for the krb/PAM issue, see: > http://bugzilla.mindrot.org/show_bug.cgi?id=688 Thanks. The patch works with pam-unix, pam-krb5 with successful credential file creation and env variable setting. May I know the version of OpenSSH this patch will be comitted. Regards, Kumar. From mouring at etoh.eviladmin.org Wed May 5 23:50:29 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Wed, 5 May 2004 08:50:29 -0500 (CDT) Subject: Connection caching? In-Reply-To: <4098A653.9070801@noaa.gov> Message-ID: On Wed, 5 May 2004, Jefferson Ogata wrote: > Now you add connection caching, and the compromise is no longer contained. If > the user is legitimately logged from the gateway into the secure system, the > intruder can now log in to the secure system, as many times as he likes. > I think Damien/Markus would agree when I say that the user would have to enable such a thing for it to be used. Either via a ssh_config or via a commandline option. Much like how X11 sessions are. Why would a user do such a thing on a machine as you describe? What gain do they get? I see none. - Ben From Jefferson.Ogata at noaa.gov Thu May 6 02:01:24 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Wed, 05 May 2004 12:01:24 -0400 Subject: Connection caching? In-Reply-To: References: Message-ID: <40990FD4.1040005@noaa.gov> Ben Lindstrom wrote: > On Wed, 5 May 2004, Jefferson Ogata wrote: >>Now you add connection caching, and the compromise is no longer contained. If >>the user is legitimately logged from the gateway into the secure system, the >>intruder can now log in to the secure system, as many times as he likes. > > I think Damien/Markus would agree when I say that the user would have to > enable such a thing for it to be used. Either via a ssh_config or via > a commandline option. Much like how X11 sessions are. > > Why would a user do such a thing on a machine as you describe? What gain > do they get? I see none. No doubt the lazy user /would/ enable such a thing. The control needs to be on the server side. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From mouring at etoh.eviladmin.org Thu May 6 02:24:44 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Wed, 5 May 2004 11:24:44 -0500 (CDT) Subject: Connection caching? In-Reply-To: <40990FD4.1040005@noaa.gov> Message-ID: On Wed, 5 May 2004, Jefferson Ogata wrote: > Ben Lindstrom wrote: > > On Wed, 5 May 2004, Jefferson Ogata wrote: > >>Now you add connection caching, and the compromise is no longer contained. If > >>the user is legitimately logged from the gateway into the secure system, the > >>intruder can now log in to the secure system, as many times as he likes. > > > > I think Damien/Markus would agree when I say that the user would have to > > enable such a thing for it to be used. Either via a ssh_config or via > > a commandline option. Much like how X11 sessions are. > > > > Why would a user do such a thing on a machine as you describe? What gain > > do they get? I see none. > > No doubt the lazy user /would/ enable such a thing. The control needs to be on > the server side. > Praytell... If the /home is RO.. they don't have a ssh_config or it is predefined for them.. How is: ssh -G somesite.com or worse: ssh '-o AllowMultipleChannels yes' somesite.com is easier than just typing: ssh somesite.com Still my oritinal point stands from a few messages ago.. NOTHING stops this from happening now from a client other than ours. Yet you don't seem to care about that fact... Only after we commented that "someday this would be a nice feature" did you start... If you want the feature.. Pony up the code so we have something physical to discuss and test against other SSH clients for breakage. Until then I think we are going in circles. - Ben From Jefferson.Ogata at noaa.gov Thu May 6 02:35:53 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Wed, 05 May 2004 12:35:53 -0400 Subject: Connection caching? In-Reply-To: References: Message-ID: <409917E9.5000205@noaa.gov> Ben Lindstrom wrote: > On Wed, 5 May 2004, Jefferson Ogata wrote: >>No doubt the lazy user /would/ enable such a thing. The control needs to be on >>the server side. > > Praytell... If the /home is RO.. they don't have a ssh_config or it is > predefined for them.. How is: > > ssh -G somesite.com > > or worse: > > ssh '-o AllowMultipleChannels yes' somesite.com > > is easier than just typing: > > ssh somesite.com It's not easier the first time, but it's easier for all the subsequent times where authentication gets bypassed. I'm confident you understand this, so why are you asking? > Still my oritinal point stands from a few messages ago.. NOTHING stops > this from happening now from a client other than ours. Yet you don't > seem to care about that fact... Only after we commented that "someday > this would be a nice feature" did you start... Obviously, I /do/ care about that fact -- that's why I've been explaining the issue with scenario after scenario so you can see why the control needs to be on the server side, and why it should have been there all along. > If you want the feature.. Pony up the code so we have something physical > to discuss and test against other SSH clients for breakage. Until then I > think we are going in circles. If/when I have time. Or I might evaluate other versions of the server. Or maybe someone else with some spare time will understand why this is important and write a patch. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From mouring at etoh.eviladmin.org Thu May 6 03:31:36 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Wed, 5 May 2004 12:31:36 -0500 (CDT) Subject: Connection caching? In-Reply-To: <409917E9.5000205@noaa.gov> Message-ID: On Wed, 5 May 2004, Jefferson Ogata wrote: > Ben Lindstrom wrote: > > On Wed, 5 May 2004, Jefferson Ogata wrote: > >>No doubt the lazy user /would/ enable such a thing. The control needs to be on > >>the server side. > > > > Praytell... If the /home is RO.. they don't have a ssh_config or it is > > predefined for them.. How is: > > > > ssh -G somesite.com > > > > or worse: > > > > ssh '-o AllowMultipleChannels yes' somesite.com > > > > is easier than just typing: > > > > ssh somesite.com > > It's not easier the first time, but it's easier for all the subsequent times > where authentication gets bypassed. I'm confident you understand this, so why > are you asking? > Not easier the second time either.. First time: ssh '-oPipeLoc /tmp/foo/host-%h'-G host then ssh -P '-oPipeLoc /tmp/foo/host-%h' Since as you claim /home is RO and is useless to them, then /tmp is their only valid refusage to use 'connection caching'. 'MaxChannelsPerConnection' can only hold up in an environment like the one you describe where all gates in and out are bared and force reauthication in order to unlock. Which is the minority not the majority of all sshd setups. I already have a -L/-R concept floating around in my head that could bypass MaxChannelsPerConnection without such a protective proxy (if I bothered to setup and review and study the proxy setup I'm sure I could come up with theories on bypassing it also). Which is the point here. You honestly think it will stop a lazy person? I've met a few very pigheaded people that will do everything they can to setup long standing badly formed trusts so they can avoid passwords/OTP/etc. Heck, I'm sure we all read the article about how most users would give up their passwords for Chocolate, and some don't even need the chocolate. =) > > Still my oritinal point stands from a few messages ago.. NOTHING stops > > this from happening now from a client other than ours. Yet you don't > > seem to care about that fact... Only after we commented that "someday > > this would be a nice feature" did you start... > > Obviously, I /do/ care about that fact -- that's why I've been explaining the > issue with scenario after scenario so you can see why the control needs to be on > the server side, and why it should have been there all along. > The control is still yet an illusion. And is that illusion worth the cost of the code needed to give the admin warm fuzzies when it can be so easily bypassed in the majority case? Also, if our sshd supports multiple channels per session now, and other ssh clients support it. Why only complain when someone suggests we support it? Is not the security of your chokepoint also in question here? Are you so sure that you have no buffer overflows (or 100% sure that your mitigation works perfectly.. E.G. PAX recent DoS)? Either in setuid binaries which would easily grant access. Or non-setuid binaries which could be used for a shell code attack to extract useful information? > > If you want the feature.. Pony up the code so we have something physical > > to discuss and test against other SSH clients for breakage. Until then I > > think we are going in circles. > > If/when I have time. Or I might evaluate other versions of the server. Or maybe > someone else with some spare time will understand why this is important and > write a patch. > Nothing stops you. And frankly if it is important to you after the SSH client supports multiple channel communications it should be important to you now, because you still are at risk in your mind. - Ben From Jefferson.Ogata at noaa.gov Thu May 6 03:59:30 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Wed, 05 May 2004 13:59:30 -0400 Subject: Connection caching? In-Reply-To: References: Message-ID: <40992B82.1010605@noaa.gov> Ben Lindstrom wrote: > On Wed, 5 May 2004, Jefferson Ogata wrote: >>Ben Lindstrom wrote: >>>On Wed, 5 May 2004, Jefferson Ogata wrote: >>> >>>>No doubt the lazy user /would/ enable such a thing. The control needs to be on >>>>the server side. >>> >>>Praytell... If the /home is RO.. they don't have a ssh_config or it is >>>predefined for them.. How is: >>> >>>ssh -G somesite.com >>> >>>or worse: >>> >>>ssh '-o AllowMultipleChannels yes' somesite.com >>> >>>is easier than just typing: >>> >>>ssh somesite.com >> >>It's not easier the first time, but it's easier for all the subsequent times >>where authentication gets bypassed. I'm confident you understand this, so why >>are you asking? > > Not easier the second time either.. > > First time: > > ssh '-oPipeLoc /tmp/foo/host-%h'-G host > > then > > ssh -P '-oPipeLoc /tmp/foo/host-%h' > > Since as you claim /home is RO and is useless to them, then /tmp is their > only valid refusage to use 'connection caching'. AFAIK, the specific default location for the connection cache socket hasn't been determined. ssh-agent puts its socket under /tmp. You keep trying to pick away at details of this gateway set up, but you seem unable to comprehend that it's merely an example. There are many other variants -- home directories writable but profiles immutable, systrace or similar deployed to allow normal ssh client behavior but block pty hijacking, etc. -- there are many other ways to configure a secure gateway. Try to understand the bigger picture -- /try/ to understand that sshd should not undermine the sysadmin's ability to enforce as many controls as possible. > 'MaxChannelsPerConnection' can only hold up in an environment like > the one you describe where all gates in and out are bared and force > reauthication in order to unlock. Which is the minority not the majority > of all sshd setups. A minority for you perhaps, but not for me. In any case, why should "secure shell" undermine a more secure environment in favor of a majority of less secure ones? > I already have a -L/-R concept floating around in my head that could > bypass MaxChannelsPerConnection without such a protective proxy (if I > bothered to setup and review and study the proxy setup I'm sure I could > come up with theories on bypassing it also). Yes, some user might do that. I've already allowed that, over and over. But not every user will. Have you ever dealt with a web-of-trust compromise? I suspect not... > Which is the point here. You honestly think it will stop a lazy person? > I've met a few very pigheaded people that will do everything they can to > setup long standing badly formed trusts so they can avoid passwords/OTP/etc. With cached connections, no one has to work to bypass authentication -- it's practically the default, at least as pitched earlier in this thread. What about this don't you understand? > Heck, I'm sure we all read the article about how most users would give up > their passwords for Chocolate, and some don't even need the chocolate. =) If you offer my users a bar of chocolate in exchange for the floppy I gave them with their RSA private key, /and/ their S/KEY password list, I think they'll balk. >>>Still my oritinal point stands from a few messages ago.. NOTHING stops >>>this from happening now from a client other than ours. Yet you don't >>>seem to care about that fact... Only after we commented that "someday >>>this would be a nice feature" did you start... >> >>Obviously, I /do/ care about that fact -- that's why I've been explaining the >>issue with scenario after scenario so you can see why the control needs to be on >>the server side, and why it should have been there all along. > > The control is still yet an illusion. And is that illusion worth the cost > of the code needed to give the admin warm fuzzies when it can be so > easily bypassed in the majority case? The X11Forwarding control is an illusion. It's there, however, because it is in fact possible to arrange an environment where it actually works. > Also, if our sshd supports multiple channels per session now, and other > ssh clients support it. Why only complain when someone suggests we > support it? Is not the security of your chokepoint also in question here? > Are you so sure that you have no buffer overflows (or 100% sure that your > mitigation works perfectly.. E.G. PAX recent DoS)? Either in setuid > binaries which would easily grant access. Or non-setuid binaries which > could be used for a shell code attack to extract useful information? As I think has been made totally plain, I complain now because I wasn't aware that openssh sshd supported it until it was discussed in this thread. >>>If you want the feature.. Pony up the code so we have something physical >>>to discuss and test against other SSH clients for breakage. Until then I >>>think we are going in circles. >> >>If/when I have time. Or I might evaluate other versions of the server. Or maybe >>someone else with some spare time will understand why this is important and >>write a patch. > > Nothing stops you. And frankly if it is important to you after > the SSH client supports multiple channel communications it should be > important to you now, because you still are at risk in your mind. Yes, it is important to me. That doesn't mean I have time to write a patch at this time, however. It does mean I might recommend to the admins I support that they stop allowing remote access via openssh until this is resolved. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From postadal at suse.cz Thu May 6 05:41:40 2004 From: postadal at suse.cz (Petr Ostadal) Date: Wed, 5 May 2004 21:41:40 +0200 (CEST) Subject: Why are error messages CRLF terminated? Message-ID: Hi, why uses openssh for printing error messages CRLF termination? Petr From johnpell at mac.com Thu May 6 11:45:38 2004 From: johnpell at mac.com (John Davidorff Pell) Date: Wed, 5 May 2004 18:45:38 -0700 Subject: Connection caching? In-Reply-To: <4098A653.9070801@noaa.gov> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <40972BCF.3030909@noaa.gov> <8F64D0AB-9E5A-11D8-98D1-0003934F6406@mac.com> <409889D4.2070106@noaa.gov> <4098A653.9070801@noaa.gov> Message-ID: <141948A8-9EFF-11D8-B206-0003934F6406@mac.com> I hadn't considered this scenario. Good points. At this point, however, we're not talking about an untrusted client so you can just as easily disable connection caching on the client (gateway) side as well. Either way, there should be options to restrict the number of streams over a single connection, as you suggest. Good communicating with you. :-) JP On 5 May 2004, at 01:31, Jefferson Ogata wrote: >> If the client is compromised, then the attacker can easily use the >> existing shell channel: by breaking into the ptys, by hijacking the >> process, or by taking control of the actual physical terminal, among >> other ways. Some require advanced attacks, some require strolling >> over to the so-and-so's desk before so-and-so's screen saver picks >> up. At this point, one command can easily add an alternate >> private-key to the remote account, and thus provide outside, >> unrestricted, unmonitored access. One can also issue one command to >> do immediate damage ("rm -rf ~ &"). > > You're making a lot of assumptions. > > Let's go through one more scenario, and please read and understand > this carefully: > > Suppose we set up ssh as a secure gateway. sshd is chrooted with the > only writable filesystem (/tmp) mounted noexec. Users' home > directories are read-only. No one can add binaries to the system, and > users can execute only the programs I provide in the chroot hierarchy. > Once a user logs in to the chrooted sshd, he can ssh from there to a > secure system, but has to authenticate a second time to do so. > > Now suppose an intruder somehow intercepts a user's password or > private key for accessing the gateway, and then logs in to the > gateway. Without "connection caching", the intruder can go no further. > He can play around on the gateway with the few commands available, but > he doesn't have a pty-hijacking program and there's no way for him to > add one. The user's home directory is read-only so he can't modify the > user's .profile to alias ssh to something else. So the intruder can't > get onto the secure system, and the compromise is contained. > > Now you add connection caching, and the compromise is no longer > contained. If the user is legitimately logged from the gateway into > the secure system, the intruder can now log in to the secure system, > as many times as he likes. -- John Davidorff Pell johnpell at mac.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2426 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040505/dd87ed67/attachment.bin From stuge-openssh-unix-dev at cdy.org Thu May 6 22:36:33 2004 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 6 May 2004 14:36:33 +0200 Subject: Connection caching? In-Reply-To: <4098894D.1070705@noaa.gov> References: <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <20040504123146.GC3056@foo.birdnet.se> <4098894D.1070705@noaa.gov> Message-ID: <20040506123633.GB3815@foo.birdnet.se> On Wed, May 05, 2004 at 02:27:25AM -0400, Jefferson Ogata wrote: > Peter Stuge wrote: > >9.4.1 End point security > > > > End point security is assumed by the connection protocol. If the > > server has been compromised, any terminal sessions, port forwarding, > > or systems accessed on the host are compromised. There are no > > mitigating factors for this. > > That statement is simply untrue. > > We can certainly imagine, and no doubt find, a trusted system where the > compromise of a user's login does not lead to any ability for an intruder > to interfere with, eavesdrop on, or modify established sessions belonging > to that user -- a system where perhaps ptrace is disabled and ptys are > chowned to root or unlinked after opening, and where no process memory > image is available. The intruder might still change the behavior of future > logins by the user, but not any already existing ones. > > In this case, perhaps an intruder can arrange that, the next time the user > authenticates to a remote system, the intruder can take control of the new > session. But meanwhile there is a real opportunity for the compromise to be > discovered /before/ it results in a remote compromise via a new ssh shell > channel. > > ...Unless the ssh server supports creating new shell sessions over an > already authenticated session. With the functionality currently under > debate, as soon as an intruder gets into a user account, he can immediately > get onto any system for which a "cached connection" is available. A limit > within sshd on the number of shell channels per ssh session mitigates > against this attack. I'll think this over, lots of things going on right now. Thanks for the example nevertheless! > > If the client end point has been compromised, and the server fails to > > stop the attacker at the authentication protocol, all services > > exposed (either as subsystems or through forwarding) will be > > vulnerable to attack. Implementors SHOULD provide mechanisms for > > administrators to control which services are exposed to limit the > > vulnerability of other services. > > Which is, in fact, what I am asking for. Right. Do you have any suggestions for how it should look w.r.t. channels? Should PAM be involved? (ssh-session, ssh-x11, ssh-forwarded-tcpip, ssh-direct-tcpip service names?) > > These controls might include controlling which machines and ports can > > be target in 'port-forwarding' operations, which users are allowed to > > use interactive shell facilities, or which users are allowed to use > > exposed subsystems. > > I would certain read that to allow limiting the number of shell channels > per successful authentication. Right. > >OTP can be used for > >authentication of one SSHv2 session, which in turn can carry multiple > >channels where a shell or a command is executed in each. > > In the model currently used by the openssh client, only one channel is > used for a shell session; other channels are used for port, X11, etc. > forwarding. Ouch, yes, I'm sorry, I got the terminology wrong. :( I wrote session but meant connection. Connections carry channels, a channel has four standardized uses where one is "session" which is intended to run one single program on the server, be it a shell, a subsystem or some other command. (Using "shell", "subsystem" or "exec" channel requests respectively.) I'm repeating this for myself and others on the list that don't know the protocol by heart (yet).. :) > Given that this is the way the openssh client behaves now, I can't see > how it's any great horror to allow the server to enforce the current > behavior. Well, the client can be made to open more channels over the connection already, using the escape commands, right? > >Right. With SSHv2 plus the ssh-session-agent all the attacker (sorry, > >lazy user) has to do is to hijack the socket instead of the terminal. > >I lack statistics to back this, but I think the terminal is easier to > >reach, because of human error. > > I don't think hijacking the socket works -- key exchange runs before > authentication. The attacker needs to know the shared key to do anything > useful with the hijacked socket. Hm? ssh-session-agent should've been ssh-connection-agent and I meant the future agent that did connection caching. :) > >On Tue, May 04, 2004 at 03:27:12AM -0400, Jefferson Ogata wrote: > >SSHv2 puts all the security in the Transport Layer, anything on top > >of that shouldn't try to impose more restrictions except for, as quoted > >above, which users are allowed access to what services. > > I don't read it the way you do. I think we're actually agreeing on this. I'm not completely convinced, but I see your point. > Let's suppose a user logs into a system that allows X11 forwarding and has > a 256 per-process file descriptor hard limit. The user proceeds to forward > 255 X11 connections, using up all the available descriptors. I somehow > doubt sshd has a suitable architecture to provide any more channels in this > situation. We would accept that the next attempt to allocate a channel > would fail on account of a hard resource limit being imposed by OS policy. > > So why would compliance with ssh v2 demand that the ssh server cannot give > the admin a means to impose a resource limit on the number of shell > channels? No, nothing demands this. There's even an error code called SSH_OPEN_ADMINISTRATIVELY_PROHIBITED for the CHANNEL_OPEN request. > >So make sure users log out using e.g. crond? > > Again, shouldn't have to. Besides, no matter how short an idle time we > allow, there is still a window for an attack to be successful. Yes. > >Publish a system policy and kick the bozo out after a day. :) > > If only... :^) That's what policies are for, no? :) > Still -- one day attack window. Yes. No good. > >It's not a bug, it's a feature, hehe. > > That's what they all say. :^) Would be nice to allow more control, yes. Would also be nice to do so without adding very much code. > >Not so obvious if you work a lot with the SSH protocol, since the > >conecpt of a session is standardized there. > > I think the context was clear here, and yes, I've referred to ssh sessions > elsewhere. But I'm trying to be tighter with the terminology so there > aren't any more misunderstandings. Thanks. I'll try rereading my own wording twice before the next time I post messages complaining about the terminology of others! > >It seems that what you really want is some kind of system where the > >user has to authenticate before every action she takes. This could be > >accomplished with a custom shell, or an application server, or... > > I want the user to have to authenticate to get a new shell. But now that > you mention it, it's an interesting idea to require authentication for > each port forwarding action. Not sure there's any way to prompt in the > existing paradigm tho. Each port forward has it's own channel, so the code probably goes into the CHANNEL_OPEN handler server_input_channel_open(). > >I'm not sure it really should be done with sshd? It compares well with > >chroot()ing sftp users.. > > I think it's more general than that. Well, not neccessarily, it could be implemented with a custom shell or a wrapper before the shell. Everything in sessions is run by the user's shell, IIRC. Anyway, a quick way to impose the restriction you want is to change #define MAX_SESSIONS 10 in session.c circa line 106 to 1. Other channels will still be opened though. //Peter From jchen at pop500.gsfc.nasa.gov Thu May 6 23:42:08 2004 From: jchen at pop500.gsfc.nasa.gov (Jay Chen) Date: Thu, 06 May 2004 09:42:08 -0400 Subject: ID mismatch Message-ID: <5.2.1.1.0.20040506093500.01e30de8@pop500.gsfc.nasa.gov> Hi, When do the sftp to remote server with file system full, sftp connection get "ID mismatch" and connection closed. Is it supposed to get the "sftp>" prompt back? I try with V3.7.1p2 and V3.8.1p1 and have the same result. Please help. rdsosl.sef_cdf-831# sftp -v edosuser at rdsosl Connecting to rdsosl... OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: /etc/ssh/ssh_config line 8: Deprecated option "RhostsAuthentication" debug1: Connecting to rdsosl [X.X.X.X] port 22. debug1: Connection established. debug1: identity file /.ssh/identity type -1 debug1: identity file /.ssh/id_rsa type -1 debug1: identity file /.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.8.1p1 debug1: match: OpenSSH_3.8.1p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'rdsosl' is known and matches the RSA host key. debug1: Found key in /.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /.ssh/identity debug1: Trying private key: /.ssh/id_rsa debug1: Trying private key: /.ssh/id_dsa debug1: Next authentication method: keyboard-interactive debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: password edosuser at rdsosl's password: debug1: Authentication succeeded (password). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: Sending subsystem: sftp sftp> cd /usr/test sftp> put test.tar test.3 debug1: Couldn't stat remote file: No such file or directory Uploading test.tar to /usr/test/test.3 test.tar 0% 0 0.0KB/s --:-- ETACouldn't write to remote file "/usr/test/test.3": Failure ID mismatch (9 != 6) rdsosl.sef_cdf-832# debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 33.1 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug1: Exit status 0 From djm at mindrot.org Fri May 7 08:03:49 2004 From: djm at mindrot.org (Damien Miller) Date: Fri, 07 May 2004 08:03:49 +1000 Subject: ID mismatch In-Reply-To: <5.2.1.1.0.20040506093500.01e30de8@pop500.gsfc.nasa.gov> References: <5.2.1.1.0.20040506093500.01e30de8@pop500.gsfc.nasa.gov> Message-ID: <409AB645.8070007@mindrot.org> Jay Chen wrote: > Hi, > > When do the sftp to remote server with file system full, sftp connection > get "ID mismatch" > and connection closed. Is it supposed to get the "sftp>" prompt back? I try > with V3.7.1p2 and V3.8.1p1 and have the same result. That looks like a bug. Can you send a trace with "sftp -vvv" (much more verbose)? -d From tdsc.af at infineon.com Fri May 7 16:56:36 2004 From: tdsc.af at infineon.com (TDSCAF) Date: Fri, 07 May 2004 08:56:36 +0200 Subject: Contribution to 3.8.1pl1 Message-ID: <409B3324.AB288ABA@infineon.com> Hello, I added the support for netgroups to be used in the AllowUsers and DenyUsers parameters. This has some advantages: * hostnames or ip addresses need not to be written or maintained in the sshd_config file, but can be kept abstract names what also simplifies a bit largescale openssh installations * sshd_config needs not change and sshd be restarted when changing the list of allowed / denied users/hosts in the NIS netgroups Though considered to be dead some time in the future, NIS still serves it's purpose in many environments. The netgroups will make their way into LDAP some time in the future, then i'll probably post another patch. For now i added the functionality mainly in the match.c file, adapted man-page files and autoconf to figure out automatically, if NIS client support is available on the platform. The attached patch can be applied changing to the source directory of 3.8.1pl1 and running gunzip < /path/to/openssh-3.8.1p1.patch_af.gz | patch -p 1 Hope this will be included into the official distribution. Everyone is welcome to review the modifications. Regards, Albert -- Albert Fluegel science + computing ag IT Services Ingolstaedter Stra?e 22 phone +49 89 356386 851 80807 Muenchen, Germany fax +49 89 356386 737 www.science-computing.de ________________________________at Infineon tdsc.af at infineon.com phone +49 89 234 27690 From tdsc.af at infineon.com Fri May 7 16:58:02 2004 From: tdsc.af at infineon.com (TDSCAF) Date: Fri, 07 May 2004 08:58:02 +0200 Subject: Contribution to 3.8.1pl1 Message-ID: <409B337A.34F52694@infineon.com> Hi, now with attachment (sorry !) Hello, I added the support for netgroups to be used in the AllowUsers and DenyUsers parameters. This has some advantages: * hostnames or ip addresses need not to be written or maintained in the sshd_config file, but can be kept abstract names what also simplifies a bit largescale openssh installations * sshd_config needs not change and sshd be restarted when changing the list of allowed / denied users/hosts in the NIS netgroups Though considered to be dead some time in the future, NIS still serves it's purpose in many environments. The netgroups will make their way into LDAP some time in the future, then i'll probably post another patch. For now i added the functionality mainly in the match.c file, adapted man-page files and autoconf to figure out automatically, if NIS client support is available on the platform. The attached patch can be applied changing to the source directory of 3.8.1pl1 and running gunzip < /path/to/openssh-3.8.1p1.patch_af.gz | patch -p 1 Hope this will be included into the official distribution. Everyone is welcome to review the modifications. Regards, Albert -- Albert Fluegel science + computing ag IT Services Ingolstaedter Stra?e 22 phone +49 89 356386 851 80807 Muenchen, Germany fax +49 89 356386 737 www.science-computing.de ________________________________at Infineon tdsc.af at infineon.com phone +49 89 234 27690 -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-3.8.1p1.patch_af.gz Type: application/x-gzip Size: 3134 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040507/a621f0df/attachment.bin From tdsc.af at infineon.com Fri May 7 17:37:48 2004 From: tdsc.af at infineon.com (TDSCAF) Date: Fri, 07 May 2004 09:37:48 +0200 Subject: Contribution to 3.8.1pl1 Message-ID: <409B3CCC.E958B847@infineon.com> Hi, attachment has been removed by some superintelligent virus filter. So i paste the diff below. Hello, I added the support for netgroups to be used in the AllowUsers and DenyUsers parameters. This has some advantages: * hostnames or ip addresses need not to be written or maintained in the sshd_config file, but can be kept abstract names what also simplifies a bit largescale openssh installations * sshd_config needs not change and sshd be restarted when changing the list of allowed / denied users/hosts in the NIS netgroups Though considered to be dead some time in the future, NIS still serves it's purpose in many environments. The netgroups will make their way into LDAP some time in the future, then i'll probably post another patch. For now i added the functionality mainly in the match.c file, adapted man-page files and autoconf to figure out automatically, if NIS client support is available on the platform. The attached patch can be applied changing to the source directory of 3.8.1pl1 and running gunzip < /path/to/openssh-3.8.1p1.patch_af.gz | patch -p 1 Hope this will be included into the official distribution. Everyone is welcome to review the modifications. Regards, Albert -- diff -ru openssh-3.8.1p1/CREDITS openssh-3.8.1p1.paf/CREDITS --- openssh-3.8.1p1/CREDITS Fri Jan 30 05:00:50 2004 +++ openssh-3.8.1p1.paf/CREDITS Fri May 7 08:02:14 2004 @@ -4,6 +4,7 @@ Theo de Raadt, and Dug Song - Creators of OpenSSH Alain St-Denis - Irix fix +Albert Fluegel - netgroup support, autoconf fix Alexandre Oliva - AIX fixes Andre Lucas - new login code, many fixes Andreas Steinmetz - Shadow password expiry support diff -ru openssh-3.8.1p1/config.h.in openssh-3.8.1p1.paf/config.h.in --- openssh-3.8.1p1/config.h.in Sun Apr 18 14:51:50 2004 +++ openssh-3.8.1p1.paf/config.h.in Thu May 6 17:23:24 2004 @@ -747,6 +747,12 @@ /* Define if you have the header file. */ #undef HAVE_RPC_TYPES_H +/* Define if you have the header file. */ +#undef HAVE_RPCSVC_YPCLNT_H + +/* Define if you have the header file. */ +#undef HAVE_RPCSVC_YP_PROT_H + /* Define if you have the `rresvport_af' function. */ #undef HAVE_RRESVPORT_AF @@ -1004,6 +1010,9 @@ /* Define if you have the `waitpid' function. */ #undef HAVE_WAITPID + +/* Define if you have the `yp_match' function. */ +#undef HAVE_YP_MATCH /* Define if you have the `_getlong' function. */ #undef HAVE__GETLONG diff -ru openssh-3.8.1p1/configure openssh-3.8.1p1.paf/configure --- openssh-3.8.1p1/configure Sun Apr 18 14:51:57 2004 +++ openssh-3.8.1p1.paf/configure Fri May 7 08:23:21 2004 @@ -4907,7 +4907,8 @@ getopt.h glob.h ia.h lastlog.h limits.h login.h \ login_cap.h maillock.h netdb.h netgroup.h \ netinet/in_systm.h pam/pam_appl.h paths.h pty.h readpassphrase.h \ - rpc/types.h security/pam_appl.h shadow.h stddef.h stdint.h \ + rpc/types.h rpcsvc/ypclnt.h rpcsvc/yp_prot.h \ + security/pam_appl.h shadow.h stddef.h stdint.h \ strings.h sys/strtio.h sys/audit.h sys/bitypes.h sys/bsdtty.h \ sys/cdefs.h sys/mman.h sys/prctl.h sys/pstat.h sys/ptms.h \ sys/select.h sys/stat.h sys/stream.h sys/stropts.h \ @@ -5202,6 +5203,13 @@ LIBS="-lsocket $LIBS" fi + +fi + +if test "x$ac_cv_func_yp_match" = "xyes" -o "x$ac_cv_lib_nsl_yp_match" = xyes ; then + cat >>confdefs.h < /* Openpty on FreeBSD at least */ #endif +#ifdef HAVE_RPCSVC_YPCLNT_H +#include +#endif +#ifdef HAVE_RPCSVC_YP_PROT_H +#include +#endif + #if defined(KRB5) && defined(USE_AFS) # include # include diff -ru openssh-3.8.1p1/match.c openssh-3.8.1p1.paf/match.c --- openssh-3.8.1p1/match.c Tue Mar 5 02:42:43 2002 +++ openssh-3.8.1p1.paf/match.c Thu May 6 17:20:22 2004 @@ -198,6 +198,159 @@ return 1; } +static char * +first_nospace(const char * str) +{ + while(*str && isspace(*str)) + str++; + return(str); +} + +#ifdef HAVE_YP_MATCH + +/* + * match entry in netgroup, idx is the number + * of the position in the typical netgroup-triples, starting with 0: + * (host,user,domain) i.e. if idx == 0, then host is matched, + * 1 -> user, 2-> domain + */ +int +match_entry_in_netgroup(const char *entry, char *netgroup, const int idx) +{ + static char *ypdomain = NULL; + + char *nismatch; + char *netgentry; + int nismatchlen, len, submatch, ret; + char *cptr, *end_triple, *end_val; + + ret = 0; + nismatch = NULL; + + if(strlen(netgroup) < 1) + goto cleanup; + + if(!ypdomain) + if(yp_get_default_domain(&ypdomain)) + goto cleanup; + + if(yp_match(ypdomain, "netgroup", netgroup, strlen(netgroup), + &nismatch, &nismatchlen)) + goto cleanup; + + nismatch[nismatchlen] = '\0'; + + for(cptr = first_nospace(nismatch); *cptr; cptr = first_nospace(cptr)){ + if(*cptr == '('){ + cptr = first_nospace(cptr + 1); + + if(!(end_triple = strchr(cptr, ')'))) + break; + + end_val = strchr(cptr, ','); + if(!end_val || end_val > end_triple){ /* invalid netgroup entry */ + cptr = end_triple + 1; + continue; + } + + if(idx > 0){ + cptr = first_nospace(end_val + 1); + end_val = strchr(cptr, ','); + if(!end_val || end_val > end_triple){ + cptr = end_triple + 1; + continue; + } + + if(idx > 1){ + cptr = first_nospace(end_val + 1); + end_val = end_triple; + } + } + + len = end_val - cptr; + netgentry = xstrdup(cptr); + netgentry[len] = '\0'; + while(isspace(netgentry[len - 1]) && len > 0) + len--; + + netgentry[len] = '\0'; + submatch = 0; + + if(len > 0) + submatch = !strcmp(netgentry, entry); + + xfree(netgentry); + + if(submatch){ + ret = 1; + goto cleanup; + } + + cptr = end_triple + 1; + } + else{ + for(end_triple = cptr; + *end_triple && !isspace(*end_triple); + end_triple++); + + len = end_triple - cptr; + end_val = xstrdup(cptr); + end_val[len] = '\0'; + + submatch = match_entry_in_netgroup(entry, end_val, idx); + + xfree(end_val); + if(submatch){ + ret = 1; + goto cleanup; + } + + cptr = end_triple; + } + } + + cleanup: + if(nismatch) + free(nismatch); + + return ret; +} + +#endif /* defined(HAVE_YP_MATCH) */ + +/* + * match user in @netgroup + */ +int +match_user_or_netgroup(const char *user, char *pattern) +{ + if(pattern[0] != '@') + return match_pattern(user, pattern); + +#ifdef HAVE_YP_MATCH + return match_entry_in_netgroup(user, pattern + 1, 1); +#else + return 0; +#endif +} + +/* + * match host in @netgroup + */ +int +match_host_and_ip_or_netgroup(const char *host, const char * ipaddr, char *pattern) +{ + if(pattern[0] != '@') + return match_host_and_ip(host, ipaddr, pattern); + +#ifdef HAVE_YP_MATCH + return match_entry_in_netgroup(host, pattern + 1, 0) + || match_entry_in_netgroup(ipaddr, pattern + 1, 0); +#else + return 0; +#endif +} + /* * match user, user at host_or_ip, user at host_or_ip_list against pattern */ @@ -208,15 +361,18 @@ char *p, *pat; int ret; - if ((p = strchr(pattern,'@')) == NULL) - return match_pattern(user, pattern); + if (strlen(pattern) < 1) + return 0; + + if ((p = strchr(pattern + 1, '@')) == NULL) + return match_user_or_netgroup(user, pattern); pat = xstrdup(pattern); - p = strchr(pat, '@'); + p = strchr(pat + 1, '@'); *p++ = '\0'; - if ((ret = match_pattern(user, pat)) == 1) - ret = match_host_and_ip(host, ipaddr, p); + if ((ret = match_user_or_netgroup(user, pat)) == 1) + ret = match_host_and_ip_or_netgroup(host, ipaddr, p); xfree(pat); return ret; diff -ru openssh-3.8.1p1/sshd_config.0 openssh-3.8.1p1.paf/sshd_config.0 --- openssh-3.8.1p1/sshd_config.0 Sun Apr 18 14:52:00 2004 +++ openssh-3.8.1p1.paf/sshd_config.0 Thu May 6 17:31:35 2004 @@ -37,7 +37,10 @@ merical user ID is not recognized. By default, login is allowed for all users. If the pattern takes the form USER at HOST then USER and HOST are separately checked, restricting logins to particular - users from particular hosts. + users from particular hosts. If NIS is available and netgroup + querying is built in, either USER and HOST can be the name of a + netgroup of users or hosts, respectively, prefixed with a @ . Then + @myusers@@myhosts is a valid entry here. AuthorizedKeysFile Specifies the file that contains the public keys that can be used @@ -112,7 +115,10 @@ is not recognized. By default, login is allowed for all users. If the pattern takes the form USER at HOST then USER and HOST are separately checked, restricting logins to particular users from - particular hosts. + particular hosts. If NIS is available and netgroup querying is + built in, either USER and HOST can be the name of a netgroup of + users or hosts, respectively, prefixed with the character @ . + Then e.g. @myusers@@myhosts is a valid entry here. GatewayPorts Specifies whether remote hosts are allowed to connect to ports diff -ru openssh-3.8.1p1/sshd_config.5 openssh-3.8.1p1.paf/sshd_config.5 --- openssh-3.8.1p1/sshd_config.5 Wed Apr 14 05:04:36 2004 +++ openssh-3.8.1p1.paf/sshd_config.5 Thu May 6 17:54:27 2004 @@ -96,7 +96,10 @@ By default, login is allowed for all users. If the pattern takes the form USER at HOST then USER and HOST are separately checked, restricting logins to particular -users from particular hosts. +users from particular hosts. If NIS is available and netgroup +querying is built in, either USER and HOST can be the name of a +netgroup of users or hosts, respectively, prefixed with a @ . Then + at myusers@@myhosts is a valid entry here. .Pp .It Cm AuthorizedKeysFile Specifies the file that contains the public keys that can be used @@ -206,7 +209,10 @@ By default, login is allowed for all users. If the pattern takes the form USER at HOST then USER and HOST are separately checked, restricting logins to particular -users from particular hosts. +users from particular hosts. If NIS is available and netgroup querying is +built in, either USER and HOST can be the name of a netgroup of +users or hosts, respectively, prefixed with the character @ . +Then e.g. @myusers@@myhosts is a valid entry here. .It Cm GatewayPorts Specifies whether remote hosts are allowed to connect to ports forwarded for the client. -- Albert Fluegel science + computing ag IT Services Ingolstaedter Stra?e 22 phone +49 89 356386 851 80807 Muenchen, Germany fax +49 89 356386 737 www.science-computing.de ________________________________at Infineon tdsc.af at infineon.com phone +49 89 234 27690 From Darren.Moffat at Sun.COM Sat May 8 00:33:13 2004 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Fri, 07 May 2004 07:33:13 -0700 Subject: Contribution to 3.8.1pl1 In-Reply-To: <409B3CCC.E958B847@infineon.com> References: <409B3CCC.E958B847@infineon.com> Message-ID: <409B9E29.20100@Sun.COM> TDSCAF wrote: > Though considered to be dead some time in the future, > NIS still serves it's purpose in many environments. > The netgroups will make their way into LDAP some time > in the future, then i'll probably post another patch. Why are you calling the yp api's directly when there is already a set of high level nameservice agnostic functions for this ? innetgr(3c), getnetgrent(3c), getnetgrent_r(3c), setnetgrent(3c), endnetgrent(3c). You should really only need to use innetgr(3c) to do this. This ensures that when netgroups are stored in NIS, NIS+ or LDAP (or anything else that is plugged into nsswitch on system that have it that supplies a netgroup back end). -- Darren J Moffat From r3r2 at yahoo.com Sat May 8 03:27:10 2004 From: r3r2 at yahoo.com (Ryan Robertson) Date: Fri, 7 May 2004 10:27:10 -0700 (PDT) Subject: Corrupted MAC on input In-Reply-To: <409107E0.9040809@zip.com.au> Message-ID: <20040507172710.50842.qmail@web10807.mail.yahoo.com> It goes worth mentioning that I have AIX servers that have both 3.7 and 3.8 running on a seperate NAT'd subnet with no issues. They run through a completely different set of routers and probably firewall rules. The other subnet where I'm having issues are running older cisco switches/routers. At this point that is the only difference. Below is debug output from the my linux client. Yes I know I need to upgrade it. Most likely by the time you read this, it will be. Also, what kind of content would you like posted for Bug 860? Thanks again, Ryan ==================================== themac at localhost noise]$ ssh -vl root 165.136.23.89 OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090703f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: Connecting to 165.136.23.89 [165.136.23.89] port 22. debug1: Connection established. debug1: identity file /home/themac/.ssh/identity type -1 debug1: identity file /home/themac/.ssh/id_rsa type 1 debug1: identity file /home/themac/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.8p1 debug1: match: OpenSSH_3.8p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host '165.136.23.89' is known and matches the RSA host key. debug1: Found key in /home/themac/.ssh/known_hosts:2 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /home/themac/.ssh/identity debug1: Offering public key: /home/themac/.ssh/id_rsa debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Trying private key: /home/themac/.ssh/id_dsa debug1: Next authentication method: keyboard-interactive debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: password root at 165.136.23.89's password: debug1: Authentication succeeded (password). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: channel 0: request pty-req debug1: Requesting X11 forwarding with authentication spoofing. debug1: channel 0: request x11-req debug1: channel 0: request shell debug1: channel 0: open confirm rwindow 0 rmax 32768 Last unsuccessful login: Wed May 5 15:15:01 2004 on ssh from 155.17.136.61 Last login: Fri May 7 14:25:17 2004 on ssh from 155.17.98.85 ******************************************************************************* * * * * * Welcome to AIX Version 5.2! * * * * * * Please see the README file in /usr/lpp/bos for information pertinent to * * this release of the AIX Operating System. * * * * UNAUTHORIZED ACCESS PROHIBITED * ******************************************************************************* prdnim:/ # wsm & [1] 417942 prdnim:/ # debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384 debug1: client_request_x11: request from 127.0.0.1 34788 debug1: fd 7 setting O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384 debug1: client_request_x11: request from 127.0.0.1 34789 debug1: fd 8 setting O_NONBLOCK debug1: channel 2: new [x11] debug1: confirm x11 debug1: channel 2: rcvd eof debug1: channel 2: output open -> drain debug1: channel 2: obuf empty debug1: channel 2: close_write debug1: channel 2: output drain -> closed debug1: channel 2: FORCE input drain debug1: channel 2: ibuf empty debug1: channel 2: send eof debug1: channel 2: input drain -> closed debug1: channel 2: send close debug1: channel 2: rcvd close debug1: channel 2: is dead debug1: channel 2: garbage collecting debug1: channel_free: channel 2: x11, nchannels 3 Disconnecting: Corrupted MAC on input. debug1: Calling cleanup 0x8051b10(0x0) debug1: Calling cleanup 0x805aa30(0x0) debug1: channel_free: channel 0: client-session, nchannels 2 debug1: channel_free: channel 1: x11, nchannels 1 debug1: Calling cleanup 0x80628b0(0x0) ================================== __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover From jchen at pop500.gsfc.nasa.gov Sat May 8 05:06:56 2004 From: jchen at pop500.gsfc.nasa.gov (Jay Chen) Date: Fri, 07 May 2004 15:06:56 -0400 Subject: ID mismatch Message-ID: <6.1.0.6.0.20040507144844.01929448@pop500.gsfc.nasa.gov> >Jay Chen wrote: >> Hi, >> >> when do the sftp to remote server with file system full, sftp connection >> get "ID mismatch" >> and connection closed. Is it supposed to get the "sftp>" prompt back? I try >> with V3.7.1p2 and V3.8.1p1 and have the same result. > >That looks like a bug. Can you send a trace with "sftp -vvv" (much more >verbose)? > >-d Hi, The following is more verbose trace: THANKS for your help. Jay Chen rdsosl.sef_cdf-1074# sftp -vvv edosuser at rdsosl Connecting to rdsosl... OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: /etc/ssh/ssh_config line 8: Deprecated option "RhostsAuthentication" debug3: cipher ok: aes128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: 3des-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: blowfish-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: cast128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: arcfour [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: aes192-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: aes256-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: ciphers ok: [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: Seeding PRNG from /usr/local/libexec/ssh-rand-helper debug2: ssh_connect: needpriv 0 debug1: Connecting to rdsosl [X.X.X.X] port 22. debug1: Connection established. debug1: identity file /.ssh/identity type -1 debug1: identity file /.ssh/id_rsa type -1 debug1: identity file /.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.8.1p1 debug1: match: OpenSSH_3.8.1p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 debug3: RNG is ready, skipping seeding debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-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,arcfour,aes192-cbc,aes256-cbc debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc 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 debug2: kex_parse_kexinit: none,zlib 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-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,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,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 debug2: kex_parse_kexinit: none,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: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 124/256 debug2: bits set: 507/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug3: check_host_in_hostfile: filename /.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug1: Host 'rdsosl' is known and matches the RSA host key. debug1: Found key in /.ssh/known_hosts:1 debug2: bits set: 509/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /.ssh/identity (0) debug2: key: /.ssh/id_rsa (0) debug2: key: /.ssh/id_dsa (0) debug3: input_userauth_banner ******************************************************************************* * * * U.S GOVERNMENT COMPUTER * * * * If not authorized to access this system, disconnect now. * * YOU SHOULD HAVE NO EXPECTATION OF PRIVACY * * By continuing, you consent to your keystrokes and data content being * * monitored. * * * ******************************************************************************* debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /.ssh/identity debug3: no such identity: /.ssh/identity debug1: Trying private key: /.ssh/id_rsa debug3: no such identity: /.ssh/id_rsa debug1: Trying private key: /.ssh/id_dsa debug3: no such identity: /.ssh/id_dsa debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: userauth_kbdint: disable: no info_req_seen debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: Next authentication method: password edosuser at rdsosl's password: debug3: packet_send2: adding 48 (len 62 padlen 18 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentication succeeded (password). debug2: fd 4 setting O_NONBLOCK debug2: fd 5 is O_NONBLOCK debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Entering interactive session. debug2: callback start debug2: ssh_session2_setup: id 0 debug1: Sending subsystem: sftp debug2: channel 0: request subsystem debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 debug2: Remote version: 3 debug3: Sent message fd 3 T:16 I:1 debug3: SSH_FXP_REALPATH . -> /irixraid/edos/home_edos sftp> cd /usr/test debug3: Sent message fd 3 T:16 I:2 debug3: SSH_FXP_REALPATH /usr/test -> /usr/test debug3: Sent message fd 3 T:17 I:3 debug3: Received stat reply T:105 I:3 sftp> put test.tar test4 debug3: Looking up test.tar debug3: Sent message fd 3 T:17 I:4 debug3: Received stat reply T:101 I:4 debug1: Couldn't stat remote file: No such file or directory Uploading test.tar to /usr/test/test4 debug3: Sent message SSH2_FXP_OPEN I:5 P:/usr/test/test4 test.tar 0% 0 0.0KB/s --:-- ETAdebug3: Sent message SSH2_FXP_WRITE I:6 O:0 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 6 32768 bytes at 0 debug3: Sent message SSH2_FXP_WRITE I:7 O:32768 S:32768 debug3: Sent message SSH2_FXP_WRITE I:8 O:65536 S:32768 debug3: Sent message SSH2_FXP_WRITE I:9 O:98304 S:32768 debug3: Sent message SSH2_FXP_WRITE I:10 O:131072 S:32768 debug3: Sent message SSH2_FXP_WRITE I:11 O:163840 S:32768 debug2: channel 0: rcvd adjust 65700 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:12 O:196608 S:32768 debug3: Sent message SSH2_FXP_WRITE I:13 O:229376 S:32768 debug3: Sent message SSH2_FXP_WRITE I:14 O:262144 S:32768 debug3: Sent message SSH2_FXP_WRITE I:15 O:294912 S:32768 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:16 O:327680 S:32768 debug3: Sent message SSH2_FXP_WRITE I:17 O:360448 S:32768 debug3: Sent message SSH2_FXP_WRITE I:18 O:393216 S:32768 debug3: Sent message SSH2_FXP_WRITE I:19 O:425984 S:32768 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:20 O:458752 S:32768 debug3: Sent message SSH2_FXP_WRITE I:21 O:491520 S:32768 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:22 O:524288 S:32768 debug3: Sent message SSH2_FXP_WRITE I:23 O:557056 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 7 32768 bytes at 32768 debug3: Sent message SSH2_FXP_WRITE I:24 O:589824 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 8 32768 bytes at 65536 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:25 O:622592 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 9 32768 bytes at 98304 debug3: Sent message SSH2_FXP_WRITE I:26 O:655360 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 10 32768 bytes at 131072 debug3: Sent message SSH2_FXP_WRITE I:27 O:688128 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 11 32768 bytes at 163840 debug2: channel 0: rcvd adjust 81920 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:28 O:720896 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 12 32768 bytes at 196608 debug3: Sent message SSH2_FXP_WRITE I:29 O:753664 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 13 32768 bytes at 229376 debug3: Sent message SSH2_FXP_WRITE I:30 O:786432 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 14 32768 bytes at 262144 debug3: Sent message SSH2_FXP_WRITE I:31 O:819200 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 15 32768 bytes at 294912 debug3: Sent message SSH2_FXP_WRITE I:32 O:851968 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 16 32768 bytes at 327680 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:33 O:884736 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 17 32768 bytes at 360448 debug3: Sent message SSH2_FXP_WRITE I:34 O:917504 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 18 32768 bytes at 393216 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:35 O:950272 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 19 32768 bytes at 425984 debug3: Sent message SSH2_FXP_WRITE I:36 O:983040 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 20 32768 bytes at 458752 debug3: Sent message SSH2_FXP_WRITE I:37 O:1015808 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 21 32768 bytes at 491520 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:38 O:1048576 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 22 32768 bytes at 524288 debug3: Sent message SSH2_FXP_WRITE I:39 O:1081344 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 23 32768 bytes at 557056 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:40 O:1114112 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 24 32768 bytes at 589824 debug3: Sent message SSH2_FXP_WRITE I:41 O:1146880 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 25 32768 bytes at 622592 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:42 O:1179648 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 26 32768 bytes at 655360 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:43 O:1212416 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 27 32768 bytes at 688128 debug3: Sent message SSH2_FXP_WRITE I:44 O:1245184 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 28 32768 bytes at 720896 debug3: Sent message SSH2_FXP_WRITE I:45 O:1277952 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 29 32768 bytes at 753664 debug3: Sent message SSH2_FXP_WRITE I:46 O:1310720 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 30 32768 bytes at 786432 debug3: Sent message SSH2_FXP_WRITE I:47 O:1343488 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 31 32768 bytes at 819200 debug2: channel 0: rcvd adjust 81920 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:48 O:1376256 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 32 32768 bytes at 851968 debug3: Sent message SSH2_FXP_WRITE I:49 O:1409024 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 33 32768 bytes at 884736 debug3: Sent message SSH2_FXP_WRITE I:50 O:1441792 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 34 32768 bytes at 917504 debug3: Sent message SSH2_FXP_WRITE I:51 O:1474560 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 35 32768 bytes at 950272 debug3: Sent message SSH2_FXP_WRITE I:52 O:1507328 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 36 32768 bytes at 983040 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:53 O:1540096 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 37 32768 bytes at 1015808 debug3: Sent message SSH2_FXP_WRITE I:54 O:1572864 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 38 32768 bytes at 1048576 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:55 O:1605632 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 39 32768 bytes at 1081344 debug3: Sent message SSH2_FXP_WRITE I:56 O:1638400 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 40 32768 bytes at 1114112 debug3: Sent message SSH2_FXP_WRITE I:57 O:1671168 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 41 32768 bytes at 1146880 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:58 O:1703936 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 42 32768 bytes at 1179648 debug3: Sent message SSH2_FXP_WRITE I:59 O:1736704 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 43 32768 bytes at 1212416 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:60 O:1769472 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 44 32768 bytes at 1245184 debug3: Sent message SSH2_FXP_WRITE I:61 O:1802240 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 45 32768 bytes at 1277952 debug3: Sent message SSH2_FXP_WRITE I:62 O:1835008 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 46 32768 bytes at 1310720 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:63 O:1867776 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 47 32768 bytes at 1343488 debug3: Sent message SSH2_FXP_WRITE I:64 O:1900544 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 48 32768 bytes at 1376256 debug2: channel 0: rcvd adjust 81920 test.tar 2% 1888KB 1.8MB/s 00:37 ETAdebug3: Sent message SSH2_FXP_WRITE I:65 O:1933312 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 49 32768 bytes at 1409024 debug3: Sent message SSH2_FXP_WRITE I:66 O:1966080 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 50 32768 bytes at 1441792 debug3: Sent message SSH2_FXP_WRITE I:67 O:1998848 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 51 32768 bytes at 1474560 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:68 O:2031616 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 52 32768 bytes at 1507328 debug3: Sent message SSH2_FXP_WRITE I:69 O:2064384 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 53 32768 bytes at 1540096 debug3: Sent message SSH2_FXP_WRITE I:70 O:2097152 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 54 32768 bytes at 1572864 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:71 O:2129920 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 55 32768 bytes at 1605632 debug3: Sent message SSH2_FXP_WRITE I:72 O:2162688 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 56 32768 bytes at 1638400 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:73 O:2195456 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 57 32768 bytes at 1671168 debug3: Sent message SSH2_FXP_WRITE I:74 O:2228224 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 58 32768 bytes at 1703936 debug3: Sent message SSH2_FXP_WRITE I:75 O:2260992 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 59 32768 bytes at 1736704 debug2: channel 0: rcvd adjust 81920 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:76 O:2293760 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 60 32768 bytes at 1769472 debug3: Sent message SSH2_FXP_WRITE I:77 O:2326528 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 61 32768 bytes at 1802240 debug3: Sent message SSH2_FXP_WRITE I:78 O:2359296 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 62 32768 bytes at 1835008 debug2: channel 0: rcvd adjust 81920 debug3: Sent message SSH2_FXP_WRITE I:79 O:2392064 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 63 32768 bytes at 1867776 debug3: Sent message SSH2_FXP_WRITE I:80 O:2424832 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 64 32768 bytes at 1900544 debug3: Sent message SSH2_FXP_WRITE I:81 O:2457600 S:32768 debug3: SSH2_FXP_STATUS 0 debug3: In write loop, ack for 65 32768 bytes at 1933312 debug3: Sent message SSH2_FXP_WRITE I:82 O:2490368 S:32768 debug3: SSH2_FXP_STATUS 4 Couldn't write to remote file "/usr/test/test4": Failure debug3: Sent message SSH2_FXP_CLOSE I:6 ID mismatch (67 != 6) rdsosl.sef_cdf-1075# debug2: channel 0: write failed debug2: channel 0: close_write debug2: channel 0: output open -> closed debug2: channel 0: rcvd adjust 67537 debug2: channel 0: rcvd adjust 81920 debug2: channel 0: read<=0 rfd 4 len 0 debug2: channel 0: read failed debug2: channel 0: close_read debug2: channel 0: input open -> drain debug2: channel 0: ibuf empty debug2: channel 0: send eof debug2: channel 0: input drain -> closed debug2: channel 0: rcvd adjust 81920 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug2: channel 0: rcvd eof debug2: channel 0: rcvd close debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1) debug3: channel 0: close_fds r -1 w -1 e 6 debug1: fd 0 clearing O_NONBLOCK debug2: fd 1 is not O_NONBLOCK debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 16.4 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug1: Exit status 0 From dwmw2 at infradead.org Sat May 8 07:19:46 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 07 May 2004 22:19:46 +0100 Subject: Connection caching? In-Reply-To: <40971DE4.1000607@zip.com.au> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> Message-ID: <1083964785.4526.935.camel@hades.cambridge.redhat.com> On Tue, 2004-05-04 at 14:36 +1000, Darren Tucker wrote: > > As for writing a patch, I wrote a patch ("Requiring multiple auth > > mechanisms") a few weeks ago and submitted it to the list. I didn't get > > one useful bit of feedback, or any indication whatever that the > > maintainers even understood the purpose of the patch. > > I looked at it in conjunction with bug #701 (which is the > "PermitRootLogin without-password" thing). It occurred to me that a > more general mechanism could be a better solution for both. As usual, I > got sidetracked. More general would be good... what I need from it would be "First s/key, then either of password or pubkey" -- dwmw2 From bugzilla-daemon at mindrot.org Sat May 8 07:54:45 2004 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 8 May 2004 07:54:45 +1000 (EST) Subject: [Bug 866] ssh(1) is too picky about unknown options in ~/.ssh/config Message-ID: <20040507215445.888BA27C18A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=866 Summary: ssh(1) is too picky about unknown options in ~/.ssh/config Product: Portable OpenSSH Version: 3.8p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-bugs at mindrot.org ReportedBy: Nicolas.Williams at sun.com CC: openssh-unix-dev at mindrot.org ssh(1) fatal()s when parsing an unknown ~/.ssh/config option. This is rather annoying since ~/.ssh/config may be shared with multiple versions of OpenSSH as well as with OpenSSH derivatives (or even non- derivates that just honor ~/.ssh/config), and since each such implementation may support different sets of features and associated config options. At least when parsing ~/.ssh/config ssh(1) should not fatal() on unknown options, but verbose(). When parsing options given on the command line, however, calling fatal() seems appropriate, and possibly when parsing $PREFIX/etc/ssh_config. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla-daemon at mindrot.org Sat May 8 08:55:11 2004 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 8 May 2004 08:55:11 +1000 (EST) Subject: [Bug 866] ssh(1) is too picky about unknown options in ~/.ssh/config Message-ID: <20040507225511.65AE227C189@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=866 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC|openssh-unix-dev at mindrot.org| Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From djm at mindrot.org 2004-05-08 08:55 ------- Don't Cc the list on bugs! ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From dtucker at zip.com.au Sat May 8 20:43:31 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 08 May 2004 20:43:31 +1000 Subject: Connection caching? In-Reply-To: <1083964785.4526.935.camel@hades.cambridge.redhat.com> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <1083964785.4526.935.camel@hades.cambridge.redhat.com> Message-ID: <409CB9D3.9080100@zip.com.au> David Woodhouse wrote: > On Tue, 2004-05-04 at 14:36 +1000, Darren Tucker wrote: >>I looked at it in conjunction with bug #701 (which is the >>"PermitRootLogin without-password" thing). It occurred to me that a >>more general mechanism could be a better solution for both. As usual, I >>got sidetracked. > > > More general would be good... what I need from it would be > "First s/key, then either of password or pubkey" I've been thinking about something like: AuthenticationsForUser user authenticationlist [source pattern-list] where authenticationlist is a comma-separated list in which you could require multiple authentication with a "+". For example, to require password and public-key, it would be: AuthenticationsForUser joe password+public-key Your example would be: AuthenticationsForUser fred \ keyboard-interactive+public-key,keyboard-interactive+password I'm not sure about including keyboard-interactive submethods (eg pam or skey), but ignoring them would probably make implementation simpler (eg you could represent the authentication methods as a simple bitmask). There should probably be an equivalent AuthenticationsForGroup. Of course, now that I've said this, someone will poke holes in it :-) While we're at it, would it make sense to teach "pattern-list" stuff in match.c to understand CIDR notation? -- 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 Sat May 8 11:25:38 2004 From: djm at mindrot.org (Damien Miller) Date: Sat, 08 May 2004 11:25:38 +1000 Subject: cidr matching In-Reply-To: <409CB9D3.9080100@zip.com.au> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <1083964785.4526.935.camel@hades.cambridge.redhat.com> <409CB9D3.9080100@zip.com.au> Message-ID: <409C3712.2090809@mindrot.org> Darren Tucker wrote: > While we're at it, would it make sense to teach "pattern-list" stuff in > match.c to understand CIDR notation? If you are thinking of ssh_config, this is insufficient - the match and application of config is done well before name->address lookup (it has to, so the HostName directive can be used). It may be possible to repeat the matching after the lookup, but then global config options have already been applied and what do we do if we match a specific host twice? -d From Jefferson.Ogata at noaa.gov Sat May 8 11:31:26 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Fri, 07 May 2004 21:31:26 -0400 Subject: Connection caching? In-Reply-To: <409CB9D3.9080100@zip.com.au> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <1083964785.4526.935.camel@hades.cambridge.redhat.com> <409CB9D3.9080100@zip.com.au> Message-ID: <409C386E.8010702@noaa.gov> Darren Tucker wrote: > David Woodhouse wrote: >> On Tue, 2004-05-04 at 14:36 +1000, Darren Tucker wrote: >>> I looked at it in conjunction with bug #701 (which is the >>> "PermitRootLogin without-password" thing). It occurred to me that a >>> more general mechanism could be a better solution for both. As >>> usual, I got sidetracked. >> >> More general would be good... what I need from it would be >> "First s/key, then either of password or pubkey" > > I've been thinking about something like: > > AuthenticationsForUser user authenticationlist [source pattern-list] > > where authenticationlist is a comma-separated list in which you could > require multiple authentication with a "+". > > For example, to require password and public-key, it would be: > > AuthenticationsForUser joe password+public-key > > Your example would be: > > AuthenticationsForUser fred \ > keyboard-interactive+public-key,keyboard-interactive+password I thank what would work would be to make the sshd_config syntax consistent with the ~/.ssh/config syntax, but instead of Host sections, have User sections. In addition, instead of AllowUsers/DenyUsers you could use Allow/Deny keywords or something similar. We should also allow specification of sub-auth-types. E.g. something along the lines of: Protocol 2 [other global options] User foo bar fubar Protocol 1 PasswordAuthentication yes PubkeyAuthentication no RequiredAuth keyboard-interactive/skey+password keyboard-interactive/skey+public-key User root PasswordAuthentication no RequiredAuth keyboard-interactive+public-key User bozo Deny yes Obviously this would necessitate a rewrite of the config file parser, and additional data structures for user-specific config settings. Not for the faint at heart. But the current config format is pretty limiting. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From dtucker at zip.com.au Sat May 8 21:47:00 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 08 May 2004 21:47:00 +1000 Subject: cidr matching In-Reply-To: <409C3712.2090809@mindrot.org> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <1083964785.4526.935.camel@hades.cambridge.redhat.com> <409CB9D3.9080100@zip.com.au> <409C3712.2090809@mindrot.org> Message-ID: <409CC8B4.2090207@zip.com.au> Damien Miller wrote: > Darren Tucker wrote: >>While we're at it, would it make sense to teach "pattern-list" stuff in >>match.c to understand CIDR notation? > > > If you are thinking of ssh_config, this is insufficient - the match and > application of config is done well before name->address lookup (it has > to, so the HostName directive can be used). Actually I was thinking of "from=pattern-list" in authorized_keys processing in sshd, so you could have something like this: from="192.168.0.0/22" 1024 35 23...233 me at host If the same matcher was used from the hypothetical AuthenticationsForUser, you could then say things like "allow password, hostbased or public key for connections from the local net, but require password+pubkey for connections from the rest of the Net", thusly: AuthenticationsForUser * password,public-key,hostbased 192.168.0.0/22 AuthenticationsForUser * password+public-key > It may be possible to repeat the matching after the lookup, but then > global config options have already been applied and what do we do if > we match a specific host twice? I haven't looked at it, I was just wondering aloud... -- 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 Sat May 8 11:48:43 2004 From: djm at mindrot.org (Damien Miller) Date: Sat, 08 May 2004 11:48:43 +1000 Subject: control of auth methods In-Reply-To: <409C386E.8010702@noaa.gov> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <1083964785.4526.935.camel@hades.cambridge.redhat.com> <409CB9D3.9080100@zip.com.au> <409C386E.8010702@noaa.gov> Message-ID: <409C3C7B.4050409@mindrot.org> Jefferson Ogata wrote: > I thank what would work would be to make the sshd_config syntax consistent with > the ~/.ssh/config syntax, but instead of Host sections, have User sections. In > addition, instead of AllowUsers/DenyUsers you could use Allow/Deny keywords or > something similar. We should also allow specification of sub-auth-types. I don't think we are interested in adding complex policy enforcement to the server. If we did this, we would be more likely to reuse an existing policy language such as KeyNote. I had patches for this a couple of years ago - check the archives. -d From mouring at etoh.eviladmin.org Sat May 8 11:57:04 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 7 May 2004 20:57:04 -0500 (CDT) Subject: Connection caching? In-Reply-To: <409CB9D3.9080100@zip.com.au> Message-ID: On Sat, 8 May 2004, Darren Tucker wrote: > David Woodhouse wrote: > > On Tue, 2004-05-04 at 14:36 +1000, Darren Tucker wrote: > > >>I looked at it in conjunction with bug #701 (which is the > >>"PermitRootLogin without-password" thing). It occurred to me that a > >>more general mechanism could be a better solution for both. As usual, I > >>got sidetracked. > > > > > > More general would be good... what I need from it would be > > "First s/key, then either of password or pubkey" > > I've been thinking about something like: > > AuthenticationsForUser user authenticationlist [source pattern-list] > > where authenticationlist is a comma-separated list in which you could > require multiple authentication with a "+". > > For example, to require password and public-key, it would be: > > AuthenticationsForUser joe password+public-key > Just keep in mind everytime this has come up. Markus has commented that the code was too complex. So just keep that in mind if you actually start playing. - Ben From dtucker at zip.com.au Sat May 8 12:46:18 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 08 May 2004 12:46:18 +1000 Subject: Connection caching? In-Reply-To: References: Message-ID: <409C49FA.4070401@zip.com.au> Ben Lindstrom wrote: > Just keep in mind everytime this has come up. Markus has commented that > the code was too complex. So just keep that in mind if you actually start > playing. I know, that's why I was talking about bitmasks, it's the simplest implementation I could think of. Basically, assign a bit to each allowed auth method and create an array of valid combinations. As each method succeeds, clear the bit corresponding to that method. When one of the masks is clear, the authentication is complete. For example (and ignoring the user specification for now), if password = bit 0, pubkey = bit 1 and keyboard-interactive = bit 2, AuthenticationsForUser fred password+public-key,keyboard-interactive would boil down to a 2-element array of methods: 0011 0100 After a successful password authentication, clear bit 0 in each: 0010 0100 OK, so none of them are all clear, so set partial-success and keep going. And so on. This should be resonably easy to do for all users, the added complication is the user specification. These could be represented by a simple 2-dimensional array. The user matching code already exists[1]. Also, we already have some special-case code for PermitRootLogin which could be removed if there was a general way of doing it. If it's still too complicated, then it's probably not worth doing. [1] and it already understands user at host notation, so the format should probably be "AuthenticationsForUser user[@host] authmethod-list". -- 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 mouring at etoh.eviladmin.org Sat May 8 13:05:20 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 7 May 2004 22:05:20 -0500 (CDT) Subject: Connection caching? In-Reply-To: <409C49FA.4070401@zip.com.au> Message-ID: On Sat, 8 May 2004, Darren Tucker wrote: > Ben Lindstrom wrote: > > Just keep in mind everytime this has come up. Markus has commented that > > the code was too complex. So just keep that in mind if you actually start > > playing. > > I know, that's why I was talking about bitmasks, it's the simplest > implementation I could think of. > > Basically, assign a bit to each allowed auth method and create an array > of valid combinations. As each method succeeds, clear the bit > corresponding to that method. When one of the masks is clear, the > authentication is complete. > > For example (and ignoring the user specification for now), if password = > bit 0, pubkey = bit 1 and keyboard-interactive = bit 2, > > AuthenticationsForUser fred password+public-key,keyboard-interactive > > would boil down to a 2-element array of methods: > > 0011 > 0100 > > After a successful password authentication, clear bit 0 in each: > > 0010 > 0100 > > OK, so none of them are all clear, so set partial-success and keep > going. And so on. > Which is fine, but some around here have expressed a need for ordered authentication. Which would make a bitmask implementation imposible without predefining all possible forms of combination. I'm sure one could argue that moving from a bitmask to character array where you number 1,2,3,4,5..etc.. for the ordering. However, I'm still thinking that could become too much. One would have to implement it both ways to see how much added complexity. - Ben From dtucker at zip.com.au Sat May 8 13:24:56 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 08 May 2004 13:24:56 +1000 Subject: Connection caching? In-Reply-To: References: Message-ID: <409C5308.4090605@zip.com.au> Ben Lindstrom wrote: > Which is fine, but some around here have expressed a need for ordered > authentication. Which would make a bitmask implementation imposible > without predefining all possible forms of combination. The client decides which order to try the authentications anyway, unless the server is going to spoon-feed it with changing "authentications that can continue" lists. I don't see what value there is in enforcing a specific order, though. > I'm sure one could argue that moving from a bitmask to character array > where you number 1,2,3,4,5..etc.. for the ordering. However, I'm > still thinking that could become too much. One would have to > implement it both ways to see how much added complexity. The same syntax can be used for both, the ordering could be implemented later if necessary. -- 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 Jefferson.Ogata at noaa.gov Sat May 8 14:30:52 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Sat, 08 May 2004 00:30:52 -0400 Subject: control of auth methods In-Reply-To: <409C3C7B.4050409@mindrot.org> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <1083964785.4526.935.camel@hades.cambridge.redhat.com> <409CB9D3.9080100@zip.com.au> <409C386E.8010702@noaa.gov> <409C3C7B.4050409@mindrot.org> Message-ID: <409C627C.1010809@noaa.gov> Damien Miller wrote: > Jefferson Ogata wrote: >>I thank what would work would be to make the sshd_config syntax consistent with >>the ~/.ssh/config syntax, but instead of Host sections, have User sections. In >>addition, instead of AllowUsers/DenyUsers you could use Allow/Deny keywords or >>something similar. We should also allow specification of sub-auth-types. > > I don't think we are interested in adding complex policy enforcement > to the server. If we did this, we would be more likely to reuse an > existing policy language such as KeyNote. I had patches for this a > couple of years ago - check the archives. That must be the royal "we", because it certainly doesn't include me. As for "complex policy enforcement", that's more like what we have now. I'm just talking about trying to be explicit about it. The current design of the config file is hardly a triumph of simplicity and logic. The auth types have internal names, yet the auth controls are this morass of booleans. It would make more sense to list the internal names, a la Ciphers. Instead we have to figure out how various combinations of peculiarly named flags such as PAMAuthenticationViaKbdInt, PermitRootLogin, ChallengeResponseAuthentication, RhostsRSAAuthentication, UsePam, AllowUsers, DenyUsers, etc. interact to produce which set of valid auth types for whom. It ends up being trial-and-error to determine whether the right users can authenticate the way you want to allow, and /can't/ authenticate the way you want to prevent, and that's not a good design for security. And the more I dig through the code the more I see what a morass the whole thing is. Try following the server loop for versions 1 and 2 respectively, through session.c, serverloop.c, back again to session.c. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From djm at mindrot.org Sat May 8 15:02:57 2004 From: djm at mindrot.org (Damien Miller) Date: Sat, 08 May 2004 15:02:57 +1000 Subject: control of auth methods In-Reply-To: <409C627C.1010809@noaa.gov> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <1083964785.4526.935.camel@hades.cambridge.redhat.com> <409CB9D3.9080100@zip.com.au> <409C386E.8010702@noaa.gov> <409C3C7B.4050409@mindrot.org> <409C627C.1010809@noaa.gov> Message-ID: <409C6A01.10005@mindrot.org> Jefferson Ogata wrote: >>I don't think we are interested in adding complex policy enforcement >>to the server. If we did this, we would be more likely to reuse an >>existing policy language such as KeyNote. I had patches for this a >>couple of years ago - check the archives. > > That must be the royal "we", because it certainly doesn't include me. As for > "complex policy enforcement", that's more like what we have now. I'm just > talking about trying to be explicit about it. Well, that's the good thing about OpenSSH being free software. What I like doesn't in any way restrict what you can do. BTW I say "we" because Markus has decided against this level of complexity before and I defer to his good judgement even when I disagree (which I don't here). > The current design of the config file is hardly a triumph of simplicity and > logic. The auth types have internal names, yet the auth controls are this morass > of booleans. It would make more sense to list the internal names, a la Ciphers. Except you weren't talking about tidying up the authentication method names, you were talking about effectively introducing a policy language. Perhaps we would be willing to add a single "AuthMethods xxx,yyy,zzz", where xxx, etc are the auth method names used in the protocol. We'd have to keep the older names around for a fair while to stop breakage. > Instead we have to figure out how various combinations of peculiarly named flags > such as PAMAuthenticationViaKbdInt, PermitRootLogin, > ChallengeResponseAuthentication, RhostsRSAAuthentication, UsePam, AllowUsers, > DenyUsers, etc. interact to produce which set of valid auth types for whom. It > ends up being trial-and-error to determine whether the right users can > authenticate the way you want to allow, and /can't/ authenticate the way you > want to prevent, and that's not a good design for security. I think you are overstating this. There is some confusion about the effect of UsePAM=yes, but the others are quite clear. PAM is something of a special (basket?) case anyway, because there one is delegating control to PAM's policy. -d From dtucker at zip.com.au Sat May 8 15:28:50 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 08 May 2004 15:28:50 +1000 Subject: control of auth methods In-Reply-To: <409C627C.1010809@noaa.gov> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <1083964785.4526.935.camel@hades.cambridge.redhat.com> <409CB9D3.9080100@zip.com.au> <409C386E.8010702@noaa.gov> <409C3C7B.4050409@mindrot.org> <409C627C.1010809@noaa.gov> Message-ID: <409C7012.90803@zip.com.au> Jefferson Ogata wrote: > The current design of the config file is hardly a triumph of simplicity > and logic. The auth types have internal names, yet the auth controls are > this morass of booleans. It would make more sense to list the internal > names, a la Ciphers. The current config file design pre-dates OpenSSH. If you look at the sample config file from ssh-1.2.12 you'll recognise the format (and many of the current options). Ciphers was added when Markus added SSH protocol 2 support. > Instead we have to figure out how various > combinations of peculiarly named flags such as > PAMAuthenticationViaKbdInt That's gone (except as a deprecated warning). > PermitRootLogin, This thread is discussing generalizing that. > ChallengeResponseAuthentication, RhostsRSAAuthentication, UsePam, > AllowUsers, DenyUsers, etc. interact to produce which set of valid auth > types for whom. It ends up being trial-and-error to determine whether > the right users can authenticate the way you want to allow, and /can't/ > authenticate the way you want to prevent, and that's not a good design > for security. You could read "trial-and-error" as "testing and validation" :-) -- 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 Sat May 8 15:39:12 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 08 May 2004 15:39:12 +1000 Subject: control of auth methods In-Reply-To: <409C6A01.10005@mindrot.org> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <1083964785.4526.935.camel@hades.cambridge.redhat.com> <409CB9D3.9080100@zip.com.au> <409C386E.8010702@noaa.gov> <409C3C7B.4050409@mindrot.org> <409C627C.1010809@noaa.gov> <409C6A01.10005@mindrot.org> Message-ID: <409C7280.7000500@zip.com.au> Damien Miller wrote: > Perhaps we would be willing to add a single "AuthMethods xxx,yyy,zzz", > where xxx, etc are the auth method names used in the protocol. We'd have > to keep the older names around for a fair while to stop breakage. How should methods that have different names between protocols 1 and 2 be handled? eg ChallengeResponseAuthentication is "challenge-response" for v1 but "keyboard-interactive" for v2. Ie, would "AuthMethods keyboard-interactive" enable challenge-response in v1? -- 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 Sat May 8 15:45:28 2004 From: djm at mindrot.org (Damien Miller) Date: Sat, 08 May 2004 15:45:28 +1000 Subject: control of auth methods In-Reply-To: <409C7280.7000500@zip.com.au> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <40953858.8070405@kegel.com> <1083544260.4383.694.camel@imladris.demon.co.uk> <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <1083964785.4526.935.camel@hades.cambridge.redhat.com> <409CB9D3.9080100@zip.com.au> <409C386E.8010702@noaa.gov> <409C3C7B.4050409@mindrot.org> <409C627C.1010809@noaa.gov> <409C6A01.10005@mindrot.org> <409C7280.7000500@zip.com.au> Message-ID: <409C73F8.9060102@mindrot.org> Darren Tucker wrote: > Damien Miller wrote: > > >>Perhaps we would be willing to add a single "AuthMethods xxx,yyy,zzz", >>where xxx, etc are the auth method names used in the protocol. We'd have >>to keep the older names around for a fair while to stop breakage. > > > How should methods that have different names between protocols 1 and 2 > be handled? eg ChallengeResponseAuthentication is "challenge-response" > for v1 but "keyboard-interactive" for v2. > > Ie, would "AuthMethods keyboard-interactive" enable challenge-response > in v1? Good point. Two obvious options: 1. Don't use protocol method names - use short names instead and make them common between protocols. E.g. pubkey, password, challresp 2. Have separate AuthMethods1 and AuthMethods2 controls. AuthMethods1 would require some poetic license, as the actual auth methods are identified by number :) Given what we want to do for PermitRootLogin, perhaps the former would lend itself to code sharing the most. -d From carson at taltos.org Sat May 8 16:41:53 2004 From: carson at taltos.org (Carson Gaspar) Date: Sat, 08 May 2004 02:41:53 -0400 Subject: Connection caching? In-Reply-To: References: Message-ID: <1B15B76A58FF95C1721DFD11@[192.168.20.2]> --On Friday, May 07, 2004 10:05 PM -0500 Ben Lindstrom wrote: > Which is fine, but some around here have expressed a need for ordered > authentication. Which would make a bitmask implementation imposible > without predefining all possible forms of combination. *Raises hand* When I implemented this eternities ago, the purpose was to require something that wasn't password based auth first, and then password auth. That way, you can turn on bad password account lockout without it being incredibly easy to cause a DOS. -- Carson From gert at greenie.muc.de Sat May 8 19:48:04 2004 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 8 May 2004 11:48:04 +0200 Subject: cidr matching In-Reply-To: <409CC8B4.2090207@zip.com.au>; from dtucker@zip.com.au on Sat, May 08, 2004 at 09:47:00PM +1000 References: <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <1083964785.4526.935.camel@hades.cambridge.redhat.com> <409CB9D3.9080100@zip.com.au> <409C3712.2090809@mindrot.org> <409CC8B4.2090207@zip.com.au> Message-ID: <20040508114804.N3896@greenie.muc.de> Hi, On Sat, May 08, 2004 at 09:47:00PM +1000, Darren Tucker wrote: > If the same matcher was used from the hypothetical > AuthenticationsForUser, you could then say things like "allow password, > hostbased or public key for connections from the local net, but require > password+pubkey for connections from the rest of the Net", thusly: > > AuthenticationsForUser * password,public-key,hostbased 192.168.0.0/22 > AuthenticationsForUser * password+public-key This is something that would be very (VERY) valuable for us. AuthenticationsForUser * password,public-key,hostbased 192.168.0.0/22 AuthenticationsForUser * password+skey (*If* they want to login from home, or from "somewhere on the road that might possibly be keyboad-sniffed", fine, but they need to use a OTP for that) gert -- Gert Doering Mobile communications ... right now writing from * back at home * From dtucker at zip.com.au Sun May 9 11:20:09 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 09 May 2004 11:20:09 +1000 Subject: Connection caching? In-Reply-To: <1B15B76A58FF95C1721DFD11@[192.168.20.2]> References: <1B15B76A58FF95C1721DFD11@[192.168.20.2]> Message-ID: <409D8749.9040504@zip.com.au> Carson Gaspar wrote: > When I implemented this eternities ago, the purpose was to require > something that wasn't password based auth first, and then password auth. > That way, you can turn on bad password account lockout without it being > incredibly easy to cause a DOS. OK, fair enough. You could also prevent password guessing if you don't have lockout. Is your patch still floating around someplace? -- 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 carson at taltos.org Sun May 9 18:31:58 2004 From: carson at taltos.org (Carson Gaspar) Date: Sun, 09 May 2004 04:31:58 -0400 Subject: Connection caching? In-Reply-To: <409D8749.9040504@zip.com.au> References: <1B15B76A58FF95C1721DFD11@[192.168.20.2]> <409D8749.9040504@zip.com.au> Message-ID: --On Sunday, May 09, 2004 11:20 AM +1000 Darren Tucker wrote: > Is your patch still floating around someplace? It's in the list archives, but it's pre-privsep. I never updated it, since it was rejected for being too complex (not code-wise, but function-wise). If Marcus no longer objects to auth vectors, I'd be happy to re-implement it, but I don't want to spend the time if it's just going to get bounced again (for non code quality reasons). -- Carson From frank.goma at atosorigin.com Mon May 10 01:41:33 2004 From: frank.goma at atosorigin.com (GOMA, Frank) Date: Sun, 09 May 2004 16:41:33 +0100 Subject: Openssh installation only works for user root Message-ID: <2407A2B36F84D54683FE604C752B433602C77720@notes4.sema.co.uk> Hi, I have recently compiled a copy of OpenSSH for use on Reliant Unix ( Sinix ) version 5.45. My installation works okay for user root. When I try to log on as another user I get prompted for the user password. When I type this in OpenSSH throws me out each time. I have been able to see any errors. My version is OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004. I am using Putty Release 0.52. Regards Frank Goma Unix Technical Services UK Atos Origin Tel: 0115 957 6336 Mobile: 07733311390 Email : Frank.Goma at atosorigin.com ___________________________________________________________________________ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. ___________________________________________________________________________ From dtucker at zip.com.au Mon May 10 09:52:24 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 10 May 2004 09:52:24 +1000 Subject: Openssh installation only works for user root In-Reply-To: <2407A2B36F84D54683FE604C752B433602C77720@notes4.sema.co.uk> References: <2407A2B36F84D54683FE604C752B433602C77720@notes4.sema.co.uk> Message-ID: <409EC438.809@zip.com.au> GOMA, Frank wrote: > I have recently compiled a copy of OpenSSH for use on Reliant Unix ( Sinix ) > version 5.45. My installation works okay for user root. When I try to log on > as another user I get prompted for the user password. When I type this in > OpenSSH throws me out each time. I have been able to see any errors. > > My version is OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar > 2004. I am using Putty Release 0.52. That sounds a bit like the broken uid/gid swapping, but a fix for that on Reliant Unix should be in 3.8p1. Check config.h after running configure, BROKEN_SETREUID and BROKEN_SETREGID should be defined. If they're not, add #define's for them and recompile and retest. If that doesn't help, you will need to run the server in debug mode to figure out what's going on. Log in as root then run ssh on another port (eg "/path/to/sshd -ddd -p 222"), connect as a normal user ("ssh -p 222 yourserver") then post the debug log here. -- 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 bigtrail2000 at yahoo.co.jp Mon May 10 08:52:24 2004 From: bigtrail2000 at yahoo.co.jp (=?ISO-2022-JP?B?GyRCJWElRyUjJSIbKEIg?=) Date: Mon, 10 May 2004 07:52:24 +0900 Subject: =?iso-2022-jp?b?GyRCTCQ+NUJ6OS05cCIoGyhCNTAwMBskQjFfJEczKzZIGyhC?= =?iso-2022-jp?b?GyRCJDckXiQ7JHMkKyEqGyhC?= Message-ID: <20040509.2252230906@bigtrail2000-yahoo.co.jp> ?????? ??????????????? ??????????????????????????? ????????????????????????? ???? bluelandok at yahoo.co.jp ?????????? ??????????????? ??????????? ??TEL 0774-56-6428 ????????????????????????????? ????5000?????????????????????????? ???????????????? ???? http://practicallady.yi.org/ From tdsc.af at infineon.com Tue May 11 01:54:15 2004 From: tdsc.af at infineon.com (TDSCAF) Date: Mon, 10 May 2004 17:54:15 +0200 Subject: Contribution to 3.8.1pl1 Message-ID: <409FA5A7.CF65B317@infineon.com> Hi, here another implementation for using netgroups in {Allow|Deny}Users, that is independent from NIS and should also work with LDAP netgroups, if the libraries on the respective OS support this. Hello, I added the support for netgroups to be used in the AllowUsers and DenyUsers parameters. This has some advantages: * hostnames or ip addresses need not to be written or maintained in the sshd_config file, but can be kept abstract names what also simplifies a bit largescale openssh installations * sshd_config needs not change and sshd be restarted when changing the list of allowed / denied users/hosts in the NIS netgroups Though considered to be dead some time in the future, NIS still serves it's purpose in many environments. The netgroups will make their way into LDAP some time in the future, then i'll probably post another patch. For now i added the functionality mainly in the match.c file, adapted man-page files and autoconf to figure out automatically, if NIS client support is available on the platform. The attached patch can be applied changing to the source directory of 3.8.1pl1 and running gunzip < /path/to/openssh-3.8.1p1.patch_af.gz | patch -p 1 Hope this will be included into the official distribution. Everyone is welcome to review the modifications. Regards, Albert -- diff -ru openssh-3.8.1p1/match.c openssh-3.8.1p1.paf/match.c --- openssh-3.8.1p1/match.c Tue Mar 5 02:42:43 2002 +++ openssh-3.8.1p1.paf/match.c Mon May 10 09:42:14 2004 @@ -199,6 +199,39 @@ } /* + * match user in @netgroup + */ +int +match_user_or_netgroup(const char *user, char *pattern) +{ + if(pattern[0] != '@') + return match_pattern(user, pattern); + +#ifdef HAVE_INNETGR + return innetgr(pattern + 1, NULL, user, NULL); +#else + return 0; +#endif +} + +/* + * match host in @netgroup + */ +int +match_host_and_ip_or_netgroup(const char *host, const char * ipaddr, char *pattern) +{ + if(pattern[0] != '@') + return match_host_and_ip(host, ipaddr, pattern); + +#ifdef HAVE_INNETGR + return innetgr(pattern + 1, host, NULL, NULL) + || innetgr(pattern + 1, ipaddr, NULL, NULL); +#else + return 0; +#endif +} + +/* * match user, user at host_or_ip, user at host_or_ip_list against pattern */ int @@ -208,15 +241,18 @@ char *p, *pat; int ret; - if ((p = strchr(pattern,'@')) == NULL) - return match_pattern(user, pattern); + if (strlen(pattern) < 1) + return 0; + + if ((p = strchr(pattern + 1, '@')) == NULL) + return match_user_or_netgroup(user, pattern); pat = xstrdup(pattern); - p = strchr(pat, '@'); + p = strchr(pat + 1, '@'); *p++ = '\0'; - if ((ret = match_pattern(user, pat)) == 1) - ret = match_host_and_ip(host, ipaddr, p); + if ((ret = match_user_or_netgroup(user, pat)) == 1) + ret = match_host_and_ip_or_netgroup(host, ipaddr, p); xfree(pat); return ret; diff -ru openssh-3.8.1p1/sshd_config.0 openssh-3.8.1p1.paf/sshd_config.0 --- openssh-3.8.1p1/sshd_config.0 Sun Apr 18 14:52:00 2004 +++ openssh-3.8.1p1.paf/sshd_config.0 Thu May 6 17:31:35 2004 @@ -37,7 +37,10 @@ merical user ID is not recognized. By default, login is allowed for all users. If the pattern takes the form USER at HOST then USER and HOST are separately checked, restricting logins to particular - users from particular hosts. + users from particular hosts. If NIS is available and netgroup + querying is built in, either USER and HOST can be the name of a + netgroup of users or hosts, respectively, prefixed with a @ . Then + @myusers@@myhosts is a valid entry here. AuthorizedKeysFile Specifies the file that contains the public keys that can be used @@ -112,7 +115,10 @@ is not recognized. By default, login is allowed for all users. If the pattern takes the form USER at HOST then USER and HOST are separately checked, restricting logins to particular users from - particular hosts. + particular hosts. If NIS is available and netgroup querying is + built in, either USER and HOST can be the name of a netgroup of + users or hosts, respectively, prefixed with the character @ . + Then e.g. @myusers@@myhosts is a valid entry here. GatewayPorts Specifies whether remote hosts are allowed to connect to ports diff -ru openssh-3.8.1p1/sshd_config.5 openssh-3.8.1p1.paf/sshd_config.5 --- openssh-3.8.1p1/sshd_config.5 Wed Apr 14 05:04:36 2004 +++ openssh-3.8.1p1.paf/sshd_config.5 Thu May 6 17:54:27 2004 @@ -96,7 +96,10 @@ By default, login is allowed for all users. If the pattern takes the form USER at HOST then USER and HOST are separately checked, restricting logins to particular -users from particular hosts. +users from particular hosts. If NIS is available and netgroup +querying is built in, either USER and HOST can be the name of a +netgroup of users or hosts, respectively, prefixed with a @ . Then + at myusers@@myhosts is a valid entry here. .Pp .It Cm AuthorizedKeysFile Specifies the file that contains the public keys that can be used @@ -206,7 +209,10 @@ By default, login is allowed for all users. If the pattern takes the form USER at HOST then USER and HOST are separately checked, restricting logins to particular -users from particular hosts. +users from particular hosts. If NIS is available and netgroup querying is +built in, either USER and HOST can be the name of a netgroup of +users or hosts, respectively, prefixed with the character @ . +Then e.g. @myusers@@myhosts is a valid entry here. .It Cm GatewayPorts Specifies whether remote hosts are allowed to connect to ports forwarded for the client. -- Albert Fluegel science + computing ag IT Services Ingolstaedter Stra?e 22 phone +49 89 356386 851 80807 Muenchen, Germany fax +49 89 356386 737 www.science-computing.de ________________________________at Infineon tdsc.af at infineon.com phone +49 89 234 27690 From mouring at etoh.eviladmin.org Tue May 11 02:18:32 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 10 May 2004 11:18:32 -0500 (CDT) Subject: Contribution to 3.8.1pl1 In-Reply-To: <409FA5A7.CF65B317@infineon.com> Message-ID: On Mon, 10 May 2004, TDSCAF wrote: [..] Do note I think the first time this was brought up it was shot down. One would have to review the archives for the extact reason because I don't remember any more. [..] > --- openssh-3.8.1p1/sshd_config.0 Sun Apr 18 14:52:00 2004 First off sshd_config.0 is auto generated from the sshd_config.5. Don't bother suppling it with the patch. > +++ openssh-3.8.1p1.paf/sshd_config.0 Thu May 6 17:31:35 2004 > @@ -37,7 +37,10 @@ > merical user ID is not recognized. By default, login is allowed > for all users. If the pattern takes the form USER at HOST then USER > and HOST are separately checked, restricting logins to particular > - users from particular hosts. > + users from particular hosts. If NIS is available and netgroup > + querying is built in, either USER and HOST can be the name of a > + netgroup of users or hosts, respectively, prefixed with a @ . Then > + @myusers@@myhosts is a valid entry here. > I really hate that syntax.. It's ugly as sin. - Ben From Sergio.Gelato at astro.su.se Tue May 11 02:36:44 2004 From: Sergio.Gelato at astro.su.se (Sergio Gelato) Date: Mon, 10 May 2004 18:36:44 +0200 Subject: Contribution to 3.8.1pl1 In-Reply-To: References: <409FA5A7.CF65B317@infineon.com> Message-ID: <20040510163644.GB4531@hanuman.astro.su.se> * Ben Lindstrom [2004-05-10 11:18:32 -0500]: > > + @myusers@@myhosts is a valid entry here. > > I really hate that syntax.. It's ugly as sin. I agree it's ugly, especially the @@, but there is precedent for the use of @ as a netgroup name prefix (Linux NFS exports) and it does have the merit of avoiding accidents where a name that wasn't intended to be a netgroup gets interpreted as one (perhaps because someone poisoned the nscd cache, or something of that sort). All in all, I'd vote for keeping it despite its ugliness. From juergen.hallbauer at t-online.de Tue May 11 04:29:13 2004 From: juergen.hallbauer at t-online.de (juergen.hallbauer at t-online.de) Date: Mon, 10 May 2004 18:29:13 -0000 Subject: SPAM-Check: Re: Message Error Message-ID: <1BNFUY-0W8WNk0@fwd02.sul.t-online.com> SPAM-Check AutoReply:Wir haben Ihre Mail erhalten! >>tech-support at ush.de From copyletterjp at yahoo.co.jp Tue May 11 01:27:36 2004 From: copyletterjp at yahoo.co.jp (=?ISO-2022-JP?B?GyRCJU0lQyVIJVMlOCVNJTkbKEIg?=) Date: Tue, 11 May 2004 00:27:36 +0900 Subject: =?iso-2022-jp?b?GyRCTCQ+NUJ6OS05cCIoQUc/TSRHJGI0SkMxJEs9UE1oGyhC?= =?iso-2022-jp?b?GyRCJF4kOSEjGyhC?= Message-ID: <20040510.1527350781@copyletterjp-yahoo.co.jp> ??????????????? ???????????? ??????????????????????? ?? 0774-52-5633 ?????????????? ???????????????????????????? ????????gomennasai79 at yahoo.co.jp ? ????????????????? ??????????? ?????????????????15?????????? ??????????????? ??????????????????????? ??http://nicenet.mydns.jp/ From mouring at etoh.eviladmin.org Tue May 11 07:35:05 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 10 May 2004 16:35:05 -0500 (CDT) Subject: Contribution to 3.8.1pl1 In-Reply-To: <20040510163644.GB4531@hanuman.astro.su.se> Message-ID: On Mon, 10 May 2004, Sergio Gelato wrote: > * Ben Lindstrom [2004-05-10 11:18:32 -0500]: > > > + @myusers@@myhosts is a valid entry here. > > > > I really hate that syntax.. It's ugly as sin. > > I agree it's ugly, especially the @@, but there is precedent for the use of > @ as a netgroup name prefix (Linux NFS exports) and it does have the merit > of avoiding accidents where a name that wasn't intended to be a netgroup > gets interpreted as one (perhaps because someone poisoned the nscd cache, > or something of that sort). All in all, I'd vote for keeping it despite > its ugliness. > The prefix of @ does not bother me.. it is the double @@ and the idea that @user@@host is a valid netgroup. Which breaks what netgroups was designed for. However, since NFS exports has different rules than {Allow/Deny}*. I don't see why we should follow with that syntax. - Ben From stanislaw.walczak at eds.com Tue May 11 13:19:26 2004 From: stanislaw.walczak at eds.com (Walczak, Stanislaw) Date: Mon, 10 May 2004 23:19:26 -0400 Subject: FW: FW: found bug in 3.8.p1 ? Message-ID: fyi -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: May 10, 2004 9:43 PM To: Walczak, Stanislaw Subject: Re: FW: found bug in 3.8.p1 ? Please don't send bug reports to my personal email address. Use the mailing list (openssh-unix-dev at mindrot.org), that's what it's there for. Walczak, Stanislaw wrote: [...] >>ian.c.campbell: debug1: Remote: X11 forwarding disabled in user >>configuration file. >>Last login: Mon May 10 11:22:50 2004 from 148.97.65.29 >>WARNING: Your password has expired. >>You must change your password now and login again! >>Enter existing login password: >>New Password: >>Re-enter new Password: >>passwd: password successfully changed for iancampbell >>ian.c.campbell: Last login: Mon May 10 11:32:57 2004 from 199.228.199.11 >>WARNING: Your password has expired. >>You must change your password now and login again! >>passwd: Changing password for iancampb >>passwd: User unknown: iancampb >>Permission denied >>Connection to 159.249.179.26 closed. This is all one login session? > [Walczak, Stanislaw] Shall we file this one as a bug ? Sure, but it's probably a bug in you vendor's "passwd" program. All sshd does is run "passwd" with no arguments then exit. -- 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 kumaresh_ind at gmx.net Tue May 11 19:53:24 2004 From: kumaresh_ind at gmx.net (Kumaresh) Date: Tue, 11 May 2004 15:23:24 +0530 Subject: SSH : UsePAM yes and Password authentication Message-ID: <021601c4373d$d55e0d20$230110ac@kurco> Hello, We have a setup with OpenSSH server on HP-UX machine with windows SSH clients and the server system is in trusted mode. There are configuration settings in the trusted system to check the number of unsuccessful logins to the system and the account can be configured to lock if the real unsuccessful attempt is exceeding the allowable limit. Now, as SSH do not have any explicit code to check all these trusted system related configuration, we have a necessity that the code has to go through PAM. We are using "PowerTerm Interconnect" windows SSH clients and in these clients there are no options to set "keyboard-interactive" method for authentication. So,even if we set "UsePAM yes" in the server side, the client is not sending a "keyboard-interactive" string and sends a "password" string, so, the "password" method is being started. So, the system is doing normal password authentication even if "UsePAM yes" is configured. But, we need the sshd server should pass through PAM so that the trusted system behaviour will be taken care by PAM modules. In order to achieve this, we like the sshd server to do the keyboad-interactive feature for Password authentication also. That is., even the normal password authentication it has to go through PAM. First of all,what are the impacts for this change in design? Is this change valid? Any help will be much appreciated. Thanks, Kumar From stanislaw.walczak at eds.com Tue May 11 23:27:42 2004 From: stanislaw.walczak at eds.com (Walczak, Stanislaw) Date: Tue, 11 May 2004 09:27:42 -0400 Subject: openssh3.8p1 passwd -f for uid's longer than 8 char problem Message-ID: Hi ! Solaris 5.8 Generic_108528-19 sun4u sparc SUNW,Ultra-60 Putty 0.53b sshd version OpenSSH_3.8p1, OpenSSL 0.9.7d 17 Mar 2004 While using passwd -f for uid 10 char long, I'm not able to logon again to change password because uid is truncated to 8 char. Incoming packet type 14 / 0x0e (SSH1_SMSG_SUCCESS) Event Log: Allocated pty Outgoing packet type 12 / 0x0c (SSH1_CMSG_EXEC_SHELL) Event Log: Started session Incoming packet type 17 / 0x11 (SSH1_SMSG_STDOUT_DATA) 00000000 00 00 00 95 4c 61 73 74 20 6c 6f 67 69 6e 3a 20 ....Last login: 00000010 4d 6f 6e 20 4d 61 79 20 31 30 20 30 38 3a 31 31 Mon May 10 08:11 00000020 3a 31 36 20 32 30 30 34 20 66 72 6f 6d 20 31 35 :16 2004 from 15 00000030 39 2e 32 34 39 2e 31 37 39 2e 31 32 30 0d 0d 0a 9.249.179.120... 00000040 57 41 52 4e 49 4e 47 3a 20 59 6f 75 72 20 70 61 WARNING: Your pa 00000050 73 73 77 6f 72 64 20 68 61 73 20 65 78 70 69 72 ssword has expir 00000060 65 64 2e 0d 0a 59 6f 75 20 6d 75 73 74 20 63 68 ed...You must ch 00000070 61 6e 67 65 20 79 6f 75 72 20 70 61 73 73 77 6f ange your passwo 00000080 72 64 20 6e 6f 77 20 61 6e 64 20 6c 6f 67 69 6e rd now and login 00000090 20 61 67 61 69 6e 21 0d 0a again!.. Incoming packet type 17 / 0x11 (SSH1_SMSG_STDOUT_DATA) 00000000 00 00 00 5b 70 61 73 73 77 64 3a 20 43 68 61 6e ...[passwd: Chan 00000010 67 69 6e 67 20 70 61 73 73 77 6f 72 64 20 66 6f ging password fo 00000020 72 20 6f 70 73 77 61 72 65 30 0d 0a 70 61 73 73 r opsware0..pass 00000030 77 64 3a 20 55 73 65 72 20 75 6e 6b 6e 6f 77 6e wd: User unknown 00000040 3a 20 6f 70 73 77 61 72 65 30 0d 0a 50 65 72 6d : opsware0..Perm 00000050 69 73 73 69 6f 6e 20 64 65 6e 69 65 64 0d 0a ission denied.. Incoming packet type 20 / 0x14 (SSH1_SMSG_EXIT_STATUS) 00000000 00 00 00 01 .... Event Log: Server sent command exit status 1 Version 3.7p2 with pwexp is behaving the same way. Thank you for help in advance /s.w. From Darren.Moffat at Sun.COM Tue May 11 23:42:24 2004 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Tue, 11 May 2004 06:42:24 -0700 Subject: openssh3.8p1 passwd -f for uid's longer than 8 char problem In-Reply-To: References: Message-ID: <40A0D840.7090202@Sun.COM> Walczak, Stanislaw wrote: > Hi ! > Solaris 5.8 Generic_108528-19 sun4u sparc SUNW,Ultra-60 > Putty 0.53b > sshd version OpenSSH_3.8p1, OpenSSL 0.9.7d 17 Mar 2004 > > While using passwd -f for uid 10 char long, I'm not able to logon again to > change password because uid is truncated to 8 char. Solaris 8 does NOT support usernames longer than 8 chars in length. It may or may not work when you use longer usernames. So it is possible that you are hitting some OS limitation rather than a limitation in OpenSSH. -- Darren J Moffat From noel at devtech.com Wed May 12 06:03:55 2004 From: noel at devtech.com (Noel J. Bergman) Date: Tue, 11 May 2004 16:03:55 -0400 Subject: Logging of authorized keys Message-ID: It is possible for ~user/.ssh/authorized_keys to have multiple entries. It would be quite helpful if openssh would enhance the log to indicate WHICH key was accepted, not just that a key was accepted. In other words, would you please modify: $TIMESTAMP $HOST sshd[$PID]: Accepted publickey for $USER from $IP port $PORT $PROTOCOL to add an indication (e.g., the comment field) as to which key was used: $TIMESTAMP $HOST sshd[$PID]: Accepted publickey ($COMMENT) for $USER from $IP port $PORT $PROTOCOL --- Noel From stuge-openssh-unix-dev at cdy.org Wed May 12 06:44:06 2004 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Tue, 11 May 2004 22:44:06 +0200 Subject: Logging of authorized keys In-Reply-To: References: Message-ID: <20040511204406.GB27894@foo.birdnet.se> On Tue, May 11, 2004 at 04:03:55PM -0400, Noel J. Bergman wrote: > In other words, would you please modify: > > $TIMESTAMP $HOST sshd[$PID]: Accepted publickey for $USER from $IP port > $PORT $PROTOCOL > > to add an indication (e.g., the comment field) as to which key was used: > > $TIMESTAMP $HOST sshd[$PID]: Accepted publickey ($COMMENT) for $USER > from $IP port $PORT $PROTOCOL This has come up before but been shot down with the rationale that arbitrary user input ($COMMENT) probably shouldn't be sent to the system logger, IIRC. //Peter From djm at mindrot.org Wed May 12 07:54:11 2004 From: djm at mindrot.org (Damien Miller) Date: Wed, 12 May 2004 07:54:11 +1000 Subject: Logging of authorized keys In-Reply-To: <20040511204406.GB27894@foo.birdnet.se> References: <20040511204406.GB27894@foo.birdnet.se> Message-ID: <40A14B83.6050209@mindrot.org> Peter Stuge wrote: > This has come up before but been shot down with the rationale that > arbitrary user input ($COMMENT) probably shouldn't be sent to the > system logger, IIRC. We don't need to worry about that: all log output is already passed through vis() to tidy any control characters. There were some issues relating to the fact that we don't keep the comments around for ssh2 keys. There is also a bug relating to fingerprint logging vs privsep, but I'm not sure how stale it is. -d From YKFNKZI at kgb.hu Wed May 12 18:07:55 2004 From: YKFNKZI at kgb.hu (Dominique Mccain) Date: Wed, 12 May 2004 04:07:55 -0400 Subject: Look at research enabling enhanced profitability Message-ID: **SRGE***SRGE***SRGE***SRGE***SRGE***SRGE** Market Undervalue Opening Price: 1.00 7 Day Target: 2.65 1 Month Target: 3.80 Outstanding Shares: 16.5 million Public Float: 3.4 million Explosive short term trading profits in a new technology issue (Ticker: SRGE) are being predicted for May 11-May 17 as many significant news releases indicate strong contractual revenues with major Telecom firms. MAJOR ANNOUNCEMENTS AND HUGE NEWSLETTER COVERAGE THIS WEEK FOR SRGE! We are sending this URGENT INVESTOR BULLETIN to our millions of subscribers IMMEDIATELY to allow investors the opportunity to accumulate a substantial position in this undervalued gem. Surge Technologies Corp. (SRGE) is the latest new pick where the stage is set for a tremendous advance. This company deserves your immediate attention! Stock Mogul Team found a new winner yet again! SRGE has been successfully working with Telecommunications giants (with five million subscriber lines) over the last 4 years, but is now projecting "a banner expansion year with geometric growth in revenues" due largely to sales demands for their innovative patented products and expansion into International telecom markets. Surge Technologies, Inc. (SRGE) is a cutting-edge leader that designs, develops, manufactures, and markets superior patented outside plant electrical surge protection equipment for the telecommunications industry. The US sales projections for this market are $4 Billion annually, with this figure growing rapidly as the expansion of new HDSL and ADSL technologies permeate the industry. SRGE just announced two major contracts totaling $5 Million, making their shares grossly undervalued based upon conservative EPS estimates. This is just the tip of the iceberg and we expect a continuous flow of huge news announcements detailing the highly profitable chain of events to follow for SRGE in the near future. We can state from our judicious research that we are not alone in viewing SRGE as one of those extremely rare opportunities where the impact of major news events simultaneously boosts the value of a company while ultimately providing substantial reward for its shareholders. SRGE provides the Telecom industry with the highest quality "protection element" for complex digital switches. Protecting these Telecom switching devices is crucial to inclusive components that are sensitive to interruptions in voltage which can cause extensive network damage, thus negating costly and time-consuming repair and down-time. Major Telecoms require this protection throughout their network in order to prevent the hazards of harming personnel, damaging expensive equipment, and massive system failures. How many times have you seen issues explode but you couldn't get your hands on them or didn't have the right information in time? We are alerting you now to a special Company with a unique technology that is on the forefront of a breakout! We are excited about SRGE's technology and expansion as they prepare to ink deal after deal with Major US Telecoms in conjunction with dramatic increases in revenue for 2004 and 2005. SRGE has made phenomenal advancements but may be one of the few stocks left in this industry group that is unknown and undervalued, therefore a 300%-400% jump may wind up being conservative. --------------------------------------------------------------------- Information within this email contains "forward looking statements" within the meaning of Section 27A of the Securities Act of 1933 and Section 21B and the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, goals, expectations, beliefs, plans, projections, objectives, assumptions or future events or performance are not statements of historical fact and may be "forward looking statements". Forward looking statements are based upon expectations, estimates and projections, at the time the statements are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those presently anticipated. Forward looking statements in this action may be identified through the use of words such as: "projects", "foresee", "expects", "estimates", "believes", "understands", "will", "anticipates", or that by statements indicating certain actions "may", "could", or "might" occur. All information provided within this email pertaining to investing, stocks, securities must be understood as information provided and not investment advice. Stock Mogul Team advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this email. None of the material within this report shall be construed as any kind of investment advice. In compliance with Section 17(b), we disclose the holdings of 20,000 independently purchased shares of srge prior to the publication of this report. Be aware of an inherent conflict of interest resulting from such holdings due to our intent to profit from the liquidation of these shares. Shares may be sold at any time, even after positive statements have been made regarding the above company. From lindysandiego at yahoo.com Thu May 13 00:16:13 2004 From: lindysandiego at yahoo.com (Thomas Baden) Date: Wed, 12 May 2004 07:16:13 -0700 (PDT) Subject: Oddness with agent forwarding and -i Message-ID: <20040512141613.37346.qmail@web60503.mail.yahoo.com> Hey everyone, I hope this isn't an old issue; I wasn't able to locate it in the archives. I have a number of scripts which make use of ssh -i and scp -i, where the target host has the specified key in its authorized_keys file with a command= override to do immediate processing of the received data. This works extremely well, as we are able to establish single-function, triggered-action RSA keys to toss data from host to host. Unfortunately, when invoked with a forwarding agent present, the agent gets to pass its key(s) before the key presented on the command line, which causes all the magic to break. I've tried echoing the debug output, and it confirms that the agent does indeed get first crack at authenticating the connection. Is this expected behaviour, or should the presence of -i on the command line take precedence over the agent? Cheers, -Thomas __________________________________ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 From gordey at stdio.com Thu May 13 02:46:32 2004 From: gordey at stdio.com (Randy Gordey) Date: Wed, 12 May 2004 12:46:32 -0400 Subject: Van Dyke's Public Key Assistant Message-ID: <008601c43840$b4f27ef0$4ba5a8c0@rgordeylaptop> Jeff Van Dyke's "Public Key Assistant subsystem" was previously discussed here: (end of a short thread) http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=103436908422003&w=2 I do see a few comments that seem to point out his arrogance and some disgust about OpenBSD's RCSID, but has anybody found it to be unsecure or if it was bug ridden. The subject sorta dies right there. If you follow the links on www.vandyke.com, they still seem to be maintaining the patch... Even if it was never going to be part of the RFC and might be only mildly popular is there a technical reason the OpenSSH project's source should not include his patch? Does it hamstring security? Anyone know if Van Dyke's license and/or copyrights would prevent a third party SSH client, from utilizing this "feature"? It looked find to me, but I have been known to do stupid things at times. That usually happens right after I assume anything. Regards, R. Gordey From Jefferson.Ogata at noaa.gov Thu May 13 02:54:00 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Wed, 12 May 2004 12:54:00 -0400 Subject: Oddness with agent forwarding and -i In-Reply-To: <20040512141613.37346.qmail@web60503.mail.yahoo.com> References: <20040512141613.37346.qmail@web60503.mail.yahoo.com> Message-ID: <40A256A8.9060106@noaa.gov> Thomas Baden wrote: > I have a number of scripts which make use of ssh -i > and scp -i, where the target host has the specified > key in its authorized_keys file with a command= > override to do immediate processing of the received > data. This works extremely well, as we are able to > establish single-function, triggered-action RSA keys > to toss data from host to host. > > Unfortunately, when invoked with a forwarding agent > present, the agent gets to pass its key(s) before the > key presented on the command line, which causes all > the magic to break. I've tried echoing the debug > output, and it confirms that the agent does indeed get > first crack at authenticating the connection. I can't comment on whether this is really intended behavior, but you can easily work around it by unsetting SSH_AUTH_SOCK before you run ssh: SSH_AUTH_SOCK= ssh -i foo... -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From david.r.steiner at Dartmouth.EDU Thu May 13 04:58:34 2004 From: david.r.steiner at Dartmouth.EDU (David R. Steiner) Date: Wed, 12 May 2004 14:58:34 -0400 Subject: 3.8p1 on Solaris 8 Message-ID: Hello, I am running into some strange (to me) behavior trying to upgrade from 3.6.1p2 to 3.8p1 on Solaris 8. All of my machines are running 3.6.1p2 (Linux boxes have had RH errata applied). When I ssh with my AFS account name from any of them to the Solaris 8 box running 3.6.1p2, it responds with "afsuser at machine's password:". Once the password is given, I am logged in just fine. When I do the same thing with 3.8.1p2, instead of the password prompt above, I get "AFS password:". I can authenticate fine but I do not receive a token. There is no difference in the pam.conf file for either of these instances. Anyone offer any suggestions? Have I missed something obvious? I know that AFS support was dropped in 3.7 (which is why all of my machines are running 3.6) but since OpenSSH is not compiled with AFS support on the Solaris boxes and relies on PAM, I am assuming this is not the issue. 3.8.p1 was configured with: ./configure --prefix=/usr/ssh --without-zlib-version-check --with-pam --with-prngd-socket=/var/run/opt/prngd-socket --with-tcp-wrappers=/usr/local --sysconfdir=/etc/ssh --with-pid-dir=/var/run --with-ipv4-default --with-default-path=/usr/bin:/bin:/usr/sbin The pam.conf file for other looks like this: other auth sufficient pam_afs.so.1 try_first_pass set_token ignore_root setenv_password_expires other auth requisite pam_authtok_get.so.1 other auth required pam_dhkeys.so.1 other auth required pam_unix_auth.so.1 TIA. -David- -- David R. Steiner david.r.steiner at dartmouth.edu UNIX System Manager Phone: 603.646.3127 Dartmouth College Fax: 603.646.1041 From mouring at etoh.eviladmin.org Thu May 13 05:13:58 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Wed, 12 May 2004 14:13:58 -0500 (CDT) Subject: 3.8p1 on Solaris 8 In-Reply-To: Message-ID: I believe this links in with your issue: http://bugzilla.mindrot.org/show_bug.cgi?id=688 No intree solution at this moment. - Ben On Wed, 12 May 2004, David R. Steiner wrote: > Hello, > > I am running into some strange (to me) behavior trying to upgrade > from 3.6.1p2 to 3.8p1 on Solaris 8. > > All of my machines are running 3.6.1p2 (Linux boxes have had RH > errata applied). When I ssh with my AFS account name from any of them > to the Solaris 8 box running 3.6.1p2, it responds with > "afsuser at machine's password:". Once the password is given, I am > logged in just fine. > > When I do the same thing with 3.8.1p2, instead of the password prompt > above, I get "AFS password:". I can authenticate fine but I do not > receive a token. > > There is no difference in the pam.conf file for either of these instances. > > Anyone offer any suggestions? Have I missed something obvious? > > I know that AFS support was dropped in 3.7 (which is why all of my > machines are running 3.6) but since OpenSSH is not compiled with AFS > support on the Solaris boxes and relies on PAM, I am assuming this is > not the issue. > > 3.8.p1 was configured with: > > ./configure --prefix=/usr/ssh --without-zlib-version-check --with-pam > --with-prngd-socket=/var/run/opt/prngd-socket > --with-tcp-wrappers=/usr/local --sysconfdir=/etc/ssh > --with-pid-dir=/var/run --with-ipv4-default > --with-default-path=/usr/bin:/bin:/usr/sbin > > The pam.conf file for other looks like this: > > other auth sufficient pam_afs.so.1 try_first_pass set_token > ignore_root setenv_password_expires > other auth requisite pam_authtok_get.so.1 > other auth required pam_dhkeys.so.1 > other auth required pam_unix_auth.so.1 > > TIA. > > -David- > -- > David R. Steiner david.r.steiner at dartmouth.edu > UNIX System Manager Phone: 603.646.3127 > Dartmouth College Fax: 603.646.1041 > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From david.r.steiner at Dartmouth.EDU Thu May 13 06:20:11 2004 From: david.r.steiner at Dartmouth.EDU (David R. Steiner) Date: Wed, 12 May 2004 16:20:11 -0400 Subject: 3.8p1 on Solaris 8 In-Reply-To: References: Message-ID: Ben, Actually, I don't think so. After I sent this, I was talking to a colleague and, after looking at the pam.conf file, he suggested that the old version was acting like it was using the login stanza which had a different format than other. We changed other to match login so it looks like this now: other auth requisite pam_authtok_get.so.1 other auth sufficient pam_dhkeys.so.1 other auth sufficient pam_unix_auth.so.1 other auth sufficient pam_afs.so.1 try_first_pass set_token ignore_root setenv_password_expires This now works. The only difference we are seeing between 3.6 and 3.8 is the password prompts are a little different. "user at machine's password" for the former vs. simply "password:" for the later. So, the problem seems to be solved for me but I am left me with 2 questions: - Was there a change in which stanza of the pam.conf file OpenSSH uses between the two versions? - Was there a change in the way the password prompt is displayed between the two versions? Thanks again. -David- At 14:13 -0500 5/12/04, Ben Lindstrom wrote: >I believe this links in with your issue: > >http://bugzilla.mindrot.org/show_bug.cgi?id=688 > >No intree solution at this moment. > >- Ben > >On Wed, 12 May 2004, David R. Steiner wrote: > >> Hello, >> >> I am running into some strange (to me) behavior trying to upgrade >> from 3.6.1p2 to 3.8p1 on Solaris 8. >> >> All of my machines are running 3.6.1p2 (Linux boxes have had RH >> errata applied). When I ssh with my AFS account name from any of them >> to the Solaris 8 box running 3.6.1p2, it responds with >> "afsuser at machine's password:". Once the password is given, I am >> logged in just fine. >> >> When I do the same thing with 3.8.1p2, instead of the password prompt >> above, I get "AFS password:". I can authenticate fine but I do not >> receive a token. >> >> There is no difference in the pam.conf file for either of these instances. >> >> Anyone offer any suggestions? Have I missed something obvious? >> >> I know that AFS support was dropped in 3.7 (which is why all of my >> machines are running 3.6) but since OpenSSH is not compiled with AFS >> support on the Solaris boxes and relies on PAM, I am assuming this is >> not the issue. >> >> 3.8.p1 was configured with: >> >> ./configure --prefix=/usr/ssh --without-zlib-version-check --with-pam >> --with-prngd-socket=/var/run/opt/prngd-socket >> --with-tcp-wrappers=/usr/local --sysconfdir=/etc/ssh >> --with-pid-dir=/var/run --with-ipv4-default >> --with-default-path=/usr/bin:/bin:/usr/sbin >> >> The pam.conf file for other looks like this: >> >> other auth sufficient pam_afs.so.1 try_first_pass set_token >> ignore_root setenv_password_expires >> other auth requisite pam_authtok_get.so.1 >> other auth required pam_dhkeys.so.1 >> other auth required pam_unix_auth.so.1 >> >> TIA. >> > > -David- -- David R. Steiner david.r.steiner at dartmouth.edu UNIX System Manager Phone: 603.646.3127 Dartmouth College Fax: 603.646.1041 From mouring at etoh.eviladmin.org Thu May 13 06:29:30 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Wed, 12 May 2004 15:29:30 -0500 (CDT) Subject: 3.8p1 on Solaris 8 In-Reply-To: Message-ID: On Wed, 12 May 2004, David R. Steiner wrote: [..] > - Was there a change in the way the password prompt is displayed > between the two versions? > 3.7/3.7.1 rewrote how PAM was handled. We imported a version of the FreeBSD pam modifications. So a lot was changed. - Ben From troya at u.washington.edu Thu May 13 07:07:31 2004 From: troya at u.washington.edu (Troy Amburg) Date: Wed, 12 May 2004 14:07:31 -0700 Subject: Bad configuration option: Banner Message-ID: <61C4F186-A458-11D8-8D3A-0003937757BA@u.washington.edu> I have been unable to use the Banner option in the sshd_config for the verision of openssh I am using: # ssh -V SSH Version OpenSSH_2.1.1, protocol versions 1.5/2.0. Compiled with SSL (0x0090704f). Here is what I get when I have the entry "Banner /etc/issue" in the sshd_config: starting SSHD daemon # /usr/local/etc/sshd_config: line 21: Bad configuration option: Banner /usr/local/etc/sshd_config: terminating, 1 bad configuration options My OS: 5.8 Generic_117000-03 sun4u sparc SUNW,Ultra-Enterprise Did I miss something during the compile? From wendyp at cray.com Thu May 13 07:12:05 2004 From: wendyp at cray.com (Wendy Palm) Date: Wed, 12 May 2004 16:12:05 -0500 Subject: Bad configuration option: Banner In-Reply-To: <61C4F186-A458-11D8-8D3A-0003937757BA@u.washington.edu> References: <61C4F186-A458-11D8-8D3A-0003937757BA@u.washington.edu> Message-ID: <40A29325.9020003@cray.com> Banner wasn't available until 2.5.1. why are you using such an old release? Troy Amburg wrote: > I have been unable to use the Banner option in the sshd_config for the > verision of openssh I am using: > # ssh -V > SSH Version OpenSSH_2.1.1, protocol versions 1.5/2.0. > Compiled with SSL (0x0090704f). > > Here is what I get when I have the entry "Banner /etc/issue" in the > sshd_config: > > starting SSHD daemon > # /usr/local/etc/sshd_config: line 21: Bad configuration option: Banner > /usr/local/etc/sshd_config: terminating, 1 bad configuration options > > My OS: > 5.8 Generic_117000-03 sun4u sparc SUNW,Ultra-Enterprise > > Did I miss something during the compile? > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev -- wendy palm Software Engineer Open Software Development, Cray Inc. wendyp at cray.com, 651-605-9154 From djm at mindrot.org Thu May 13 07:40:22 2004 From: djm at mindrot.org (Damien Miller) Date: Thu, 13 May 2004 07:40:22 +1000 Subject: Oddness with agent forwarding and -i In-Reply-To: <20040512141613.37346.qmail@web60503.mail.yahoo.com> References: <20040512141613.37346.qmail@web60503.mail.yahoo.com> Message-ID: <40A299C6.9040706@mindrot.org> Thomas Baden wrote: > Is this expected behaviour, or should the presence of > -i on the command line take precedence over the agent? You can use the IdentitiesOnly option (on the commandline or in ssh_config) to ignore keys from the agent. -d From djm at mindrot.org Thu May 13 07:41:24 2004 From: djm at mindrot.org (Damien Miller) Date: Thu, 13 May 2004 07:41:24 +1000 Subject: Bad configuration option: Banner In-Reply-To: <61C4F186-A458-11D8-8D3A-0003937757BA@u.washington.edu> References: <61C4F186-A458-11D8-8D3A-0003937757BA@u.washington.edu> Message-ID: <40A29A04.5080100@mindrot.org> Troy Amburg wrote: > I have been unable to use the Banner option in the sshd_config for the > verision of openssh I am using: > # ssh -V > SSH Version OpenSSH_2.1.1, protocol versions 1.5/2.0. > Compiled with SSL (0x0090704f). You *don't* want to be using such an old version. -d From troya at u.washington.edu Thu May 13 07:46:04 2004 From: troya at u.washington.edu (Troy Amburg) Date: Wed, 12 May 2004 14:46:04 -0700 Subject: Bad configuration option: Banner In-Reply-To: <40A29A04.5080100@mindrot.org> Message-ID: Thank you. I didn't realize the version until Wendy pointed it out. Sorry for the false alarm, but thank you for everyones help. On Wednesday, May 12, 2004, at 02:41 PM, Damien Miller wrote: > Troy Amburg wrote: >> I have been unable to use the Banner option in the sshd_config for the >> verision of openssh I am using: >> # ssh -V >> SSH Version OpenSSH_2.1.1, protocol versions 1.5/2.0. >> Compiled with SSL (0x0090704f). > > You *don't* want to be using such an old version. > > -d > > Troy Amburg Sr. Computer Specialist Dept. of Microbiology University of Washington From bob at proulx.com Thu May 13 09:54:31 2004 From: bob at proulx.com (Bob Proulx) Date: Wed, 12 May 2004 17:54:31 -0600 Subject: ssh-keyscan not using ProxyCommand? Message-ID: <20040512235431.GA9235@misery.proulx.com> I have a network without a network connection to other networks. But a socks server is dual homed between it and other networks. I can use socks to ssh to other networks. I use ProxyCommand with the socks aware connect.c program to connect out. All works great. I discovered while trying to use the ssh-keyscan program that it does not use the ProxyCommand configuration. At least in my testing it does not return any information in this case. I also tried the Dante 'socksify nc $hostname 22' and I can get the connection banner. But 'ssh-keyscan -t rsa $hostname' returns nothing. Trying to run it socksified similarly does not work either. I have not looked at the code so I can't say for sure what is happening. This prevents it from being able to connect to remote machines across the socks server and extracting the remote host key. Darn. Not completely terrible but it would be nice if this worked. The return code does not reflect any failures. Shouldn't it? (I know it is designed to run many connections at once and so some of them might fail and bookkeeping can be an issue. I would also be worried about 'sh -e' effects. Perhaps as an option to keep track of this?) Request for two wishlist items. 1. Have ssh-keyscan use the ProxyCommand the same as ssh does. This would enable ssh-keyscan to work exactly the same way that ssh works. 2. If ssh-keyscan is unable to extract a key from a remote host to reflect this in the return code if an option is present. Does this sound reasonable? This is from Debian 'unstable' with glibc-2.3.2.ds1-11 on an x86. ssh -V OpenSSH_3.8p1 Debian 1:3.8p1-3, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004 Thanks Bob From openssh at roumenpetrov.info Thu May 13 16:41:39 2004 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Thu, 13 May 2004 09:41:39 +0300 Subject: Oddness with agent forwarding and -i In-Reply-To: <20040512141613.37346.qmail@web60503.mail.yahoo.com> References: <20040512141613.37346.qmail@web60503.mail.yahoo.com> Message-ID: <40A318A3.2060501@roumenpetrov.info> Did you test OpenSSH 3.8.1x ssh flag IdentitiesOnly ? Please see ssh_config(5) man page for the option IdentitiesOnly. Sample ~/.ssh/config: ======================================= Host host1 IdentitiesOnly yes IdentityFile ~/.ssh/id1 Host host2 IdentitiesOnly yes IdentityFile ~/.ssh/id2 ======================================= Note with config lake above you can skip -i flag. For versions before 3.8.1x I suggest workaround: 1.) for one ssh command in interactive mode as example: $ ssh-agent scp -i ... 2.) for many ssh commands start new shell in interactive mode as follow: $ ssh-agent /bin/sh ... enter commands ... $ CTRL+D 3.) if you use shell script run it as follow: $ ssh-agent myscript.sh Enjoy ;-) Thomas Baden wrote: >Hey everyone, > >I hope this isn't an old issue; I wasn't able to >locate it in the archives. > >I have a number of scripts which make use of ssh -i >and scp -i, where the target host has the specified >key in its authorized_keys file with a command= >override to do immediate processing of the received >data. This works extremely well, as we are able to >establish single-function, triggered-action RSA keys >to toss data from host to host. > >Unfortunately, when invoked with a forwarding agent >present, the agent gets to pass its key(s) before the >key presented on the command line, which causes all >the magic to break. I've tried echoing the debug >output, and it confirms that the agent does indeed get >first crack at authenticating the connection. > >Is this expected behaviour, or should the presence of >-i on the command line take precedence over the agent? > >Cheers, >-Thomas > > From mouring at etoh.eviladmin.org Fri May 14 02:24:45 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 13 May 2004 11:24:45 -0500 (CDT) Subject: ssh-keyscan not using ProxyCommand? In-Reply-To: <20040512235431.GA9235@misery.proulx.com> Message-ID: > Request for two wishlist items. > > 1. Have ssh-keyscan use the ProxyCommand the same as ssh does. This > would enable ssh-keyscan to work exactly the same way that ssh > works. > I'm thinking this would be a major change. Since ssh-keyscan really does not use any of the ssh client code. And I can't see how one would add this to make it work right within the current code base. I suggest putting this in 'Bugzilla.mindrot.org' as an enhancement request incase someone has time to look at this later on. It will make it easier not to forget. - Ben From support at winzip.de. Fri May 14 07:37:54 2004 From: support at winzip.de. (support at winzip.de.) Date: Thu, 13 May 2004 18:37:54 -0300 Subject: Status (openssh-unix-dev@mindrot.org) Message-ID: <20040514012835.6233827C187@shitei.mindrot.org> Mail Delivery Error - This mail contains unicode characters ------------- failed message ------------- k-Ptun27fO&16k7>xfE0jVjQA4k0'ra1Df;YnR8't%? 1.-aQ#!W9oo?|FhaK%?Z&EA'NMDVQj)'k3;sr:Xt_Em &SbrCA#'YW:Sp1o$UFI|g(#JV?09*AC?ejG8JSrHNIms?$ )6!EXEk.m)nYaw(d1&4!VSQdW5eH2MP?+,9> The message has been sent as a binary attachment. From Calusic at richard.eu.org Fri May 14 13:42:55 2004 From: Calusic at richard.eu.org (Calusic at richard.eu.org) Date: Fri, 14 May 2004 03:42:55 +0000 Subject: Openssh-unix-dev, IHow do they f@kk with snakes? In-Reply-To: <505349J4GKC4101B@mindrot.org> References: <505349J4GKC4101B@mindrot.org> Message-ID: <10AKIIBJ9B345JF8@richard.eu.org> Looks like you've come to a real Z00 here! Yeap! We have goats, we have horses, sheep, snakes, even dogs! e have lots of @n1m at ls here and we also have lots of g1r|s who just love to have some s. e -x with these creatures? How do they do it? http://zoo-action.com/av/val/?ZPvtC How do they sa-ck those c0c.k-s? How do they f at kk with snakes? Snakes don't have c0c.k-s!!! Guys! Our g1r|s can do it with every creature they want! They are ready for it! They are tired from men! They do realize that wild @n1m at ls are f at kking like no man would ever f at kk them. Cause they are animals and they f at kk just like everybody did thousands and millions years ago! http://zoo-action.com/av/val/?zDvyV Stunning 1ma-.ges, v1de0s, art series, lots of @n1m at ls, y0.u-n.g horny g1r|s spre at d1ng their legs and s at kking c0c-k.s! This is a first ever -X-.-X-.-X- zoo where every g1r| can f at kk the creature she wants! LOOK AT THIS NOW! aCYAEIAK DmucvHbtY From qwrmr at gcmn.com Sun May 16 15:10:44 2004 From: qwrmr at gcmn.com (Anette Rotstein) Date: Sun, 16 May 2004 00:10:44 -0500 Subject: Strap In For CGHI.OB, On The Move rxlmrd Message-ID: <20040516051551.A3BFC27C18A@shitei.mindrot.org> 671m99)}_m5h}C1IxL5mC263w62a INVESTORS WEEKLY UPDATE - GET CGHI.OB ASAP SPECIAL-ALERT- Centurion Gold Holdings, Inc CGHI (OTC:BB) is located in Johannesburg, South Africa, started three years ago to identify and acquire promising ore-bearing properties. In the past six months, it has acquired four properties: the Primrose Gold Mine; the Omaruru Gold Mine; the Sallies Mine and a chrome bearing operation. The Company is positioning itself to become a major producer in this market by acquiring mineral bearing properties and mineral rights. The world?s largest producer of gold, South Africa?s enormous gold ore reserves represent more than 40% of global reserves. On April 22nd the Company announced that it had submitted its application to move to the AMEX. CGHI (OTC:BB) has progressed nicely and is now poised to break out to all new highs on the strength of news coming out soon on some major acquisitions. Watch it move this next week on this news. Check out the gains from our recent recommendations. MACE at 2.11 (NASDQ) High 14.80....701% Gain! MAGS at 9.74 (NASDQ) High 40.35....414% Gain! GTVCF (OTC:BB) at .52 High 1.02.....100% in five days NOW ??....CGHI (OTC:BB) at 1.75 RECORD SETTING HIGH PREDICTED ON NEWS! Centurion Gold Holdings, Inc: CGHI (OTC:BB) Current-Price:1.58 Short-Term Target:3.75 12-month target 15.00 on AMEX Shares-Outstanding: 47.8 Million / Float 5 million Revenue/Net Income Projections on Current Holdings Year Revenue ($ millions) Net ($ millions) 2004 5,80 2,270 2005 9,35 3,565 2006 9,90 3,785 2007 10,40 4,010 2008 22,40 8,510 Centurion Gold Holding?s fiscal year ends March 31. The Company expects to show revenue and net income for its fourth-quarter, when it reports for the period ending March 31. Reasons to buy CGHI: After acquisitions, CGHI annual revenue will be $45.71 million in 2004, with reserves valued at approximately $1.4 billion at 10% of current metal values. With the full development of all assets, by 2008, revenue will be $200 million at current commodity prices in US dollars. OUR ADVICE: GET CGHI.OB TODAY! +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ riband circumflex bucket clubfoot ensilage blight disfigure sextet erosion From markus at openbsd.org Sun May 16 21:36:51 2004 From: markus at openbsd.org (Markus Friedl) Date: Sun, 16 May 2004 13:36:51 +0200 Subject: Connection caching? In-Reply-To: <4094ED9F.3000008@zip.com.au> References: <4094A631.3050609@kegel.com> <4094BBCA.8090205@mindrot.org> <20040502131525.M26458@greenie.muc.de> <4094ED9F.3000008@zip.com.au> Message-ID: <20040516113651.GE16838@folly> On Sun, May 02, 2004 at 10:46:23PM +1000, Darren Tucker wrote: > Gert Doering wrote: > > >On Sun, May 02, 2004 at 07:13:46PM +1000, Damien Miller wrote: > > > >>One you have established a SSH transport, you can fire off lots of > >>sessions (command, shell or subsystem) which have independant > >>lifespans. > > > >Putty also supports this. Quite impressive, actually. > > lsh does too (lshg/lsh -G). Hmm, someone really ought to hack it into > ssh(1) ... yes, i'm planing to do this since about 2000 :( From markus at openbsd.org Sun May 16 21:40:37 2004 From: markus at openbsd.org (Markus Friedl) Date: Sun, 16 May 2004 13:40:37 +0200 Subject: Connection caching? In-Reply-To: <409706E9.2060700@noaa.gov> References: <409596A8.7000204@mindrot.org> <40967BE6.7050908@noaa.gov> <4096DCA4.5070304@mindrot.org> <4096DE24.5010004@noaa.gov> <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> Message-ID: <20040516114037.GF16838@folly> On Mon, May 03, 2004 at 10:58:49PM -0400, Jefferson Ogata wrote: > It disappoints me that you guys have so little concern about providing > controllable authentication mechanisms. You really just don't get how dumb > it is to have implemented this feature in the server /without/ having > provided a configuration directive to control it, do you? i don't see how 'multiple parallel login sessions over one ssh connection' is related to 'controllable authentication' it's not different from screen(1) From markus at openbsd.org Sun May 16 21:44:52 2004 From: markus at openbsd.org (Markus Friedl) Date: Sun, 16 May 2004 13:44:52 +0200 Subject: Connection caching? In-Reply-To: <409889D4.2070106@noaa.gov> References: <4096E1E6.40706@mindrot.org> <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <40972BCF.3030909@noaa.gov> <8F64D0AB-9E5A-11D8-98D1-0003934F6406@mac.com> <409889D4.2070106@noaa.gov> Message-ID: <20040516114451.GG16838@folly> On Wed, May 05, 2004 at 02:29:40AM -0400, Jefferson Ogata wrote: > John Davidorff Pell wrote: > >Can I ask you (or someone else) to define "session"? I can think of a > >number of reasons that a single shell/pipe can carry many different > >"sessions". > > > >Just trying to follow the discussion, and this part is a little > >confusing. :-) > > > >On 3 May 2004, at 22:36, Jefferson Ogata wrote: > > > >>It is a reasonable expectation for an admin to be able to say: one > >>authentication authorizes one session. > > It is a reasonable expectation for an admin to be able to say: one > successful authentication authorizes only one shell channel. i don't think so. this one shell can start another multiplexer and you can still run multiple shells after one successful authentication (e.g. with screen(1) or window(1) or even job control). From stuge-openssh-unix-dev at cdy.org Sun May 16 23:22:58 2004 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sun, 16 May 2004 15:22:58 +0200 Subject: Connection caching? In-Reply-To: <20040516114451.GG16838@folly> References: <4096E5CA.5040007@noaa.gov> <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <40972BCF.3030909@noaa.gov> <8F64D0AB-9E5A-11D8-98D1-0003934F6406@mac.com> <409889D4.2070106@noaa.gov> <20040516114451.GG16838@folly> Message-ID: <20040516132258.GA30195@foo.birdnet.se> On Sun, May 16, 2004 at 01:44:52PM +0200, Markus Friedl wrote: > > It is a reasonable expectation for an admin to be able to say: one > > successful authentication authorizes only one shell channel. > > i don't think so. > > this one shell can start another multiplexer and you can still > run multiple shells after one successful authentication (e.g. > with screen(1) or window(1) or even job control). Unless it's a restricted/custom shell, in which case the shell can be tailored to not allow multiplexing. How can a custom shell check that it hasn't been invoked previously by the same sshd? I'm thinking getppid() but then there needs to be records of all running shells stored somewhere.. Yes, that would work, but enforcing it in sshd has a few benefits; it's earlier, it works with all shells and it is quite intuitive. There may be more. We all want better control over what is allowed when, to what user, perhaps depending on authentication method. This is an already-known problem in sshd_config, with all of the authentication method settings for example. I never got any feedback on my idea about using PAM for all of this, I'd be happy to hear some comments about why that would be a bad idea. :) Hope you're all having a nice weekend! //Peter From BPENDERGAST at corvis.com.au Mon May 17 15:53:12 2004 From: BPENDERGAST at corvis.com.au (BRADLEY PENDERGAST) Date: Mon, 17 May 2004 15:53:12 +1000 Subject: password aging question Message-ID: <91355936D071D511A24800508BBE3411041AA90C@SYDEXC01> Vesion 3.8.1 of OpenSSH has been compiled on a Solaris 8 host. I am having difficulties in enabling password aging to work from reading /etc/default/passwd and /etc/shadow. # passwd -f < user-id > works satisfactorily however once a password ages through due course from the settings in /etc/default/passwd and /etc/shadow the users are not prompted to change passwords and the user is logged out immediatetly. I have searched this site and the WWW looking for a solution, and have followed some suggestions to setup privledged separation, but still no luck. Does password aging work with OpenSSH? Below are my compile options and configuration file. Many thanks Brad # ./configure --prefix=/opt/ssh \ > --without-pam --disable-suid-ssh --without-rsh \ > --with-lastlog=/var/adm/lastlog \ > --with-pgp --with-nologin-allow=/etc/nolgin.allow \ > --without-none --with-privsep-user=sshd \ > --with-privsep-path=/var/empty \ > --without-prng --without-rand-helper # cat sshd_config # $OpenBSD: sshd_config,v 1.68 2003/12/29 16:39:50 millert Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin:/opt/ssh/bin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value. #Port 22 #Protocol 2,1 #ListenAddress 0.0.0.0 #ListenAddress :: # HostKey for protocol version 1 #HostKey /opt/ssh/etc/ssh_host_key # HostKeys for protocol version 2 #HostKey /opt/ssh/etc/ssh_host_rsa_key #HostKey /opt/ssh/etc/ssh_host_dsa_key # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 1h #ServerKeyBits 768 # Logging #obsoletes QuietMode and FascistLogging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m #PermitRootLogin yes #StrictModes yes #RSAAuthentication yes #PubkeyAuthentication yes #AuthorizedKeysFile .ssh/authorized_keys # For this to work you will also need host keys in /opt/ssh/etc/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes #PermitEmptyPasswords no # Change to no to disable s/key passwords #ChallengeResponseAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes # Set this to 'yes' to enable PAM authentication (via challenge-response) # and session processing. Depending on your PAM configuration, this may # bypass the setting of 'PasswordAuthentication' and 'PermitEmptyPasswords' #UsePAM no #AllowTcpForwarding yes #GatewayPorts no #X11Forwarding no #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #UseLogin no #UsePrivilegeSeparation yes #PermitUserEnvironment no #Compression yes #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS yes #PidFile /var/run/sshd.pid #MaxStartups 10 # no default banner path Banner /etc/issue # override default of no subsystems Subsystem sftp /opt/ssh/libexec/sftp-server Brad Pendergast Systems Administration Business Technology Services Credit Union Services Corporation (Australia) Limited Telephone (02) 8299 9358 Facsimile (02) 8299 9638 E-mail: bpendergast at cuscal.com.au ________________________________________________________ NOTICE The information in this email and or any of the attachments may contain; a. Confidential information of Credit Union Services Corporation (Australia) Limited (CUSCAL) or third parties; and or b. Legally privileged information of CUSCAL or third parties; and or c. Copyright material of CUSCAL or third parties. If you are not an authorised recipient of this email, please contact CUSCAL immediately by return email or by telephone on 61-2-8299 9000 and delete the email from your system. We do not accept any liability in connection with computer virus, data corruption, interruption or any damage generally as a result of transmission of this email. From SRNarayanan at idrbt.ac.in Mon May 17 14:09:58 2004 From: SRNarayanan at idrbt.ac.in (SRNarayanan) Date: Mon, 17 May 2004 09:39:58 +0530 Subject: Rate of compression Message-ID: <161A4BA7815AAF44AA9434FF0B980D5F7705B3@mailidrbt.idrbt.net> Hi there, I would like to know some of the major features for OpenSSH(version 3.2.3 and upwards) to be used on AIX version 5.x. It would be nice if any of you could inform me the bencmark statistics available on the rate of compression that this OpenSSH can do for a 'binary' file transfer and the resulting load on the network. S.Ram From dan at doxpara.com Mon May 17 16:44:46 2004 From: dan at doxpara.com (Dan Kaminsky) Date: Sun, 16 May 2004 23:44:46 -0700 Subject: Rate of compression In-Reply-To: <161A4BA7815AAF44AA9434FF0B980D5F7705B3@mailidrbt.idrbt.net> References: <161A4BA7815AAF44AA9434FF0B980D5F7705B3@mailidrbt.idrbt.net> Message-ID: <40A85F5E.1090209@doxpara.com> SRNarayanan wrote: >Hi there, > >I would like to know some of the major features for OpenSSH(version >3.2.3 and upwards) to be used on AIX version 5.x. It would be nice if >any of you could inform me the bencmark statistics available on the rate >of compression that this OpenSSH can do for a 'binary' file transfer and >the resulting load on the network. > > >S.Ram > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > OpenSSH uses the gzip algorithm at level 5. With a constant per-packet overhead, it will create equivalent network traffic to that gzip mode. --Dan From djm at mindrot.org Mon May 17 16:47:24 2004 From: djm at mindrot.org (Damien Miller) Date: Mon, 17 May 2004 16:47:24 +1000 Subject: Rate of compression In-Reply-To: <161A4BA7815AAF44AA9434FF0B980D5F7705B3@mailidrbt.idrbt.net> References: <161A4BA7815AAF44AA9434FF0B980D5F7705B3@mailidrbt.idrbt.net> Message-ID: <40A85FFC.8070208@mindrot.org> SRNarayanan wrote: > Hi there, > > I would like to know some of the major features for OpenSSH(version > 3.2.3 and upwards) to be used on AIX version 5.x. It would be nice if > any of you could inform me the bencmark statistics available on the rate > of compression that this OpenSSH can do for a 'binary' file transfer and > the resulting load on the network. That depends entirely on the data you are compressing. Transferring a stream of 0 bytes will compress very well. On the other hand MPEG video will compress very poorly, and may even suffer some expansion. You should perform your own tests on your own data, nothing else is really relevant. -d From dtucker at zip.com.au Mon May 17 17:44:58 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 17 May 2004 17:44:58 +1000 Subject: password aging question In-Reply-To: <91355936D071D511A24800508BBE3411041AA90C@SYDEXC01> References: <91355936D071D511A24800508BBE3411041AA90C@SYDEXC01> Message-ID: <40A86D7A.50009@zip.com.au> BRADLEY PENDERGAST wrote: > Vesion 3.8.1 of OpenSSH has been compiled on a Solaris 8 host. I am having > difficulties in enabling password aging to work from reading > /etc/default/passwd and /etc/shadow. Do you mean 3.8p1 or 3.8.1p1? > # passwd -f < user-id > works satisfactorily however once a password ages > through due course from the settings in /etc/default/passwd and /etc/shadow > the users are not prompted to change passwords and the user is logged out > immediatetly. That sounds a bit like exec'ing /usr/bin/passwd is failing in that case, but that's just a guess. [...] > Does password aging work with OpenSSH? It should work in the current version (3.8.1p1), if it doesn't then there's a bug somewhere. I just tried it on my Solaris 8 box with an artificially aged password and it worked as expected. ># ./configure --prefix=/opt/ssh \ [...] >> --with-pgp --with-nologin-allow=/etc/nolgin.allow \ OpenSSH's configure does not have those options. Are you using a vanilla source tree? Could you please run the server in debug mode and connect with an account that has an expired password (eg "/path/to/sshd -ddd -p 2022" then connect with "ssh -p 2022 user at yourserver"). Please post the output here (also, the corresponding entry from /etc/shadow, minus the encrypted password). -- 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 Lutz.Jaenicke at aet.TU-Cottbus.DE Tue May 18 02:28:17 2004 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Mon, 17 May 2004 18:28:17 +0200 Subject: PRNGD 0.9.28 released Message-ID: <20040517162817.GA2277@serv01.aet.tu-cottbus.de> Hi! I have just uploaded version 0.9.28 of prngd. It does fix a hang in an endless loop under certain conditions. I have never seen this myself on HP-UX but I have received some reports, more or less all from Solaris 8 users, one of which finally lead to the correct analysis. Problem: after calling waitpid(), errno is evaluated for the case of waidpid()=0 even though errno is not set in this case. If errno had the value "EINTR" at this point, an endless loop condition arose. It is recommended that users of older versions of prngd upgrade to 0.9.28. Additional changes are related to minor bugfixes (possible core dumps due to NULL pointer access in snprintf()) and platform support. http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_tls/prngd.html Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus From s.ayyagari at xpedite.com Tue May 18 07:22:45 2004 From: s.ayyagari at xpedite.com (Subu Ayyagari) Date: Mon, 17 May 2004 17:22:45 -0400 Subject: FW: pam headers not found : openssh3.8p1 install fails Message-ID: Pl. help!! I am installing Openssh3.8p1 on RH7.2. Configure fails with error: "configure: error: PAM headers not found" Command used to configure: ./configure --prefix=/usr/local/openssh --sysconfdir=/etc/openssh --with-pam --with-ssl-dir=/usr/local/openssl I am not subscribed to this list. So ple. send me email. -subu ----------------------------------------------- root at linux7 openssh-3.8p1]# rpm -qa | grep pam pam-0.75-14 pam_krb5-1.46-1 From jason at devrandom.org Tue May 18 08:16:31 2004 From: jason at devrandom.org (Jason McCormick) Date: Mon, 17 May 2004 18:16:31 -0400 Subject: FW: pam headers not found : openssh3.8p1 install fails In-Reply-To: References: Message-ID: <200405171816.32029.jason@devrandom.org> On Monday 17 May 2004 05:22 pm, Subu Ayyagari wrote: > I am installing Openssh3.8p1 on RH7.2. > Configure fails with error: > "configure: error: PAM headers not found" You need to install the pam-devel package from the RedHat CDs. It's also available online at: ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i386/RedHat/RPMS/pam-devel-0.75-14.i386.rpm -- Jason McCormick jason at devrandom.org GPG Key ID: 96D6CF63 From BPENDERGAST at corvis.com.au Tue May 18 10:06:37 2004 From: BPENDERGAST at corvis.com.au (BRADLEY PENDERGAST) Date: Tue, 18 May 2004 10:06:37 +1000 Subject: password aging question Message-ID: <91355936D071D511A24800508BBE3411091A8BEA@SYDEXC01> Apologies for wasting your time on this. Password aging does work. I forwarded the date on the box ( a crash and burn test box ) and password aging worked properly. I was trying to fudge the /etc/shadow file during initial testing. -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: Monday, 17 May 2004 5:45 PM To: BRADLEY PENDERGAST Cc: 'openssh-unix-dev at mindrot.org' Subject: Re: password aging question BRADLEY PENDERGAST wrote: > Vesion 3.8.1 of OpenSSH has been compiled on a Solaris 8 host. I am having > difficulties in enabling password aging to work from reading > /etc/default/passwd and /etc/shadow. Do you mean 3.8p1 or 3.8.1p1? > # passwd -f < user-id > works satisfactorily however once a password ages > through due course from the settings in /etc/default/passwd and /etc/shadow > the users are not prompted to change passwords and the user is logged out > immediatetly. That sounds a bit like exec'ing /usr/bin/passwd is failing in that case, but that's just a guess. [...] > Does password aging work with OpenSSH? It should work in the current version (3.8.1p1), if it doesn't then there's a bug somewhere. I just tried it on my Solaris 8 box with an artificially aged password and it worked as expected. ># ./configure --prefix=/opt/ssh \ [...] >> --with-pgp --with-nologin-allow=/etc/nolgin.allow \ OpenSSH's configure does not have those options. Are you using a vanilla source tree? Could you please run the server in debug mode and connect with an account that has an expired password (eg "/path/to/sshd -ddd -p 2022" then connect with "ssh -p 2022 user at yourserver"). Please post the output here (also, the corresponding entry from /etc/shadow, minus the encrypted password). -- 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 ________________________________________________________ NOTICE The information in this email and or any of the attachments may contain; a. Confidential information of Credit Union Services Corporation (Australia) Limited (CUSCAL) or third parties; and or b. Legally privileged information of CUSCAL or third parties; and or c. Copyright material of CUSCAL or third parties. If you are not an authorised recipient of this email, please contact CUSCAL immediately by return email or by telephone on 61-2-8299 9000 and delete the email from your system. We do not accept any liability in connection with computer virus, data corruption, interruption or any damage generally as a result of transmission of this email. From kumaresh_ind at gmx.net Wed May 19 04:54:33 2004 From: kumaresh_ind at gmx.net (Kumaresh) Date: Wed, 19 May 2004 00:24:33 +0530 Subject: pam_setcred fails for "USE_POSIX_THREADS + non-root users + PrivSep yes" Message-ID: <003301c43d09$93cef370$230110ac@kurco> Hello, We use USE_POSIX_THREADS in our HP-UX build of OpenSSH. When we connect a non-root user with PAM [pam-kerberos] then I get the following error. debug3: PAM: opening session debug1: PAM: reinitializing credentials PAM: pam_setcred(): Failure setting user credentials This is particularly for non-root users with PrivSep YES. When I connect to a root user with PrivSep YES or to a non-root user with PrivSep NO, then no issues. This is tested on 3.7.1p2 and 3.8.1p1 and two versions behave alike. This is not the case when USE_POSIX_THREADS is disabled and it works for PrivSep yes and no for root and non-root users. Just to check the pid that call the pam_setcred in do_pam_setcred, I used the getpid() call in the do_pam_setcred function and for both THREAD enabled and disabled builds, the child pid and the pid that call this function are the same and inspite of this similarity this problem is seen. Any help will be much appreciated. Regards, Kumar. From letsgonhlcanes at yahoo.com Wed May 19 05:51:58 2004 From: letsgonhlcanes at yahoo.com (Lets Go Canes) Date: Tue, 18 May 2004 12:51:58 -0700 (PDT) Subject: Problem with X tunneling, su, and xauth Message-ID: <20040518195158.72842.qmail@web50402.mail.yahoo.com> Hi all. I'm trying to use ssh to connect from a PC (using TerraTerm with the ssh add-in) to a Solaris 8 or Solaris 9 box (both running OpenSSH 3.7.1p2) to establish a session for X-forwarding. Everything works great, until I use "su" to change to another account (such as root). The su'd user doesn't seem to be able to authenticate properly to use the X-tunnel. I did a Google search, and found reference to 3 techniques for solving the problem: 1) set the XAUTHORITY environment variable to point to the .Xauthority file from the first account, 2) set the HOME environment variable to point to the home directory of the first account, or 3) extract the cookie using xauth from the first account and merge it into the second account. Neither 1 nor 2 seem to work, and when I try to extract the key using method 3 (xauth list $DISPLAY), it comes up empty. Am I overlooking something obvious? Thanks for any help/ideas. ===== -------------- Lets Go Canes! __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ From cody-ssh at raspen.org Wed May 19 06:43:50 2004 From: cody-ssh at raspen.org (Cody A Raspen) Date: Tue, 18 May 2004 16:43:50 -0400 (EDT) Subject: use of -D at EscapeChar command line Message-ID: Greetings, Here's a small patch to allow adding dynamic port forwards during a session using the ~C command line. Local and remote port forwards are already supported in a similar manner, but we thought this would be useful as well -- hope it finds its way to the official distribution. Best, Cody Raspen John Mishanski -------------- next part -------------- diff -aur openssh-3.8.1p1-orig/clientloop.c openssh-3.8.1p1/clientloop.c --- openssh-3.8.1p1-orig/clientloop.c 2003-12-17 00:33:11.000000000 -0500 +++ openssh-3.8.1p1/clientloop.c 2004-05-18 16:12:57.000000000 -0400 @@ -508,6 +508,7 @@ u_short fwd_port, fwd_host_port; char buf[1024], sfwd_port[6], sfwd_host_port[6]; int local = 0; + int socks = 0; leave_raw_mode(); handler = signal(SIGINT, SIG_IGN); @@ -518,12 +519,18 @@ s++; if (*s == 0) goto out; - if (strlen(s) < 2 || s[0] != '-' || !(s[1] == 'L' || s[1] == 'R')) { + if (strlen(s) < 2 || s[0] != '-' || !(s[1] == 'L' || s[1] == 'R' || s[1] == 'D')) { logit("Invalid command."); goto out; } if (s[1] == 'L') local = 1; + + if (s[1] == 'D') { + socks = 1; + local = 1; + } + if (!local && !compat20) { logit("Not supported for SSH protocol version 1."); goto out; @@ -532,27 +539,47 @@ while (*s && isspace(*s)) s++; - if (sscanf(s, "%5[0-9]:%255[^:]:%5[0-9]", - sfwd_port, buf, sfwd_host_port) != 3 && - sscanf(s, "%5[0-9]/%255[^/]/%5[0-9]", - sfwd_port, buf, sfwd_host_port) != 3) { - logit("Bad forwarding specification."); - goto out; - } - if ((fwd_port = a2port(sfwd_port)) == 0 || - (fwd_host_port = a2port(sfwd_host_port)) == 0) { - logit("Bad forwarding port(s)."); - goto out; - } - if (local) { - if (channel_setup_local_fwd_listener(fwd_port, buf, - fwd_host_port, options.gateway_ports) < 0) { + if (socks){ + if ( (sscanf(s, "%5[0-9]", sfwd_port)) != 1) { + logit("Bad forwarding port."); + goto out; + } + + fwd_port = a2port(sfwd_port); + if (channel_setup_local_fwd_listener(fwd_port, "socks", + 0, options.gateway_ports) < 0) { logit("Port forwarding failed."); goto out; } - } else - channel_request_remote_forwarding(fwd_port, buf, - fwd_host_port); + + } else { + if (sscanf(s, "%5[0-9]:%255[^:]:%5[0-9]", + sfwd_port, buf, sfwd_host_port) != 3 && + sscanf(s, "%5[0-9]/%255[^/]/%5[0-9]", + sfwd_port, buf, sfwd_host_port) != 3) { + + logit("Bad forwarding specification."); + goto out; + } + + if ((fwd_port = a2port(sfwd_port)) == 0 || + (fwd_host_port = a2port(sfwd_host_port)) == 0) { + logit("Bad forwarding port(s)."); + goto out; + } + + if (local) { + if (channel_setup_local_fwd_listener(fwd_port, buf, + fwd_host_port, options.gateway_ports) < 0) { + logit("Port forwarding failed."); + goto out; + } + } else + channel_request_remote_forwarding(fwd_port, buf, + fwd_host_port); + + } + logit("Forwarding port."); out: signal(SIGINT, handler); From jmknoble at pobox.com Wed May 19 06:51:36 2004 From: jmknoble at pobox.com (Jim Knoble) Date: Tue, 18 May 2004 16:51:36 -0400 Subject: Problem with X tunneling, su, and xauth In-Reply-To: <20040518195158.72842.qmail@web50402.mail.yahoo.com> References: <20040518195158.72842.qmail@web50402.mail.yahoo.com> Message-ID: <20040518205136.GQ22753@crawfish.ais.com> Circa 2004-05-18 12:51:58 -0700 dixit Lets Go Canes: : The su'd user doesn't seem to be able to authenticate properly to use : the X-tunnel. [...] : Am I overlooking something obvious? (4) Use sudo instead of su. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) ..................................................................... :"The methods now being used to merchandise the political candidate : : as though he were a deodorant positively guarantee the electorate : : against ever hearing the truth about anything." --Aldous Huxley : :...................................................................: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 256 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040518/bf9e9d44/attachment.bin From scott.burch at camberwind.com Wed May 19 07:17:40 2004 From: scott.burch at camberwind.com (Scott Omar Burch) Date: Tue, 18 May 2004 16:17:40 -0500 Subject: Problem with X tunneling, su, and xauth In-Reply-To: <20040518205136.GQ22753@crawfish.ais.com> References: <20040518195158.72842.qmail@web50402.mail.yahoo.com> <20040518205136.GQ22753@crawfish.ais.com> Message-ID: <40AA7D74.1030602@camberwind.com> Jim, The su'd to user does not have authority to your X display. You should use sudo, but to get to work your way: 1) From the user account that is doing the su'ing find out what it's display is set to and grab the output of xauth list (You want the ouput that matches the current display). 2) Su to the user and set your diplay to that of the original user. 3) xauth add [the output you grabbed from 1) ] If you use sudo then you don't need to do any of this. Jim Knoble wrote: > Circa 2004-05-18 12:51:58 -0700 dixit Lets Go Canes: > > : The su'd user doesn't seem to be able to authenticate properly to use > : the X-tunnel. > > [...] > > : Am I overlooking something obvious? > > (4) Use sudo instead of su. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From listz at hate.cx Wed May 19 07:47:37 2004 From: listz at hate.cx (listz at hate.cx) Date: Tue, 18 May 2004 15:47:37 -0600 Subject: pam_tally question Message-ID: <20040518214737.GB11701@chaos.enmity.org> hi, i just noticed that my pam_tally config has stopped working. it used to work in 3.6.1p2, but since then hasn't. i configured openssh like so: ./configure --with-tcp-wrappers --with-pam --with-privsep-user=sshd --with-md5-passwords --with-ipaddr-display and i do have "UsePAM yes" set in sshd_config. i've tried and failed to get it to work with 3.7.1p2 and 3.8.1p1. i've tried compiling them both --with-pam and --without-pam and tried both "UsePAM yes" and "UsePAM no" all to no avail. /var/log/faillog exists and it is owned by root and set to 600. these are redhat 7.3 and 9 systems. it displays the same behavior on both. any thoughts? ::[ RFC 2795 ]:: "Democracy means simply the bludgeoning of the people by the people for the people." -Oscar Wilde From dtucker at zip.com.au Wed May 19 11:03:19 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 19 May 2004 11:03:19 +1000 Subject: pam_tally question In-Reply-To: <20040518214737.GB11701@chaos.enmity.org> References: <20040518214737.GB11701@chaos.enmity.org> Message-ID: <40AAB257.3000306@zip.com.au> listz at hate.cx wrote: > and i do have "UsePAM yes" set in sshd_config. i've tried and failed to get it > to work with 3.7.1p2 and 3.8.1p1. i've tried compiling them both --with-pam and > --without-pam and tried both "UsePAM yes" and "UsePAM no" all to no avail. > /var/log/faillog exists and it is owned by root and set to 600. these are redhat > 7.3 and 9 systems. it displays the same behavior on both. any thoughts? Do you have "ChallengeResponseAuthentication yes" and "PasswordAuthentication no" in sshd_config? If not it's possible that you're not actually using PAM to authenticate (which might explain your problem). -- 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 listz at hate.cx Thu May 20 00:34:08 2004 From: listz at hate.cx (listz at hate.cx) Date: Wed, 19 May 2004 08:34:08 -0600 Subject: pam_tally question In-Reply-To: <40AAB257.3000306@zip.com.au> References: <20040518214737.GB11701@chaos.enmity.org> <40AAB257.3000306@zip.com.au> Message-ID: <20040519143408.GA13509@chaos.enmity.org> actually i figured tht out yesterday by looking through all of the bugs as suggested in #4 of the "Reporting Bugs" section of openssh.com. The entry that actually helped me was ticket #843. sshd_config confused me because all it said about ChallengeResponseAuthentication was to set it to "no" to disable s/key, and i thought "well, i don't use s/key!" so it was set to "no". once i read that i realized what i had done wrong and all systems now obey pam_tally...mostly. something else odd that popped up during my testing: i have pam_tally set to deny on 3 unsuccessful attempts. this is certainly the case for password authentication, however i have to get to 4 to stop logins with ssh keys. i'll unsuccessfully attempt to authenticate 3 times with a password, pam_tally indicates 3 unsuccessful login attempts, but i'm still able to successfully login with an ssh key. it only prevents ssh key logins as well once i get to 4 unsuccessful login attempts. is this known behavior? on Wed May 19 11:03, Darren Tucker disclosed: > listz at hate.cx wrote: > >and i do have "UsePAM yes" set in sshd_config. i've tried and failed to > >get it > >to work with 3.7.1p2 and 3.8.1p1. i've tried compiling them both > >--with-pam and > >--without-pam and tried both "UsePAM yes" and "UsePAM no" all to no avail. > >/var/log/faillog exists and it is owned by root and set to 600. these are > >redhat > >7.3 and 9 systems. it displays the same behavior on both. any thoughts? > > Do you have "ChallengeResponseAuthentication yes" and > "PasswordAuthentication no" in sshd_config? If not it's possible that > you're not actually using PAM to authenticate (which might explain your > problem). > > -- > 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. ::[ RFC 2795 ]:: "Democracy means simply the bludgeoning of the people by the people for the people." -Oscar Wilde statik at hate.cx | "It's like a koala crapped a rainbow in my brain!" PGP fingerprint: D656 01EB 79FC 9285 F110 2AB1 D8BC B3BA BEA2 E0C5 From jmknoble at pobox.com Thu May 20 01:32:05 2004 From: jmknoble at pobox.com (Jim Knoble) Date: Wed, 19 May 2004 11:32:05 -0400 Subject: Problem with X tunneling, su, and xauth In-Reply-To: <40AA7D74.1030602@camberwind.com> References: <20040518195158.72842.qmail@web50402.mail.yahoo.com> <20040518205136.GQ22753@crawfish.ais.com> <40AA7D74.1030602@camberwind.com> Message-ID: <20040519153205.GA4065@crawfish.ais.com> Circa 2004-05-18 16:17:40 -0500 dixit Scott Omar Burch: : Jim, : : The su'd to user does not have authority to your X display. You should : use sudo, but to get to work your way: [...] Thanks; i'm well aware of all that, however (which is why i suggested the use of sudo). The gentle subscriber who actually posted the question appears to go by "Let's Go Canes" and mentions your 'xauth list' technique as his/her method #3. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) ..................................................................... :"The methods now being used to merchandise the political candidate : : as though he were a deodorant positively guarantee the electorate : : against ever hearing the truth about anything." --Aldous Huxley : :...................................................................: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 256 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040519/5647785b/attachment.bin From dtucker at zip.com.au Thu May 20 11:09:15 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 20 May 2004 11:09:15 +1000 Subject: pam_tally question In-Reply-To: <20040519143408.GA13509@chaos.enmity.org> References: <20040518214737.GB11701@chaos.enmity.org> <40AAB257.3000306@zip.com.au> <20040519143408.GA13509@chaos.enmity.org> Message-ID: <40AC053B.7000308@zip.com.au> listz at hate.cx wrote: > actually i figured tht out yesterday by looking through all of the bugs as > suggested in #4 of the "Reporting Bugs" section of openssh.com. The entry that > actually helped me was ticket #843. Excellent! Someone who reads those things! I had feared that such people were in the same category as the Easter Bunny :-) (OK, that's probably not fair. I would like to think that lots of people find them useful and that we never hear from them because it solves their problems.) > sshd_config confused me because all it said > about ChallengeResponseAuthentication was to set it to "no" to disable s/key, > and i thought "well, i don't use s/key!" so it was set to "no". once i read that > i realized what i had done wrong and all systems now obey pam_tally...mostly. The UsePAM comments have recently been made (hopefully) clearer in the example config and the sshd_config man page: # Set this to 'yes' to enable PAM authentication (via # challenge-response) and session processing. Depending on your PAM # configuration, this may bypass the setting of 'PasswordAuthentication' # and 'PermitEmptyPasswords' UsePAM Enables the Pluggable Authentication Module interface. If set to ``yes'' this will enable PAM authentication using ChallengeResponseAuthentication and PAM account and session module processing for all authentication types. Because PAM challenge-response authentication usually serves an equivalent role to password authentication, you should disable either PasswordAuthentication or ChallengeResponseAuthentication. If UsePAM is enabled, you will not be able to run sshd(8) as a non-root user. The default is ``no''. Hmm, maybe the PAM stuff warrants an FAQ entry too? > something else odd that popped up during my testing: i have pam_tally set to > deny on 3 unsuccessful attempts. this is certainly the case for password > authentication, however i have to get to 4 to stop logins with ssh keys. i'll > unsuccessfully attempt to authenticate 3 times with a password, pam_tally > indicates 3 unsuccessful login attempts, but i'm still able to successfully > login with an ssh key. it only prevents ssh key logins as well once i get to 4 > unsuccessful login attempts. is this known behavior? I would guess that's an off-by-one error in pam_tally's account module. You will probably find that there's something like this in the auth module: if (failed) if (++fails > 3) /* return error */ while in the account module: if (fails > 3) /* return error */ In such a case, the account module will only return failures after the *fourth* failure if the authentication does not happen via its auth module. -- 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 Berg at mindrot.org Fri May 21 06:50:03 2004 From: Berg at mindrot.org (Berg at mindrot.org) Date: Fri, 21 May 2004 06:50:03 +1000 (EST) Subject: business forecasting service Message-ID: <20040520205003.0512727C187@shitei.mindrot.org> Accurate forecasting of economics, business sales, markets, weather, any time into the future. www.justgoodtiming.com Regards, Larry Berg. From lindysandiego at yahoo.com Fri May 21 08:38:12 2004 From: lindysandiego at yahoo.com (Thomas Baden) Date: Thu, 20 May 2004 15:38:12 -0700 (PDT) Subject: Oddness with agent forwarding and -i In-Reply-To: <40A256A8.9060106@noaa.gov> Message-ID: <20040520223812.82612.qmail@web60505.mail.yahoo.com> --- Jefferson Ogata wrote: > I can't comment on whether this is really intended > behavior, but you can easily > work around it by unsetting SSH_AUTH_SOCK before you > run ssh: > > SSH_AUTH_SOCK= ssh -i foo... Thanks a bunch; that seems to have done the trick. I'm still curious to know whether the agent should be taking precedence over the -i command-line option, though. Cheers, -Thomas __________________________________ Do you Yahoo!? Yahoo! Domains ? Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer From djm at mindrot.org Fri May 21 13:46:58 2004 From: djm at mindrot.org (Damien Miller) Date: Fri, 21 May 2004 13:46:58 +1000 Subject: Van Dyke's Public Key Assistant In-Reply-To: <008601c43840$b4f27ef0$4ba5a8c0@rgordeylaptop> References: <008601c43840$b4f27ef0$4ba5a8c0@rgordeylaptop> Message-ID: <40AD7BB2.8050400@mindrot.org> Randy Gordey wrote: > Jeff Van Dyke's "Public Key Assistant subsystem" was previously discussed > here: (end of a short thread) > > http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=103436908422003&w=2 > > I do see a few comments that seem to point out his arrogance and some > disgust about OpenBSD's RCSID, but has anybody found it to be unsecure or if > it was bug ridden. The subject sorta dies right there. If you follow the > links on www.vandyke.com, they still seem to be maintaining the patch... Speaking personally, I haven't had time too look at it. > Even if it was never going to be part of the RFC and might be only mildly > popular is there a technical reason the OpenSSH project's source should not > include his patch? Does it hamstring security? Every patch has security implications, things that manipulate authorisation databases (such as authorized_keys) require additional scrutiny. -d From dan at doxpara.com Fri May 21 17:08:15 2004 From: dan at doxpara.com (Dan Kaminsky) Date: Fri, 21 May 2004 00:08:15 -0700 Subject: Van Dyke's Public Key Assistant In-Reply-To: <40AD7BB2.8050400@mindrot.org> References: <008601c43840$b4f27ef0$4ba5a8c0@rgordeylaptop> <40AD7BB2.8050400@mindrot.org> Message-ID: <40ADAADF.4090809@doxpara.com> I'd been thinking for some time we need something better than my present fuglier-than-thou solution, something along the lines of: cat ~/.ssh/id_dsa.pub | ssh user at host "cat >> ~/.ssh/authorized_keys2" There are just so many things that can go wrong -- replacing > for >>, some sites need it to be authorized_keys, etc. If there's a mildly standardized subsystem, I can't imagine what'd be bad about adding support for it to OpenSSH. We could even somewhat safely support an escape command to automatically add "this identity" to the local authorized key, inside a separate channel (ssh2 only). We can do this now with the above hack, but...not as elegantly as any of us might like. --Dan Damien Miller wrote: >Randy Gordey wrote: > > > >>Jeff Van Dyke's "Public Key Assistant subsystem" was previously discussed >>here: (end of a short thread) >> >>http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=103436908422003&w=2 >> >>I do see a few comments that seem to point out his arrogance and some >>disgust about OpenBSD's RCSID, but has anybody found it to be unsecure or if >>it was bug ridden. The subject sorta dies right there. If you follow the >>links on www.vandyke.com, they still seem to be maintaining the patch... >> >> > >Speaking personally, I haven't had time too look at it. > > > >>Even if it was never going to be part of the RFC and might be only mildly >>popular is there a technical reason the OpenSSH project's source should not >>include his patch? Does it hamstring security? >> >> > >Every patch has security implications, things that manipulate >authorisation databases (such as authorized_keys) require additional >scrutiny. > >-d > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > From djm at mindrot.org Fri May 21 17:18:55 2004 From: djm at mindrot.org (Damien Miller) Date: Fri, 21 May 2004 17:18:55 +1000 Subject: Van Dyke's Public Key Assistant In-Reply-To: <40ADAADF.4090809@doxpara.com> References: <008601c43840$b4f27ef0$4ba5a8c0@rgordeylaptop> <40AD7BB2.8050400@mindrot.org> <40ADAADF.4090809@doxpara.com> Message-ID: <40ADAD5F.3020108@mindrot.org> Dan Kaminsky wrote: > I'd been thinking for some time we need something better than my present > fuglier-than-thou solution, something along the lines of: > > cat ~/.ssh/id_dsa.pub | ssh user at host "cat >> ~/.ssh/authorized_keys2" > > There are just so many things that can go wrong -- replacing > for >>, > some sites need it to be authorized_keys, etc. If there's a mildly > standardized subsystem, I can't imagine what'd be bad about adding > support for it to OpenSSH. We could even somewhat safely support an > escape command to automatically add "this identity" to the local > authorized key, inside a separate channel (ssh2 only). We can do this > now with the above hack, but...not as elegantly as any of us might like. We have contrib/ssh-copy-id{,.1} that proports to do this automagically. I won't attest to the quality of it, because I don't use it. -d From markus at openbsd.org Fri May 21 17:00:05 2004 From: markus at openbsd.org (Markus Friedl) Date: Fri, 21 May 2004 09:00:05 +0200 Subject: Oddness with agent forwarding and -i In-Reply-To: <20040520223812.82612.qmail@web60505.mail.yahoo.com> References: <40A256A8.9060106@noaa.gov> <20040520223812.82612.qmail@web60505.mail.yahoo.com> Message-ID: <20040521070005.GB125@folly> On Thu, May 20, 2004 at 03:38:12PM -0700, Thomas Baden wrote: > --- Jefferson Ogata wrote: > > I can't comment on whether this is really intended > > behavior, but you can easily > > work around it by unsetting SSH_AUTH_SOCK before you > > run ssh: > > > > SSH_AUTH_SOCK= ssh -i foo... > > Thanks a bunch; that seems to have done the trick. > I'm still curious to know whether the agent should be > taking precedence over the -i command-line option, > though. because -i might require passphrases. From frank.goma at atosorigin.com Sat May 22 00:30:41 2004 From: frank.goma at atosorigin.com (GOMA, Frank) Date: Fri, 21 May 2004 15:30:41 +0100 Subject: Openssh installation only works for user root Message-ID: <2407A2B36F84D54683FE604C752B433602C777C8@notes4.sema.co.uk> Darren, Thanks for your response and apologies for the late reply. BROKEN_SETREUID and BROKEN_SETREGID are defined. Please see below the output from the debug. ( I have removed the real ip and replaced it with X.X.X.X for security reasons. ) YYYY: root@/>sshd -ddd -p 22 debug2: read_server_config: filename /usr/local/etc/sshd_config debug1: sshd version OpenSSH_3.8p1 debug1: private host key: #0 type 0 RSA1 debug3: Not a RSA1 key file /usr/local/etc/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug3: Not a RSA1 key file /usr/local/etc/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from X.X.X.X port 4669 debug1: Client protocol version 1.5; client software version PuTTY-Release-0.52 debug1: no match: PuTTY-Release-0.52 debug1: Local version string SSH-1.99-OpenSSH_3.8p1 debug3: privsep user:group 141:106 debug1: permanently_set_uid: 141/106 debug1: Sent 768 bit server key and 1024 bit host key. debug2: Network child is on pid 10766 debug3: preauth child monitor started debug3: entering debug1: Encryption type: blowfish debug3: entering: type 28 debug3: : checking request 28 debug3: entering: type 29 debug3: entering debug3: entering: type 29 debug2: : 28 used once, disabling now debug3: entering debug3: entering debug3: entering: type 30 debug3: : checking request 30 debug3: entering debug2: : 30 used once, disabling now debug3: entering debug1: Received session key; encryption turned on. debug1: Installing crc compensation attack detector. debug3: entering debug3: entering: type 6 debug3: : waiting for MONITOR_ANS_PWNAM debug3: entering: type 7 debug3: entering debug3: : checking request 6 debug3: debug3: : today 12559 sp_expire -1 days left -12560 debug3: account expiration disabled debug3: : sending MONITOR_ANS_PWNAM: 1 debug3: entering: type 7 debug2: : 6 used once, disabling now debug3: entering debug1: Attempting authentication for FGoma. debug3: entering debug3: entering: type 10 debug3: : waiting for MONITOR_ANS_AUTHPASSWORD debug3: : checking request 10 debug3: entering: type 11 debug3: : sending result 0 debug3: entering: type 11 debug3: entering debug3: : user not authenticated Failed none for FGoma from X.X.X.X port 4669 debug3: entering debug3: entering debug3: entering: type 10 debug3: : waiting for MONITOR_ANS_AUTHPASSWORD debug3: : checking request 10 debug3: entering: type 11 debug3: entering debug3: : today 12559 sp_lstchg 12559 sp_max 168 debug3: : sending result 1 debug3: entering: type 11 debug3: : user authenticated Accepted password for FGoma from X.X.X.X port 4669 debug1: : FGoma has been authenticated by privileged process Accepted password for FGoma from X.X.X.X port 4669 debug3: : Waiting for new keys debug3: entering: type 24 debug3: entering debug3: : Sending ssh1 KEY+IV debug3: : Sending compression state debug3: entering: type 24 debug3: : Finished sending state debug3: : Getting compression state debug3: : Getting Network I/O buffers debug3: : Share sync debug3: : Share sync end debug2: User child is on pid 10774 debug3: entering debug1: permanently_set_uid: 143/103 debug1: session_new: init debug1: session_new: session 0 debug1: Installing crc compensation attack detector. debug1: Allocating pty. debug3: entering: type 25 debug3: : checking request 25 debug3: entering debug1: session_new: init debug1: session_new: session 0 debug3: : waiting for MONITOR_ANS_PTY debug3: entering: type 26 debug3: entering debug3: entering: type 26 : recvmsg: expected received 1 got 0 debug1: do_cleanup : sendmsg(11): Invalid argument debug1: do_cleanup debug1: session_pty_cleanup: session 0 release /dev/pts/5 -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: 10 May 2004 00:52 To: GOMA, Frank Cc: 'openssh-unix-dev at mindrot.org' Subject: Re: Openssh installation only works for user root GOMA, Frank wrote: > I have recently compiled a copy of OpenSSH for use on Reliant Unix ( Sinix ) > version 5.45. My installation works okay for user root. When I try to log on > as another user I get prompted for the user password. When I type this in > OpenSSH throws me out each time. I have been able to see any errors. > > My version is OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar > 2004. I am using Putty Release 0.52. That sounds a bit like the broken uid/gid swapping, but a fix for that on Reliant Unix should be in 3.8p1. Check config.h after running configure, BROKEN_SETREUID and BROKEN_SETREGID should be defined. If they're not, add #define's for them and recompile and retest. If that doesn't help, you will need to run the server in debug mode to figure out what's going on. Log in as root then run ssh on another port (eg "/path/to/sshd -ddd -p 222"), connect as a normal user ("ssh -p 222 yourserver") then post the debug log here. -- 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. ___________________________________________________________________________ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. ___________________________________________________________________________ From dtucker at zip.com.au Sat May 22 00:55:45 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 22 May 2004 00:55:45 +1000 Subject: Openssh installation only works for user root In-Reply-To: <2407A2B36F84D54683FE604C752B433602C777C8@notes4.sema.co.uk> References: <2407A2B36F84D54683FE604C752B433602C777C8@notes4.sema.co.uk> Message-ID: <40AE1871.8030805@zip.com.au> GOMA, Frank wrote: > : recvmsg: expected received 1 got 0 > debug1: do_cleanup > : sendmsg(11): Invalid argument > debug1: do_cleanup > debug1: session_pty_cleanup: session 0 release /dev/pts/5 It appears that descriptor passing is broken somehow, which messes up privilege separation. You can set "UsePrivilegeSeparation no" in sshd_config to disable it. You can also try adding "#define DISABLE_FD_PASSING 1" to config.h and recompile (this will disable the post-auth privsep, but pre-auth should still work). Is Reliant Unix 5.45 old or new? Does privsep work on other releases? -- 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 markus at openbsd.org Sat May 22 01:15:52 2004 From: markus at openbsd.org (Markus Friedl) Date: Fri, 21 May 2004 17:15:52 +0200 Subject: Connection caching? In-Reply-To: <20040516132258.GA30195@foo.birdnet.se> References: <4096EB10.8000700@mindrot.org> <4096F6B8.7070202@noaa.gov> <4096FB50.4060909@mindrot.org> <409706E9.2060700@noaa.gov> <40971DE4.1000607@zip.com.au> <40972BCF.3030909@noaa.gov> <8F64D0AB-9E5A-11D8-98D1-0003934F6406@mac.com> <409889D4.2070106@noaa.gov> <20040516114451.GG16838@folly> <20040516132258.GA30195@foo.birdnet.se> Message-ID: <20040521151551.GB6990@folly> On Sun, May 16, 2004 at 03:22:58PM +0200, Peter Stuge wrote: > On Sun, May 16, 2004 at 01:44:52PM +0200, Markus Friedl wrote: > > > It is a reasonable expectation for an admin to be able to say: one > > > successful authentication authorizes only one shell channel. > > > > i don't think so. > > > > this one shell can start another multiplexer and you can still > > run multiple shells after one successful authentication (e.g. > > with screen(1) or window(1) or even job control). > > Unless it's a restricted/custom shell, in which case the shell can > be tailored to not allow multiplexing. we could add an option for the # of parallel sessions that are allowed over a single ssh session. currently there's a random limit of 10 sessions. From Jefferson.Ogata at noaa.gov Sat May 22 02:26:22 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Fri, 21 May 2004 12:26:22 -0400 Subject: Oddness with agent forwarding and -i In-Reply-To: <20040521070005.GB125@folly> References: <40A256A8.9060106@noaa.gov> <20040520223812.82612.qmail@web60505.mail.yahoo.com> <20040521070005.GB125@folly> Message-ID: <40AE2DAE.4050502@noaa.gov> Markus Friedl wrote: > On Thu, May 20, 2004 at 03:38:12PM -0700, Thomas Baden wrote: >>--- Jefferson Ogata wrote: >>>I can't comment on whether this is really intended >>>behavior, but you can easily >>>work around it by unsetting SSH_AUTH_SOCK before you >>>run ssh: >>> >>>SSH_AUTH_SOCK= ssh -i foo... >> >>Thanks a bunch; that seems to have done the trick. >>I'm still curious to know whether the agent should be >>taking precedence over the -i command-line option, >>though. > > because -i might require passphrases. If a key in agent is more accessible than the key named with -i, the user would presumably simply refrain from passing -i. The current behavior is weird because if you have a key with a specific command= setting and a generic shell key, agent may authenticate with the generic key even though you set -i. There is an option to ignore agent keys, or you can just unset SSH_AUTH_SOCK as I noted earlier, but I think it's counter-intuitive that a key explicitly specified with -i isn't at least tried ahead of anything in agent. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From llyyz14487n_barletta at e-shares.biz Sat May 22 10:12:57 2004 From: llyyz14487n_barletta at e-shares.biz (e-Shares) Date: Sat, 22 May 2004 00:12:57 +0000 Subject: Client-defined term of investment. 3% every day. And many more benefits.. Message-ID: <20040514068.8221.qmail@e-shares.biz> Hello, 2-3% daily, including weekend & holidays. Client defined term of investment: from 1 day to unlimited. eShares is your window to the world of financial freedom! http://www.e-shares.biz Regards, From haruka at sky-dream.com Sat May 22 21:46:11 2004 From: haruka at sky-dream.com (=?ISO-2022-JP?B?GyRCNV5KZxsoQiEh?=) Date: Sat, 22 May 2004 20:46:11 +0900 Subject: =?iso-2022-jp?b?GyRCIVQkNDZhPWo9UEQlJVslOSVISmc9OCFVGyhC?= Message-ID: <20040522115246.8026527C187@shitei.mindrot.org> ???????????? ????8000??17000? ?????? 8000??3???20? ?48??!! ????18????????? ?????????????????????????????????????? ?????????????????? ?????????????????????????????? ?????????????????? ?????? http://www.56114.jp/hosuto From copyletterjp at yahoo.co.jp Mon May 24 00:46:27 2004 From: copyletterjp at yahoo.co.jp (=?ISO-2022-JP?B?GyRCJU0lQyVIJVMlOCVNJTkbKEIg?=) Date: Sun, 23 May 2004 23:46:27 +0900 Subject: =?iso-2022-jp?b?GyRCTCQ+NUJ6OS05cCIoQUc/TSRHJGI0SkMxJEs9UE1oGyhC?= =?iso-2022-jp?b?GyRCJF4kOSEqGyhC?= Message-ID: <20040523.1446270359@copyletterjp-yahoo.co.jp> ??????????????? ???????????? ??????????????????????? ?? 0774-52-5633 ?????????????? ???????????????????????????? ????????gomennasai79 at yahoo.co.jp ? ????????????????? ??????????? ?????????????????15????????? ?????9800??? ??????????????? ??????????????????????? ??http://netbusinessok.mydns.jp/ From dan at doxpara.com Mon May 24 05:02:50 2004 From: dan at doxpara.com (Dan Kaminsky) Date: Sun, 23 May 2004 12:02:50 -0700 Subject: stdio to port forward? Message-ID: <40B0F55A.1050702@doxpara.com> All-- I'm attempting to implement something I've wanted for a while...a stdio link to a TCP port forward, at least for SSH2, but preferably for either protocol. There's certainly no technical reason this can't be done, but the vagaries of terminal / file descriptor handling are posing something of a challenge. Does anyone have any suggestions for "correct" approaches for this? I absolutely don't want to simply fork off a version of SSH in the background and connect() to its port forward -- that's quite hijackable, and simply inelegant. Attempts to alter SSH2's initial channel type to direct-tcpip seem to be failing too, even if I packet_put_cstring/int the appropriate values. Not asking for anyone to code this up for me (though -Whost:port is the planned syntax), just could use a conceptual guide. Again, SSH1 support would be some definite gravy. End goal is to finally fix the trojaned ssh client problem, by allowing end to end crypto semantics through bastion hosts. Shutting down the ssh usage hole that's led to major compromises for Apache and Sourceforge would be very, very nice. --Dan From dtucker at zip.com.au Mon May 24 09:22:10 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 24 May 2004 09:22:10 +1000 Subject: stdio to port forward? In-Reply-To: <40B0F55A.1050702@doxpara.com> References: <40B0F55A.1050702@doxpara.com> Message-ID: <40B13222.8070009@zip.com.au> Dan Kaminsky wrote: > I'm attempting to implement something I've wanted for a while...a > stdio link to a TCP port forward, at least for SSH2, but preferably for > either protocol. There's certainly no technical reason this can't be > done, but the vagaries of terminal / file descriptor handling are posing > something of a challenge. > > Does anyone have any suggestions for "correct" approaches for this? Well, the "fast" option is to use connect/netcat: ssh -o 'Proxycommand ssh bastion connect yourhost 22" yourhost The disadvantage is you need connect or netcat on the bastion host. (I also had problems with netcat not exitting but apparently recent versions don't do that). -- 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 Jefferson.Ogata at noaa.gov Mon May 24 18:31:17 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Mon, 24 May 2004 04:31:17 -0400 Subject: stdio to port forward? In-Reply-To: <40B13222.8070009@zip.com.au> References: <40B0F55A.1050702@doxpara.com> <40B13222.8070009@zip.com.au> Message-ID: <40B1B2D5.8010805@noaa.gov> Darren Tucker wrote: > Dan Kaminsky wrote: >> I'm attempting to implement something I've wanted for a while...a >> stdio link to a TCP port forward, at least for SSH2, but preferably >> for either protocol. There's certainly no technical reason this can't >> be done, but the vagaries of terminal / file descriptor handling are >> posing something of a challenge. >> >> Does anyone have any suggestions for "correct" approaches for this? > > Well, the "fast" option is to use connect/netcat: > > ssh -o 'Proxycommand ssh bastion connect yourhost 22" yourhost > > The disadvantage is you need connect or netcat on the bastion host. (I > also had problems with netcat not exitting but apparently recent > versions don't do that). It also fails, on its own, to allow port forwarding without giving the user a shell, which I understood to be one of the basic goals. The fast option is to use SSL with client certificates. stunnel is handy for this. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From djm at mindrot.org Mon May 24 19:05:46 2004 From: djm at mindrot.org (Damien Miller) Date: Mon, 24 May 2004 19:05:46 +1000 Subject: stdio to port forward? In-Reply-To: <40B1B2D5.8010805@noaa.gov> References: <40B0F55A.1050702@doxpara.com> <40B13222.8070009@zip.com.au> <40B1B2D5.8010805@noaa.gov> Message-ID: <40B1BAEA.8050009@mindrot.org> Jefferson Ogata wrote: > Darren Tucker wrote: > >>Well, the "fast" option is to use connect/netcat: >> >>ssh -o 'Proxycommand ssh bastion connect yourhost 22" yourhost >> >>The disadvantage is you need connect or netcat on the bastion host. (I >>also had problems with netcat not exitting but apparently recent >>versions don't do that). > > It also fails, on its own, to allow port forwarding without giving the user a > shell, which I understood to be one of the basic goals. One could use a authorized_keys file with command="nc host 22". If you don't trust the bastion, then you should definitely be using pubkey authentication anyway: it binds to the session id and thus the server's host key, making MITM nearly impossible (assuming the client already knows about the server's host key) -d From dtucker at zip.com.au Mon May 24 19:25:22 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 24 May 2004 19:25:22 +1000 Subject: stdio to port forward? In-Reply-To: <40B1B2D5.8010805@noaa.gov> References: <40B0F55A.1050702@doxpara.com> <40B13222.8070009@zip.com.au> <40B1B2D5.8010805@noaa.gov> Message-ID: <40B1BF82.6060603@zip.com.au> Jefferson Ogata wrote: >> ssh -o 'Proxycommand ssh bastion connect yourhost 22" yourhost > > It also fails, on its own, to allow port forwarding without giving the > user a shell, which I understood to be one of the basic goals. I didn't get the impression that it was one of the basic goals (and I just re-read the original post and still don't). The thing that was specifically mentioned was a trojaned ssh client on the bastion host, which it will protect against since at worst (or best, depending on your point of view :-) trojaning netcat would let you do a MITM attack. (How the bastion host got trojaned in the first place is a separate issue.) I never said it was ideal, just fast (to set up, that is). That said, I think the the proposal would be useful since uses existing capabilities of sshd and removes the need for another binary, running process and, as you noted, a valid shell on the bastion host (although you can mitigate that with a forced command, as djm noted). > The fast option is to use SSL with client certificates. stunnel is > handy for this. You can do that, but it requires extra software on both client and bastion host, and it's non-trivial to set up. (BTW, if anyone wants to actually do this, see http://groups.google.com/groups?selm=c28pnq%24dj4%241%40gate.dodgy.net.au for one way.) -- 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 dan at doxpara.com Mon May 24 19:32:51 2004 From: dan at doxpara.com (Dan Kaminsky) Date: Mon, 24 May 2004 02:32:51 -0700 Subject: stdio to port forward? In-Reply-To: <40B1BAEA.8050009@mindrot.org> References: <40B0F55A.1050702@doxpara.com> <40B13222.8070009@zip.com.au> <40B1B2D5.8010805@noaa.gov> <40B1BAEA.8050009@mindrot.org> Message-ID: <40B1C143.8070408@doxpara.com> A user cannot configure their public keys with a server w/o access to some sort of shell. Another reason to support a pubkey subsystem -- we also get to avoid homegrown PHP flying around the file system with root permissions updating authorized_keys files and getting away with it because "ssl makes it se-kure" :-) Also, an obvious disadvantage of the system below is that the client can't direct its final destination. That makes it a no-go for most bastion uses (what are you going to use -- a separate account for each destination? A separate port?). --Dan Damien Miller wrote: >Jefferson Ogata wrote: > > >>Darren Tucker wrote: >> >> >> >>>Well, the "fast" option is to use connect/netcat: >>> >>>ssh -o 'Proxycommand ssh bastion connect yourhost 22" yourhost >>> >>>The disadvantage is you need connect or netcat on the bastion host. (I >>>also had problems with netcat not exitting but apparently recent >>>versions don't do that). >>> >>> >>It also fails, on its own, to allow port forwarding without giving the user a >>shell, which I understood to be one of the basic goals. >> >> > >One could use a authorized_keys file with command="nc host 22". > >If you don't trust the bastion, then you should definitely be using >pubkey authentication anyway: it binds to the session id and thus the >server's host key, making MITM nearly impossible (assuming the client >already knows about the server's host key) > >-d > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > From djm at mindrot.org Mon May 24 19:41:40 2004 From: djm at mindrot.org (Damien Miller) Date: Mon, 24 May 2004 19:41:40 +1000 Subject: stdio to port forward? In-Reply-To: <40B1C143.8070408@doxpara.com> References: <40B0F55A.1050702@doxpara.com> <40B13222.8070009@zip.com.au> <40B1B2D5.8010805@noaa.gov> <40B1BAEA.8050009@mindrot.org> <40B1C143.8070408@doxpara.com> Message-ID: <40B1C354.70203@mindrot.org> Dan Kaminsky wrote: > A user cannot configure their public keys with a server w/o access to > some sort of shell. Another reason to support a pubkey subsystem -- we > also get to avoid homegrown PHP flying around the file system with root > permissions updating authorized_keys files and getting away with it > because "ssl makes it se-kure" :-) An alternative would be to just make the user's shell a script that does "nc host 22", but then you lose some ability to control destinations. > Also, an obvious disadvantage of the system below is that the client > can't direct its final destination. That makes it a no-go for most > bastion uses (what are you going to use -- a separate account for each > destination? A separate port?). In the past I have used either a separate key or a separate account. All of the SSH bastion/proxies that I have configured have only allowed access to relatively small number of hosts, I'm sure that others will have other needs. -d From dtucker at zip.com.au Mon May 24 19:54:08 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 24 May 2004 19:54:08 +1000 Subject: stdio to port forward? In-Reply-To: <40B1C354.70203@mindrot.org> References: <40B0F55A.1050702@doxpara.com> <40B13222.8070009@zip.com.au> <40B1B2D5.8010805@noaa.gov> <40B1BAEA.8050009@mindrot.org> <40B1C143.8070408@doxpara.com> <40B1C354.70203@mindrot.org> Message-ID: <40B1C640.5020409@zip.com.au> Damien Miller wrote: > Dan Kaminsky wrote: >>Also, an obvious disadvantage of the system below is that the client >>can't direct its final destination. That makes it a no-go for most >>bastion uses (what are you going to use -- a separate account for each >>destination? A separate port?). > > In the past I have used either a separate key or a separate account. You could also extract the hostname from SSH_ORIGINAL_COMMAND, compare it to a lost of allowed hosts and connect if it's permitted. -- 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 jimc at math.ucla.edu Mon May 24 09:19:50 2004 From: jimc at math.ucla.edu (Jim Carter) Date: Sun, 23 May 2004 16:19:50 -0700 (PDT) Subject: OpenSSH v3.8p1 fails to interoperate for GSSAPI (Kerberos) and X-Windows Message-ID: Versions: openssh-3.8p1-33, heimdal-0.6.1rc3-51, XFree86-4.3.99.902-40, tk-8.4.6-37, all from SuSE 9.1 (unhacked); back-version peers have openssh-3.5p1, XFree86-4.3.0-115, etc. from SuSE 8.2. Symptoms: 1. When the client and server versions are unequal, the Kerberos ticket is not accepted for authentication. All the clients have PreferredAuthentications gssapi-with-mic, gssapi, others. 2. When ForwardX11 is true (ssh -X switch), ForwardX11Trusted is at its default value (false), the client is 3.8p1, and the server is 3.5p1, most X Window System clients work OK, but the following fail with the indicated obscure error messages: xmag BadDrawable (infinite loop of this error) xwd BadWindow xcalc (intermittent; sorry, didn't write down the code) tcl/tk apps BadAtom doing X_GetProperty for 0x1a0 = InterpRegistry. To demonstrate, it's sufficient to do "wish" with no script. Opera, Konqueror, Mozilla and Netscape were not tested but they all have a feature similar to tcl/tk and most likely would fail similarly. This is a property on the root window through which one instance passes messages to another, e.g. so a mail reader's helper app can signal a browser to open a URL in a new window. Sometimes but not always, the failure of one of the above apps triggers a behavior mode where, from then on, the connection from any X app whatsoever is refused with the message "Invalid MIT-MAGIC-COOKIE-1 key". With the ssh -Y switch (ForwardX11Trusted true) on a v3.8p1 client and v3.5p1 server, all the above apps work properly. When the client is v3.5p1 and with any server version, all the apps work properly. In a trinary chain 3.5 -> 3.8 -> 3.5, all the apps work properly. When both the client and the server are 3.8p1, and tcl/tk is the latest version, it works but xmag and xwd fail as above. Analysis: Sometime between 2003-09-12 and the present, a draft RFC: http://www.vandyke.com/technology/draft-ietf-secsh-gsskeyex.txt was issued defining gssapi-with-mic, which resists certain "man in the middle" attacks. v3.8p1 does only gssapi-with-mic; versions up to v3.7 do only old-style gssapi. There appears to be no ./configure switch to turn on gssapi-without-mic at compile time in v3.8. The resulting lack of interoperability fully explains the symptoms seen. There is no workaround. Web postings suggest that apparently there has been an upgrade to X-Windows security that involves a configurable security policy that includes at least two classes of clients, trusted and untrusted, and something involving access cookies that have a limited lifetime. From these hints I can understand the X errors: each failing app tries to read an object (window, property, etc.) that it did not create, which fails if it is generically untrusted. As a workaround, the Debian developer Colin Wilson has specified ForwardX11Trusted = true as the default in their distro's ssh_config. Discussion: To get to the conclusions above I spent all of Saturday from morning to 22:00, compiling back versions of OpenSSH and, eventually, reverting files of v3.8p1 to v3.7p1, one at a time, until I hit a relevant effect. Once I spotted the change to ForwardX11Trusted in readconf.c, I had the keyword for a search on Google, which revealed what was happening. I am not a happy camper at this moment. Here at UCLA-Mathnet we had to revert a patch to Solaris, that hackers are actively exploiting, because of a lack of backward compatibility: it breaks several important apps and we couldn't get them upgraded workingly. For this reason we are going through a lot of disruption and spending a lot of money to junk a collection of Sun servers and convert to Linux (SuSE), where our apps do run and which we can keep patched. Now that we don't have to support some older Solaris boxes we're also deploying Kerberos (Heimdal). We intend to provide the excellent service that our users expect. In particular, we are part of a worldwide community and we need to interoperate with peers whose upgrade policies we can't dictate. We're going to have to make a decision: by installing or reverting v3.8 we will accept or send out Kerberos tickets over ssh only with peers who do run v3.8, or only from those who don't. Given our situation it's clear that we have to make the second choice: revert from v3.8p1 to some earlier version, probably v3.7p1. That decision makes the X-Windows issue moot, but eventually we would need to get ForwardX11Trusted turned on when needed: likely turn it on in ssh_config. For the Future: In OpenSSH v3.9 I hope to see both gssapi-with-mic and old-style gssapi supported by both the client and the server. I understand the need to encourage sysops to upgrade to gssapi-with-mic, but a suicide strategy (upgrading is mandatory and we won't talk to you if you don't) is suicidal for you, not for us. A truly paranoid sysop, in an environment where "man in the middle" attacks are expected, will put only gssapi-with-mic in PreferredAuthentications and/or do a similar maneuver on his server using a future separate option. But imposing that policy atomically on everyone is not going to happen. Not even within one administrative domain, because machines have to be upgraded one at a time, and if one had the bad judgment to upgrade to v3.8, the post-upgrade and pre-upgrade machines would be cut off from one another, for Kerberos and X11 trust. Helpful for the user would be an "ask" option for GSSAPIAuthentication, or even for every style of authentication, triggering a message along these lines: The server refuses gssapi-with-mic (or whatever your most preferred method is) but accepts gssapi (or other lesser method). Is this a known obsolescence of the server, or is a man in the middle trying to steal your credential? In his posting the Debian developer points out that users are going to learn to make X-Windows work by setting ForwardX11Trusted true in their personal .ssh/config files, or putting -Y in their ssh shell aliases, where the sysop cannot discover and revert them when the current confusion on X security is straightened out. Unfortunately, ForwardX11Trusted implies ForwardX11, so if I set ForwardX11Trusted true, every ssh will forward X, which is a waste and a possible security exposure. I request that these options be made independent, including a -y switch on ssh to turn off trust. In ssh_config I would set FowardX11 false and ForwardX11Trusted true, so plain ssh does not forward, but if X were forwarded with the -X switch, it would be trusted, unless the user overrode for particular hosts with -y or in his private .ssh/config file. Later, when I had some idea how or whether my apps were going to work through X11 security, I would change the global ForwardX11Trusted to false, after notifying the users. My users and I look forward to getting the best security possible on any particular connection, even if some connections are superior to others. James F. Carter Voice 310 825 2897 FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: jimc at math.ucla.edu http://www.math.ucla.edu/~jimc (q.v. for PGP key) From dtucker at zip.com.au Tue May 25 09:45:58 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 25 May 2004 09:45:58 +1000 Subject: OpenSSH v3.8p1 fails to interoperate for GSSAPI (Kerberos) and X-Windows In-Reply-To: References: Message-ID: <40B28936.6020200@zip.com.au> Before I start, 3.8.1p1 is out and fixes a number of bugs with 3.8p1, so you should consider using it instead. Jim Carter wrote: > Sometime between 2003-09-12 and the present, a draft RFC: > http://www.vandyke.com/technology/draft-ietf-secsh-gsskeyex.txt > was issued defining gssapi-with-mic, which resists certain "man in the > middle" attacks. v3.8p1 does only gssapi-with-mic; versions up to v3.7 > do only old-style gssapi. There appears to be no ./configure switch to > turn on gssapi-without-mic at compile time in v3.8. The resulting lack > of interoperability fully explains the symptoms seen. There is no > workaround. Simon Wilkinson published a patch to enable backwards compatibility with "gssapi" authentication. http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=107826289602763 > To get to the conclusions above I spent all of Saturday from morning to > 22:00, compiling back versions of OpenSSH Were the release notes unclear? Both of these were documented in the "Changes since OpenSSH 3.7.1" section": * ssh(1) now uses untrusted cookies for X11-Forwarding. Some X11 applications might need full access to the X11 server, see ForwardX11Trusted in ssh(1) and xauth(1) for more information. * The experimental "gssapi" support has been replaced with the "gssapi-with-mic" to fix possible MITM attacks. The two versions are not compatible. The full text of the release notes is: http://www.openssh.com/txt/release-3.8 > In OpenSSH v3.9 I hope to see both gssapi-with-mic and old-style gssapi > supported by both the client and the server. Limited interop (with what is an obsolete internet-draft with known security problems) is provided by Simon's patch. > In his posting the Debian developer points out that users are going to > learn to make X-Windows work by setting ForwardX11Trusted true in their > personal .ssh/config files, or putting -Y in their ssh shell aliases, > where the sysop cannot discover and revert them when the current > confusion on X security is straightened out. Unfortunately, > ForwardX11Trusted implies ForwardX11, so if I set ForwardX11Trusted > true, every ssh will forward X, which is a waste and a possible security > exposure. That's only the "-Y" command-line option (which is a substitute for "-X"), ForwardX11Trusted does not imply ForwardX11 (at least in the current version, I didn't check older ones). -- 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 Tue May 25 10:11:48 2004 From: djm at mindrot.org (Damien Miller) Date: Tue, 25 May 2004 10:11:48 +1000 Subject: OpenSSH v3.8p1 fails to interoperate for GSSAPI (Kerberos) and X-Windows In-Reply-To: References: Message-ID: <40B28F44.4060704@mindrot.org> Jim Carter wrote: > Versions: openssh-3.8p1-33, heimdal-0.6.1rc3-51, XFree86-4.3.99.902-40, > tk-8.4.6-37, all from SuSE 9.1 (unhacked); back-version peers have > openssh-3.5p1, XFree86-4.3.0-115, etc. from SuSE 8.2. > > Symptoms: > > 1. When the client and server versions are unequal, the Kerberos ticket > is not accepted for authentication. All the clients have > PreferredAuthentications gssapi-with-mic, gssapi, others. openssh-3.5 never included GSSAPI autentication. You must be using a distribution or 3rd party patch. > 2. When ForwardX11 is true (ssh -X switch), ForwardX11Trusted is at its > default value (false), the client is 3.8p1, and the server is 3.5p1, > most X Window System clients work OK, but the following fail with the > indicated obscure error messages: > > xmag BadDrawable (infinite loop of this error) > xwd BadWindow > xcalc (intermittent; sorry, didn't write down the code) > tcl/tk apps BadAtom doing X_GetProperty for 0x1a0 = InterpRegistry. > To demonstrate, it's sufficient to do "wish" with no > script. http://www.openssh.com/faq.html#3.13 > Sometime between 2003-09-12 and the present, a draft RFC: > http://www.vandyke.com/technology/draft-ietf-secsh-gsskeyex.txt > was issued defining gssapi-with-mic, which resists certain "man in the > middle" attacks. v3.8p1 does only gssapi-with-mic; versions up to v3.7 > do only old-style gssapi. There appears to be no ./configure switch to > turn on gssapi-without-mic at compile time in v3.8. The resulting lack > of interoperability fully explains the symptoms seen. There is no > workaround. We won't include support for a deprecated exchange with known security problems. The only release (3.7) that included support for the "gssapi" (i.e. without MIC) included the following text in the release notes: > - This release contains some GSSAPI user authentication support > to replace legacy KerberosV authentication support. At present > this code is still considered experimental and SHOULD NOT BE > USED. I'm told that Simon Wilkinson has patches to add the old gssapi (no MIC) exchange back for people who need it, but I can't see it on his site: http://www.sxw.org.uk/computing/patches/openssh.html The GSSAPI issue wouldn't have caused you as much pain if your Linux vendor hadn't added support for an unfinished protocol. Most other Linux vendors did the right thing and made the patch available as a compile time options, or as a clearly labelled separate package. If this same vendor is not providing you with the necessary support to retain compatibility with their previous versions, then you probably go and yell at them :) -d From roland.mainz at nrubsig.org Tue May 25 10:19:01 2004 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Tue, 25 May 2004 02:19:01 +0200 Subject: OpenSSH v3.8p1 fails to interoperate for GSSAPI (Kerberos) andX-Windows References: Message-ID: <40B290F5.D21CEFB5@nrubsig.org> Jim Carter wrote: [snip] > 2. When ForwardX11 is true (ssh -X switch), ForwardX11Trusted is at its > default value (false), the client is 3.8p1, and the server is 3.5p1, > most X Window System clients work OK, but the following fail with the > indicated obscure error messages: > > xmag BadDrawable (infinite loop of this error) > xwd BadWindow > xcalc (intermittent; sorry, didn't write down the code) Could you file BUG REPORTS at http://freedesktop.org/bugzilla/enter_bug.cgi?product=xorg , one bug report per application, please ? If you hurry up it's likely that the next release (X11R6.7.1 ?!) may include the fixes... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From dtucker at zip.com.au Tue May 25 11:07:33 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 25 May 2004 11:07:33 +1000 Subject: OpenSSH v3.8p1 fails to interoperate for GSSAPI (Kerberos) and X-Windows In-Reply-To: <40B28F44.4060704@mindrot.org> References: <40B28F44.4060704@mindrot.org> Message-ID: <40B29C55.9020608@zip.com.au> Damien Miller wrote: > I'm told that Simon Wilkinson has patches to add the old gssapi > (no MIC) exchange back for people who need it, but I can't see it on > his site: http://www.sxw.org.uk/computing/patches/openssh.html If anyone else is looking for this it's: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=107826289602763 It took me a while to dig it out of the archives (and I knew it was there and had some recollection of what it looked like) so I'm not surprised some people don't know about it. Simon, perhaps you could add it to your page? -- 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 Jordi.Sanfeliu at fibranet.com Tue May 25 17:34:56 2004 From: Jordi.Sanfeliu at fibranet.com (Jordi Sanfeliu) Date: Tue, 25 May 2004 09:34:56 +0200 Subject: X-Forwarding freezes keyboard on ThinClient Vortex86 Message-ID: <40B2F720.2060004@fibranet.com> Hello all, Please send a Cc: to me in addition to the list. I am not subscribed and this will make it easier for me to follow the thread and reply. Thanks. My scenary is as follows: I have a Linux server with OpenSSH 3.7.1p2 installed and this server acting as an LTSP. Some PCs (all Pentium+ classes) acting as X-Terminals connects to this server via PXE boot --> DHCP --> booting LTSP-kernel (2.4.24) --> executing XFree86 4.3.99 --> and finally executing "ssh -X user at linuxserver some_program" (same version OpenSSH as server) in order to execute the OpenOffice binary and nothing more. Thanks to the X-Forwarding feature, all the OpenOffice executes in a very capable Linux server for all PCs acting as a X-Terminals and the things works fine in an environment very stable and secure. Now the BIG problem ------------------- Recently I'm testing a new Thin Client solution (http://www.vortex86.com) to subsitute these PCs for something more "thin" and little. This Thin Client have a Vortex86 processor at 200Mhz and 128MB of RAM, and is a good solution in order to think to convert all the PCs into this very little Thin Client. To test this new Thin Client almost nothing was changed in the LTSP configuration, just the MAC address and the video configuration and resolution. The problem arises when unexpectedly the X-Forwarding feature hang the keyboard after 3 or 4 key-clicks. The mouse continues working (well at least it moves), but the keyboard does not respond, keyboard-leds are dead and the display freezed. If I remove the line "ssh -X user at linuxserver ....." and (manually) executes from the Linux server the OpenOffice program with the DISPLAY variable containing the Thin Client IP address (that is not using X-Forwarding nor OpenSSH at all), it works fine!!!. Moreover, if I executes from the Thin Client "X -query" in order to begin an XDM session (or KDM session), it works fine!!! That's mean that the problem is on X-Forwarding. But what is the cause for this strange behavior? Thanks in advance. -- Jordi Sanfeliu FIBRANET Network Services Provider http://www.fibranet.com From bob at proulx.com Wed May 26 01:22:54 2004 From: bob at proulx.com (Bob Proulx) Date: Tue, 25 May 2004 09:22:54 -0600 Subject: stdio to port forward? In-Reply-To: <40B13222.8070009@zip.com.au> References: <40B0F55A.1050702@doxpara.com> <40B13222.8070009@zip.com.au> Message-ID: <20040525152254.GA12600@misery.proulx.com> Darren Tucker wrote: > Well, the "fast" option is to use connect/netcat: > > ssh -o 'Proxycommand ssh bastion connect yourhost 22" yourhost > > The disadvantage is you need connect or netcat on the bastion host. (I > also had problems with netcat not exitting but apparently recent > versions don't do that). Of course the ProxyCommand solution with connect/netcat is cleaner. But if I understand correctly and it was not available then you can still use daisy chaining for access. ssh -t bastion ssh yourhost ssh -t bastion1 ssh -t bastion2 ssh yourhost This works for rsync as well. rsync -e 'ssh bastion ssh' /some/path yourhost:/some/path rsync -e 'ssh bastion1 ssh bastion2 ssh' /some/path yourhost:/some/path Bob From dan at doxpara.com Wed May 26 01:45:23 2004 From: dan at doxpara.com (Dan Kaminsky) Date: Tue, 25 May 2004 08:45:23 -0700 Subject: stdio to port forward? In-Reply-To: <20040525152254.GA12600@misery.proulx.com> References: <40B0F55A.1050702@doxpara.com> <40B13222.8070009@zip.com.au> <20040525152254.GA12600@misery.proulx.com> Message-ID: <40B36A13.7060305@doxpara.com> >Of course the ProxyCommand solution with connect/netcat is cleaner. >But if I understand correctly and it was not available then you can >still use daisy chaining for access. > > ssh -t bastion ssh yourhost > ssh -t bastion1 ssh -t bastion2 ssh yourhost > >This works for rsync as well. > > rsync -e 'ssh bastion ssh' /some/path yourhost:/some/path > rsync -e 'ssh bastion1 ssh bastion2 ssh' /some/path yourhost:/some/path > > Oh, it works like a charm. Only problem is the utter horrors that are unleashed when the hosts in the middle get trojaned, as has happened to both Apache and Sourceforge. --Dan From dopheide at ncsa.uiuc.edu Wed May 26 07:49:09 2004 From: dopheide at ncsa.uiuc.edu (Mike Dopheide) Date: Tue, 25 May 2004 16:49:09 -0500 (CDT) Subject: Requiring multiple auth mechanisms In-Reply-To: <40741297.2090804@noaa.gov> Message-ID: We've ported this patch to OpenSSH 3.8.1p1 (attached). Our initial testing indicates that it doesn't work with privilege separation and only works with PAM (keyboard-interactive) if PAM is the first successful authentication mechanism. Both of these issues are things we'd like to resolve, but I'm not familiar enough with the code to know if there are any show-stoppers. (Any thoughts from the crowd?) To help clarify the PAM issue, when requiring multiple auth mechanisms, PAM will automatically fail if any other mechanism before it succeeds. However, if you force keyboard-interactive to happen first or if everything before it fails, PAM then appears to work fine and other auth mechanisms will continue to work after it. -Mike > I looked around for a while, but couldn't find any code for requiring multiple > authentication mechanisms in openssh. So I wrote an implemention. > > I thought at first I should change the PasswordAuthentication, > PubkeyAuthentication, etc. keywords to allow no/yes/required. But there's some > funky stuff in auth2.c with respect to keyboard interactive auth that would make > this kind of gnarly, semantics-wise. > > I also thought about providing a new keyword to specify a list of required > authentication mechanisms. But then you have to make sure those mechanisms are > also enabled, and it's easy to write conflicting configurations. In addition, if > a list of required auth mechs is given, then enabling mechanisms that are not > required is pointless, because they won't be sufficient. > > So my final decision, for the sake of simplicity, was to add a > "NumRequiredAuthMethods" keyword, which defaults to 1. If you set it to 2, the > client must pass at least two of the enabled auth methods. I'm using the term > "methods" here because I'm only counting general auth methods as defined in > auth2.c's "authmethods" array, namely publickey, password, keyboard-interactive, > and hostbased. So there may be multiple types of keyboard-interactive auth, but > keyboard-interactive only counts as a single method. > > So, for example, if you have PasswordAuthentication and PubkeyAuthentication > enabled, and set NumRequiredAuthMethods to 2, you will have to pass both types. > But PAMAuthenticationViaKbdInt and ChallengeResponseAuthentication are the same > authentication method (keyboard-interactive), so if you want to require 2 > classes, you'll have to have at least one of the other methods enabled as well. > > I don't know much about some of the supported authentication types, particularly > pam, so I'm not totally sure my approach makes sense for everyone's needs. My > particular need was to require both public key and S/KEY factors so that > one-time passwords can be combined with a strong electronic authenticator. I > don't trust my users not to end up trojaned with a keylogger, so I need OTP, but > I also want a public key in case someone loses his S/KEY cheat sheet. > > The attached patch is designed for Red Hat's openssh-3.1p1-14 SRPM (add as > Patch14, use -p1 on patch line in %prep). It should work against openssh-3.8 > with slight tweaks (authmethods changed in auth2.c). If people need a patch > against 3.8, I can build it; just ask. > > I would really appreciate it if anyone with interest could vet this for stupid > mistakes. > > -- -------------- next part -------------- diff -ur openssh-3.8.1p1/auth2.c openssh-3.8.1p1.multiauth/auth2.c --- openssh-3.8.1p1/auth2.c 2004-03-08 06:04:07.000000000 -0600 +++ openssh-3.8.1p1.multiauth/auth2.c 2004-05-25 11:02:34.000000000 -0500 @@ -75,7 +75,7 @@ /* helper */ static Authmethod *authmethod_lookup(const char *); -static char *authmethods_get(void); +static char *authmethods_get(int); int user_key_allowed(struct passwd *, Key *); /* @@ -205,6 +205,7 @@ userauth_finish(Authctxt *authctxt, int authenticated, char *method) { char *methods; + int success = 0; if (!authctxt->valid && authenticated) fatal("INTERNAL ERROR: authenticated invalid user %s", @@ -233,41 +234,62 @@ if (authctxt->postponed) return; - /* XXX todo: check if multiple auth methods are needed */ + /* Check if enough multiple auth methods have passed */ if (authenticated == 1) { - /* turn off userauth */ - dispatch_set(SSH2_MSG_USERAUTH_REQUEST, &dispatch_protocol_ignore); - packet_start(SSH2_MSG_USERAUTH_SUCCESS); - packet_send(); - packet_write_wait(); - /* now we can break out */ - authctxt->success = 1; + int passed; + int k; + int j; + + for (j = 0, k = 1, passed = 0; authmethods[j] != NULL; j++, k <<= 1) { + if (strncmp (method, authmethods[j]->name, strlen (authmethods[j]->name)) == 0) + authctxt->passed |= k; + if (authctxt->passed & k) + ++passed; + } + if (passed < options.num_required_auth_methods) { + success = 1; + authenticated = 0; + } } else { - if (authctxt->failures++ > AUTH_FAIL_MAX) - packet_disconnect(AUTH_FAIL_MSG, authctxt->user); - methods = authmethods_get(); - packet_start(SSH2_MSG_USERAUTH_FAILURE); - packet_put_cstring(methods); - packet_put_char(0); /* XXX partial success, unused */ - packet_send(); - packet_write_wait(); - xfree(methods); + if (authctxt->failures++ > AUTH_FAIL_MAX) + packet_disconnect(AUTH_FAIL_MSG, authctxt->user); + } + + if (authenticated == 1) { + /* turn off userauth */ + dispatch_set(SSH2_MSG_USERAUTH_REQUEST, &dispatch_protocol_ignore); + packet_start(SSH2_MSG_USERAUTH_SUCCESS); + packet_send(); + packet_write_wait(); + /* now we can break out */ + authctxt->success = 1; + } else { + methods = authmethods_get(authctxt->passed); + packet_start(SSH2_MSG_USERAUTH_FAILURE); + packet_put_cstring(methods); + packet_put_char(success); + packet_send(); + packet_write_wait(); + xfree(methods); } } #define DELIM "," static char * -authmethods_get(void) +authmethods_get(int passed) { Buffer b; char *list; + int k; int i; buffer_init(&b); - for (i = 0; authmethods[i] != NULL; i++) { + for (i = 0, k = 1; authmethods[i] != NULL; i++, k <<= 1) { if (strcmp(authmethods[i]->name, "none") == 0) continue; + if (passed & k) + continue; if (authmethods[i]->enabled != NULL && *(authmethods[i]->enabled) != 0) { if (buffer_len(&b) > 0) diff -ur openssh-3.8.1p1/auth.h openssh-3.8.1p1.multiauth/auth.h --- openssh-3.8.1p1/auth.h 2004-04-16 07:47:55.000000000 -0500 +++ openssh-3.8.1p1.multiauth/auth.h 2004-05-25 12:14:54.000000000 -0500 @@ -52,6 +52,7 @@ int valid; /* user exists and is allowed to login */ int attempt; int failures; + int passed; int force_pwchange; char *user; /* username sent by the client */ char *service; diff -ur openssh-3.8.1p1/servconf.c openssh-3.8.1p1.multiauth/servconf.c --- openssh-3.8.1p1/servconf.c 2004-01-23 05:03:10.000000000 -0600 +++ openssh-3.8.1p1.multiauth/servconf.c 2004-05-25 12:18:11.000000000 -0500 @@ -78,6 +78,7 @@ options->password_authentication = -1; options->kbd_interactive_authentication = -1; options->challenge_response_authentication = -1; + options->num_required_auth_methods = -1; options->permit_empty_passwd = -1; options->permit_user_env = -1; options->use_login = -1; @@ -194,6 +195,8 @@ options->kbd_interactive_authentication = 0; if (options->challenge_response_authentication == -1) options->challenge_response_authentication = 1; + if (options->num_required_auth_methods == -1) + options->num_required_auth_methods = 1; if (options->permit_empty_passwd == -1) options->permit_empty_passwd = 0; if (options->permit_user_env == -1) @@ -253,8 +256,8 @@ sPermitRootLogin, sLogFacility, sLogLevel, sRhostsRSAAuthentication, sRSAAuthentication, sKerberosAuthentication, sKerberosOrLocalPasswd, sKerberosTicketCleanup, - sKerberosGetAFSToken, - sKerberosTgtPassing, sChallengeResponseAuthentication, + sKerberosGetAFSToken, sKerberosTgtPassing, + sNumRequiredAuthMethods, sChallengeResponseAuthentication, sPasswordAuthentication, sKbdInteractiveAuthentication, sListenAddress, sPrintMotd, sPrintLastLog, sIgnoreRhosts, sX11Forwarding, sX11DisplayOffset, sX11UseLocalhost, @@ -329,6 +332,7 @@ { "kbdinteractiveauthentication", sKbdInteractiveAuthentication }, { "challengeresponseauthentication", sChallengeResponseAuthentication }, { "skeyauthentication", sChallengeResponseAuthentication }, /* alias */ + { "numrequiredauthmethods", sNumRequiredAuthMethods }, { "checkmail", sDeprecated }, { "listenaddress", sListenAddress }, { "printmotd", sPrintMotd }, @@ -664,6 +668,10 @@ intptr = &options->challenge_response_authentication; goto parse_flag; + case sNumRequiredAuthMethods: + intptr = &options->num_required_auth_methods; + goto parse_int; + case sPrintMotd: intptr = &options->print_motd; goto parse_flag; diff -ur openssh-3.8.1p1/servconf.h openssh-3.8.1p1.multiauth/servconf.h --- openssh-3.8.1p1/servconf.h 2003-12-30 18:37:34.000000000 -0600 +++ openssh-3.8.1p1.multiauth/servconf.h 2004-05-25 12:20:42.000000000 -0500 @@ -88,6 +88,8 @@ * authentication. */ int kbd_interactive_authentication; /* If true, permit */ int challenge_response_authentication; + int num_required_auth_methods; /* Minimum number of auth methods + * that must succeed. */ int permit_empty_passwd; /* If false, do not permit empty * passwords. */ int permit_user_env; /* If true, read ~/.ssh/environment */ diff -ur openssh-3.8.1p1/sshd_config openssh-3.8.1p1.multiauth/sshd_config --- openssh-3.8.1p1/sshd_config 2003-12-30 18:38:32.000000000 -0600 +++ openssh-3.8.1p1.multiauth/sshd_config 2004-05-25 12:22:01.000000000 -0500 @@ -57,6 +57,10 @@ # Change to no to disable s/key passwords #ChallengeResponseAuthentication yes +# Change to require multiple authentication types, e.g. password and +# publickey. (Currently you'll need to turn off UsePrivilegeSeparation) +#NumRequiredAuthMethods 1 + # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes diff -ur openssh-3.8.1p1/sshd_config.5 openssh-3.8.1p1.multiauth/sshd_config.5 --- openssh-3.8.1p1/sshd_config.5 2004-04-13 22:04:36.000000000 -0500 +++ openssh-3.8.1p1.multiauth/sshd_config.5 2004-05-25 12:27:48.000000000 -0500 @@ -411,6 +411,12 @@ are refused if the number of unauthenticated connections reaches .Dq full (60). +.It Cm NumRequiredAuthMethods +Specifies how many authentication methods must succeed during ssh2 +authentication. There are four potential methods: publickey, password, +keyboard-interactive, and hostbased. Setting this value to 2 or higher forces +the client to successfully authenticate in multiple ways, for example, using +both S/Key and publickey. .It Cm PasswordAuthentication Specifies whether password authentication is allowed. The default is From dtucker at zip.com.au Thu May 27 19:22:05 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 27 May 2004 19:22:05 +1000 Subject: X-Forwarding freezes keyboard on ThinClient Vortex86 In-Reply-To: <40B2F720.2060004@fibranet.com> References: <40B2F720.2060004@fibranet.com> Message-ID: <40B5B33D.50607@zip.com.au> Jordi Sanfeliu wrote: > To test this new Thin Client almost nothing was changed in the LTSP > configuration, just the MAC address and the video configuration and > resolution. The problem arises when unexpectedly the X-Forwarding > feature hang the keyboard after 3 or 4 key-clicks. The mouse continues > working (well at least it moves), but the keyboard does not respond, > keyboard-leds are dead and the display freezed. That sounds like a hardware (or low-level OS problem). > If I remove the line "ssh -X user at linuxserver ....." and (manually) > executes from the Linux server the OpenOffice program with the DISPLAY > variable containing the Thin Client IP address (that is not using > X-Forwarding nor OpenSSH at all), it works fine!!!. Perhaps the extra load caused by the crypto pushes borderline hardware over the edge, or possibly uncovers some kind of race in the OS? Try running something to suck up all the CPU and see if your problems happen without ssh (I suggest "openssl aes-128-cbc -in /dev/zero -out /dev/null" with a bogus password). -- 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 ted at foi.se Thu May 27 22:44:37 2004 From: ted at foi.se (Daniel Tourde) Date: Thu, 27 May 2004 14:44:37 +0200 Subject: scp host1:file1 host2:file2 -> Permission denied?????? Message-ID: <40B5E2B5.6060300@foi.se> Hello, I have a stupid problem with scp and I can't find where it comes from. I am running 3 machines here with RedHat 7.3, RedHat 8 and RedHat 9. The 3 of them have openssh-3.7.1p2 (built from the SRPMS found on the openssh web site). I have though a problem to run a command of the type 'scp host1:file1 host2:file2' (my ssh being correctly setup): [ted at papeete ~]$ scp papeete.foi.se:~/nils_holgersson_airline.jpg cherbourg.foi.se:~ Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,password,keyboard-interactive). lost connection when the following works perfectly... [ted at papeete ~]$ scp ~/nils_holgersson_airline.jpg cherbourg.foi.se:~ nils_holgersson_airline.jpg 100% 4813 0.0KB/s 00:00 the following works flawlessly as well: [ted at papeete ~]$ ssh papeete.foi.se [ted at papeete ~]$ [ted at papeete ~]$ ssh papeete [ted at papeete ~]$ [ted at papeete ~]$ ssh cherbourg.foi.se [ted at cherbourg ~]$ [ted at papeete ~]$ ssh cherbourg [ted at cherbourg ~]$ The /etc/ssh/ssh_config and /etc/ssh/sshd_config have not been modified. They are exactly the ones obtained from the compilation of the SRPMS. So, I am clueless about the reason of this stupid problem. Needless to say that for an application using 'scp' heavily I need a working 'scp host1:file1 host2:file2' Has anyone any idea? Daniel Tourde -- *********************************************************************** Daniel TOURDE E-mail : daniel.tourde at foi.se Tel : +46 (0)8-55 50 43 44 Cellular : +46 (0)70-849 93 40 FOI, Swedish Defence Research Agency; Aeronautics Division - FFA Dept. of Wind Energy and Aviation Environmental Research SE-172 90 Stockholm, Sweden Fax : +46 (0)8-25 34 81 *********************************************************************** From Jordi.Sanfeliu at fibranet.com Thu May 27 23:33:22 2004 From: Jordi.Sanfeliu at fibranet.com (Jordi Sanfeliu) Date: Thu, 27 May 2004 15:33:22 +0200 Subject: X-Forwarding freezes keyboard on ThinClient Vortex86 In-Reply-To: <40B5B33D.50607@zip.com.au> References: <40B2F720.2060004@fibranet.com> <40B5B33D.50607@zip.com.au> Message-ID: <40B5EE22.8030907@fibranet.com> Darren Tucker wrote: > > That sounds like a hardware (or low-level OS problem). > Maybe, but the linux kernel 2.4.24, XFree86 4.3.99 (4.4.0RC1) and all the other utilities does not report any problem. > > Perhaps the extra load caused by the crypto pushes borderline hardware > over the edge, or possibly uncovers some kind of race in the OS? > > Try running something to suck up all the CPU and see if your problems > happen without ssh (I suggest "openssl aes-128-cbc -in /dev/zero -out > /dev/null" with a bogus password). > Tried. I have downloaded from openssl.org its last version (0.9.7d) and compiled. Then it has been executed _during 3 hours_ on such hardware (Thin Client with Vortex86), using your suggestion reproduced above. Result. All works fine. After 3 hours I have pressed CTRL-C in order to stop the execution and the keyboard responds well as expected. No hardware freeze or keyboard hang. We will need to search the source of problem in other direction. I will try to disable the Compression during the X-Forwarding process ... -- Jordi Sanfeliu FIBRANET Network Services Provider http://www.fibranet.com From mouring at etoh.eviladmin.org Thu May 27 23:37:01 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 27 May 2004 08:37:01 -0500 (CDT) Subject: scp host1:file1 host2:file2 -> Permission denied?????? In-Reply-To: <40B5E2B5.6060300@foi.se> Message-ID: scp host1:file host2:file is like saying: ssh host1 "scp file host2:file" As a result the method of authentication between host1 and host2 MUST NOT require a tty. You can use public key with ssh-agent, but you can't be prompted for a password or any interactive authentication. - Ben On Thu, 27 May 2004, Daniel Tourde wrote: > Hello, > > > I have a stupid problem with scp and I can't find where it comes from. I > am running 3 machines here with RedHat 7.3, RedHat 8 and RedHat 9. The 3 > of them have openssh-3.7.1p2 (built from the SRPMS found on the openssh > web site). > > I have though a problem to run a command of the type 'scp host1:file1 > host2:file2' (my ssh being correctly setup): > > [ted at papeete ~]$ scp papeete.foi.se:~/nils_holgersson_airline.jpg > cherbourg.foi.se:~ > Permission denied, please try again. > Permission denied, please try again. > Permission denied (publickey,password,keyboard-interactive). > lost connection > > when the following works perfectly... > > [ted at papeete ~]$ scp ~/nils_holgersson_airline.jpg cherbourg.foi.se:~ > nils_holgersson_airline.jpg > 100% 4813 0.0KB/s 00:00 > > > the following works flawlessly as well: > [ted at papeete ~]$ ssh papeete.foi.se > [ted at papeete ~]$ > > [ted at papeete ~]$ ssh papeete > [ted at papeete ~]$ > > [ted at papeete ~]$ ssh cherbourg.foi.se > [ted at cherbourg ~]$ > > [ted at papeete ~]$ ssh cherbourg > [ted at cherbourg ~]$ > > > The /etc/ssh/ssh_config and /etc/ssh/sshd_config have not been modified. > They are exactly the ones obtained from the compilation of the SRPMS. > So, I am clueless about the reason of this stupid problem. Needless to > say that for an application using 'scp' heavily I need a working 'scp > host1:file1 host2:file2' > > Has anyone any idea? > > > > Daniel Tourde > > > -- > *********************************************************************** > Daniel TOURDE E-mail : daniel.tourde at foi.se > Tel : +46 (0)8-55 50 43 44 > Cellular : +46 (0)70-849 93 40 > FOI, Swedish Defence Research Agency; Aeronautics Division - FFA > Dept. of Wind Energy and Aviation Environmental Research > SE-172 90 Stockholm, Sweden Fax : +46 (0)8-25 34 81 > *********************************************************************** > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From ted at foi.se Thu May 27 23:30:54 2004 From: ted at foi.se (Daniel Tourde) Date: Thu, 27 May 2004 15:30:54 +0200 Subject: scp host1:file1 host2:file2 -> Permission denied?????? In-Reply-To: References: Message-ID: <40B5ED8E.5040206@foi.se> Hello Ben, Thanks for your answer. > scp host1:file host2:file is like saying: > > ssh host1 "scp file host2:file" Yes. I know that, considering that I am already on host1, a simple "scp file1 host2:file2" could also do the trick, somehow. > As a result the method of authentication between host1 and host2 MUST NOT > require a tty. You can use public key with ssh-agent, but you can't be > prompted for a password or any interactive authentication. This is were you are loosing me. Is there a fondamental difference between: scp host1:file1 host2:file and scp file1 host2:file ? If yes, what is it then and how a system is supposed to be configured to make it work whatever the user types. -- *********************************************************************** Daniel TOURDE E-mail : daniel.tourde at foi.se Tel : +46 (0)8-55 50 43 44 Cellular : +46 (0)70-849 93 40 FOI, Swedish Defence Research Agency; Aeronautics Division - FFA Dept. of Wind Energy and Aviation Environmental Research SE-172 90 Stockholm, Sweden Fax : +46 (0)8-25 34 81 *********************************************************************** From flash at itp.tu-graz.ac.at Thu May 27 23:18:23 2004 From: flash at itp.tu-graz.ac.at (Christian Pfaffel) Date: 27 May 2004 15:18:23 +0200 Subject: Patch: OpenSSH 3.8.1p1, PAM, pam_krb5 & Privilege Separation Message-ID: <7gn03u3t5s.fsf@faeppc20.tu-graz.ac.at> A non-text attachment was scrubbed... Name: openssh-setcred.patch Type: text/x-patch Size: 2735 bytes Desc: PAM and Kerberos Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040527/d7678ac6/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-pam-privsep.patch Type: text/x-patch Size: 1171 bytes Desc: GSSAPIAuth PAM and PrivSep Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040527/d7678ac6/attachment-0001.bin -------------- next part -------------- -- Christian Pfaffel Technische Universit?t Graz Telefon: +43 / 316 / 873 - 81 90 Institut f?r Theoretische Physik Telefax: +43 / 316 / 873 - 86 78 Petersgasse 16, A-8010 Graz http://fubphpc.tu-graz.ac.at/~flash/pubkey.gpg From mouring at etoh.eviladmin.org Fri May 28 00:23:35 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 27 May 2004 09:23:35 -0500 (CDT) Subject: scp host1:file1 host2:file2 -> Permission denied?????? In-Reply-To: <40B5ED8E.5040206@foi.se> Message-ID: On Thu, 27 May 2004, Daniel Tourde wrote: > Hello Ben, > > > Thanks for your answer. > > > scp host1:file host2:file is like saying: > > > > ssh host1 "scp file host2:file" > > Yes. I know that, considering that I am already on host1, a simple "scp > file1 host2:file2" could also do the trick, somehow. > > > > As a result the method of authentication between host1 and host2 MUST NOT > > require a tty. You can use public key with ssh-agent, but you can't be > > prompted for a password or any interactive authentication. > > This is were you are loosing me. > Is there a fondamental difference between: > scp host1:file1 host2:file > and > scp file1 host2:file ? > > If yes, what is it then and how a system is supposed to be configured to > make it work whatever the user types. > scp does not try to figure out if "host1" or "host2" is the same as the machine you are on. To do so would be extremely tricky and could result in wrong guessing. therefor it always assume that you are transfer to two other machines. -Ben From ghibo at mandrakesoft.com Fri May 28 01:31:09 2004 From: ghibo at mandrakesoft.com (=?ISO-8859-15?Q?Giuseppe_Ghib=F2?=) Date: Thu, 27 May 2004 17:31:09 +0200 Subject: openssh & delay Message-ID: <40B609BD.9080207@mandrakesoft.com> Hi, I wrote you to ask whether this patch is OK for you. I extracted from the current debian openssh patch set. The problem is that in a openssh 3.6.1p2 installation compiled with pam support when one is doing an ssh connection to a 3.6.1p2 ssh server there is a slight delay of around 3-4 seconds before one gets the login, and even before you type the login name and password you get this message in /var/log/messages of the remote machine one is going to connect to: sshd(pam_unix)[4402]: authentication failure; uid=... euid=... tty=NODEVssh ruser= rhost=... user=... I've noticed also that under current openssh-3.8 instead there isn't such delay nor log entry. At the beginning I thought it was caused to delay caused by IPV6 DNS lookups, then something related to pam, and recently I found that such behaviour was already reported and explained, for instance, here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=192207 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193546 http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=101157#c8 and http://www.securityfocus.com/archive/121/326500/2003-06-18/2003-06-24/0 and depends on the attempts with EmptyPassword and pam the ssh does. Debian uses a patch (which I extracted and attached here) which seems working for fixing this behaviour. The openssh 3.8 seems also using a similar solution, with: if (*password == '\0' && options.permit_empty_passwd == 0) return 0; in auth-passwd.c; so I was wondering if it's safe to use the (attached) debian patch, in which case Stew/Vincent will provide and official Mandrake openssh update. Thanks. Bye. Giuseppe. -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-3.6.1p2-delay.patch.gz Type: application/x-gzip Size: 711 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040527/5dfaabed/attachment.bin From lindysandiego at yahoo.com Fri May 28 04:16:28 2004 From: lindysandiego at yahoo.com (Thomas Baden) Date: Thu, 27 May 2004 11:16:28 -0700 (PDT) Subject: Oddness with agent forwarding and -i In-Reply-To: <40AE2DAE.4050502@noaa.gov> Message-ID: <20040527181628.73918.qmail@web51701.mail.yahoo.com> Jefferson Ogata wrote: > If a key in agent is more accessible than the key > named with -i, the user would presumably simply > refrain from passing -i. > The current behavior is weird because if you have a > key with a specific command= setting and a generic > shell key, agent may authenticate with the generic > key even though you set -i. There is an option to > ignore agent keys, or you can just unset > SSH_AUTH_SOCK as I noted earlier, but I think it's > counter-intuitive that a key explicitly specified > with -i isn't at least tried ahead of anything in > agent. That's what I thought, hence why I asked the question of the list. ===== Cheers, -Thomas __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ From david.r.steiner at Dartmouth.EDU Fri May 28 05:49:22 2004 From: david.r.steiner at Dartmouth.EDU (David R. Steiner) Date: Thu, 27 May 2004 15:49:22 -0400 Subject: Solaris/PAM/AFS: can't make it work Message-ID: Greetings, I know this has been discussed (pretty much since 3.7.1) and I have been going through the archives trying to make sense of it but I am still having problems getting 3.8.1p1 to work with PAM and AFS on Solaris 8. The problem (for those who may have missed it): When I try and log in as an AFS user to a Solaris 8 box running 3.8.1p1, I can authenticate to the machine but do not get a token (on one box, I was getting someone else's token =8-O ). Here is what I have done so far: - I tried forcing USE_POSIX_THREADS when building as described in http://bugzilla.mindrot.org/show_bug.cgi?id=688 . My understanding of how to do this was to set CFLAGS=-DUSE_POSIX_THREADS when configuring and I added -lpthreads to the LIBS in the Makefile. (Correct?) When I tried this, I was prompted for a password but when I entered it the server closed the connection. The debug output from the server (from the point of the password prompt) was: Postponed keyboard-interactive for dsteiner from 129.170.18.58 port 45683 ssh2 debug3: mm_sshpam_respond debug3: mm_request_send entering: type 52 debug3: mm_sshpam_respond: waiting for MONITOR_ANS_PAM_RESPOND debug3: mm_request_receive_expect entering: type 53 debug3: mm_request_receive entering 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_request_send entering: type 53 debug3: mm_request_receive entering debug3: mm_sshpam_respond: pam_respond returned 1 debug3: mm_sshpam_query debug3: mm_request_send entering: type 50 debug3: mm_sshpam_query: waiting for MONITOR_ANS_PAM_QUERY debug3: mm_request_receive_expect entering: type 51 debug3: mm_request_receive entering debug3: monitor_read: checking request 50 debug3: mm_answer_pam_query debug3: PAM: sshpam_query entering debug3: ssh_msg_recv entering debug3: PAM: do_pam_account pam_acct_mgmt = 0 debug3: ssh_msg_send: type 0 debug3: PAM: import_environments entering buffer_get: trying to get more bytes 4 than in buffer 0 debug1: do_cleanup debug1: PAM: cleanup debug3: PAM: sshpam_thread_cleanup entering debug1: do_cleanup debug1: PAM: cleanup debug3: PAM: sshpam_thread_cleanup entering - I tried applying the patches that Christian Pfaffel posted. But they did not produce any different results than the unpatched version. It did not matter whether the UsePAMSetCred option was set to yes or no. My configuration looks like this: ./configure --prefix=/usr/ssh --with-pam --with-tcp-wrappers=/usr/local --sysconfdir=/etc/ssh --with-pid-dir=/var/run --with-ipv4-default --with-default-path=/usr/bin:/bin:/usr/sbin:/sbin:/usr/afsws/bin:/usr/ssh/bin:/usr/local/bin I would greatly appreciate hearing if anyone has any other suggestions or can see something I have done wrong. TIA -David- -- David R. Steiner david.r.steiner at dartmouth.edu UNIX System Manager Phone: 603.646.3127 Dartmouth College Fax: 603.646.1041 From jimc at math.ucla.edu Fri May 28 05:52:40 2004 From: jimc at math.ucla.edu (Jim Carter) Date: Thu, 27 May 2004 12:52:40 -0700 (PDT) Subject: OpenSSH v3.8p1 fails to interoperate for GSSAPI (Kerberos) and X-Windows Message-ID: Damien Miller wrote: > The GSSAPI issue wouldn't have caused you as much pain if your Linux > vendor hadn't added support for an unfinished protocol. Most other > Linux vendors did the right thing and made the patch available as a > compile time options, or as a clearly labelled separate package. > If this same vendor is not providing you with the necessary support to > retain compatibility with their previous versions, then you probably go > and yell at them :) I have :-( I'll append your comments to the ticket file. The vendor is SuSE. Generally they're fairly aggressive, but within the bounds of reason, in getting new features into their distro. I see your comment that GSSAPI first appeared in OpenSSH v3.7. You are probably right that SuSE added a circulating patch to v3.5p1, or backported the 3.7 GSSAPI code, both of which they are known to do regularly when a feature is important. In the current climate of hacking, I imagine that Kerberos-capable ssh is one of the features most often asked for. Here's a reference for "current climate of hacking", which is worth reading: http://securecomputing.stanford.edu/alerts/multiple-unix-6apr2004.html James F. Carter Voice 310 825 2897 FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: jimc at math.ucla.edu http://www.math.ucla.edu/~jimc (q.v. for PGP key) From jimc at math.ucla.edu Fri May 28 05:51:03 2004 From: jimc at math.ucla.edu (Jim Carter) Date: Thu, 27 May 2004 12:51:03 -0700 (PDT) Subject: OpenSSH v3.8p1 fails to interoperate for GSSAPI (Kerberos) and X-Windows Message-ID: Thank you all for your replies. Please accept my apology for a somewhat intemperate tone, but also please consider where I was coming from: I had figured out that our Kerberos deployment was going to be derailed because of the 3.5[SuSE] <-> 3.8 lack of interoperability, and then I turned to the X-Windows issue: seemingly random error messages that suggested corruption in the encrypted channel. I had no idea that it was deliberate and documented! Darren Tucker wrote: > Simon Wilkinson published a patch to enable backwards compatibility with > "gssapi" authentication. > http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=107826289602763 Thank you! This will be very helpful. I must have used keywords (like gssapi-with-mic) in my Google search that missed it. I have a software audit script that can deal with locally patched software, rather than having to slavishly use whatever the distro gives us. (A big advantage of using a distro is that most of the time you can automate patches, but there *is* a downside...) When all of our systems have been upgraded and when we're sure that off-site users aren't going to get cut off -- probably we won't have too many that we'll have to bully into upgrading -- we can decommit gssapi-without-mic. > That's only the "-Y" command-line option (which is a substitute for > "-X"), ForwardX11Trusted does not imply ForwardX11 (at least in the > current version, I didn't check older ones). OK, that's reasonable. For the record, I confirm that if you set ForwardX11Trusted=true and ForwardX11=false in ssh_config, then plain "ssh" does not forward X11, but "ssh -X" does forward it, and it is trusted (the offending apps will run). (With either setting, ssh -Y works as expected.) This is how we've set up our ssh_config for the machines with openssh v3.8p1, following the Debian guy's suggestion. James F. Carter Voice 310 825 2897 FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: jimc at math.ucla.edu http://www.math.ucla.edu/~jimc (q.v. for PGP key) From dtucker at zip.com.au Fri May 28 11:00:28 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 28 May 2004 11:00:28 +1000 Subject: openssh & delay In-Reply-To: <40B609BD.9080207@mandrakesoft.com> References: <40B609BD.9080207@mandrakesoft.com> Message-ID: <40B68F2C.7000304@zip.com.au> Giuseppe Ghib? wrote: > Hi, I wrote you to ask whether this patch is OK for you. I extracted > from the current debian openssh patch set. FWIW it looks ok to me (but I'm biased, I put that patch together for Debian bug #192207), It just short circuits the "none" checks if PermitEmptyPasswords=no and feeds PAM a bogus password for root if PermitRootLogin!=yes. Assuming you have PAM delay on failure, an attacker can trivially determine the PermitEmptyPasswords setting, but I think that's about it. Credit where it's due: the bogus root password bit is originally from Openwall (their "owl-always-auth" patch). -- 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 Fri May 28 12:15:55 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 28 May 2004 12:15:55 +1000 Subject: Solaris/PAM/AFS: can't make it work In-Reply-To: References: Message-ID: <40B6A0DB.4050005@zip.com.au> David R. Steiner wrote: > I know this has been discussed (pretty much since 3.7.1) and I have been > going through the archives trying to make sense of it but I am still > having problems getting 3.8.1p1 to work with PAM and AFS on Solaris 8. [...] > - I tried forcing USE_POSIX_THREADS when building as described in > http://bugzilla.mindrot.org/show_bug.cgi?id=688 . My understanding of > how to do this was to set CFLAGS=-DUSE_POSIX_THREADS when configuring > and I added -lpthreads to the LIBS in the Makefile. (Correct?) Right, more or less (it's -lpthread not -lpthreads). The easiest way is: ./configure --with-cflags=-DUSE_POSIX_THREADS --with-libs=-lpthread > debug3: PAM: import_environments entering > buffer_get: trying to get more bytes 4 than in buffer 0 Are you sure this isn't 3.8p1? There was a bug in the use-threads configuration in 3.8p1 that caused that problem, but it was fixed in 3.8.1p1. If that's not it you could also try these patches by Christian Pfaffel, (I don't know enough about how pam_dhkeys works to know if this will help in your case or not): http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=108566628206690 -- 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 Fri May 28 12:18:23 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 28 May 2004 12:18:23 +1000 Subject: X-Forwarding freezes keyboard on ThinClient Vortex86 In-Reply-To: <40B5EE22.8030907@fibranet.com> References: <40B2F720.2060004@fibranet.com> <40B5B33D.50607@zip.com.au> <40B5EE22.8030907@fibranet.com> Message-ID: <40B6A16F.6070209@zip.com.au> Jordi Sanfeliu wrote: > I will try to disable the Compression during the X-Forwarding process ... Also try "ForwardX11Trusted yes" in ssh_config (I can't see how it could mess up the keyboard but it's worth a try). -- 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 giebels at ocs.mq.edu.au Sat May 29 02:31:29 2004 From: giebels at ocs.mq.edu.au (giebels at ocs.mq.edu.au) Date: Fri, 28 May 2004 16:31:29 +0000 Subject: eaq software In-Reply-To: References: Message-ID: <92B6FD6062387034@ocs.mq.edu.au> Dreamwaver MX 2004 $60 Windows XP Professional + Office XP Professional $80 Illustrator 10 $60 http://JMMAMD.biz/OE017/?affiliate_id=233763&campaign_id=601 Corel Draw Graphics Suite 12 $60 PageMaker 7 (2CD) $60 Photoshop 7 $60 PageMaker 7 (2CD) $60 Windows XP Professional $50 MS Plus! XP $50 From chutz at gg3.net Fri May 28 18:07:59 2004 From: chutz at gg3.net (Georgi Georgiev) Date: Fri, 28 May 2004 17:07:59 +0900 Subject: Corrupted MAC on input Message-ID: <20040528080758.GA18981@lion.gg3.net> I hope the experience I had with this problem could shed some light to the more knowledgable. I started having the "Corrupted MAC on input" since a few days ago. I do not know what the cause is, but from what I've read in this thread, it could be an ssh problem. I have not changed the configuration on my machine in any way. The only machine I have a problem with is a $ uname -a IRIX64 onyx 6.5 10151453 IP35 http://onyx.hucc.hokudai.ac.jp/cgi-bin/MachineInfo The computer I connect from is a Gentoo Linux, Single P4 3.0GHz HT, running SMP vanilla kenrel 2.6.6. The ssh client identifies itself as SSH-2.0-OpenSSH_3.8p1. The server side, I do not have much control over. The ssh daemon presents the following greeting: SSH-1.99-OpenSSH_3.6.1p2 I get these Corrupted MAC errors very, very often now (I had never seen one until a few days ago). The easiest way to cause them is to start vi and start going up and down in a text file. These errors occur with SSHv2 conections only. If I connect with ssh -1 there is no problem, regardless if I turn on compression to level 9. After reading the comment about a possible problem with compression, I tried running "find /" to see if this will cause a Corrupted MAC, but it worked fine. I seem to have problems only when at input (never on output). The error always interrupts me in the middle of whatever it is I am typing. Speed doesn't seem to be an issue. I copied a 11MB file using scp *from* that server, without a problem: $ scp onyx:mpich.tar.gz dump However, copying the same file *to* the server fails almost immediately: $ scp dump onyx: I also captured a complete ssh session using tcpdump. Replaying it with tcpdump -r shows only 74 frames (the dumped file is 7249 bytes). I could post it if anyone thinks it can help. I captured the failing scp session as well. The quicker of the two captures contains only 30 frames. I would like to know your opinion about what the cause of the problem is. Please make sure you CC: any replies as I am not a subscriber. -- / Georgi Georgiev / BOFH Excuse #343: The ATM board has run out / \ chutz at gg3.net \ of 10 pound notes. We are having a whip \ / +81(90)6266-1163 / round to refill it, care to contribute ? / From ghibo at mandrakesoft.com Fri May 28 19:07:54 2004 From: ghibo at mandrakesoft.com (=?ISO-8859-1?Q?Giuseppe_Ghib=F2?=) Date: Fri, 28 May 2004 11:07:54 +0200 Subject: openssh & delay In-Reply-To: <40B68F2C.7000304@zip.com.au> References: <40B609BD.9080207@mandrakesoft.com> <40B68F2C.7000304@zip.com.au> Message-ID: <40B7016A.2050405@mandrakesoft.com> Darren Tucker wrote: > Giuseppe Ghib? wrote: > >> Hi, I wrote you to ask whether this patch is OK for you. I extracted >> from the current debian openssh patch set. > > > FWIW it looks ok to me (but I'm biased, I put that patch together for > Debian bug #192207), It just short circuits the "none" checks if > PermitEmptyPasswords=no and feeds PAM a bogus password for root if > PermitRootLogin!=yes. Assuming you have PAM delay on failure, an > attacker can trivially determine the PermitEmptyPasswords setting, but I > think that's about it. Well, isn't this the same behaviour of current openssh 3.8? > > Credit where it's due: the bogus root password bit is originally from > Openwall (their "owl-always-auth" patch). > Thanks, for the info. Bye. Giuseppe. From saju.paul at emergis-systems.com Fri May 28 23:05:22 2004 From: saju.paul at emergis-systems.com (Saju Paul) Date: Fri, 28 May 2004 09:05:22 -0400 Subject: sftp Client for Windows XP Message-ID: Folks, Excuse my ignorance on the subject but I'm new to OpenSSH and have been tasked to write a 'sftp' Client for a home-grown application that runs on a Windows platform. The answers to my questions is probably on the List Archives but I'm not able to find it even after a few search attempts. So here goes... 1. Is it possible to even write a custom 'sftp' client for our application on the MS Windows platform ? (my system uses Windows XP on a standard Intel based processor) on which I'll need to be able to build the OpenSSH libraries (libssh.a, libopenbsd-compat.a and any others) at a minimum. 2. Does Windows support OpenSSH or vice versa ? 3. If OpenSSH cannot be used are they any commercial versions of SSH that I might be able to use ? Thanks, Saju Paul ps: On a system running Fedora (version of Linux); installed the portable OpenSSH version 3.8.1 on it; Ran local loopback tests with ssh & sftp. Both work Okay. From stuge-openssh-unix-dev at cdy.org Fri May 28 23:13:30 2004 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 28 May 2004 15:13:30 +0200 Subject: sftp Client for Windows XP In-Reply-To: References: Message-ID: <20040528131330.GA32465@foo.birdnet.se> On Fri, May 28, 2004 at 09:05:22AM -0400, Saju Paul wrote: > 3. If OpenSSH cannot be used are they any commercial versions of > SSH that I might be able to use ? I suggest you look at the FileZilla and PuTTY projects, both of which are native Win32 projects, unlike OpenSSH. //Peter From michal at pasternak.w.lub.pl Fri May 28 23:17:00 2004 From: michal at pasternak.w.lub.pl (Michal Pasternak) Date: Fri, 28 May 2004 15:17:00 +0200 Subject: sftp Client for Windows XP In-Reply-To: References: Message-ID: <20040528131700.GA30597@pasternak.w.lub.pl> Saju Paul [Fri, May 28, 2004 at 09:05:22AM -0400]: > 1. Is it possible to even write a custom 'sftp' client for our application > on the MS Windows platform ? Of course. If you don't have to use C, there's a nice implementation called 'Conch' in Python - http://twistedmatrix.com/ - works really nice, and as all Python stuff, it's extremely portable. If I'd have to write some SSH client for win32 quick, I start there. I'm sure someone else will answer your questions having C in mind. HTH, -- m -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040528/adf4750b/attachment.bin From wknox at mitre.org Fri May 28 23:20:42 2004 From: wknox at mitre.org (William R. Knox) Date: Fri, 28 May 2004 09:20:42 -0400 (EDT) Subject: sftp Client for Windows XP In-Reply-To: References: Message-ID: Take a look at PuTTY (I'm sure you're getting buried with this answer), a freely available Telnet/SSH/SFTP client for Windows (http://www.chiark.greenend.org.uk/~sgtatham/putty/). Bill Knox Lead Operating Systems Programmer/Analyst The MITRE Corporation On Fri, 28 May 2004, Saju Paul wrote: > Date: Fri, 28 May 2004 09:05:22 -0400 > From: Saju Paul > To: openssh-unix-dev at mindrot.org > Subject: sftp Client for Windows XP > > Folks, > Excuse my ignorance on the subject but I'm new to OpenSSH and have been > tasked to write a 'sftp' Client for a home-grown application that runs on a > Windows platform. > > The answers to my questions is probably on the List Archives but I'm not > able to find it even after a few search attempts. > > So here goes... > > 1. Is it possible to even write a custom 'sftp' client for our application > on the MS Windows platform ? (my system uses Windows XP on a standard Intel > based processor) on which I'll need to be able to build the OpenSSH > libraries (libssh.a, libopenbsd-compat.a and any others) at a minimum. > > 2. Does Windows support OpenSSH or vice versa ? > > 3. If OpenSSH cannot be used are they any commercial versions of SSH that I > might be able to use ? > > Thanks, > Saju Paul > > ps: On a system running Fedora (version of Linux); installed the portable > OpenSSH version 3.8.1 > on it; Ran local loopback tests with ssh & sftp. Both work Okay. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From dtucker at zip.com.au Fri May 28 23:30:25 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 28 May 2004 23:30:25 +1000 Subject: sftp Client for Windows XP In-Reply-To: References: Message-ID: <40B73EF1.6030005@zip.com.au> Saju Paul wrote: > 1. Is it possible to even write a custom 'sftp' client for our application > on the MS Windows platform ? (my system uses Windows XP on a standard Intel > based processor) on which I'll need to be able to build the OpenSSH > libraries (libssh.a, libopenbsd-compat.a and any others) at a minimum. It's possible to make sftp into a native Windows program but it's likely to be an awful lot of work. sftp needs ssh, and ssh makes a lot of assumptions that's running on a Unix-like platform and libssh.a is not intended for use by applications. > 2. Does Windows support OpenSSH or vice versa ? Yes, via Cygwin (out-of-the-box) or Services For Unix (third-party patches). > 3. If OpenSSH cannot be used are they any commercial versions of SSH that I > might be able to use ? Try PuTTY or Peter Gutmann's cryptlib. -- 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 Fri May 28 23:39:58 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 28 May 2004 23:39:58 +1000 Subject: openssh & delay In-Reply-To: <40B7016A.2050405@mandrakesoft.com> References: <40B609BD.9080207@mandrakesoft.com> <40B68F2C.7000304@zip.com.au> <40B7016A.2050405@mandrakesoft.com> Message-ID: <40B7412E.4010201@zip.com.au> Giuseppe Ghib? wrote: > Darren Tucker wrote: >> Assuming you have PAM delay on failure, an >> attacker can trivially determine the PermitEmptyPasswords setting, but >> I think that's about it. > > Well, isn't this the same behaviour of current openssh 3.8? Yes, and afaict it's unavoidable (since SSH2's "none" auth does double duty as "let me in if you require no further authentication" and "tell me the list of authentications required to continue", and PAM won't tell applications anything about what authentications it will require.) -- 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 Sat May 29 01:01:45 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 29 May 2004 01:01:45 +1000 Subject: Corrupted MAC on input In-Reply-To: <20040528080758.GA18981@lion.gg3.net> References: <20040528080758.GA18981@lion.gg3.net> Message-ID: <40B75459.4070801@zip.com.au> Georgi Georgiev wrote: > I started having the "Corrupted MAC on input" since a few days ago. I do not > know what the cause is, but from what I've read in this thread, it could be an > ssh problem. It's most likely faulty hardware at some point, expecially if you've not made any changes. Flaky RAM, faulty network cards, cables, buggy router firmware... See: http://bugzilla.mindrot.org/show_bug.cgi?id=510 http://bugzilla.mindrot.org/show_bug.cgi?id=845 > I have not changed the configuration on my machine in any way. The only machine > I have a problem with is a IRIX64 onyx 6.5 10151453 IP35 At least some revisions of IRIX appear to have a memory-trashing bug somewhere inside the getaddrinfo() family of functions. That IRIX box wasn't patched recently, was it? http://bugzilla.mindrot.org/show_bug.cgi?id=585 -- 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 agrewell at uwb.edu Sat May 29 02:58:51 2004 From: agrewell at uwb.edu (Aaron Grewell) Date: Fri, 28 May 2004 09:58:51 -0700 Subject: gssapi-with-mic and Win2K KDC? Message-ID: <1085763531.5302.1243.camel@cygnus.uwb.edu> Upgrading to the 3.8.x versions of OpenSSH appears to have broken support for Win2K KDC's. Win2K supports gssapi just fine, but the new gssapi-with-mic does not appear to work. I was able to use the old 3.6.x versions with Kerberos authentication, and the newer 3.7.x versions with gssapi authentication, but 3.8.x does not seem to work at all. The mitm patch provided for 3.8p1 does work, but it seems unlikely it will be maintained over the long term. What are the odds the gssapi functionality might be retained for compatibility purposes? Even if it were a default-off compile-time option that would work for me. The soonest MS would be likely to update their gssapi support would be Longhorn Server in the 2006-2007 timeframe (if at all) so the interoperability issues with their KDC's are likely to continue for some time to come. Thanks much, Aaron Grewell Network Administrator University of Washington Bothell From deengert at anl.gov Sat May 29 03:39:40 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 28 May 2004 12:39:40 -0500 Subject: gssapi-with-mic and Win2K KDC? References: <1085763531.5302.1243.camel@cygnus.uwb.edu> Message-ID: <40B7795C.35FB1BEC@anl.gov> Aaron Grewell wrote: > > Upgrading to the 3.8.x versions of OpenSSH appears to have broken > support for Win2K KDC's. Win2K supports gssapi just fine, but the new > gssapi-with-mic does not appear to work. It works for us. We have used W2000 ADs, and they are now all W2003 ADs. OpenSSH-3.8p1. What type of errors are you seeing? > I was able to use the old > 3.6.x versions with Kerberos authentication, and the newer 3.7.x > versions with gssapi authentication, but 3.8.x does not seem to work at > all. The mitm patch provided for 3.8p1 does work, but it seems unlikely > it will be maintained over the long term. What are the odds the gssapi > functionality might be retained for compatibility purposes? The comunity should be making an effort to move towards geting rid of the gssapi, and move to the gssapi-with-mic with all due haste. > Even if it > were a default-off compile-time option that would work for me. The > soonest MS would be likely to update their gssapi support would be > Longhorn Server in the 2006-2007 timeframe (if at all) so the > interoperability issues with their KDC's are likely to continue for some > time to come. > > Thanks much, > Aaron Grewell > Network Administrator > University of Washington Bothell > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From agrewell at uwb.edu Sat May 29 04:14:07 2004 From: agrewell at uwb.edu (Aaron Grewell) Date: Fri, 28 May 2004 11:14:07 -0700 Subject: gssapi-with-mic and Win2K KDC? In-Reply-To: <40B7795C.35FB1BEC@anl.gov> References: <1085763531.5302.1243.camel@cygnus.uwb.edu> <40B7795C.35FB1BEC@anl.gov> Message-ID: <1085768047.5302.1277.camel@cygnus.uwb.edu> On Fri, 2004-05-28 at 10:39, Douglas E. Engert wrote: > Aaron Grewell wrote: > > > > Upgrading to the 3.8.x versions of OpenSSH appears to have broken > > support for Win2K KDC's. Win2K supports gssapi just fine, but the new > > gssapi-with-mic does not appear to work. > > It works for us. We have used W2000 ADs, and they are now all W2003 ADs. > OpenSSH-3.8p1. > > What type of errors are you seeing? > Oh goody. Maybe I've just borked something. I've got my Linux boxes (RHEL3) set up for PAM authentication to Win2K via Kerberos. This works fine, so I'm pretty sure I haven't screwed up the Kerberos end of it. Also, if I turn off Kerberos and GSSAPI and turn on PAM in OpenSSH this also works fine. However, I would like to be able to use both password authentication and ticket-based passwordless authentication for those hosts that support it. Thus the need for GSSAPI support. > The comunity should be making an effort to move towards geting rid > of the gssapi, and move to the gssapi-with-mic with all due haste. > Sure, but this is MS we're talking about. "Community who?" But back to the authentication issues. When I try to login via GSSAPI with or without a ticket in 3.8.x it prompts for a password, then refuses my password, as though I had typed it improperly. The same UID/password through PAM works fine. More detail: With ssh 3.8.1p1 on both client and server On the ssh server: # GSSAPI options GSSAPIAuthentication yes GSSAPICleanupCredentials yes On the client: [localaccount at workstation localaccount]$ ssh adminaccount at server.uwb.edu -vvv OpenSSH_3.8.1p1, OpenSSL 0.9.7a Feb 19 2003 debug1: Reading configuration data /home/localaccount/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to server.uwb.edu [216.186.72.7] port 22. debug1: Connection established. debug1: identity file /home/localaccount/.ssh/identity type -1 debug1: identity file /home/localaccount/.ssh/id_rsa type -1 debug1: identity file /home/localaccount/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.8.1p1 debug1: match: OpenSSH_3.8.1p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro up1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c tr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c tr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib 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-gro up1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c tr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c tr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,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: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 115/256 debug2: bits set: 503/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/localaccount/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug3: check_host_in_hostfile: filename /home/localaccount/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug1: Host 'server.uwb.edu' is known and matches the RSA host key. debug1: Found key in /home/localaccount/.ssh/known_hosts:1 debug2: bits set: 496/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/localaccount/.ssh/identity ((nil)) debug2: key: /home/localaccount/.ssh/id_rsa ((nil)) debug2: key: /home/localaccount/.ssh/id_dsa ((nil)) debug1: Authentications that can continue: publickey,gssapi-with-mic,password,ke yboard-interactive debug3: start over, passed a different list publickey,gssapi-with-mic,password,k eyboard-interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/localaccount/.ssh/identity debug3: no such identity: /home/localaccount/.ssh/identity debug1: Trying private key: /home/localaccount/.ssh/id_rsa debug3: no such identity: /home/localaccount/.ssh/id_rsa debug1: Trying private key: /home/localaccount/.ssh/id_dsa debug3: no such identity: /home/localaccount/.ssh/id_dsa debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password,ke yboard-interactive debug3: userauth_kbdint: disable: no info_req_seen debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: Next authentication method: password adminaccount at server.uwb.edu's password: debug3: packet_send2: adding 48 (len 73 padlen 7 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password,ke yboard-interactive Permission denied, please try again. adminaccount at server.uwb.edu's password: debug3: packet_send2: adding 48 (len 73 padlen 7 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password,ke yboard-interactive Permission denied, please try again. adminaccount at server.uwb.edu's password: debug3: packet_send2: adding 48 (len 73 padlen 7 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password,ke yboard-interactive debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey,gssapi-with-mic,password,keyboard-interactive). From david.r.steiner at Dartmouth.EDU Sat May 29 05:03:14 2004 From: david.r.steiner at Dartmouth.EDU (David R. Steiner) Date: Fri, 28 May 2004 15:03:14 -0400 Subject: Solaris/PAM/AFS: can't make it work In-Reply-To: <40B6A0DB.4050005@zip.com.au> References: <40B6A0DB.4050005@zip.com.au> Message-ID: At 12:15 +1000 5/28/04, Darren Tucker wrote: >David R. Steiner wrote: >>I know this has been discussed (pretty much since 3.7.1) and I have >>been going through the archives trying to make sense of it but I >>am still having problems getting 3.8.1p1 to work with PAM and AFS >>on Solaris 8. >[...] >>- I tried forcing USE_POSIX_THREADS when building as described in >>http://bugzilla.mindrot.org/show_bug.cgi?id=688 . My understanding >>of how to do this was to set CFLAGS=-DUSE_POSIX_THREADS when >>configuring and I added -lpthreads to the LIBS in the Makefile. >>(Correct?) > >>Right, more or less (it's -lpthread not -lpthreads). oops. >>debug3: PAM: import_environments entering >>buffer_get: trying to get more bytes 4 than in buffer 0 > >Are you sure this isn't 3.8p1? There was a bug in the use-threads >configuration in 3.8p1 that caused that problem, but it was fixed in >3.8.1p1. Ok, another mistake on my part. I have been rebuilding this so many times, I lost track. I think I did try the threads fix on 3.8p1. I then downloaded 3.8.1p1 when I tried Christian Pfaffel's patches. Never went back to try threads on the new version. This morning, I started with a fresh copy of 3.8.1p1 and built it with threads and it now seems to be working. Thanks for the help. -David- -- David R. Steiner david.r.steiner at dartmouth.edu UNIX System Manager Phone: 603.646.3127 Dartmouth College Fax: 603.646.1041 From deengert at anl.gov Sat May 29 07:31:39 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 28 May 2004 16:31:39 -0500 Subject: gssapi-with-mic and Win2K KDC? References: <1085763531.5302.1243.camel@cygnus.uwb.edu> <40B7795C.35FB1BEC@anl.gov> <1085768047.5302.1277.camel@cygnus.uwb.edu> Message-ID: <40B7AFBB.659E634D@anl.gov> Aaron Grewell wrote: > > On Fri, 2004-05-28 at 10:39, Douglas E. Engert wrote: > > Aaron Grewell wrote: > > > > > > Upgrading to the 3.8.x versions of OpenSSH appears to have broken > > > support for Win2K KDC's. Win2K supports gssapi just fine, but the new > > > gssapi-with-mic does not appear to work. > > > > It works for us. We have used W2000 ADs, and they are now all W2003 ADs. > > OpenSSH-3.8p1. > > > > What type of errors are you seeing? > > > > Oh goody. Maybe I've just borked something. I've got my Linux boxes > (RHEL3) set up for PAM authentication to Win2K via Kerberos. This works > fine, so I'm pretty sure I haven't screwed up the Kerberos end of it. > Also, if I turn off Kerberos and GSSAPI and turn on PAM in OpenSSH this > also works fine. However, I would like to be able to use both password > authentication and ticket-based passwordless authentication for those > hosts that support it. Thus the need for GSSAPI support. > > > The comunity should be making an effort to move towards geting rid > > of the gssapi, and move to the gssapi-with-mic with all due haste. > > > > Sure, but this is MS we're talking about. "Community who?" I don't see MS fits in here. Its only the KDC. The difference between the gsspia and gssapi-with-mic is the the with-mic uses gss_wrap/unwrap to bind the session keys to the authenication. Even if you had a Windows ssh client the used the SSPI it caould do the gssapi-wit-mic. (SecureCRT for example can do this.) > > But back to the authentication issues. When I try to login via GSSAPI > with or without a ticket in 3.8.x it prompts for a password, then > refuses my password, as though I had typed it improperly. The same > UID/password through PAM works fine. More detail: > > With ssh 3.8.1p1 on both client and server > > On the ssh server: > # GSSAPI options > GSSAPIAuthentication yes > GSSAPICleanupCredentials yes > > On the client: > [localaccount at workstation localaccount]$ ssh adminaccount at server.uwb.edu > -vvv Try using "ssh -vvv -l adminaccount server.uwb.edu" I tried something using user at host and it failed, but -l user host works. > OpenSSH_3.8.1p1, OpenSSL 0.9.7a Feb 19 2003 > debug1: Reading configuration data /home/localaccount/.ssh/config > debug1: Reading configuration data /etc/ssh/ssh_config > debug2: ssh_connect: needpriv 0 > debug1: Connecting to server.uwb.edu [216.186.72.7] port 22. > debug1: Connection established. > debug1: identity file /home/localaccount/.ssh/identity type -1 > debug1: identity file /home/localaccount/.ssh/id_rsa type -1 > debug1: identity file /home/localaccount/.ssh/id_dsa type -1 > debug1: Remote protocol version 1.99, remote software version > OpenSSH_3.8.1p1 > debug1: match: OpenSSH_3.8.1p1 pat OpenSSH* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug2: kex_parse_kexinit: > diffie-hellman-group-exchange-sha1,diffie-hellman-gro > up1-sha1 > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, > aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c > tr > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, > aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c > tr > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open > ssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open > ssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib > debug2: kex_parse_kexinit: none,zlib > 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-gro > up1-sha1 > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, > aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c > tr > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, > aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c > tr > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open > ssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open > ssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib > debug2: kex_parse_kexinit: none,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: server->client aes128-cbc hmac-md5 none > debug2: mac_init: found hmac-md5 > debug1: kex: client->server aes128-cbc hmac-md5 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP > debug2: dh_gen_key: priv key bits set: 115/256 > debug2: bits set: 503/1024 > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > debug3: check_host_in_hostfile: filename > /home/localaccount/.ssh/known_hosts > debug3: check_host_in_hostfile: match line 1 > debug3: check_host_in_hostfile: filename > /home/localaccount/.ssh/known_hosts > debug3: check_host_in_hostfile: match line 1 > debug1: Host 'server.uwb.edu' is known and matches the RSA host key. > debug1: Found key in /home/localaccount/.ssh/known_hosts:1 > debug2: bits set: 496/1024 > debug1: ssh_rsa_verify: signature correct > debug2: kex_derive_keys > debug2: set_newkeys: mode 1 > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug2: set_newkeys: mode 0 > debug1: SSH2_MSG_NEWKEYS received > debug1: SSH2_MSG_SERVICE_REQUEST sent > debug2: service_accept: ssh-userauth > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug2: key: /home/localaccount/.ssh/identity ((nil)) > debug2: key: /home/localaccount/.ssh/id_rsa ((nil)) > debug2: key: /home/localaccount/.ssh/id_dsa ((nil)) > debug1: Authentications that can continue: > publickey,gssapi-with-mic,password,ke > yboard-interactive > debug3: start over, passed a different list > publickey,gssapi-with-mic,password,k > eyboard-interactive > debug3: preferred publickey,keyboard-interactive,password What happened to gssapi-with-mic here? Does the sshd have a keytab with the host/@ principal? Did the user do a kinit to get a ticket? On my system, I get: debug1: Authentications that can continue: publickey,gssapi-with-mic,gssapi debug3: start over, passed a different list publickey,gssapi-with-mic,gssapi debug3: preferred gssapi-with-mic,gssapi,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: gssapi,publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Delegating credentials debug1: Delegating credentials > debug3: authmethod_lookup publickey > debug3: remaining preferred: keyboard-interactive,password > debug3: authmethod_is_enabled publickey > debug1: Next authentication method: publickey > debug1: Trying private key: /home/localaccount/.ssh/identity > debug3: no such identity: /home/localaccount/.ssh/identity > debug1: Trying private key: /home/localaccount/.ssh/id_rsa > debug3: no such identity: /home/localaccount/.ssh/id_rsa > debug1: Trying private key: /home/localaccount/.ssh/id_dsa > debug3: no such identity: /home/localaccount/.ssh/id_dsa > debug2: we did not send a packet, disable method > debug3: authmethod_lookup keyboard-interactive > debug3: remaining preferred: password > debug3: authmethod_is_enabled keyboard-interactive > debug1: Next authentication method: keyboard-interactive > debug2: userauth_kbdint > debug2: we sent a keyboard-interactive packet, wait for reply > debug1: Authentications that can continue: > publickey,gssapi-with-mic,password,ke > yboard-interactive > debug3: userauth_kbdint: disable: no info_req_seen > debug2: we did not send a packet, disable method > debug3: authmethod_lookup password > debug3: remaining preferred: > debug3: authmethod_is_enabled password > debug1: Next authentication method: password > adminaccount at server.uwb.edu's password: > debug3: packet_send2: adding 48 (len 73 padlen 7 extra_pad 64) > debug2: we sent a password packet, wait for reply > debug1: Authentications that can continue: > publickey,gssapi-with-mic,password,ke > yboard-interactive > Permission denied, please try again. > adminaccount at server.uwb.edu's password: > debug3: packet_send2: adding 48 (len 73 padlen 7 extra_pad 64) > debug2: we sent a password packet, wait for reply > debug1: Authentications that can continue: > publickey,gssapi-with-mic,password,ke > yboard-interactive > Permission denied, please try again. > adminaccount at server.uwb.edu's password: > debug3: packet_send2: adding 48 (len 73 padlen 7 extra_pad 64) > debug2: we sent a password packet, wait for reply > debug1: Authentications that can continue: > publickey,gssapi-with-mic,password,ke > yboard-interactive > debug2: we did not send a packet, disable method > debug1: No more authentication methods to try. > Permission denied > (publickey,gssapi-with-mic,password,keyboard-interactive). -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From chutz at gg3.net Sat May 29 12:06:33 2004 From: chutz at gg3.net (Georgi Georgiev) Date: Sat, 29 May 2004 11:06:33 +0900 Subject: Corrupted MAC on input In-Reply-To: <40B75459.4070801@zip.com.au> References: <20040528080758.GA18981@lion.gg3.net> <40B75459.4070801@zip.com.au> Message-ID: <20040529020633.GB6596@lion.gg3.net> maillog: 29/05/2004-01:01:45(+1000): Darren Tucker types > Georgi Georgiev wrote: > >I started having the "Corrupted MAC on input" since a few days ago. I do > >not > >know what the cause is, but from what I've read in this thread, it could > >be an > >ssh problem. > > It's most likely faulty hardware at some point, expecially if you've not > made any changes. Flaky RAM, faulty network cards, cables, buggy router > firmware... See: > > http://bugzilla.mindrot.org/show_bug.cgi?id=510 > http://bugzilla.mindrot.org/show_bug.cgi?id=845 > > >I have not changed the configuration on my machine in any way. The only > >machine > >I have a problem with is a IRIX64 onyx 6.5 10151453 IP35 > > At least some revisions of IRIX appear to have a memory-trashing bug > somewhere inside the getaddrinfo() family of functions. That IRIX box > wasn't patched recently, was it? > > http://bugzilla.mindrot.org/show_bug.cgi?id=585 Thanks for the detailed answer. I will forward this response to our network administrator. Bug #845 seems to be helpful, though it is only one machine that is giving me problems (I have no problems with other machines on the same network), and I only have the problem when connecting from my lab (I connected with my laptop from a physically different location and was unable to reproduce). This narrows down the gray area, so I hope we get the issue resolved. -- *- Georgi Georgiev *- Windows is the only solitaire game that *- -* chutz at gg3.net -* requires 16 MB of RAM. -* *- +81(90)6266-1163 *- *- From lkcl at lkcl.net Sun May 30 19:23:58 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 30 May 2004 09:23:58 +0000 Subject: Debian / SE/Linux - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193664 Message-ID: <20040530092358.GR2851@lkcl.net> dear openssh developers, i was wondering if you were aware of some patches for security enhancements to openssh - to support SE/Linux. www.nsa.gov/selinux. i am at present compiling a status report for debian/selinux. could someone be kind enough to provide me with some information that i can put on my report? sincerely, l. From djm at mindrot.org Sun May 30 19:43:52 2004 From: djm at mindrot.org (Damien Miller) Date: Sun, 30 May 2004 19:43:52 +1000 Subject: Debian / SE/Linux - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193664 In-Reply-To: <20040530092358.GR2851@lkcl.net> References: <20040530092358.GR2851@lkcl.net> Message-ID: <40B9ACD8.30807@mindrot.org> Luke Kenneth Casson Leighton wrote: > dear openssh developers, > > i was wondering if you were aware of some patches for security > enhancements to openssh - to support SE/Linux. I eventually found a patch at: http://www.nsa.gov/selinux/patches/openssh-selinux.patch.gz (from http://www.nsa.gov/selinux/code/download5.cfm) but it doesn't seem to do much at all - the only code change is the marking of a ssh-agent fd to be close-on-exec. Is this the patch that you are referring to? -d From lkcl at lkcl.net Sun May 30 21:41:17 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 30 May 2004 11:41:17 +0000 Subject: Debian / SE/Linux (resend due to html bounce) Message-ID: <20040530114116.GC5232@lkcl.net> Content-Description: Undelivered Message From: Luke Kenneth Casson Leighton To: Damien Miller Cc: openssh-unix-dev at mindrot.org, pam-list at redhat.com, SE-Linux , hartmans at debian.org Subject: Re: Debian / SE/Linux - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193664 Mail-Followup-To: Damien Miller , openssh-unix-dev at mindrot.org, pam-list at redhat.com, SE-Linux , hartmans at debian.org X-SA-Exim-Connect-IP: 192.168.0.223 X-SA-Exim-Mail-From: lkcl at lkcl.net On Sun, May 30, 2004 at 07:43:52PM +1000, Damien Miller wrote: > Luke Kenneth Casson Leighton wrote: > > dear openssh developers, > > > > i was wondering if you were aware of some patches for security > > enhancements to openssh - to support SE/Linux. > > I eventually found a patch at: > > http://www.nsa.gov/selinux/patches/openssh-selinux.patch.gz > (from http://www.nsa.gov/selinux/code/download5.cfm) > > but it doesn't seem to do much at all - the only code change is the > marking of a ssh-agent fd to be close-on-exec. that, and the inclusion of pam_selinux.so as a required session plugin, and the setting of a security context on the DSA and RSA keys in sshd initialisation (a redhat rpm thing?) > Is this the patch that you are referring to? yes it is. the ssh-agent fd close-on-exec is actually a really important security bug because otherwise you end up with an open file descriptor being passed over to a process that should have no rights or use for it. SE/Linux is really cool in that respect: the audit process logged that this file handle was being passed over to a child process, and the policy for ssh-agent said that that wasn't allowed. cool, huh? :) [apparently, PAM has a similar bug in /sbin/unix_verify: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248310 but the debian maintainer for pam is being a bit of idiot and won't look at it. sorry, mr hartmans, but it's bypass time, and your comments _are_ a matter of public record, after all] l. From djm at mindrot.org Sun May 30 21:48:31 2004 From: djm at mindrot.org (Damien Miller) Date: Sun, 30 May 2004 21:48:31 +1000 Subject: Debian / SE/Linux - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193664 In-Reply-To: <20040530112322.GA5232@lkcl.net> References: <20040530092358.GR2851@lkcl.net> <40B9ACD8.30807@mindrot.org> <20040530112322.GA5232@lkcl.net> Message-ID: <40B9CA0F.8030803@mindrot.org> Luke Kenneth Casson Leighton wrote: > On Sun, May 30, 2004 at 07:43:52PM +1000, Damien Miller wrote: >>but it doesn't seem to do much at all - the only code change is the >>marking of a ssh-agent fd to be close-on-exec. > > that, and the inclusion of pam_selinux.so as a required session > plugin, and the setting of a security context on the DSA and > RSA keys in sshd initialisation (a redhat rpm thing?) I think we should leave these changes for the vendors of SELinux enabled distributions. We want the current files to work for everyone. The files in contrib/redhat get synced from time to time. so they will pick up changes in their distribution (eventually). >>Is this the patch that you are referring to? > > yes it is. > > the ssh-agent fd close-on-exec is actually a really important > security bug because otherwise you end up with an open file > descriptor being passed over to a process that should have no > rights or use for it. The FD in question is to /dev/null and closed anyway if it isn't dup'd to one of std{in.out,err} so I can't see how this achieves anything. > SE/Linux is really cool in that respect: the audit process > logged that this file handle was being passed over to a child > process, and the policy for ssh-agent said that that wasn't > allowed. > > cool, huh? :) Not in this case, no :) > [apparently, PAM has a similar bug in /sbin/unix_verify: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248310 > > but the debian maintainer for pam is being a bit of idiot > and won't look at it. sorry, mr hartmans, but it's bypass time, > and your comments _are_ a matter of public record, after all] Please don't drag SELinux fights onto our list, we have enough of our own. -d From lkcl at lkcl.net Sun May 30 22:35:07 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 30 May 2004 12:35:07 +0000 Subject: Debian / SE/Linux - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193664 In-Reply-To: <40B9CA0F.8030803@mindrot.org> References: <20040530092358.GR2851@lkcl.net> <40B9ACD8.30807@mindrot.org> <20040530112322.GA5232@lkcl.net> <40B9CA0F.8030803@mindrot.org> Message-ID: <20040530123507.GE5232@lkcl.net> On Sun, May 30, 2004 at 09:48:31PM +1000, Damien Miller wrote: > Luke Kenneth Casson Leighton wrote: > > On Sun, May 30, 2004 at 07:43:52PM +1000, Damien Miller wrote: > >>but it doesn't seem to do much at all - the only code change is the > >>marking of a ssh-agent fd to be close-on-exec. > > > > that, and the inclusion of pam_selinux.so as a required session > > plugin, and the setting of a security context on the DSA and > > RSA keys in sshd initialisation (a redhat rpm thing?) > > I think we should leave these changes for the vendors of SELinux > enabled distributions. We want the current files to work for everyone. hmm, *thinks*. ... redhat is going to SE/Linux "by default". ... debian probably isn't, so has to cater for both. ... therefore a separate mechanism is required - e.g. a package named openssh-selinux - which has one extra patch: to add in pam_session.so to /etc/pam.d/ssh. [ yuk! but hey, it's not for you to deal with. ] > The files in contrib/redhat get synced from time to time. so they will > pick up changes in their distribution (eventually). > > >>Is this the patch that you are referring to? > > > > yes it is. > > > > the ssh-agent fd close-on-exec is actually a really important > > security bug because otherwise you end up with an open file > > descriptor being passed over to a process that should have no > > rights or use for it. > > The FD in question is to /dev/null and closed anyway if it isn't > dup'd to one of std{in.out,err} so I can't see how this achieves > anything. well, i'd be remiss in not mentioning it to you: fortunately in this case it looks like it's covered. it'd be really helpful, however, if you _could_ apply that close-on-exec, because without it, it's necessary to add an audit "ignore" just for that file handle, which could come back and bite you later, or to constantly and forever apply that patch in all releases of an openssh'd selinux package. > > SE/Linux is really cool in that respect: the audit process > > logged that this file handle was being passed over to a child > > process, and the policy for ssh-agent said that that wasn't > > allowed. > > > > cool, huh? :) > > Not in this case, no :) :) > > [apparently, PAM has a similar bug in /sbin/unix_verify: > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248310 > > > > but the debian maintainer for pam is being a bit of idiot > > and won't look at it. sorry, mr hartmans, but it's bypass time, > > and your comments _are_ a matter of public record, after all] > > Please don't drag SELinux fights onto our list, we have enough of > our own. *lol*. ack. please ignore: it was intended for pam-list anyway. l. From lkcl at lkcl.net Sun May 30 23:00:07 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 30 May 2004 13:00:07 +0000 Subject: Debian / SE/Linux - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193664 In-Reply-To: <40B9CA0F.8030803@mindrot.org> References: <20040530092358.GR2851@lkcl.net> <40B9ACD8.30807@mindrot.org> <20040530112322.GA5232@lkcl.net> <40B9CA0F.8030803@mindrot.org> Message-ID: <20040530130007.GF5232@lkcl.net> On Sun, May 30, 2004 at 09:48:31PM +1000, Damien Miller wrote: > Luke Kenneth Casson Leighton wrote: > > On Sun, May 30, 2004 at 07:43:52PM +1000, Damien Miller wrote: > >>but it doesn't seem to do much at all - the only code change is the > >>marking of a ssh-agent fd to be close-on-exec. > > > > that, and the inclusion of pam_selinux.so as a required session > > plugin, and the setting of a security context on the DSA and > > RSA keys in sshd initialisation (a redhat rpm thing?) > > I think we should leave these changes for the vendors of SELinux > enabled distributions. We want the current files to work for everyone. hang about.... let me think: pam_selinux.so is patched into pam, now, and so would be there by default. i _believe_ that when SE/Linux is not enabled, then pam_selinux.so should have no effect. in fact, i have a system now where SE/Linux is not enabled, yet a patched pam that has pam_selinux has been installed, and i can log in fine. looking at the code, yes: is_selinux_enabled() indicating that selinux is not enabled, returns PAM_SUCCESS. so, basically, what that boils down to is that if you _do_ add the line session required pam_selinux.so, then on a non-SELinux system (which _will_ have a pam_selinux.so), nothing will break: everything will work unaffected and as expected. of course, this requires that the upstream pam maintainers incorporate pam_selinux.so. l. From mouring at etoh.eviladmin.org Mon May 31 03:57:27 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sun, 30 May 2004 12:57:27 -0500 (CDT) Subject: Debian / SE/Linux - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193664 In-Reply-To: <20040530123507.GE5232@lkcl.net> Message-ID: On Sun, 30 May 2004, Luke Kenneth Casson Leighton wrote: > > > the ssh-agent fd close-on-exec is actually a really important > > > security bug because otherwise you end up with an open file > > > descriptor being passed over to a process that should have no > > > rights or use for it. > > > > The FD in question is to /dev/null and closed anyway if it isn't > > dup'd to one of std{in.out,err} so I can't see how this achieves > > anything. > > well, i'd be remiss in not mentioning it to you: fortunately > in this case it looks like it's covered. > > it'd be really helpful, however, if you _could_ apply that > close-on-exec, because without it, it's necessary to add an > audit "ignore" just for that file handle, which could come > back and bite you later, or to constantly and forever apply > that patch in all releases of an openssh'd selinux package. > Why not just fix the auditing software to understand the fact that the FD is /dev/null? That would be the best solution for everyone. Since it would stops incorrect whining, and it doesn't require a useless hack where one is not needed. There is nothing worse than a whiny auditing tool that gives you crap output with a few pearls of useful information. =) - Ben From djm at mindrot.org Mon May 31 08:00:24 2004 From: djm at mindrot.org (Damien Miller) Date: Mon, 31 May 2004 08:00:24 +1000 Subject: Debian / SE/Linux - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193664 In-Reply-To: <20040530123507.GE5232@lkcl.net> References: <20040530092358.GR2851@lkcl.net> <40B9ACD8.30807@mindrot.org> <20040530112322.GA5232@lkcl.net> <40B9CA0F.8030803@mindrot.org> <20040530123507.GE5232@lkcl.net> Message-ID: <40BA5978.6070601@mindrot.org> Luke Kenneth Casson Leighton wrote: > it'd be really helpful, however, if you _could_ apply that > close-on-exec, because without it, it's necessary to add an > audit "ignore" just for that file handle, which could come > back and bite you later, or to constantly and forever apply > that patch in all releases of an openssh'd selinux package. Adding the close-on-exec would be incorrect: you would end up with one of std(in,out,err) closed rather than pointing to /dev/null upon exec. There have been security vulnerabilities in the past that have been caused by this state of affairs. Surely it would make more sense to fix the audit policy. -d From lkcl at lkcl.net Mon May 31 05:17:36 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 30 May 2004 19:17:36 +0000 Subject: Debian / SE/Linux - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193664 In-Reply-To: References: <20040530123507.GE5232@lkcl.net> Message-ID: <20040530191736.GF6144@lkcl.net> On Sun, May 30, 2004 at 12:57:27PM -0500, Ben Lindstrom wrote: > On Sun, 30 May 2004, Luke Kenneth Casson Leighton wrote: > > > > > the ssh-agent fd close-on-exec is actually a really important > > > > security bug because otherwise you end up with an open file > > > > descriptor being passed over to a process that should have no > > > > rights or use for it. > > > > > > The FD in question is to /dev/null and closed anyway if it isn't > > > dup'd to one of std{in.out,err} so I can't see how this achieves > > > anything. > > > > well, i'd be remiss in not mentioning it to you: fortunately > > in this case it looks like it's covered. > > > > it'd be really helpful, however, if you _could_ apply that > > close-on-exec, because without it, it's necessary to add an > > audit "ignore" just for that file handle, which could come > > back and bite you later, or to constantly and forever apply > > that patch in all releases of an openssh'd selinux package. > > > > Why not just fix the auditing software to understand the fact that the FD > is /dev/null? it's a good question, and one that i am (personally) not qualified to answer, however i know that the people on the selinux mailing list are (scott or russell). ... but you no doubt know that what you're asking is going to involve kernel modifications. bearing in mind that i don't fully appreciate all the issues, i would ask you to consider this: are you _really_ sure you want to ask for a special-case kernel-level hack to deal with opening /dev/null? and if the linux kernel developers noticed such an addition, how do you think they would react? the auditing is going on in the kernel, not in user-space, in one of these newfangled "security capabilities" modules. help help, does anyone know better than my flounderings as to what the issues are, here? l. p.s. if cc'ing to the openssh list, don't send _anything_ with html tags in it, even small code fragments like .sigs with less than a href blah blah greater than because their list server will reject your message. From markus at openbsd.org Mon May 31 18:59:56 2004 From: markus at openbsd.org (Markus Friedl) Date: Mon, 31 May 2004 10:59:56 +0200 Subject: Debian / SE/Linux - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193664 In-Reply-To: <20040530123507.GE5232@lkcl.net> References: <20040530092358.GR2851@lkcl.net> <40B9ACD8.30807@mindrot.org> <20040530112322.GA5232@lkcl.net> <40B9CA0F.8030803@mindrot.org> <20040530123507.GE5232@lkcl.net> Message-ID: <20040531085956.GA12991@folly> On Sun, May 30, 2004 at 12:35:07PM +0000, Luke Kenneth Casson Leighton wrote: > well, i'd be remiss in not mentioning it to you: fortunately > in this case it looks like it's covered. > > it'd be really helpful, however, if you _could_ apply that > close-on-exec, because without it, it's necessary to add an > audit "ignore" just for that file handle, which could come > back and bite you later, or to constantly and forever apply > that patch in all releases of an openssh'd selinux package. i think adding close-on-exec is wrong in this case.