From djm at mindrot.org Wed Jul 1 22:22:41 2009 From: djm at mindrot.org (Damien Miller) Date: Wed, 1 Jul 2009 22:22:41 +1000 (EST) Subject: openbsd-compat/getrrsetbyname.c: answer buffer size too large for EDNS0 and glibc In-Reply-To: <4A4962E1.40705@zip.com.au> References: <4A48494E.20901@hauke-lampe.de> <4A4962E1.40705@zip.com.au> Message-ID: On Tue, 30 Jun 2009, Darren Tucker wrote: > Hauke Lampe wrote: > > Hello. > > > > I have an issue with SSHFP lookups using "VerifyHostKeyDNS=yes" and > > "options edns0" in /etc/resolv.conf (glib >= 2.6). > > > > > > getrrsetbyname() calls res_query() with a maximum buffer size of 65536. > > The glibc resolver truncates this value to 16 bits, reducing the query's > > advertised buffer size to 0. > > > > BIND appears to ignore it while Unbound returns a server failure. > > > > glibc's source suggests that it should retry the query without EDNS0 but > > it does not. Maybe a timeout triggers earlier. > > > > OpenSSH then logs "DNS lookup error: general failure" and continues. > > > > I propose reducing ANSWER_BUFFER_SIZE to 65535. Of course, the > > stub-resolver should probably catch this kind of problem, too. > > Sounds reasonable to me. Any objections? No, but doesn't the glibc bug need to be fixed too? There is nothing in the res_query(3) documentation that specifies integer overflow of the length argument. -d From jakob at rfc.se Wed Jul 1 22:22:27 2009 From: jakob at rfc.se (Jakob Schlyter) Date: Wed, 1 Jul 2009 08:22:27 -0400 Subject: openbsd-compat/getrrsetbyname.c: answer buffer size too large for EDNS0 and glibc In-Reply-To: <4A48494E.20901@hauke-lampe.de> References: <4A48494E.20901@hauke-lampe.de> Message-ID: <7FEF6FF1-2961-45B4-86AA-9E8155725AB9@rfc.se> On 29 jun 2009, at 00.55, Hauke Lampe wrote: > I propose reducing ANSWER_BUFFER_SIZE to 65535. Of course, the > stub-resolver should probably catch this kind of problem, too. makes sense to me. jakob From mouring at eviladmin.org Thu Jul 2 13:57:52 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Wed, 1 Jul 2009 22:57:52 -0500 Subject: Bug #1129 (umask for internal-sftp) or fixing bug #1599 ? In-Reply-To: <7FEF6FF1-2961-45B4-86AA-9E8155725AB9@rfc.se> References: <4A48494E.20901@hauke-lampe.de> <7FEF6FF1-2961-45B4-86AA-9E8155725AB9@rfc.se> Message-ID: Is part of the sftp-server/sftp improvements happening this summer including the -u feature for setting the umask? Or looking at #1599? I've just ran into this case myself where either bug would make things a bit cleaner than running two sshds since I need a umask set for sftp and chroot ability. - Ben *https://bugzilla.mindrot.org/show_bug.cgi?id=1229 From deepak.pandey07 at gmail.com Fri Jul 3 18:17:57 2009 From: deepak.pandey07 at gmail.com (deepak pandey) Date: Fri, 3 Jul 2009 13:47:57 +0530 Subject: [Query :] SSH support for sun-netra x4250 ILOM Message-ID: <516f57eb0907030117x49e24e12n635297989a242c97@mail.gmail.com> Hi, I am not able to execute the commands on ILOM using ssh . Have a look below screenshot. Can you help me in creating SSH session with ILOM . root at localhost ~]# ssh root at 10.255.17.102 "show /SYS" Password: shell: Invalid credentials But directly i am able to connect ILOM using ssh . Regards, Deepak From list+opensshdev at hauke-lampe.de Sat Jul 4 01:47:54 2009 From: list+opensshdev at hauke-lampe.de (Hauke Lampe) Date: Fri, 03 Jul 2009 17:47:54 +0200 Subject: openbsd-compat/getrrsetbyname.c: answer buffer size too large for EDNS0 and glibc In-Reply-To: References: <4A48494E.20901@hauke-lampe.de> <4A4962E1.40705@zip.com.au> Message-ID: <4A4E282A.40904@hauke-lampe.de> Damien Miller wrote: > No, but doesn't the glibc bug need to be fixed too? There is nothing in > the res_query(3) documentation that specifies integer overflow of the > length argument. I agree. If larger buffers are allowed in res_* arguments, the library should cap EDNS0 buffer size at 65535. Until a fix for this reaches main distributions, getrrsetbyname should work around it, though, IMHO. I took this to the glibc maintainer and Ubuntu: http://sources.redhat.com/bugzilla/show_bug.cgi?id=10360 https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/395196 Hauke. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From peter at stuge.se Sat Jul 4 04:04:51 2009 From: peter at stuge.se (Peter Stuge) Date: Fri, 3 Jul 2009 20:04:51 +0200 Subject: [Query :] SSH support for sun-netra x4250 ILOM In-Reply-To: <516f57eb0907030117x49e24e12n635297989a242c97@mail.gmail.com> References: <516f57eb0907030117x49e24e12n635297989a242c97@mail.gmail.com> Message-ID: <20090703180451.4720.qmail@stuge.se> deepak pandey wrote: > I am not able to execute the commands on ILOM using ssh . Have a > look below screenshot. Can you help me in creating SSH session > with ILOM . > > > root at localhost ~]# ssh root at 10.255.17.102 "show /SYS" > Password: > shell: Invalid credentials > > But directly i am able to connect ILOM using ssh . Try including -t in your ssh command: ssh -t root at 10.255.17.102 "show /SYS" //Peter From tpikonen at gmail.com Sun Jul 5 04:17:44 2009 From: tpikonen at gmail.com (Teemu Ikonen) Date: Sat, 4 Jul 2009 20:17:44 +0200 Subject: ChrootDirectory on a per key basis In-Reply-To: <97fdf2d70811131147j78b7ebf8kfe5d8e9118e82baa@mail.gmail.com> References: <49049595.9060404@gmail.com> <97fdf2d70811131147j78b7ebf8kfe5d8e9118e82baa@mail.gmail.com> Message-ID: <97fdf2d70907041117g300edc72p580eb4bf29e4810c@mail.gmail.com> Hi, Some months ago I posted a patch to sftp-server which allows restriction of the sftp access to a subdirectory with a command line parameter (see below). I've now put the code for the patched sftp-server to gitorious for people who are interested (if any :). The project is at http://gitorious.org/jsftp-server and also contains a branch for Debian packaging, for easy installation to Debian and Ubuntu. Teemu On Thu, Nov 13, 2008 at 9:47 PM, Teemu Ikonen wrote: > On Sun, Oct 26, 2008 at 5:06 PM, Teemu Ikonen wrote: >> Damien Miller wrote: >>> No, letting users chroot to arbitrary directories introduces >>> serious security problems. Think about hard-linking /bin/su into >>> a chroot on the same filesystem where an attacker has filled in >>> a friendly /etc/passwd. >> >> OK, so adding chrootdir option to authorized keys is a bad idea. >> >> Another way to achieve my objective, which is additional sftp file access >> restrictions to connections authorized with certain keys, would be to modify >> sftp-server to accept a directory parameter. The authorized_keys could then >> have 'command="sftp-server -d /home/user/stuff"' option to restrict access >> to /home/user/stuff. > > Hi again, > > I implemented this in sftp-server.c, see the attached patch. The > access restriction is made by checking every received file argument > with a modified version of realpath() (named fakepath), which resolves > the given file name to a real path and fails if this path leads > outside of the directory given in the command line argument. > > Comments on the patch (security and otherwise) would be very much welcome. > > Teemu > From vinschen at redhat.com Tue Jul 7 20:13:54 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 7 Jul 2009 12:13:54 +0200 Subject: [PATCH] contrib/cygwin/ssh-host-config: Improve support for automated updates Message-ID: <20090707101354.GM12258@calimero.vinschen.de> Hi, The below patch fixes two problems. The first one is a better support for automated scripts. The old script had a logic problem when it came to asking the caller for the user account to use for the sshd service. The second is a problem in the usage of eval. Could somebody with checkin rights please apply the patch? Thanks, Corinna Index: contrib/cygwin/ssh-host-config =================================================================== RCS file: /cvs/openssh/contrib/cygwin/ssh-host-config,v retrieving revision 1.26 diff -u -p -r1.26 ssh-host-config --- contrib/cygwin/ssh-host-config 29 Jan 2009 20:40:30 -0000 1.26 +++ contrib/cygwin/ssh-host-config 7 Jul 2009 10:13:09 -0000 @@ -1,6 +1,6 @@ #!/bin/bash # -# ssh-host-config, Copyright 2000, 2001, 2002, 2003 Red Hat Inc. +# ssh-host-config, Copyright 2000-2009 Red Hat Inc. # # This file is part of the Cygwin port of OpenSSH. @@ -26,7 +26,9 @@ port_number=22 privsep_configured=no privsep_used=yes cygwin_value="" +user_account= password_value= +opt_force=no # ====================================================================== # Routine: create_host_keys @@ -287,6 +289,11 @@ install_service() { csih_inform "sshd requires. You need to have or to create a privileged" csih_inform "account. This script will help you do so." echo + + [ "${opt_force}" = "yes" ] && opt_f=-f + [ -n "${user_account}" ] && opt_u="-u ""${user_account}""" + csih_select_privileged_username ${opt_f} ${opt_u} sshd + if ! csih_create_privileged_user "${password_value}" then csih_error_recoverable "There was a serious problem creating a privileged user." @@ -316,12 +323,12 @@ install_service() { if [ -n "${csih_cygenv}" ] then - cygwin_env="-e CYGWIN=\"${csih_cygenv}\"" + cygwin_env=( -e "CYGWIN=${csih_cygenv}" ) fi if [ -z "${password}" ] then - if eval cygrunsrv -I sshd -d \"CYGWIN sshd\" -p /usr/sbin/sshd \ - -a "-D" -y tcpip ${cygwin_env} + if cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd \ + -a "-D" -y tcpip "${cygwin_env[@]}" then echo csih_inform "The sshd service has been installed under the LocalSystem" @@ -330,8 +337,8 @@ install_service() { csih_inform "will start automatically after the next reboot." fi else - if eval cygrunsrv -I sshd -d \"CYGWIN sshd\" -p /usr/sbin/sshd \ - -a "-D" -y tcpip ${cygwin_env} \ + if cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd \ + -a "-D" -y tcpip "${cygwin_env[@]}" \ -u "${run_service_as}" -w "${password}" then echo @@ -378,11 +385,13 @@ if [ "$PROGDIR" = "/etc/postinstall" ] then csih_auto_answer="no" csih_disable_color + opt_force=yes fi if [ -n "${SSH_HOST_CONFIG_AUTO_ANSWER_NO}" ] then csih_auto_answer="no" csih_disable_color + opt_force=yes fi # ====================================================================== @@ -407,10 +416,12 @@ do -y | --yes ) csih_auto_answer=yes + opt_force=yes ;; -n | --no ) csih_auto_answer=no + opt_force=yes ;; -c | --cygwin ) @@ -423,6 +434,11 @@ do shift ;; + -u | --user ) + user_account="$1" + shift + ;; + -w | --pwd ) password_value="$1" shift @@ -443,6 +459,7 @@ do echo " --no -n Answer all questions with \"no\" automatically." echo " --cygwin -c Use \"options\" as value for CYGWIN environment var." echo " --port -p sshd listens on port n." + echo " --user -u privileged user for service." echo " --pwd -w Use \"pwd\" as password for privileged user." echo " --privileged On Windows NT/2k/XP, require privileged user" echo " instead of LocalSystem for sshd service." @@ -489,7 +506,7 @@ then fi # Create /var/empty file used as chroot jail for privilege separation -csih_make_dir "${LOCALSTATEDIR}/empty" "Cannot create log directory." +csih_make_dir "${LOCALSTATEDIR}/empty" "Cannot create ${LOCALSTATEDIR}/empty directory." chmod 755 "${LOCALSTATEDIR}/empty" setfacl -m u:system:rwx "${LOCALSTATEDIR}/empty" -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From vinschen at redhat.com Tue Jul 7 20:57:16 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 7 Jul 2009 12:57:16 +0200 Subject: Read buffer size in clientloop.c Message-ID: <20090707105716.GN12258@calimero.vinschen.de> Hi, when trying to optimize socket transfer rates under Cygwin, it turned out that the underlying WinSock implementation is surprisingly sensitive to buffer sizes. The latest Cygwin from CVS is now setting the socket receive/send buffers (SO_RCVBUF/SO_SNDBUF) to 64K, rather than keeping them at their default values of 8K which thwarts data transfers a lot. While testing I still had the problem that for some reason the ssh read transfer rates were only a third up to a half of the write transfer rates. It turned out that the culprit was ssh itself. In clientloop.c, it defines read buffers of the size 8K. Setting them to 64K under Cygwin raises the read transfer rates comparable to the write rates. It occured to me that we talked about this already 3 years ago in a thread about HPN-SSH, just the performance numbers were different: http://marc.info/?l=openssh-unix-dev&m=114414372902485&w=2 So the question I have is again this: Would it be ok to raise the buffers in client_process_net_input() and client_process_input() to 64K, maybe only on Cygwin? Or to make the buffer sizes a configurable option? Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From dtucker at zip.com.au Tue Jul 7 21:53:37 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 7 Jul 2009 21:53:37 +1000 Subject: Read buffer size in clientloop.c In-Reply-To: <20090707105716.GN12258@calimero.vinschen.de> References: <20090707105716.GN12258@calimero.vinschen.de> Message-ID: <20090707115337.GA22534@gate.dtucker.net> On Tue, Jul 07, 2009 at 12:57:16PM +0200, Corinna Vinschen wrote: > when trying to optimize socket transfer rates under Cygwin, it turned > out that the underlying WinSock implementation is surprisingly sensitive > to buffer sizes. The latest Cygwin from CVS is now setting the socket > receive/send buffers (SO_RCVBUF/SO_SNDBUF) to 64K, rather than keeping > them at their default values of 8K which thwarts data transfers a lot. > > While testing I still had the problem that for some reason the ssh read > transfer rates were only a third up to a half of the write transfer > rates. It turned out that the culprit was ssh itself. In clientloop.c, > it defines read buffers of the size 8K. Setting them to 64K under > Cygwin raises the read transfer rates comparable to the write rates. > > It occured to me that we talked about this already 3 years ago in a > thread about HPN-SSH, just the performance numbers were different: > http://marc.info/?l=openssh-unix-dev&m=114414372902485&w=2 > > So the question I have is again this: > > Would it be ok to raise the buffers in client_process_net_input() and > client_process_input() to 64K, maybe only on Cygwin? Or to make the > buffer sizes a configurable option? If there's a measureable performance gain (which it sounds like there is) then I personally have no objection to making it a compile time option. Damien? Maybe something like this? Index: clientloop.c =================================================================== RCS file: /home/dtucker/openssh/cvs/openssh/clientloop.c,v retrieving revision 1.201 diff -u -p -r1.201 clientloop.c --- clientloop.c 5 Jul 2009 21:17:35 -0000 1.201 +++ clientloop.c 7 Jul 2009 11:38:33 -0000 @@ -636,7 +636,7 @@ static void client_process_net_input(fd_set *readset) { int len, cont = 0; - char buf[8192]; + char buf[SSH_IOBUFSZ]; /* * Read input from the server, and add any such data to the buffer of @@ -1129,7 +1129,7 @@ static void client_process_input(fd_set *readset) { int len; - char buf[8192]; + char buf[SSH_IOBUFSZ]; /* Read input from stdin. */ if (FD_ISSET(fileno(stdin), readset)) { Index: configure.ac =================================================================== RCS file: /home/dtucker/openssh/cvs/openssh/configure.ac,v retrieving revision 1.420 diff -u -p -r1.420 configure.ac --- configure.ac 16 Jun 2009 06:11:02 -0000 1.420 +++ configure.ac 7 Jul 2009 11:41:04 -0000 @@ -442,6 +442,7 @@ int main(void) { exit(0); } AC_DEFINE(DISABLE_FD_PASSING, 1, [Define if your platform needs to skip post auth file descriptor passing]) + AC_DEFINE(SSH_IOBUFSZ, 65536, [Windows is sensitive to read buffer size]) ;; *-*-dgux*) AC_DEFINE(IP_TOS_IS_BROKEN, 1, Index: defines.h =================================================================== RCS file: /home/dtucker/openssh/cvs/openssh/defines.h,v retrieving revision 1.155 diff -u -p -r1.155 defines.h --- defines.h 16 Jun 2009 06:11:02 -0000 1.155 +++ defines.h 7 Jul 2009 11:39:15 -0000 @@ -749,4 +749,8 @@ struct winsize { #define INET6_ADDRSTRLEN 46 #endif +#ifndef SSH_IOBUFSZ +# define SSH_IOBUFSZ 8192 +#endif + #endif /* _DEFINES_H */ -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Tue Jul 7 22:56:28 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 7 Jul 2009 14:56:28 +0200 Subject: Non-standard conformant usage of ctype functions Message-ID: <20090707125628.GP12258@calimero.vinschen.de> Hi, Per the definitions of the ctype functions in POSIX-1.2008 "the c argument is an int, the value of which the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF. If the argument has any other value, the behavior is undefined." For obvious reasons this results in problems if you use signed char variables as parameters in calls to the ctype functions, if you support other charsets than ASCII. In theory OpenSSH has this problem as well. With a few exceptions it uses (signed) char values throughout in calls to ctype functions like isspace. However, given that OpenSSH doesn't call setlocale, the locale is always "C" and the chance that the ctype functions return a wrong value is rather tiny. Nevertheless, for the sake of correctness, and to avoid potential problems in some later, locale-aware version of OpenSSH, I'd like to propose to change all calls of ctype functions in OpenSSH from, for instance: if (isupper(c)) c = (char)tolower(c); to: if (isupper((u_char)c)) c = (char)tolower((u_char)c); If that's ok with you, I'd create a matching patch. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From vdanen at redhat.com Wed Jul 8 03:14:59 2009 From: vdanen at redhat.com (Vincent Danen) Date: Tue, 7 Jul 2009 11:14:59 -0600 Subject: Does anyone know anything about this "0-day" ssh vulnerability? Message-ID: <20090707171459.GN4962@redhat.com> Hi all. I've looked at the archives and it seems to be quiet regarding this supposed "0-day" openssh vulnerability and I'm wondering if anyone here may have some insight or further information regarding it. We've been monitoring things and the amount of speculative info flying around is incredible. Some claim it's the CPNI-957037 issue, thus affecting <5.2, others are indicating it's the unsafe signal handler issue fixed in 4.4. Granted, Red Hat does ship with a patched 4.3, but we have corrected all issues that we know to have existed with 4.3. And the veracity of the supposed "logs" are sketchy at best. Thanks. -- Vincent Danen / Red Hat Security Response Team From openssh at roumenpetrov.info Wed Jul 8 05:46:54 2009 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Tue, 07 Jul 2009 22:46:54 +0300 Subject: Non-standard conformant usage of ctype functions In-Reply-To: <20090707125628.GP12258@calimero.vinschen.de> References: <20090707125628.GP12258@calimero.vinschen.de> Message-ID: <4A53A62E.9080600@roumenpetrov.info> Corinna Vinschen wrote: > Hi, > > Per the definitions of the ctype functions in POSIX-1.2008 "the c > argument is an int, the value of which the application shall ensure is a > character representable as an unsigned char or equal to the value of the > macro EOF. If the argument has any other value, the behavior is > undefined." > > For obvious reasons this results in problems if you use signed char > variables as parameters in calls to the ctype functions, if you support > other charsets than ASCII. > In theory OpenSSH has this problem as well. With a few exceptions it > uses (signed) char values throughout in calls to ctype functions like > isspace. No idea why is not reported. > However, given that OpenSSH doesn't call setlocale, the locale is always > "C" and the chance that the ctype functions return a wrong value is rather > tiny. Nevertheless, for the sake of correctness, and to avoid potential > problems in some later, locale-aware version of OpenSSH, I'd like to > propose to change all calls of ctype functions in OpenSSH from, for > instance: > > if (isupper(c)) > c = (char)tolower(c); > > to: > > if (isupper((u_char)c)) > c = (char)tolower((u_char)c); I'm using in my X.509 certificate support patch following macro: #ifndef ISSPACE # define ISSPACE(ch) (isspace((int)(unsigned char)(ch))) #endif to avoid problem with signed strings(characters). If I remember well affected platform is solaris 8(?). I think that other functions like isalpha, isdigit are impacted too. > If that's ok with you, I'd create a matching patch. May be a patch based on macros like ISPACE above, but the question is why to patch code if it not reported a issue ? > Corinna > Roumen From vinschen at redhat.com Wed Jul 8 18:24:34 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 8 Jul 2009 10:24:34 +0200 Subject: Non-standard conformant usage of ctype functions In-Reply-To: <4A53A62E.9080600@roumenpetrov.info> References: <20090707125628.GP12258@calimero.vinschen.de> <4A53A62E.9080600@roumenpetrov.info> Message-ID: <20090708082434.GA14568@calimero.vinschen.de> On Jul 7 22:46, Roumen Petrov wrote: > Corinna Vinschen wrote: >> For obvious reasons this results in problems if you use signed char >> variables as parameters in calls to the ctype functions, if you support >> other charsets than ASCII. >> In theory OpenSSH has this problem as well. With a few exceptions it >> uses (signed) char values throughout in calls to ctype functions like >> isspace. > > No idea why is not reported. It's reported when using the latest Cygwin. The underlying C library, newlib, recently changed the ctype.h macros so that a -Wall warning "array subscript has type 'char'" gets triggered. >> However, given that OpenSSH doesn't call setlocale, the locale is always >> "C" and the chance that the ctype functions return a wrong value is rather >> tiny. Nevertheless, for the sake of correctness, and to avoid potential >> problems in some later, locale-aware version of OpenSSH, I'd like to >> propose to change all calls of ctype functions in OpenSSH from, for >> instance: >> [...] > I think that other functions like isalpha, isdigit are impacted too. All isFOO functions are affected, as well as toupper/tolower. >> If that's ok with you, I'd create a matching patch. > May be a patch based on macros like ISPACE above, but the question is > why to patch code if it not reported a issue ? That's what I was trying to explain above. However, if the OpenSSH maintainers think this is not worth a fix, I let it go. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From des at des.no Wed Jul 8 20:27:31 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed, 08 Jul 2009 12:27:31 +0200 Subject: Does anyone know anything about this "0-day" ssh vulnerability? In-Reply-To: <20090707171459.GN4962@redhat.com> (Vincent Danen's message of "Tue, 7 Jul 2009 11:14:59 -0600") References: <20090707171459.GN4962@redhat.com> Message-ID: <861vorbhbg.fsf@ds4.des.no> Vincent Danen writes: > Hi all. I've looked at the archives and it seems to be quiet regarding > this supposed "0-day" openssh vulnerability and I'm wondering if anyone > here may have some insight or further information regarding it. Not really: http://isc.sans.org/diary.html?storyid=6742 DES -- Dag-Erling Sm?rgrav - des at des.no From djm at mindrot.org Wed Jul 8 21:31:24 2009 From: djm at mindrot.org (Damien Miller) Date: Wed, 8 Jul 2009 21:31:24 +1000 (EST) Subject: Does anyone know anything about this "0-day" ssh vulnerability? In-Reply-To: <20090707171459.GN4962@redhat.com> References: <20090707171459.GN4962@redhat.com> Message-ID: On Tue, 7 Jul 2009, Vincent Danen wrote: > Hi all. I've looked at the archives and it seems to be quiet regarding > this supposed "0-day" openssh vulnerability and I'm wondering if > anyone here may have some insight or further information regarding it. > > We've been monitoring things and the amount of speculative info flying > around is incredible. Some claim it's the CPNI-957037 issue, thus > affecting <5.2, others are indicating it's the unsafe signal handler > issue fixed in 4.4. > > Granted, Red Hat does ship with a patched 4.3, but we have corrected > all issues that we know to have existed with 4.3. And the veracity of > the supposed "logs" are sketchy at best. I don't have any non-public information. I have exchanged some emails with one of the victims of the alleged sshd 0day, but he was not able to provide any evidence that the attack was sshd-related. In particular, I spent some time analysing a packet trace that he provided, but it seems to consist of simple brute-force attacks. So, I'm not pursuaded that an 0day exists at all. The only evidence so far are some anonymous rumours and unverifiable intrusion transcripts. Speculating as to what an exploit, should it exist, might consist of: The two issues of note that have been fixed since openssh-4.3 are the aforementioned signal race (in 4.4) and a privsep signature verification weakness (in 4.5). I doubt that it is the race condition as not even Mark Dowd was able to make an working exploit from it. The privsep weakness could be used to escalate privilege out of some other unknown flaw, but it would not grant access by itself. It is certainly not the CBC mode side-channel attack reported by CPNI; it is only useful to a MITM under quite tight constraints and wouldn't be useful to attack a server blindly. If the attack doesn't work against a more recent version of OpenSSH, then it is possible that we fixed it incidentally while making some other change or that we did not realise some bug as exploitable. I'm sure that someone sufficiently interested could crawl through the diffs from openssh-4.3 to 5.2 and cast a fresh set of eyes over each change - they might get the bragging rights of being the first to disclose an exploitable remote sshd bug in quite a few years :) -d From vdanen at redhat.com Thu Jul 9 07:13:56 2009 From: vdanen at redhat.com (Vincent Danen) Date: Wed, 8 Jul 2009 15:13:56 -0600 Subject: Does anyone know anything about this "0-day" ssh vulnerability? In-Reply-To: References: <20090707171459.GN4962@redhat.com> Message-ID: <20090708211356.GG4366@redhat.com> * [2009-07-08 21:31:24 +1000] Damien Miller wrote: >> Hi all. I've looked at the archives and it seems to be quiet regarding >> this supposed "0-day" openssh vulnerability and I'm wondering if >> anyone here may have some insight or further information regarding it. >> >> We've been monitoring things and the amount of speculative info flying >> around is incredible. Some claim it's the CPNI-957037 issue, thus >> affecting <5.2, others are indicating it's the unsafe signal handler >> issue fixed in 4.4. >> >> Granted, Red Hat does ship with a patched 4.3, but we have corrected >> all issues that we know to have existed with 4.3. And the veracity of >> the supposed "logs" are sketchy at best. > >I don't have any non-public information. I have exchanged some emails >with one of the victims of the alleged sshd 0day, but he was not able to >provide any evidence that the attack was sshd-related. In particular, I >spent some time analysing a packet trace that he provided, but it seems >to consist of simple brute-force attacks. That's what we were suspecting as well, based on looking at the public pcap dump that was noted. >So, I'm not pursuaded that an 0day exists at all. The only evidence so >far are some anonymous rumours and unverifiable intrusion transcripts. Ok, thanks for that. One particular hosting company seems to be tossing around "inside info" and development of a patch, and so on, which is making all of this worse. >Speculating as to what an exploit, should it exist, might consist of: > >The two issues of note that have been fixed since openssh-4.3 are the >aforementioned signal race (in 4.4) and a privsep signature verification >weakness (in 4.5). I doubt that it is the race condition as not even >Mark Dowd was able to make an working exploit from it. The privsep >weakness could be used to escalate privilege out of some other unknown >flaw, but it would not grant access by itself. > >It is certainly not the CBC mode side-channel attack reported by CPNI; >it is only useful to a MITM under quite tight constraints and wouldn't >be useful to attack a server blindly. > >If the attack doesn't work against a more recent version of OpenSSH, >then it is possible that we fixed it incidentally while making some >other change or that we did not realise some bug as exploitable. I'm >sure that someone sufficiently interested could crawl through the diffs >from openssh-4.3 to 5.2 and cast a fresh set of eyes over each change >- they might get the bragging rights of being the first to disclose an >exploitable remote sshd bug in quite a few years :) Thanks for all that info, Damien. Very much appreciated. -- Vincent Danen / Red Hat Security Response Team From helmut at subdivi.de Thu Jul 9 08:03:38 2009 From: helmut at subdivi.de (Helmut Grohne) Date: Thu, 9 Jul 2009 00:03:38 +0200 Subject: Feature request: "SetupCommand" invoked before connecting Message-ID: <20090708220337.GA10134@alf.mars> Hi, (I'm not subscribed to the list, so please CC me on reply.) I'd like to request adding a feature to OpenSSH: Task: ~~~~~ It is quite sometime useful to invoke a program prior to connecting to an ssh server. The most common use case will probably be port knocking. That is a small program sends certain packets to a server and the server reacts to this by unlocking the ssh port, which would be blocked otherwise to defend against brute force attacks. Solutions: ~~~~~~~~~~ 1) (Ab)using ProxyCommand. This is employed in some howtos on port knocking. It however has the disadvantage that TCPKeepAlive and some timeout options are no longer honoured. 2) Wrapping ssh. While this does not disable other options like above one has to create a second option parser for ssh. Furthermore configuration that belongs to ssh is now located somewhere else (not in .ssh/config). The approach may also fail when third party applications that invoke ssh reset $PATH. 3) Extending ssh itself using a new configuration item "SetupCommand": Sample Implementation: ~~~~~~~~~~~~~~~~~~~~~~ I propose adding a new configuration item "SetupCommand" for the ssh client software. It would accept a string that is treated exactly the same as LocalCommand. As with LocalCommand it should also be ignored when PermitLocalCommand is disabled. Otherwise the command should be executed right before connecting to the server. I created a patch against 5.1p1 and tested it (attached). What do you think about this: 1) Is option 3 the best approach or did I overlook something? 2) Is this useful enough to patch ssh? 3) Can this implementation be used or do we need something better? Thanks in advance Helmut -------------- next part -------------- A non-text attachment was scrubbed... Name: setupcommand.diff Type: text/x-diff Size: 3838 bytes Desc: not available URL: From djm at mindrot.org Thu Jul 9 13:54:18 2009 From: djm at mindrot.org (Damien Miller) Date: Thu, 9 Jul 2009 13:54:18 +1000 (EST) Subject: Feature request: "SetupCommand" invoked before connecting In-Reply-To: <20090708220337.GA10134@alf.mars> References: <20090708220337.GA10134@alf.mars> Message-ID: On Thu, 9 Jul 2009, Helmut Grohne wrote: > Sample Implementation: > ~~~~~~~~~~~~~~~~~~~~~~ > I propose adding a new configuration item "SetupCommand" for the ssh > client software. It would accept a string that is treated exactly the > same as LocalCommand. As with LocalCommand it should also be ignored > when PermitLocalCommand is disabled. Otherwise the command should be > executed right before connecting to the server. If you need to do work before a ssh session, why not just make a shell script and, optionally, alias ssh to point to your shell script? -d From noreply at netlogmail.com Thu Jul 9 15:51:44 2009 From: noreply at netlogmail.com (Muthu G) Date: Thu, 9 Jul 2009 15:51:44 +1000 (EST) Subject: Visit my Netlog profile Message-ID: <20090709055144.A1CDBC4C24@natsu.mindrot.org> Hey, I have created a Netlog profile with my pictures, videos, blogs and events and I want to add you as a friend so you can see it. You first need to register on Netlog! When you log in, you can create your own profile. Take a look: http://en.netlog.com/go/mailurl/type=invite_1&mailid=360945168&id=1&url=-L2dvL3JlZ2lzdGVyL2lkPTExNTc0MTY0OTgmaT10OTE_ Greetings, Muthu ---------------------------------------------------------------- Don't want to receive invitations from your friends anymore? http://en.netlog.com/go/mailurl/type=invite_1&mailid=360945168&id=2&url=-L2dvL25vbWFpbHMvaW52aXRlL2VtYWlsPS1iM0JsYm5OemFDMTFibWw0TFdSbGRrQnRhVzVrY205MExtOXlad19fJmNvZGU9MDM1Mjk2NTAmaWQ9MTE1NzQxNjQ5OCZpPXQ5Mg__ From Doris.CL.Wong at pccw.com Thu Jul 9 15:59:28 2009 From: Doris.CL.Wong at pccw.com (Wong, Doris CL) Date: Thu, 9 Jul 2009 13:59:28 +0800 Subject: FW: Quotation Request - OpenSSH Message-ID: <4E1A4933157A41429141AE7369A0AD830DDE499F@HKPCWM09.corphq.hk.pccw.com> Dear Sir, We would lik to subscribe the support for OpenSSH for a tender project. Please kindly advise the annual subscription plan (with details of SLA) & annual fee. For the price, is it determined by number of server? or number of CPU? or number of core? Shall we get quotation/support from you? or please advise the reseller contact. Since the tender will be closed next week, may we have your initial reply tomorrow. Thank you very much. Best Regards, Doris Wong Assistant Purchasing Manager Group Strategic Purchasing PCCW-HKT Ltd Tel : 852-2883 7206 | Fax : 852-2962 5076 From bert.wesarg at googlemail.com Thu Jul 9 17:12:01 2009 From: bert.wesarg at googlemail.com (Bert Wesarg) Date: Thu, 9 Jul 2009 09:12:01 +0200 Subject: [PATCH] ControlCommand: execute a command if no control socket is available In-Reply-To: <20090708220337.GA10134@alf.mars> References: <20090708220337.GA10134@alf.mars> Message-ID: <1247123521-24288-1-git-send-email-bert.wesarg@googlemail.com> On Thu, Jul 9, 2009 at 00:03, Helmut Grohne wrote: > Hi, > > I'd like to request adding a feature to OpenSSH: > > Task: > ~~~~~ > It is quite sometime useful to invoke a program prior to connecting to > an ssh server. The most common use case will probably be port knocking. > That is a small program sends certain packets to a server and the server > reacts to this by unlocking the ssh port, which would be blocked > otherwise to defend against brute force attacks. I have a similar task: I don't want my interactive ssh shell session or git/svn sessions to act as master processes, so that they may hang after I started a second session. So I would need to start a master process with 'ssh -nNfM' first and than my interactive session. And I would like to automate this. To solve this problem I propose and implemented this: A new ControlMaster mode named "command", which acts like "no", but if there is no existing control socket it executes the command given by ControlCommand. It has the substitutions like the LocalCommand and %s as the path of the control socket, additionally. The simpliest configuration would be: ControlMaster command ControlCommand "ssh -nNfM -p %p %u@%h" The patch removes also the redundant check in ssh_local_cmd() for the permit_local_command option, because all callsites check this in-front of the call. Signed-off-by: Bert Wesarg --- mux.c | 24 +++++++++++++++++++----- readconf.c | 15 +++++++++++++-- readconf.h | 3 +++ ssh.c | 40 +++++++++++++++++++++++++++++++++++----- sshconnect.c | 3 +-- 5 files changed, 71 insertions(+), 14 deletions(-) diff --git a/mux.c b/mux.c index 79f8376..f4a1e8a 100644 --- a/mux.c +++ b/mux.c @@ -280,14 +280,16 @@ muxserver_accept_control(void) switch (mux_command) { case SSHMUX_COMMAND_OPEN: if (options.control_master == SSHCTL_MASTER_ASK || - options.control_master == SSHCTL_MASTER_AUTO_ASK) + options.control_master == SSHCTL_MASTER_AUTO_ASK || + options.control_master == SSHCTL_MASTER_COMMAND_ASK) allowed = ask_permission("Allow shared connection " "to %s? ", host); /* continue below */ break; case SSHMUX_COMMAND_TERMINATE: if (options.control_master == SSHCTL_MASTER_ASK || - options.control_master == SSHCTL_MASTER_AUTO_ASK) + options.control_master == SSHCTL_MASTER_AUTO_ASK || + options.control_master == SSHCTL_MASTER_COMMAND_ASK) allowed = ask_permission("Terminate shared connection " "to %s? ", host); if (allowed) @@ -518,6 +520,10 @@ muxclient(const char *path) /* FALLTHROUGH */ case SSHCTL_MASTER_NO: break; + case SSHCTL_MASTER_COMMAND: + case SSHCTL_MASTER_COMMAND_ASK: + debug("command-mux: Start control command"); + break; default: return; } @@ -534,14 +540,22 @@ muxclient(const char *path) if ((sock = socket(PF_UNIX, SOCK_STREAM, 0)) < 0) fatal("%s socket(): %s", __func__, strerror(errno)); +retry: if (connect(sock, (struct sockaddr *)&addr, addr_len) == -1) { if (muxclient_command != SSHMUX_COMMAND_OPEN) { fatal("Control socket connect(%.100s): %s", path, strerror(errno)); } - if (errno == ENOENT) - debug("Control socket \"%.100s\" does not exist", path); - else { + if (errno == ENOENT) { + if (options.control_master != SSHCTL_MASTER_COMMAND || + options.control_command == NULL) { + debug("Control socket \"%.100s\" does not exist", path); + } else { + debug("Executing control command: %.500s", options.control_command); + if (!ssh_local_cmd(options.control_command)) + goto retry; + } + } else { error("Control socket connect(%.100s): %s", path, strerror(errno)); } diff --git a/readconf.c b/readconf.c index 53fc6c7..4d81a48 100644 --- a/readconf.c +++ b/readconf.c @@ -128,8 +128,9 @@ typedef enum { oEnableSSHKeysign, oRekeyLimit, oVerifyHostKeyDNS, oConnectTimeout, oAddressFamily, oGssAuthentication, oGssDelegateCreds, oServerAliveInterval, oServerAliveCountMax, oIdentitiesOnly, - oSendEnv, oControlPath, oControlMaster, oHashKnownHosts, - oTunnel, oTunnelDevice, oLocalCommand, oPermitLocalCommand, + oSendEnv, oControlPath, oControlMaster, oControlCommand, + oHashKnownHosts, oTunnel, oTunnelDevice, + oLocalCommand, oPermitLocalCommand, oVisualHostKey, oZeroKnowledgePasswordAuthentication, oDeprecated, oUnsupported } OpCodes; @@ -222,6 +223,7 @@ static struct { { "sendenv", oSendEnv }, { "controlpath", oControlPath }, { "controlmaster", oControlMaster }, + { "controlcommand", oControlCommand }, { "hashknownhosts", oHashKnownHosts }, { "tunnel", oTunnel }, { "tunneldevice", oTunnelDevice }, @@ -856,6 +858,10 @@ parse_int: value = SSHCTL_MASTER_ASK; else if (strcmp(arg, "autoask") == 0) value = SSHCTL_MASTER_AUTO_ASK; + else if (strcmp(arg, "command") == 0) + value = SSHCTL_MASTER_COMMAND; + else if (strcmp(arg, "commandask") == 0) + value = SSHCTL_MASTER_COMMAND_ASK; else fatal("%.200s line %d: Bad ControlMaster argument.", filename, linenum); @@ -863,6 +869,10 @@ parse_int: *intptr = value; break; + case oControlCommand: + charptr = &options->control_command; + goto parse_string; + case oHashKnownHosts: intptr = &options->hash_known_hosts; goto parse_flag; @@ -1057,6 +1067,7 @@ initialize_options(Options * options) options->num_send_env = 0; options->control_path = NULL; options->control_master = -1; + options->control_command = NULL; options->hash_known_hosts = -1; options->tun_open = -1; options->tun_local = -1; diff --git a/readconf.h b/readconf.h index 8fb3a85..a3de419 100644 --- a/readconf.h +++ b/readconf.h @@ -112,6 +112,7 @@ typedef struct { char *control_path; int control_master; + char *control_command; int hash_known_hosts; @@ -130,6 +131,8 @@ typedef struct { #define SSHCTL_MASTER_AUTO 2 #define SSHCTL_MASTER_ASK 3 #define SSHCTL_MASTER_AUTO_ASK 4 +#define SSHCTL_MASTER_COMMAND 5 +#define SSHCTL_MASTER_COMMAND_ASK 6 void initialize_options(Options *); void fill_default_options(Options *); diff --git a/ssh.c b/ssh.c index 9613468..95aa693 100644 --- a/ssh.c +++ b/ssh.c @@ -212,6 +212,7 @@ main(int ac, char **av) extern char *optarg; struct servent *sp; Forward fwd; + char *host_arg; /* Ensure that fds 0, 1 and 2 are open or directed to /dev/null */ sanitise_stdfd(); @@ -548,6 +549,9 @@ main(int ac, char **av) if (!host) usage(); + /* safe the hostname given on the command-line */ + host_arg = host; + SSLeay_add_all_algorithms(); ERR_load_crypto_strings(); @@ -623,6 +627,9 @@ main(int ac, char **av) &options, 0); } + if (options.hostname != NULL) + host = options.hostname; + /* Fill configuration defaults. */ fill_default_options(&options); @@ -652,15 +659,12 @@ main(int ac, char **av) cp = options.local_command; options.local_command = percent_expand(cp, "d", pw->pw_dir, "h", options.hostname? options.hostname : host, - "l", thishost, "n", host, "r", options.user, "p", buf, + "l", thishost, "n", host_arg, "r", options.user, "p", buf, "u", pw->pw_name, (char *)NULL); debug3("expanded LocalCommand: %s", options.local_command); xfree(cp); } - if (options.hostname != NULL) - host = options.hostname; - /* force lowercase for hostkey matching */ if (options.host_key_alias != NULL) { for (p = options.host_key_alias; *p; p++) @@ -673,12 +677,12 @@ main(int ac, char **av) xfree(options.proxy_command); options.proxy_command = NULL; } + if (options.control_path != NULL && strcmp(options.control_path, "none") == 0) { xfree(options.control_path); options.control_path = NULL; } - if (options.control_path != NULL) { char thishost[NI_MAXHOST]; @@ -692,6 +696,32 @@ main(int ac, char **av) "r", options.user, "l", thishost, (char *)NULL); xfree(cp); } + + if (options.control_command != NULL && + strcmp(options.control_command, "none") == 0) { + xfree(options.control_command); + options.control_command = NULL; + } + if (options.control_command != NULL && options.control_path != NULL) { + char thishost[NI_MAXHOST]; + + if (gethostname(thishost, sizeof(thishost)) == -1) + fatal("gethostname: %s", strerror(errno)); + snprintf(buf, sizeof(buf), "%d", options.port); + cp = options.control_command; + options.control_command = percent_expand(cp, + "l", thishost, + "h", options.hostname ?: host, + "p", buf, + "r", options.user, + "n", host_arg, + "u", pw->pw_name, + "d", pw->pw_dir, + "s", options.control_path, + (char *)NULL); + xfree(cp); + } + if (muxclient_command != 0 && options.control_path == NULL) fatal("No ControlPath specified for \"-O\" command"); if (options.control_path != NULL) diff --git a/sshconnect.c b/sshconnect.c index 3e57e85..87f4a87 100644 --- a/sshconnect.c +++ b/sshconnect.c @@ -1157,8 +1157,7 @@ ssh_local_cmd(const char *args) pid_t pid; int status; - if (!options.permit_local_command || - args == NULL || !*args) + if (args == NULL || !*args) return (1); if ((shell = getenv("SHELL")) == NULL) -- tg: (6a49252..) bw/control-command (depends on: origin) From helmut at subdivi.de Thu Jul 9 17:16:10 2009 From: helmut at subdivi.de (Helmut Grohne) Date: Thu, 9 Jul 2009 09:16:10 +0200 Subject: Feature request: "SetupCommand" invoked before connecting In-Reply-To: References: <20090708220337.GA10134@alf.mars> Message-ID: <20090709071609.GA26793@alf.mars> On Thu, Jul 09, 2009 at 01:54:18PM +1000, Damien Miller wrote: > If you need to do work before a ssh session, why not just make a shell > script and, optionally, alias ssh to point to your shell script? This was listed as solution 2. An alias will especially not work with programs like scp (and I don't want to change every location I invoke ssh). One can still add a second ssh program in $PATH, but that would require parsing ssh options to find out which host is to be connected. Configuration that belongs to ssh would also be separated from ssh. All in all the proposed addition of a configuration item looks much cleaner to me. Still all mentioned solutions work including this one. Helmut From helmut at subdivi.de Thu Jul 9 17:29:08 2009 From: helmut at subdivi.de (Helmut Grohne) Date: Thu, 9 Jul 2009 09:29:08 +0200 Subject: [PATCH] ControlCommand: execute a command if no control socket is available In-Reply-To: <1247123521-24288-1-git-send-email-bert.wesarg@googlemail.com> References: <20090708220337.GA10134@alf.mars> <1247123521-24288-1-git-send-email-bert.wesarg@googlemail.com> Message-ID: <20090709072908.GB26793@alf.mars> On Thu, Jul 09, 2009 at 09:12:01AM +0200, Bert Wesarg wrote: > The simpliest configuration would be: > > ControlMaster command > ControlCommand "ssh -nNfM -p %p %u@%h" Interesting. It looks like one control master nastyness goes away. :-) Your patch could also be abused for my task by badly mixing ControlMaster configuration. However a separated approach should be much cleaner. > The patch removes also the redundant check in ssh_local_cmd() for the > permit_local_command option, because all callsites check this in-front of the > call. Good. I did not check that. > --- > mux.c | 24 +++++++++++++++++++----- > readconf.c | 15 +++++++++++++-- > readconf.h | 3 +++ > ssh.c | 40 +++++++++++++++++++++++++++++++++++----- > sshconnect.c | 3 +-- > 5 files changed, 71 insertions(+), 14 deletions(-) I'd suggest that your patch also changes ssh_config.5. It would have to be documented anyway before it can be applied, so you can do that beforehand. Helmut From bert.wesarg at googlemail.com Thu Jul 9 17:53:16 2009 From: bert.wesarg at googlemail.com (Bert Wesarg) Date: Thu, 9 Jul 2009 09:53:16 +0200 Subject: [PATCH] ControlCommand: execute a command if no control socket is available In-Reply-To: <20090709072908.GB26793@alf.mars> References: <20090708220337.GA10134@alf.mars> <1247123521-24288-1-git-send-email-bert.wesarg@googlemail.com> <20090709072908.GB26793@alf.mars> Message-ID: <36ca99e90907090053h6c87f1b9ye0518626a1d5ee3e@mail.gmail.com> On Thu, Jul 9, 2009 at 09:29, Helmut Grohne wrote: > On Thu, Jul 09, 2009 at 09:12:01AM +0200, Bert Wesarg wrote: >> The simpliest configuration would be: >> >> ControlMaster ?command >> ControlCommand "ssh -nNfM -p %p %u@%h" > > Interesting. It looks like one control master nastyness goes away. :-) I abuse this too, to mount also sshfs shares in the background ;-) Oh, and I blogged about this: http://www.nrtm.de/index.php/2009/05/26/connection-sharing-with-openssh/ > > Your patch could also be abused for my task by badly mixing > ControlMaster configuration. However a separated approach should be much > cleaner. > >> The patch removes also the redundant check in ssh_local_cmd() for the >> permit_local_command option, because all callsites check this in-front of the >> call. > > Good. I did not check that. > >> --- >> ?mux.c ? ? ? ?| ? 24 +++++++++++++++++++----- >> ?readconf.c ? | ? 15 +++++++++++++-- >> ?readconf.h ? | ? ?3 +++ >> ?ssh.c ? ? ? ?| ? 40 +++++++++++++++++++++++++++++++++++----- >> ?sshconnect.c | ? ?3 +-- >> ?5 files changed, 71 insertions(+), 14 deletions(-) > > I'd suggest that your patch also changes ssh_config.5. It would have to > be documented anyway before it can be applied, so you can do that > beforehand. Thats correct. I didn't mean to request inclusion, just for RFC (which I should have put into the subject) Bert > > Helmut > From peter at stuge.se Thu Jul 9 21:37:48 2009 From: peter at stuge.se (Peter Stuge) Date: Thu, 9 Jul 2009 13:37:48 +0200 Subject: Feature request: "SetupCommand" invoked before connecting In-Reply-To: <20090709071609.GA26793@alf.mars> References: <20090708220337.GA10134@alf.mars> <20090709071609.GA26793@alf.mars> Message-ID: <20090709113748.11085.qmail@stuge.se> Helmut Grohne wrote: > > If you need to do work before a ssh session, why not just make a > > shell script and, optionally, alias ssh to point to your shell > > script? > > This was listed as solution 2. An alias will especially not work > with programs like scp Why not? Note: Rename the original ssh binary and your script is the new ssh. //Peter From dtucker at zip.com.au Thu Jul 9 23:29:50 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 09 Jul 2009 23:29:50 +1000 Subject: FW: Quotation Request - OpenSSH In-Reply-To: <4E1A4933157A41429141AE7369A0AD830DDE499F@HKPCWM09.corphq.hk.pccw.com> References: <4E1A4933157A41429141AE7369A0AD830DDE499F@HKPCWM09.corphq.hk.pccw.com> Message-ID: <4A55F0CE.7020804@zip.com.au> Wong, Doris CL wrote: > We would lik to subscribe the support for OpenSSH for a tender project. > Please kindly advise the annual subscription plan (with details of SLA) & > annual fee. > > For the price, is it determined by number of server? or number of CPU? or > number of core? > > Shall we get quotation/support from you? or please advise the reseller > contact. I don't know of anyone offering support on OpenSSH on its own. Many vendors ship OpenSSH (or a derivative) with their products and some offer support of what they ship. If this is true for your platform(s) this is probably your best bet. Alternatively, one of the organisations offering support for OpenBSD may be able to help (see http://www.openbsd.org/support.html). -- 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 gpsteward at yahoo.com Thu Jul 9 23:24:55 2009 From: gpsteward at yahoo.com (Graham Steward) Date: Thu, 9 Jul 2009 06:24:55 -0700 (PDT) Subject: Hanging ssh sessions with openssh-5.1p1 and Solaris 8 & 10 Message-ID: <377685.66422.qm@web111505.mail.gq1.yahoo.com> Hi, Has anyone had any luck looking into this by any chance ? > On Mon, Aug 04, 2008 at 02:34:23PM -0400, Jeff Wieland wrote: >> Since we upgraded OpenSSH from 5.0p1 to 5.1p1 on our Solaris 8 boxes >> (I know, I know, we should upgrade or retire them...), we've started >> experiencing problems with slogin'ing into these boxes, running vi, >> and pasting text into the vi session. >> >> As long as we are pasting in less that 1024 characters it's fine. >> With >= 1024 characters, the session hangs. We've also seen this problem, which also affects Apple's Mac OS X OpenSSH 5.1p1 as well as all our Solaris 8,9 & 10 machines running 5.1p1 & 5.2p1 - but debian's OpenSSH 5.1 is fine. Running a truss against the parent sshd sits at: 20193: write(1, 0x00063078, 1) (sleeping...) Here's a load of output which I hope could help identify the cause(s) of this behaviour if anyone's interested. I ran a dtrace script against the sshd processes on the machine and noticed one reading & writing as I pasted in a large quantity of text to a file (/tmp/sshd.test_test): # ./opensnoop -n sshd UID PID CMD D BYTES FILE 12962 9649 sshd R 1056 12962 9649 sshd W 1022 /devices/pseudo/clone at 0:ptm 12962 9649 sshd R 480 12962 9649 sshd W 386 /devices/pseudo/clone at 0:ptm 12962 9649 sshd R 512 /devices/pseudo/clone at 0:ptm 12962 9649 sshd R 9712 12962 9649 sshd R 512 /devices/pseudo/clone at 0:ptm 12962 9649 sshd W 7313 /devices/pseudo/clone at 0:ptm A ptree of the vi shows all processes involved: # ptree 10879 1083 /usr/local/sbin/sshd 9626 /usr/local/sbin/sshd -R 9649 /usr/local/sbin/sshd -R 9651 -tcsh 10879 vi /tmp/sshd.test_test Running pfiles on pid 9649 we get: # pfiles 9649 9649: /usr/local/sbin/sshd -R Current rlimit: 256 file descriptors 0: S_IFCHR mode:0666 dev:356,0 ino:6815752 uid:0 gid:3 rdev:13,2 O_RDWR|O_LARGEFILE /devices/pseudo/mm at 0:null 1: S_IFCHR mode:0666 dev:356,0 ino:6815752 uid:0 gid:3 rdev:13,2 O_RDWR|O_LARGEFILE /devices/pseudo/mm at 0:null 2: S_IFCHR mode:0666 dev:356,0 ino:6815752 uid:0 gid:3 rdev:13,2 O_RDWR|O_LARGEFILE /devices/pseudo/mm at 0:null 3: S_IFDOOR mode:0444 dev:365,0 ino:92 uid:0 gid:0 size:0 O_RDONLY|O_LARGEFILE FD_CLOEXEC door to nscd[2394] /var/run/name_service_door 4: S_IFIFO mode:0000 dev:354,0 ino:16183814 uid:12962 gid:4640 size:0 O_RDWR|O_NONBLOCK FD_CLOEXEC 5: S_IFSOCK mode:0666 dev:363,0 ino:2848 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(0.0.192.80) sockname: AF_INET xxx.yyy.10.222 port: 22 peername: AF_INET xxx.yyy.12.20 port: 50166 6: S_IFIFO mode:0000 dev:354,0 ino:16183814 uid:12962 gid:4640 size:0 O_RDWR|O_NONBLOCK FD_CLOEXEC 7: S_IFSOCK mode:0666 dev:363,0 ino:3489 uid:0 gid:0 size:0 O_RDWR FD_CLOEXEC SOCK_STREAM SO_SNDBUF(16384),SO_RCVBUF(5120) sockname: AF_UNIX 8: S_IFCHR mode:0000 dev:356,0 ino:56458 uid:0 gid:0 rdev:23,9 O_RDWR|O_NONBLOCK|O_NOCTTY|O_LARGEFILE /devices/pseudo/clone at 0:ptm 10: S_IFCHR mode:0000 dev:356,0 ino:56458 uid:0 gid:0 rdev:23,9 O_RDWR|O_NONBLOCK|O_NOCTTY|O_LARGEFILE /devices/pseudo/clone at 0:ptm 11: S_IFCHR mode:0000 dev:356,0 ino:56458 uid:0 gid:0 rdev:23,9 O_RDWR|O_NONBLOCK|O_NOCTTY|O_LARGEFILE /devices/pseudo/clone at 0:ptm Other process pfiles: # pfiles 9626 9626: /usr/local/sbin/sshd -R Current rlimit: 256 file descriptors 0: S_IFCHR mode:0666 dev:356,0 ino:6815752 uid:0 gid:3 rdev:13,2 O_RDONLY|O_LARGEFILE /devices/pseudo/mm at 0:null 1: S_IFCHR mode:0666 dev:356,0 ino:6815752 uid:0 gid:3 rdev:13,2 O_RDWR|O_LARGEFILE /devices/pseudo/mm at 0:null 2: S_IFCHR mode:0666 dev:356,0 ino:6815752 uid:0 gid:3 rdev:13,2 O_RDWR|O_LARGEFILE /devices/pseudo/mm at 0:null 3: S_IFDOOR mode:0444 dev:365,0 ino:92 uid:0 gid:0 size:0 O_RDONLY|O_LARGEFILE FD_CLOEXEC door to nscd[2394] /var/run/name_service_door 4: S_IFCHR mode:0000 dev:356,0 ino:56458 uid:0 gid:0 rdev:23,9 O_RDWR|O_NONBLOCK|O_NOCTTY|O_LARGEFILE /devices/pseudo/clone at 0:ptm 5: S_IFSOCK mode:0666 dev:363,0 ino:2848 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(0.0.192.80) sockname: AF_INET xxx.yyy.10.222 port: 22 peername: AF_INET xxx.yyy.12.20 port: 50166 6: S_IFSOCK mode:0666 dev:363,0 ino:5314 uid:0 gid:0 size:0 O_RDWR FD_CLOEXEC SOCK_STREAM SO_SNDBUF(16384),SO_RCVBUF(5120) sockname: AF_UNIX # pfiles 10879 10879: vi /tmp/sshd.test_test Current rlimit: 256 file descriptors 0: S_IFCHR mode:0620 dev:356,0 ino:12582934 uid:12962 gid:7 rdev:24,9 O_RDWR|O_NOCTTY|O_LARGEFILE /devices/pseudo/pts at 0:9 1: S_IFCHR mode:0620 dev:356,0 ino:12582934 uid:12962 gid:7 rdev:24,9 O_RDWR|O_NOCTTY|O_LARGEFILE /devices/pseudo/pts at 0:9 2: S_IFCHR mode:0620 dev:356,0 ino:12582934 uid:12962 gid:7 rdev:24,9 O_RDWR|O_NOCTTY|O_LARGEFILE /devices/pseudo/pts at 0:9 3: S_IFREG mode:0600 dev:85,0 ino:42979 uid:12962 gid:4640 size:24576 O_RDWR|O_CREAT|O_EXCL /var/tmp/Exxka4pv Nothing makes it into the temp file. Most of it (depending on size) shows up in a truss of the sshd process 9649, but never makes it any further. Thanks in advance, Graham Darren Tucker wrote: > On Mon, Aug 04, 2008 at 02:34:23PM -0400, Jeff Wieland wrote: >> Since we upgraded OpenSSH from 5.0p1 to 5.1p1 on our Solaris 8 boxes >> (I know, I know, we should upgrade or retire them...), we've started >> experiencing problems with slogin'ing into these boxes, running vi, >> and pasting text into the vi session. >> >> As long as we are pasting in less that 1024 characters it's fine. >> With >= 1024 characters, the session hangs. > > Do you know if the problem occurs on the client or server side? ie if > you use an older client with a newer server (and vice versa) does the > problem occur? It's the server side. It still happens if you use the 5.0p1 client, and it also happens with the SecureCRT client. >> If you run "/usr/ucb/lptest 72 23 | cat -n" in one window, and >> then cut paste up to the "V" on line 13, things work as expected. >> If you include the "W" on the line 13, the vi session will hang >> with none of characters that are being pasted showing up. >> >> We've been building OpenSSH with Sun Studio 11 -- I tried building >> it with GNU-CC 3.4.4 with the same results. We also link against >> a locally built zlib, since Solaris 8 doesn't have zlib 1.2.3. >> And we've used OpenSSL 0.9.8g and 0.9.8h with the same results. >> >> We also tried building OpenSSH 5.1p1 on our Solaris 10 boxes using >> Sun Studio 12, and we also get the hangs there. The client doesn't >> seem to matter -- we've seen it OpenSSH 5.1p1 from both Solaris >> and Slackware Linux, and also from SecureCRT. >> >> I have not been able to get anything useful from running sshd in >> debug mode (at least, not that I recognize as useful :-) ). > > Well you could post it, someone else might recognise someting :-) I'll see if I can get this done tomorrow. It's a crazy couple of weeks right now... > Some versions of AIX have bugs in the tty drivers that prevent largish > writes from working correctly. Pehaps Solaris has something similar > (although I can't imagine why it's only started recently). > > You could try the patch below to test this theory. > > Index: channels.c > =================================================================== > RCS file: /usr/local/src/security/openssh/cvs/openssh/channels.c,v > retrieving revision 1.273 > diff -u -p -r1.273 channels.c > --- channels.c 16 Jul 2008 12:42:06 -0000 1.273 > +++ channels.c 5 Aug 2008 01:08:22 -0000 > @@ -1578,11 +1578,10 @@ channel_handle_wfd(Channel *c, fd_set *r > } > return 1; > } > -#ifdef _AIX > + > /* XXX: Later AIX versions can't push as much data to tty */ > if (compat20 && c->wfd_isatty) > - dlen = MIN(dlen, 8*1024); > -#endif > + dlen = MIN(dlen, 1024); > > len = write(c->wfd, buf, dlen); > if (len < 0 && > OK -- I can try this too. But it isn't necessary with the 5.0p1 sshd, so I'm thinking that something changed w.r.t. OpenSSH. -- From noah.williamsson at gmail.com Fri Jul 10 03:21:00 2009 From: noah.williamsson at gmail.com (noah williamsson) Date: Thu, 9 Jul 2009 19:21:00 +0200 Subject: [PATCH] Allow binding to a local port (OpenSSH 5.2) Message-ID: OpenSSH supports the -b bind_address argument for binding to a local IP address when connecting to a remote host. It's however currently not possible to specify a local port to bind to, something I've found useful at several occasions. Below is an unified diff that introduces the [-B bind_port] option to ssh(1) and a ssh_config(5) style option "BindPort bind_port". This allows for binding the clientside programs to a specified local port when outgoing connections are made. Note: I didn't bother updating the man pages at this stage but I could if it sounds interesting. The patch is based on OpenSSH 5.2p1 but applies to OpenSSH 5.2 too. I've found this patch working on decent releases of Ubuntu aswell as Mac OS X Leopard. Feedback is welcome. Please CC me if you reply to the list as I'm not subscribed. diff -ruN a/readconf.c b/readconf.c --- a/readconf.c 2009-02-14 06:28:21.000000000 +0100 +++ b/readconf.c 2009-07-09 18:24:09.000000000 +0200 @@ -123,7 +123,7 @@ oGlobalKnownHostsFile2, oUserKnownHostsFile2, oPubkeyAuthentication, oKbdInteractiveAuthentication, oKbdInteractiveDevices, oHostKeyAlias, oDynamicForward, oPreferredAuthentications, oHostbasedAuthentication, - oHostKeyAlgorithms, oBindAddress, oSmartcardDevice, + oHostKeyAlgorithms, oBindAddress, oBindPort, oSmartcardDevice, oClearAllForwardings, oNoHostAuthenticationForLocalhost, oEnableSSHKeysign, oRekeyLimit, oVerifyHostKeyDNS, oConnectTimeout, oAddressFamily, oGssAuthentication, oGssDelegateCreds, @@ -205,6 +205,7 @@ { "preferredauthentications", oPreferredAuthentications }, { "hostkeyalgorithms", oHostKeyAlgorithms }, { "bindaddress", oBindAddress }, + { "bindport", oBindPort }, #ifdef SMARTCARD { "smartcarddevice", oSmartcardDevice }, #else @@ -608,6 +609,10 @@ charptr = &options->bind_address; goto parse_string; + case oBindPort: + charptr = &options->bind_port; + goto parse_string; + case oSmartcardDevice: charptr = &options->smartcard_device; goto parse_string; @@ -1046,6 +1051,7 @@ options->log_level = SYSLOG_LEVEL_NOT_SET; options->preferred_authentications = NULL; options->bind_address = NULL; + options->bind_port = NULL; options->smartcard_device = NULL; options->enable_ssh_keysign = - 1; options->no_host_authentication_for_localhost = - 1; diff -ruN a/readconf.h b/readconf.h --- a/readconf.h 2009-02-14 06:28:21.000000000 +0100 +++ b/readconf.h 2009-07-09 18:17:36.000000000 +0200 @@ -84,6 +84,7 @@ char *user_hostfile2; char *preferred_authentications; char *bind_address; /* local socket address for connection to sshd */ + char *bind_port; /* local socket source port for connection to sshd */ char *smartcard_device; /* Smartcard reader device */ int verify_host_key_dns; /* Verify host key using DNS */ diff -ruN a/ssh.c b/ssh.c --- a/ssh.c 2009-02-14 06:28:21.000000000 +0100 +++ b/ssh.c 2009-07-09 18:35:12.000000000 +0200 @@ -179,10 +179,11 @@ usage(void) { fprintf(stderr, -"usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]\n" -" [-D [bind_address:]port] [-e escape_char] [-F configfile]\n" -" [-i identity_file] [-L [bind_address:]port:host:hostport]\n" -" [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]\n" +"usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-B bind_port ]\n" +" [-c cipher_spec] [-D [bind_address:]port] [-e escape_char]\n" +" [-F configfile] [-i identity_file]\n" +" [-L [bind_address:]port:host:hostport] [-l login_name]\n" +" [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]\n" " [-R [bind_address:]port:host:hostport] [-S ctl_path]\n" " [-w local_tun[:remote_tun]] [user@]hostname [command]\n" ); @@ -272,7 +273,7 @@ use_syslog = 0; again: - while ((opt = getopt(ac, av, "1246ab:c:e:fgi:kl:m:no:p:qstvx" + while ((opt = getopt(ac, av, "1246ab:B:c:e:fgi:kl:m:no:p:qstvx" "ACD:F:I:KL:MNO:PR:S:TVw:XYy")) != -1) { switch (opt) { case '1': @@ -514,6 +515,9 @@ case 'b': options.bind_address = optarg; break; + case 'B': + options.bind_port = optarg; + break; case 'F': config = optarg; break; diff -ruN a/sshconnect.c b/sshconnect.c --- a/sshconnect.c 2009-02-01 12:19:54.000000000 +0100 +++ b/sshconnect.c 2009-07-09 18:39:21.000000000 +0200 @@ -194,7 +194,7 @@ error("socket: %.100s", strerror(errno)); /* Bind the socket to an alternative local IP address */ - if (options.bind_address == NULL) + if (options.bind_address == NULL && options.bind_port == NULL) return sock; memset(&hints, 0, sizeof(hints)); @@ -202,7 +202,7 @@ hints.ai_socktype = ai->ai_socktype; hints.ai_protocol = ai->ai_protocol; hints.ai_flags = AI_PASSIVE; - gaierr = getaddrinfo(options.bind_address, NULL, &hints, &res); + gaierr = getaddrinfo(options.bind_address, options.bind_port, &hints, &res); if (gaierr) { error("getaddrinfo: %s: %s", options.bind_address, ssh_gai_strerror(gaierr)); @@ -210,7 +210,10 @@ return -1; } if (bind(sock, res->ai_addr, res->ai_addrlen) < 0) { - error("bind: %s: %s", options.bind_address, strerror(errno)); + error("bind: %s port %s: %s", + options.bind_address? options.bind_address: "0.0.0.0", + options.bind_port? options.bind_port: "0", + strerror(errno)); close(sock); freeaddrinfo(res); return -1; -- Best regards, Noah Williamsson From gerald.kallas at web.de Fri Jul 10 05:08:55 2009 From: gerald.kallas at web.de (Gerald Kallas) Date: Thu, 09 Jul 2009 21:08:55 +0200 Subject: =?iso-8859-15?Q?OpenSSH_on_MIPS_(Big_Endian)_uclibc_shows_empty_direct?= =?iso-8859-15?Q?ory_listing_when_connected_with_sftp?= Message-ID: <981040575@web.de> I've set up an OpenSSH on my MIPS (Big Endian) uclibc based system .. for development purposes on a qemu environment and for production an a settop box with real hardware. I experienced that sftp connected clients always get an empty directory listing. Same with OpenSSH at all as also with dropbear in combination with OpenSSH's sftp-server binary. More digging into details I checked the raw directory listing that is returned when requesting dir lsiting .. Command: ls Status: Listing directory / Listing: ?--------- 38 16893 15 1099511628032 Jan 1 1970 . Listing: ?--------- 38 16893 15 1099511628032 Jan 1 1970 .. Listing: ?--------- 19 16877 bin 1099511628032 Jan 1 1970 bin Listing: ?--------- 35 16877 adm 1099511628032 Jan 1 1970 dev Listing: ?--------- 18 16893 disk 1099511628032 Jan 1 1970 etc Listing: ?--------- 9 16893 adm 1099511628032 Jan 1 1970 lib Listing: ?--------- 194 16877 bin 1099511628032 Jan 1 1970 media Listing: ?--------- 28 16877 disk 1099511628032 Jan 1 1970 mnt Listing: ?--------- 199 41471 daemon 1099511628032 Jan 1 1970 opt Listing: ?--------- 1 16749 90 1099511628032 Jan 1 1970 proc Listing: ?--------- 39 41471 daemon 1099511628032 Jan 1 1970 root Listing: ?--------- 23 16877 bin 1099511628032 Jan 1 1970 sbin Listing: ?--------- 31 16893 sys 1099511628032 Jan 1 1970 share Listing: ?--------- 1 16877 9 1099511628032 Jan 1 1970 sys Listing: ?--------- 193 17407 sys 1099511628032 Jan 1 1970 tmp Listing: ?--------- 6 16877 7 1099511628032 Jan 1 1970 usr Listing: ?--------- 22 16877 sys 1099511628032 Jan 1 1970 var It seems that the listing is incomplete (e.g. missing permissions, file size etc.). I wonder whether this is a behaviour especially on MIPS uclibc platform (on Ubuntu it works correctly for example). Regards - catshout From vinschen at redhat.com Fri Jul 10 19:33:45 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 10 Jul 2009 11:33:45 +0200 Subject: Read buffer size in clientloop.c In-Reply-To: <20090707115337.GA22534@gate.dtucker.net> References: <20090707105716.GN12258@calimero.vinschen.de> <20090707115337.GA22534@gate.dtucker.net> Message-ID: <20090710093345.GG12258@calimero.vinschen.de> On Jul 7 21:53, Darren Tucker wrote: > On Tue, Jul 07, 2009 at 12:57:16PM +0200, Corinna Vinschen wrote: > > Would it be ok to raise the buffers in client_process_net_input() and > > client_process_input() to 64K, maybe only on Cygwin? Or to make the > > buffer sizes a configurable option? > > If there's a measureable performance gain (which it sounds like there is) > then I personally have no objection to making it a compile time option. > Damien? Maybe something like this? I tested this patch and it works fine for Cygwin. Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From dtucker at zip.com.au Mon Jul 13 11:39:21 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 13 Jul 2009 11:39:21 +1000 Subject: openbsd-compat/getrrsetbyname.c: answer buffer size too large for EDNS0 and glibc In-Reply-To: <4A4E282A.40904@hauke-lampe.de> References: <4A48494E.20901@hauke-lampe.de> <4A4962E1.40705@zip.com.au> <4A4E282A.40904@hauke-lampe.de> Message-ID: <4A5A9049.8080401@zip.com.au> Hauke Lampe wrote: > Damien Miller wrote: > >> No, but doesn't the glibc bug need to be fixed too? There is nothing in >> the res_query(3) documentation that specifies integer overflow of the >> length argument. > > I agree. If larger buffers are allowed in res_* arguments, the library > should cap EDNS0 buffer size at 65535. > > Until a fix for this reaches main distributions, getrrsetbyname should > work around it, though, IMHO. Thanks, your patch has been applied and will be in the next release. -- 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 helmut at subdivi.de Tue Jul 14 04:34:11 2009 From: helmut at subdivi.de (Helmut Grohne) Date: Mon, 13 Jul 2009 20:34:11 +0200 Subject: Feature request: "SetupCommand" invoked before connecting In-Reply-To: <20090708220337.GA10134@alf.mars> References: <20090708220337.GA10134@alf.mars> Message-ID: <20090713183410.GA29415@alf.mars> Please CC me in a reply, so I don't have to watch out for replies in mailing list archives. Peter Stuge wrote: > Why not? Note: Rename the original ssh binary and your script is the > new ssh. This does not work with an alias. Adding a wrapper still imposes the disadvantages mentioned before (second option parser, scattered configuration). Yes, it will work (around). All I'm saying is that there is a cleaner solution. Workarounds I've seen: * http://trac.cipherdyne.org/trac/fwknop/browser/fwknop/trunk/patches (would be obsoleted by this patch) * http://marc.info/?l=openssh-unix-dev&m=115303182509343&w=2 (cleaner solution by this patch) Feature also requested: * http://lists.mindrot.org/pipermail/openssh-unix-dev/2006-July/024463.html Helmut From leo.liou at centrify.com Tue Jul 14 06:11:46 2009 From: leo.liou at centrify.com (Leo Liou) Date: Mon, 13 Jul 2009 13:11:46 -0700 Subject: openssh conversation failure issue on HPUX Message-ID: <5EA7093E78F0A040A9EC6D6255CB3006A25CA6@exch-one.centrify.com> Openssh 5.0p1 on HPUX 11.23. Here is the message: Jun 15 13:21:28 a300sua0 sshd[10798]: pam_setcred: error Permission denied See http://www.docs.hp.com/en/T1471-90033/ch01s06.html We track the issue to sshpam_cleanup() which resets the conversation function pointer to sshpam_null_conv() before calling pam_setcred with PAM_DELETE_CRED. sshpam_null_conv() always just returns PAM_CONV_ERR. It seems HPUX PAM module then decided to call the conversation function (not sure why), and gets this error. Is it possible/advisable to (maybe use #ifdef) move the pam_set_item call to after the pam_setcred block? Thanks Leo Liou Not a shred of evidence exists in favor of the notion that life is serious ... From peter at stuge.se Tue Jul 14 08:47:09 2009 From: peter at stuge.se (Peter Stuge) Date: Tue, 14 Jul 2009 00:47:09 +0200 Subject: Feature request: "SetupCommand" invoked before connecting In-Reply-To: <20090713183410.GA29415@alf.mars> References: <20090708220337.GA10134@alf.mars> <20090713183410.GA29415@alf.mars> Message-ID: <20090713224709.15381.qmail@stuge.se> Hi again Helmut, (Please don't cc me, I am on the list.) Helmut Grohne wrote: > Please CC me in a reply, so I don't have to watch out for replies > in mailing list archives. No problem! > Peter Stuge wrote: > > Why not? Note: Rename the original ssh binary and your script is > > the new ssh. > > This does not work with an alias. How do you mean alias? Shell alias? No, that's not the wrapper script that was suggested, so it doesn't do the trick. > Adding a wrapper still imposes the disadvantages mentioned before > (second option parser, scattered configuration). Yes, it will work > (around). Sorry, I don't understand which disadvantages you refer to. The suggestion is to rename the original ssh binary from ssh to for example ssh.orig and then to create a script named ssh which does everything you need, before finally execing ssh.orig. //Peter From dkg at fifthhorseman.net Tue Jul 14 09:18:54 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 13 Jul 2009 19:18:54 -0400 Subject: Feature request: "SetupCommand" invoked before connecting In-Reply-To: <20090713224709.15381.qmail@stuge.se> References: <20090708220337.GA10134@alf.mars> <20090713183410.GA29415@alf.mars> <20090713224709.15381.qmail@stuge.se> Message-ID: <4A5BC0DE.70901@fifthhorseman.net> On 07/13/2009 06:47 PM, Peter Stuge wrote: > Helmut Grohne wrote: >> Adding a wrapper still imposes the disadvantages mentioned before >> (second option parser, scattered configuration). Yes, it will work >> (around). > > Sorry, I don't understand which disadvantages you refer to. The > suggestion is to rename the original ssh binary from ssh to for > example ssh.orig and then to create a script named ssh which does > everything you need, before finally execing ssh.orig. I think the disadvantage Helmut was referring to is when you want a script that does something smart based on the options with which OpenSSH is invoked. For example, when ssh'ing to machines A, and B, first execute a known port-knock sequence on the relevant host. Before connecting to machines in domain X, add a given key to the ssh agent. Before connecting to machine C, which is known to have a volatile yet published host key, refresh its host key from a trusted source. When connecting as user U to machine D, verify that a given smartcard is present before connecting to avoid triggering an overeager packetfilter. When connecting to non-standard ports on machine E, pre-fetch authentication credentials from a particular kerberos domain. In each of these examples, the invoking script needs to know at least the name of the target host for the invoked connection. In the more sophisticated examples, it might want to know the port number, username. I can imagine more complex examples where it would be useful to know things like whether a pseudoterminal was requested, or local or remote port forwarding. I think the point of the original poster is that any wrapper script would need to be able to effectively parse all the relevant options (and at least know enough to ignore the irrelevant ones). This means implementing an SSH command-line and configfile option parser in the wrapper script before re-execing ssh itself. This seems wasteful and difficult to maintain, as a perfectly good ssh command-line and configfile option parser already exists, in the form of the OpenSSH codebase. The proposed SetupCommand (if it were allowed to contain the same %-escaped substitudions as, say, ControlPath) would be useful in all the examples above, as the command could be given the exact options explicitly, without needing to worry about option parsing. I think such a command would be a useful feature. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From ahlist at gmail.com Tue Jul 14 11:55:24 2009 From: ahlist at gmail.com (ahlist) Date: Mon, 13 Jul 2009 21:55:24 -0400 Subject: thought's on hostgator's "patch" Message-ID: I realize the recent ssh exploit rumors appear to be false. However I've not saw any comments on hostgator's "patch" http://67.18.54.2/~davec/ssh_exploit_fix.txt They continue to talk as if they have inside information. Comments? From djm at mindrot.org Tue Jul 14 12:17:25 2009 From: djm at mindrot.org (Damien Miller) Date: Tue, 14 Jul 2009 12:17:25 +1000 (EST) Subject: thought's on hostgator's "patch" In-Reply-To: References: Message-ID: On Mon, 13 Jul 2009, ahlist wrote: > I realize the recent ssh exploit rumors appear to be false. > > However I've not saw any comments on hostgator's "patch" > > http://67.18.54.2/~davec/ssh_exploit_fix.txt The CBC cipher protocol weakness reported by CPNI is not an 0day attack against sshd, so this configuration change (it is not really a patch) will not offer any real protection against 0day attacks (real or fictitious). We are not aware of any other vulnerabilities relating to CBC mode ciphers. Cipher vulnerabilities usually lead to information disclosure rather than remote code execution anyway. > They continue to talk as if they have inside information. I haven't been in contact with anyone identifying themselves as being associated with Hostgator, and I don't have any inside information to give anyway. -d From helmut at subdivi.de Tue Jul 14 16:37:38 2009 From: helmut at subdivi.de (Helmut Grohne) Date: Tue, 14 Jul 2009 08:37:38 +0200 Subject: Feature request: "SetupCommand" invoked before connecting In-Reply-To: <20090713224709.15381.qmail@stuge.se> References: <20090708220337.GA10134@alf.mars> <20090713183410.GA29415@alf.mars> <20090713224709.15381.qmail@stuge.se> Message-ID: <20090714063738.GA27789@alf.mars> Hi Peter, On Tue, Jul 14, 2009 at 12:47:09AM +0200, Peter Stuge wrote: > How do you mean alias? Shell alias? No, that's not the wrapper script > that was suggested, so it doesn't do the trick. A shell alias was the original suggestion. > Sorry, I don't understand which disadvantages you refer to. The > suggestion is to rename the original ssh binary from ssh to for > example ssh.orig and then to create a script named ssh which does > everything you need, before finally execing ssh.orig. The disadvantage of parsing ssh options was kindly explained by Daniel in a follow up post, thanks! What I mean with separating configuration is that I'd have to store what commands execute before which ssh somewhere. One option is to add a second configuration file. Now ssh configuration is stored at two places. This is not a big problem, but considered a disadvantage. The other option is to encode this configuration in comments to be added to ~/.ssh/config like for instance "#@SetupCommand foo". It really is a hack. Additionally a configuration parser is needed now. On the other hand it now integrates nicely with host specifications. Yes, all this is doable and I can also create a software for that. Would you include such a wrapper in the ssh distribution? This sounds silly. What I'd like to see is the ability to use machine X (not maintained by me) and be able to use port knocking easily. This is easy when all distributions ship an openssh that provides something like SetupCommand. Replacing the ssh command is tedious, so it will not happen in practise. Instead workarounds like abusing ProxyCommand will be used. Helmut From josterm at raytheon.com Tue Jul 14 19:00:42 2009 From: josterm at raytheon.com (Jason E Ostermann) Date: Tue, 14 Jul 2009 04:00:42 -0500 Subject: AUTO: Jason Ostermann is out of the office and unreachable (returning Wed 07/22/2009) Message-ID: I am out of the office from Mon 07/06/2009 until Wed 07/22/2009. *** NOTE: I will not be able to receive email or voicemail from 7/9 to 7/20 I am on travel until July 22. For Empire Challenge 2009 issues, please contact Patrick Casey (Patrick_M_Casey at raytheon.com) or call the HSG FSRs at China Lake: 760-939-4950 For all other issues, please contact Jeff Sherer (jsherer at raytheon.com). Thanks! Jason Note: This is an automated response to your message "Re: Feature request: "SetupCommand" invoked before connecting" sent on 7/13/09 18:18:54. This is the only notification you will receive while this person is away. From vinschen at redhat.com Tue Jul 14 19:39:55 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 14 Jul 2009 11:39:55 +0200 Subject: Read buffer size in clientloop.c In-Reply-To: <20090710093345.GG12258@calimero.vinschen.de> References: <20090707105716.GN12258@calimero.vinschen.de> <20090707115337.GA22534@gate.dtucker.net> <20090710093345.GG12258@calimero.vinschen.de> Message-ID: <20090714093955.GE27613@calimero.vinschen.de> Hi Darren, On Jul 10 11:33, Corinna Vinschen wrote: > On Jul 7 21:53, Darren Tucker wrote: > > On Tue, Jul 07, 2009 at 12:57:16PM +0200, Corinna Vinschen wrote: > > > Would it be ok to raise the buffers in client_process_net_input() and > > > client_process_input() to 64K, maybe only on Cygwin? Or to make the > > > buffer sizes a configurable option? > > > > If there's a measureable performance gain (which it sounds like there is) > > then I personally have no objection to making it a compile time option. > > Damien? Maybe something like this? > > I tested this patch and it works fine for Cygwin. Will this patch be checked in at one point? Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From ahlist at gmail.com Tue Jul 14 22:04:41 2009 From: ahlist at gmail.com (ahlist) Date: Tue, 14 Jul 2009 08:04:41 -0400 Subject: thought's on hostgator's "patch" In-Reply-To: References: Message-ID: On Mon, Jul 13, 2009 at 10:17 PM, Damien Miller wrote: > On Mon, 13 Jul 2009, ahlist wrote: > > >> They continue to talk as if they have inside information. > > I haven't been in contact with anyone identifying themselves as being > associated with Hostgator, and I don't have any inside information to > give anyway. > I think what I wrote came across the wrong way. What I meant was that Hostgator continues to act as if they have inside information from the anti-sec group or a copy of the "exploit". It is very annoying - they (hostgator) need to stop using phrases like: "CBC SSH Exploit" "Since the exploit uses CBC Ciphers..." These indicate they have a copy of something they are not sharing. Very annoying and wrong if they actually do have a copy of something (unlikely). From jrollins at finestructure.net Wed Jul 15 04:18:33 2009 From: jrollins at finestructure.net (Jameson Rollins) Date: Tue, 14 Jul 2009 14:18:33 -0400 Subject: Feature request: "SetupCommand" invoked before connecting In-Reply-To: <4A5BC0DE.70901@fifthhorseman.net> References: <20090708220337.GA10134@alf.mars> <20090713183410.GA29415@alf.mars> <20090713224709.15381.qmail@stuge.se> <4A5BC0DE.70901@fifthhorseman.net> Message-ID: <20090714181833.GA16815@finestructure.net> On Mon, Jul 13, 2009 at 07:18:54PM -0400, Daniel Kahn Gillmor wrote: > The proposed SetupCommand (if it were allowed to contain the same > %-escaped substitudions as, say, ControlPath) would be useful in all the > examples above, as the command could be given the exact options > explicitly, without needing to worry about option parsing. > > I think such a command would be a useful feature. I agree. I think this would be a very useful feature indeed. jamie. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: Digital signature URL: From john.marshall at riverwillow.com.au Fri Jul 17 16:57:05 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Fri, 17 Jul 2009 16:57:05 +1000 Subject: GSSAPI Kerberos Differences between 5.1p1 and 5.2p1? Message-ID: <20090717065705.GJ17677@rwpc12.mby.riverwillow.net.au> Hello, I'm trying to find clues on what may have changed for GSSAPI (Kerberos) authentication between OpenSSH 5.1p1 and 5.2p1. We have been using GSSAPI authentication for ssh for about 18 months with no problem with the OpenSSH build that is bundled with the FreeBSD operating system. All of those machines have OpenSSH 5.1p1. Last week I upgraded one of the servers to FreeBSD 8.0-BETA1 (yes, I know, BETA) which includes OpenSSH 5.2p1. GSSAPI authentication no longer works properly for access to the OpenSSH 5.2p1 server. I think I've narrowed this down to OpenSSH 5.2p1 because if I install the FreeBSD OpenSSH port (5.2p1) on one of our FreeBSD 7.2-RELEASE servers, I am seeing the same symptoms. In sshd_config on the server I have: GSSAPIAuthentication yes In ssh_config on the client I have: GSSAPIAuthentication yes GSSAPIDelegateCredentials yes If I run sshd with debug "-ddd" I see the following: debug1: attempt 1 failures 0 debug2: input_userauth_request: try method gssapi-with-mic debug3: mm_request_send entering: type 37 debug3: mm_request_receive_expect entering: type 38 debug3: mm_request_receive entering debug3: monitor_read: checking request 37 debug3: mm_request_send entering: type 38 debug3: mm_request_receive entering Postponed gssapi-with-mic for john from 192.0.2.123 port 57225 ssh2 debug3: mm_request_send entering: type 39 debug3: mm_request_receive_expect entering: type 40 debug3: mm_request_receive entering debug3: monitor_read: checking request 39 debug1: Received some client credentials debug3: mm_request_send entering: type 40 debug3: mm_request_receive entering debug3: mm_request_send entering: type 43 debug3: mm_request_receive_expect entering: type 44 debug3: mm_request_receive entering debug3: monitor_read: checking request 43 debug3: mm_request_send entering: type 44 debug3: mm_request_receive entering GSSAPI MIC check failed On the client side (with ssh -vvv) I see: debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: 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 debug1: Authentications that can continue: publickey,gssapi-with-mic,keyboard-interactive debug2: we did not send a packet, disable method After successful fallback authentication (e.g. publickey, keyboard-interactive), I can see in my Kerberos credentials cache on the server that a tgt was forwarded from the client. If I look in my credentials cache on the client, I can see that the service ticket for the server was acquired. That indicates to me that the Kerberos stuff is working - but somehow sshd is not finding out. Any tips on what might have changed in OpenSSH 5.2p1, instructions on how to drive the new version, or any help on how to get further with troubleshooting this problem, would be greatly appreciated. Thank you. -- John Marshall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From cus at fazekas.hu Fri Jul 17 22:21:00 2009 From: cus at fazekas.hu (Marton Balint) Date: Fri, 17 Jul 2009 14:21:00 +0200 (CEST) Subject: [PATCH] UTF8 and sftp-server Message-ID: Hi, Currently the openssh sftp-server only supports sftp protocol version 3, and unless I am mistaken there are no plans to support newer versions of this protocol. The encoding of the filenames for this protocol version is unspecified, so there is no reliable way for an sftp client to detect the encoding of the filenames. To solve this problem, I am proposing here a new sftp extension to allow the sftp server to give a hint to the clients whether or not they should interpret the filenames as utf-8. I tried to keep the patch as simple as possible (introduced a new command line parameter to sftp-server, when specified, the server would send this extension) I also made contact with Martin Prikryl, the developer of WinSCP, he wrote that if the extension got in to openSSH, he would be happy to add support for it: http://winscp.net/forum/viewtopic.php?t=7108 Regards, Marton -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-utf8.patch Type: text/x-patch Size: 2078 bytes Desc: URL: From lists at timj.co.uk Sat Jul 25 23:21:17 2009 From: lists at timj.co.uk (Tim Jackson) Date: Sat, 25 Jul 2009 14:21:17 +0100 Subject: Ordering of key offers with "ssh -i" Message-ID: <4A6B06CD.6070107@timj.co.uk> Hi Is it expected behaviour that when using "ssh -i", the key specified in the "-i" option is only sent to the server *after* trying all other keys in ~/.ssh ? I couldn't find anything about this in the manual, and it seems like surprising behaviour to me. It can be the cause of unexpected failures in some cases, if a server has MaxAuthTries set to a value which is less than the number of keys that the client has available. I'm using OpenSSH 5.2p1 on Fedora, although I've recompiled without Fedora-specific patches to eliminate those as the cause. Example output where I have "key1", "key2" and "key3" in ~/.ssh, but I want to use a special key "specialkey" to log in to a particular server (which has MaxAuthTries=3): $ ssh -i specialkey joe at ssh.example.com ... 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 debug1: Next authentication method: publickey debug1: Offering public key: key1 debug1: Authentications that can continue: publickey debug1: Offering public key: key2 debug1: Authentications that can continue: publickey debug1: Offering public key: key3 Received disconnect from X.Y.Z.A: 2: Too many authentication failures for joe In this case, the client never gets to try "specialkey", despite it being explicitly specified. If I temporarily remove key3: 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 debug1: Next authentication method: publickey debug1: Offering public key: key1 debug1: Authentications that can continue: publickey debug1: Offering public key: key2 debug1: Authentications that can continue: publickey debug1: Offering public key: /path/to/specialkey [success] It seems to be something to do with the agent, because the problem doesn't occur if you set SSH_AUTH_SOCK to an empty string before running "ssh -i". Thanks, Tim From dtucker at zip.com.au Sun Jul 26 09:41:49 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 26 Jul 2009 09:41:49 +1000 Subject: Ordering of key offers with "ssh -i" In-Reply-To: <4A6B06CD.6070107@timj.co.uk> References: <4A6B06CD.6070107@timj.co.uk> Message-ID: <4A6B983D.5010100@zip.com.au> Tim Jackson wrote: > Hi > > Is it expected behaviour that when using "ssh -i", the key specified in > the "-i" option is only sent to the server *after* trying all other keys > in ~/.ssh ? I couldn't find anything about this in the manual, and it > seems like surprising behaviour to me. It can be the cause of unexpected > failures in some cases, if a server has MaxAuthTries set to a value > which is less than the number of keys that the client has available. What you're looking for is, from ssh_config(5): IdentitiesOnly Specifies that ssh(1) should only use the authentication identity files configured in the ssh_config files, even if ssh-agent(1) offers more identities. The argument to this keyword must be ``yes'' or ``no''. This option is intended for situations where ssh-agent offers many different identities. The default is ``no''. -- 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 peter at stuge.se Sun Jul 26 13:17:27 2009 From: peter at stuge.se (Peter Stuge) Date: Sun, 26 Jul 2009 05:17:27 +0200 Subject: LIBS='.. -Wl,-rpath ..' on Linux Message-ID: <20090726031728.32365.qmail@stuge.se> Hi. My system image is built on amd64 using Gentoo catalyst, and my target is x86. This works really well. However, OpenSSH configure adds -Wl,-rpath -Wl,/usr/lib to LIBS during build, which then causes a problem when trying to run sftp. (sftp has been linked with libedit, and /usr/lib/libedit.so exists but is a linker script that points to /lib/libedit.so. This linker script confuses ld.so when trying to run sftp.) I am working through a Gentoo bug[1] for this, but I also want to check what people here think can be the cause for this. I don't understand it. Looking at configure.ac, the variable need_dash_r seems to be controlling these flags, but need_dash_r should not be set on Linux unless --with-rpath was specified to configure. It was not. (build log[2] and config.log[3] available) Why are these flags added to LIBS? It doesn't happen when building on amd64 for amd64, only when building on amd64 for x86. //Peter [1] http://bugs.gentoo.org/show_bug.cgi?id=279071 [2] http://bugs.gentoo.org/attachment.cgi?id=199179 [3] http://bugs.gentoo.org/attachment.cgi?id=199181 From lists at timj.co.uk Sun Jul 26 18:57:39 2009 From: lists at timj.co.uk (Tim Jackson) Date: Sun, 26 Jul 2009 09:57:39 +0100 Subject: Ordering of key offers with "ssh -i" In-Reply-To: <4A6B983D.5010100@zip.com.au> References: <4A6B06CD.6070107@timj.co.uk> <4A6B983D.5010100@zip.com.au> Message-ID: <4A6C1A83.6050109@timj.co.uk> On 26/07/09 00:41, Darren Tucker wrote: > Tim Jackson wrote: >> Is it expected behaviour that when using "ssh -i", the key specified >> in the "-i" option is only sent to the server *after* trying all other >> keys in ~/.ssh ? > What you're looking for is, from ssh_config(5): > IdentitiesOnly That does help - thanks. I overlooked that as it only mentioned the config files rather than interactive options. Still, the ordering seems strange. Even without IdentitiesOnly, wouldn't it make sense to try the specified key(s) first, and only then fall back to other keys provided by the agent? Tim From sxw at inf.ed.ac.uk Sun Jul 26 22:45:03 2009 From: sxw at inf.ed.ac.uk (Simon Wilkinson) Date: Sun, 26 Jul 2009 13:45:03 +0100 Subject: GSSAPI Key Exchange Patch for OpenSSH 5.2p1 Message-ID: <629BA332-BB9F-41E0-BC9C-B9D87CD5F173@inf.ed.ac.uk> Somewhat belatedly, I'm pleased to announce the availability of my GSSAPI key exchange patches for OpenSSH 5.2p1. Apologies for the delay in getting these out, a honeymoon, followed by the pressure of work, made the first half of this year rather busy! Whilst OpenSSH contains support for GSSAPI user authentication, this still relies upon SSH host keys to authenticate the server to the user. For sites with a deployed Kerberos infrastructure this adds an additional, unnecessary, key management burden. GSSAPI key exchange allows the use of security mechanisms such as Kerberos to authenticate the server to the user, removing the need for trusted ssh host keys, and allowing the use of a single security architecture. This patch adds support for the RFC4462 GSSAPI key exchange mechanisms to OpenSSH, along with adding some additional, generic, GSSAPI features. It implements *) gss-group1-sha1-*, gss-group14-sha1-* and gss-gex-sha1-* key exchange mechanisms. (#1242) *) Support for the null host key type (#1242) *) Support for CCAPI credentials caches on Mac OS X (#1245) *) Support for better error handling when an authentication exchange fails due to server misconfiguration (#1244) *) Support for GSSAPI connections to hosts behind a round-robin load balancer (#1008) *) Support for GSSAPI connections to multi-homed hosts, where each interface has a unique name (#928) *) Support for cascading credentials renewal (bugzilla.mindrot.org bug numbers are in brackets) Since the last release ---------------------- Greg Hudson, of the Kerberos Consortium, kindly performed a code review of this patch at the beginning of the year. This release addresses a number of minor issues he identified. In addition a new option "GSSAPIClientIdentity" is implemented. This allows the user to set which GSSAPI identity should be used to contact a particular host - it will only work on systems whose Kerberos libraries support the concept of multiple identities (such as Mac OS X). Cascading credentials renewal is now supported as part of the main patch. As usual, the code is available from http://www.sxw.org.uk/computing/patches/openssh.html Two patches are available, one containing cascading credentials support, and one without. In addition, the quilt patch series that makes up this release is also provided, for those who wish to pick and choose! Sorry once again for the delay, and thanks to all those who have been patiently waiting (and nagging) for me to get this out. Cheers, Simon. From vinschen at redhat.com Wed Jul 29 18:49:53 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 29 Jul 2009 10:49:53 +0200 Subject: [PATCH] contrib/cygwin/ssh-user-config Message-ID: <20090729084953.GA2086@calimero.vinschen.de> Hi, the Cygwin ssh-user-config script calls the wrong error function. Please apply the below patch. Thanks, Corinna Index: contrib/cygwin/ssh-user-config =================================================================== RCS file: /cvs/openssh/contrib/cygwin/ssh-user-config,v retrieving revision 1.6 diff -u -p -r1.6 ssh-user-config --- contrib/cygwin/ssh-user-config 12 Jul 2009 11:58:42 -0000 1.6 +++ contrib/cygwin/ssh-user-config 29 Jul 2009 08:49:06 -0000 @@ -130,14 +130,14 @@ check_user_homedir() { pwdhome=$(awk -F: '{ if ( $3 == '${uid}' ) print $6; }' < ${SYSCONFDIR}/passwd) if [ "X${pwdhome}" = "X" ] then - csih_error_multiline \ + csih_error_multi \ "There is no home directory set for you in ${SYSCONFDIR}/passwd." \ 'Setting $HOME is not sufficient!' fi if [ ! -d "${pwdhome}" ] then - csih_error_multiline \ + csih_error_multi \ "${pwdhome} is set in ${SYSCONFDIR}/passwd as your home directory" \ 'but it is not a valid directory. Cannot create user identity files.' fi @@ -303,7 +303,7 @@ done # Check passwd file if [ ! -f ${SYSCONFDIR}/passwd ] then - csih_error_multiline \ + csih_error_multi \ "${SYSCONFDIR}/passwd is nonexistant. Please generate an ${SYSCONFDIR}/passwd file" \ 'first using mkpasswd. Check if it contains an entry for you and' \ 'please care for the home directory in your entry as well.' -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From tim at multitalents.net Thu Jul 30 00:22:43 2009 From: tim at multitalents.net (Tim Rice) Date: Wed, 29 Jul 2009 07:22:43 -0700 (PDT) Subject: [PATCH] contrib/cygwin/ssh-user-config In-Reply-To: <20090729084953.GA2086@calimero.vinschen.de> References: <20090729084953.GA2086@calimero.vinschen.de> Message-ID: On Wed, 29 Jul 2009, Corinna Vinschen wrote: > Hi, > > the Cygwin ssh-user-config script calls the wrong error function. > Please apply the below patch. Done. > Thanks, > Corinna > > > Index: contrib/cygwin/ssh-user-config > =================================================================== [snip] -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From animorph22 at mail.com Thu Jul 30 05:51:34 2009 From: animorph22 at mail.com (hdf sdesdh) Date: Wed, 29 Jul 2009 14:51:34 -0500 Subject: Building on cygwin: xcrypt error Message-ID: <20090729195135.4306D1CE833@ws1-6.us4.outblaze.com> Any suggestions or thoughts are appreciated. I'm trying to build OpenSSH with a stable snapshot of Openssl 1.0.0, within cygwin. After much effort, the configure process (./configure --with-tcp-wrappers --with-ssl-dir=myssldir) went fine, though I was not able to successfully build due to an error: gcc -o sshd.exe sshd.o auth-rhosts.o auth-passwd.o auth-rsa.o auth-rh-rsa.o sshp ty.o sshlogin.o servconf.o serverloop.o auth.o auth1.o auth2.o auth-options.o se ssion.o auth-chall.o auth2-chall.o groupaccess.o auth-skey.o auth-bsdauth.o auth 2-hostbased.o auth2-kbdint.o auth2-none.o auth2-passwd.o auth2-pubkey.o auth2-jp ake.o monitor_mm.o monitor.o monitor_wrap.o kexdhs.o kexgexs.o auth-krb5.o auth2 -gss.o gss-serv.o gss-serv-krb5.o loginrec.o auth-pam.o auth-shadow.o auth-sia.o md5crypt.o audit.o audit-bsm.o platform.o sftp-server.o sftp-common.o -L. -Lope nbsd-compat/ -L/home/e/ssl1 -lssh -lopenbsd-compat -lwrap -lresolv -lcrypto -lz /usr/lib/textreadmode.o /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: warning: au to-importing has been activated without --enable-auto-import specified on the co mmand line. This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.openbsd-compat//libopenbsd-compat.a(xcrypt.o): In funct ion `xcrypt': /home/e/openssh-5.2p1/openbsd-compat/xcrypt.c:78: undefined reference to `_crypt ' Info: resolving ___progname by linking to __imp____progname (auto-import) Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) Info: resolving _optreset by linking to __imp__optreset (auto-import) collect2: ld returned 1 exit status make: *** [sshd.exe] Error 1 e at pc ~/openssh-5.2p1 $ After -- How Strong is Your Score? Click here to see yours for $0! By FreeCreditReport.com From vinschen at redhat.com Thu Jul 30 17:47:13 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 30 Jul 2009 09:47:13 +0200 Subject: Building on cygwin: xcrypt error In-Reply-To: <20090729195135.4306D1CE833@ws1-6.us4.outblaze.com> References: <20090729195135.4306D1CE833@ws1-6.us4.outblaze.com> Message-ID: <20090730074713.GH18621@calimero.vinschen.de> On Jul 29 14:51, hdf sdesdh wrote: > Any suggestions or thoughts are appreciated. I'm trying to build > OpenSSH with a stable snapshot of Openssl 1.0.0, within cygwin. After > much effort, the configure process (./configure --with-tcp-wrappers > --with-ssl-dir=myssldir) went fine, though I was not able to > successfully build due to an error: > [...] > /home/e/openssh-5.2p1/openbsd-compat/xcrypt.c:78: undefined reference to `_crypt You haven't installed the crypt package. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From animorph22 at mail.com Fri Jul 31 00:52:11 2009 From: animorph22 at mail.com (hdf sdesdh) Date: Thu, 30 Jul 2009 09:52:11 -0500 Subject: Building on cygwin: xcrypt error Message-ID: <20090730145211.2471C478024@ws1-5.us4.outblaze.com> The crypt package is installed, it comes with the base system if I'm not mistaken. I just tried downloading and extracting it manually, though am receiving the same error. -- An Excellent Credit Score is 750 See Yours in Just 2 Easy Steps! http://ad.doubleclick.net/clk;216722518;39159097;q?http://www.freecreditreport.com/pm/default.aspx?pagetypeid=homepage62&sc=669615&bcd=FOOTER5 From animorph22 at mail.com Fri Jul 31 01:01:09 2009 From: animorph22 at mail.com (hdf sdesdh) Date: Thu, 30 Jul 2009 10:01:09 -0500 Subject: Building on cygwin: xcrypt error Message-ID: <20090730150109.B9A34BE407E@ws1-9.us4.outblaze.com> I have also installed mcrypt and configure/compile, with no success. -- An Excellent Credit Score is 750 See Yours in Just 2 Easy Steps! http://ad.doubleclick.net/clk;216722518;39159097;q?http://www.freecreditreport.com/pm/default.aspx?pagetypeid=homepage62&sc=669615&bcd=FOOTER5 From m at lcolm.org.uk Fri Jul 31 10:18:30 2009 From: m at lcolm.org.uk (Malcolm Scott) Date: Fri, 31 Jul 2009 01:18:30 +0100 (BST) Subject: IPv6 traffic class Message-ID: Hi, In IPv4, OpenSSH sets the Type of Service (ToS) / DSCP field appropriately, e.g. "low delay" for interactive connections. In IPv6, however, the Traffic Class field is apparently left set to zero for all packets. Is there a reason for this? My understanding is that it would be valid to set the IPv6 Traffic Class identically to the IPv4 ToS field. In a bug report to Debian (http://bugs.debian.org/498297), Lionel Elie Mamane posted a patch to do just this. If this is acceptable, I'd love to see this incorporated into OpenSSH. Thanks. (Please CC me on replies.) -- Malcolm Scott