From alon.barlev at gmail.com Tue Jan 1 01:53:43 2008 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon, 31 Dec 2007 16:53:43 +0200 Subject: OpenSSH PKCS#11merge In-Reply-To: <9e0cf0bf0712301441w5b51dd3ydd23c5565304a9e7@mail.gmail.com> References: <200709250733.47491.alon.barlev@gmail.com> <9e0cf0bf0712281050g75ee27b5n54eef7f9f6f51e56@mail.gmail.com> <200712301130.45791.david.daniel.smith@gmail.com> <9e0cf0bf0712292324y3d20b47cy46b3d96526f1a5a8@mail.gmail.com> <9e0cf0bf0712301441w5b51dd3ydd23c5565304a9e7@mail.gmail.com> Message-ID: <9e0cf0bf0712310653m63a51fd6v1220194d8dde82c4@mail.gmail.com> Update. Installed OpenBSD, applied this patch (ignore all missing files) Add pkcs11.c into lib/Makefile. Compile using: CFLAGS="-DENABLE_PKCS11" LDFLAGS="-lpkcs11-helper" make And it compiles and seems to be running. The problem is that I don't have a working smartcard environment on OpenBSD. Can anyone help? Best Regards, Alon Bar-Lev. On 12/31/07, Alon Bar-Lev wrote: > Hello, > > Thanks for Ben help I released a new version of PKCS#11 patch, available from: > http://alon.barlev.googlepages.com/openssh-pkcs11 > > Most of the work is *BSD coding styles, I also allocated short options > for the parameters, as I understand now that long options are not > valid and configuration file for the agent will not be available. > > There is an agentless configuration now, mainly to be OpenSC > compatible. This is none recommended as it loads all available keys of > a provided into ssh, and will prompt for passphrase every time ssh is > executed. > > I hope we will be able to resolve the last issue... How the agent > protocol can support dynamic nature of hardware cryptography... Or if > there any other suggestions of how the expected behavior might be. > > Best Regards, > Alon Bar-Lev. > > --- > > ChangeLog: > > 20071229 > - (alonbl) Indent file to meet BSD styles. > - (alonbl) Modify parameters (again) to meet BSD styles. > I truly regret that I keep modifying the parameters, I believe > this is not the last time, as I don't have full cooperation of > upstream. > Get provider keys: > Old: > ssh-add --pkcs11-show-ids ... > New: > ssh-keygen -K provider_info > Add key: > Old: > ssh-add --pkcs11-add-id ... > New: > ssh-add -I id [session_cache [cert_file]] > > Agentless operation (not recommended, OpenSC compatibility): > New: > ssh -# provider_info ... > > Because I don't wish to add more switches, I added a format > for provider information: > lib[:prot_auth[:private_mode[:cert_is_private]]] > For most implementations specify only the library name. > - Rebase with openssh-4.7p1. > - (alonbl) Release 0.20 > From jronan at tssg.org Thu Jan 3 00:43:14 2008 From: jronan at tssg.org (John Ronan) Date: Wed, 2 Jan 2008 13:43:14 +0000 Subject: enable none cipher Message-ID: <268A829F-D524-47D7-AA5E-81E7202FD950@tssg.org> Hi, I was looking at the thread on the 'null' cipher and was wondering if you have done anything one it, if you need any help (or just encouragement ;)). I'm a radio experimenter (radio ham) and currently I'm using ssh illegally over the air, as I'm not legally allowed to encrypt sessions over the Radio Link. Being able to have strong authentication with no encryption would make my (any many others) operations 'legal'. Currently it doesn't matter that I'm legal or not really as there's no one else in the area on the frequency. Regards de John EI7IG -- John Ronan , +353-51-302938 Telecommunications Software & Systems Group, http://www.tssg.org From mward at aconex.com Thu Jan 3 15:18:22 2008 From: mward at aconex.com (Mikel Ward) Date: Thu, 03 Jan 2008 15:18:22 +1100 Subject: scp -q behavior different than documented Message-ID: <1199333902.18785.17.camel@laptop.acx> Hi The man page says -q disables the progress meter, but it also disables all other output. $ scp -q badhost:/bin/ls . $ scp badhost:/bin/ls . ssh: badhost: Name or service not known I would like -q to disable the progress meter as documented (I don't see the point of a -q flag if all it does is discards stderr, since I can already do that with my shell), but you might prefer to update the man page to reflect the current behavior instead. Tested with openssh-4.7p1 on Fedora. Thanks Mike From stuge-openssh-unix-dev at cdy.org Sun Jan 6 09:48:54 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 5 Jan 2008 23:48:54 +0100 Subject: OpenSSH PKCS#11merge In-Reply-To: <9e0cf0bf0712281050g75ee27b5n54eef7f9f6f51e56@mail.gmail.com> References: <9e0cf0bf0709290108h1a4be251t5943454f1c510adc@mail.gmail.com> <9e0cf0bf0709290636q5c87566fk5fa4107dad1fb8db@mail.gmail.com> <20070929142628.13104.qmail@cdy.org> <200709292009.39873.alon.barlev@gmail.com> <9e0cf0bf0710130913q7ef26c55gf3d9e391beef3b33@mail.gmail.com> <20071014035528.10383.qmail@cdy.org> <9e0cf0bf0710132242k2a84ea74x644fdee327b780a2@mail.gmail.com> <9e0cf0bf0711101143u943b32m88c8035f70942dea@mail.gmail.com> <9e0cf0bf0712281050g75ee27b5n54eef7f9f6f51e56@mail.gmail.com> Message-ID: <20080105224854.14564.qmail@cdy.org> On Fri, Dec 28, 2007 at 08:50:42PM +0200, Alon Bar-Lev wrote: > The main issue I am waiting for Peter to response is why he thinks > that the ssh-agent protocol should not be changed to support > dynamic environment. I'll try to have a look at this during the weekend and get back to you. Just got back from 24C3 and NYE in Berlin. //Peter From stuge-openssh-unix-dev at cdy.org Sun Jan 6 10:09:03 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sun, 6 Jan 2008 00:09:03 +0100 Subject: scp -q behavior different than documented In-Reply-To: <1199333902.18785.17.camel@laptop.acx> References: <1199333902.18785.17.camel@laptop.acx> Message-ID: <20080105230903.20969.qmail@cdy.org> On Thu, Jan 03, 2008 at 03:18:22PM +1100, Mikel Ward wrote: > The man page says -q disables the progress meter, but it also > disables all other output. It would be great if you could file a bug in bugzilla for this, or even provide a patch. :) //Peter From mward at aconex.com Mon Jan 7 11:29:05 2008 From: mward at aconex.com (Mikel Ward) Date: Mon, 07 Jan 2008 11:29:05 +1100 Subject: scp -q behavior different than documented In-Reply-To: <20080105230903.20969.qmail@cdy.org> References: <1199333902.18785.17.camel@laptop.acx> <20080105230903.20969.qmail@cdy.org> Message-ID: <1199665745.2925.0.camel@laptop.acx> Filed bug 1427 https://bugzilla.mindrot.org/show_bug.cgi?id=1427 From njleanne at hotmail.com Mon Jan 7 15:58:33 2008 From: njleanne at hotmail.com (leanne) Date: Mon, 7 Jan 2008 04:58:33 +0000 Subject: ssh -q doesn't suppress all warning messages Message-ID: Hi all, One question, the ssh man page says the -q option suppress all warnings and diagnostics. however, the following condition still has the warning message appeared on the console: #man ssh .............. -q Quiet mode. Causes all warning and diagnostic messages to be suppressed. .............. # ssh -q -i ~/.ssh/id_dsa_3 sshpa3 "uname -a"Warning: Identity file //.ssh/id_dsa_3 not accessible: No such file or directory. I checked the source code that if we use "-q" option, we just set the log level to QUIET, and the above warning message is printed from the -i option: ssh.c line 387 case 'i': if (stat(optarg, &st) < 0) { fprintf(stderr, "Warning: Identity file %s " "not accessible: %s.\n", optarg, strerror(errno)); break; } if (options.num_identity_files >= SSH_MAX_IDENTITY_FILES) fatal("Too many identity files specified " "(max %d)", SSH_MAX_IDENTITY_FILES); options.identity_files[options.num_identity_files++] = xstrdup(optarg); break; So if we can't suppress all warning messages using "-q", should we revise the man page? _________________________________________________________________ MSN????????????????????? http://im.live.cn/emoticons/?ID=18 From nitishp at gmail.com Mon Jan 7 22:01:50 2008 From: nitishp at gmail.com (NitishP) Date: Mon, 7 Jan 2008 03:01:50 -0800 Subject: [PATCH] Replaced int with mode_t as requested Message-ID: Index: openssh/openbsd-compat/openbsd-compat.h =================================================================== RCS file: /cvs/openssh/openbsd-compat/openbsd-compat.h,v retrieving revision 1.43 diff -u -p -r1.43 openbsd-compat.h --- openssh/openbsd-compat/openbsd-compat.h 25 Jun 2007 12:15:13 -0000 1.43 +++ openssh/openbsd-compat/openbsd-compat.h 7 Jan 2008 06:58:54 -0000 @@ -84,7 +84,7 @@ int setenv(register const char *name, re #endif #ifndef HAVE_STRMODE -void strmode(int mode, char *p); +void strmode(mode_t mode, char *p); #endif #if !defined(HAVE_MKDTEMP) || defined(HAVE_STRICT_MKSTEMP) Index: openssh/openbsd-compat/strmode.c =================================================================== RCS file: /cvs/openssh/openbsd-compat/strmode.c,v retrieving revision 1.7 diff -u -p -r1.7 strmode.c --- openssh/openbsd-compat/strmode.c 10 Nov 2005 05:38:54 -0000 1.7 +++ openssh/openbsd-compat/strmode.c 7 Jan 2008 06:58:54 -0000 @@ -37,10 +37,8 @@ #include #include -/* XXX mode should be mode_t */ - void -strmode(int mode, char *p) +strmode(mode_t mode, char *p) { /* print type */ switch (mode & S_IFMT) { From stuge-openssh-unix-dev at cdy.org Tue Jan 8 15:15:46 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Tue, 8 Jan 2008 05:15:46 +0100 Subject: OpenSSH PKCS#11merge In-Reply-To: <9e0cf0bf0709290938m407f95f0g52665f1cc2d29c3f@mail.gmail.com> References: <200709250733.47491.alon.barlev@gmail.com> <9e0cf0bf0709290108h1a4be251t5943454f1c510adc@mail.gmail.com> <9e0cf0bf0709290636q5c87566fk5fa4107dad1fb8db@mail.gmail.com> <20070929142628.13104.qmail@cdy.org> <9e0cf0bf0709290938m407f95f0g52665f1cc2d29c3f@mail.gmail.com> Message-ID: <20080108041546.13057.qmail@cdy.org> Ok. On Sat, Sep 29, 2007 at 06:38:57PM +0200, Alon Bar-Lev wrote: > > You mentioned extending the agent protocol. Can you expand on > > that a little? Is it really neccessary? So my point here is that the agent is the only process that can be trusted to communicated with the user. ssh-add and others that are talking to the agent may be running somewhere else and may be compromised. The agent should always have final say. Compare with how ssh-add -c is implemented. Look for the confirm flag in ssh-agent.c. > > Can't the agent figure out when it needs help from the user just > > from how it is being used without actually being instructed by > > anyone? By this I mean that the agent is already able to determine when user input is required. And there is also an existing mechanism in place in ssh-agent for acquiring user input. > This is the major change all smartcard components requires, there > are some opened issues in bugzilla regarding this. Which ones do you mean? Please point them out. > Smartcards are dynamic in nature unlike file based keys, smartcards > can be removed and inserted by the users, also the session between > the application and the smartcard is sometime time limited. ssh-agent already handles limitied lifetime for file based keys. I think that code can be reused. > There are two kinds of user prompts that an smartcard enabled > application needs to have: > > 1. Token prompt - When key should be used but the hardware device > is not available the application should prompt the user to insert > his token. Certainly. I think this should be a prompt just like the one for keys added with the confirmation constraint. > This is very important when re-negotiation is performed, as users > don't expect session disconnect because their token is not > available. Hm, which re-negotiation do you mean? AFAIK the user's key is never used once authenticated between SSH client and server is completed. Rekeying etc only deals with session keys, right? > 2. Passphrase prompt - Private key is used first time on session, > may be triggered when: > a. A new session is created. > b. Card was removed and inserted, this actually forces application > to create a new session. > c. Provider forces session duration timeout, this also forces > application to create a new session. Yup. I think simply calling read_passphrase() in ssh-agent.c is the best way to do this. > Because I did not wanted to touch more than I needed, I currently > implemented these callbacks using external program the ssh-agent > execute when needed. No need for the prompt_prog stuff, see the mechanism in readpass.c. > But a much cleaner solution would be modifying the ssh-agent > protocol so that it inform the forground application to perform the > prompt. Thing is, we do not want the agent to proxy information from the network to tokens. The agent should read this information directly from the user. > BTW: I don't understood why ssh does not execute ssh-agent > internally if one is not available... GnuPG does this and it seems > to minimize code duplication... Probably because the agent causes a considerable change in behavior when agent forwarding is enabled. Forcing an agent whenever someone uses a key to authenticate would be a regression IMO. I like the fact that the agent is optional and distinct from agent forwarding. //Peter From dtucker at zip.com.au Tue Jan 8 17:12:24 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 8 Jan 2008 17:12:24 +1100 Subject: have configure generate header dependencies automatically Message-ID: <20080108061224.GA9231@gate.dtucker.net> Hi all. While working on something I got bitten by a mismatch between .o files due to a changed struct. This is easily prevented. Building proper dependency information into the Makefiles would be major surgery and require ongoing maintenance (although some of that could be automated by parsing the .depend files generated on OpenBSD). This patch is basically the brute-force approach: it will cause a recompile everything in a given directory if any header file changes. It should have no effect on building the releases, only for folks who modify stuff. Can anyone see any possible downsides to this patch, other than unnecessary recompiles for people hacking the headers? Index: Makefile.in =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/Makefile.in,v retrieving revision 1.285 diff -u -p -r1.285 Makefile.in --- Makefile.in 11 Jun 2007 04:01:42 -0000 1.285 +++ Makefile.in 8 Jan 2008 05:36:33 -0000 @@ -56,6 +56,7 @@ ENT=@ENT@ XAUTH_PATH=@XAUTH_PATH@ LDFLAGS=-L. -Lopenbsd-compat/ @LDFLAGS@ EXEEXT=@EXEEXT@ +INCLUDES=@INCLUDES@ INSTALL_SSH_PRNG_CMDS=@INSTALL_SSH_PRNG_CMDS@ INSTALL_SSH_RAND_HELPER=@INSTALL_SSH_RAND_HELPER@ @@ -120,7 +121,7 @@ $(LIBSSH_OBJS): Makefile.in config.h $(SSHOBJS): Makefile.in config.h $(SSHDOBJS): Makefile.in config.h -.c.o: +.c.o: $(INCLUDES) $(CC) $(CFLAGS) $(CPPFLAGS) -c $< LIBCOMPAT=openbsd-compat/libopenbsd-compat.a Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/configure.ac,v retrieving revision 1.389 diff -u -p -r1.389 configure.ac --- configure.ac 2 Jan 2008 07:08:45 -0000 1.389 +++ configure.ac 8 Jan 2008 05:41:21 -0000 @@ -88,6 +88,12 @@ AC_SUBST(LD) AC_C_INLINE +INCLUDES="`echo $srcdir/*.h`" +AC_SUBST(INCLUDES, [$INCLUDES]) + +COMPAT_INCLUDES="`cd openbsd-compat && echo $srcdir/../openbsd-compat/*.h`" +AC_SUBST(COMPAT_INCLUDES, [$COMPAT_INCLUDES]) + AC_CHECK_DECL(LLONG_MAX, have_llong_max=1, , [#include ]) if test "$GCC" = "yes" || test "$GCC" = "egcs"; then Index: openbsd-compat/Makefile.in =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/Makefile.in,v retrieving revision 1.41 diff -u -p -r1.41 Makefile.in --- openbsd-compat/Makefile.in 25 Jun 2007 12:15:13 -0000 1.41 +++ openbsd-compat/Makefile.in 8 Jan 2008 05:45:45 -0000 @@ -15,6 +15,7 @@ AR=@AR@ RANLIB=@RANLIB@ INSTALL=@INSTALL@ LDFLAGS=-L. @LDFLAGS@ +COMPAT_INCLUDES=@COMPAT_INCLUDES@ OPENBSD=base64.o basename.o bindresvport.o daemon.o dirname.o getcwd.o getgrouplist.o getopt.o getrrsetbyname.o glob.o inet_aton.o inet_ntoa.o inet_ntop.o mktemp.o readpassphrase.o realpath.o rresvport.o setenv.o setproctitle.o sha2.o sigact.o strlcat.o strlcpy.o strmode.o strsep.o strtonum.o strtoll.o strtoul.o vis.o @@ -22,14 +23,14 @@ COMPAT=bsd-arc4random.o bsd-asprintf.o b PORTS=port-aix.o port-irix.o port-linux.o port-solaris.o port-tun.o port-uw.o -.c.o: +.c.o: ../config.h $(COMPAT_INCLUDES) $(CC) $(CFLAGS) $(CPPFLAGS) -c $< all: libopenbsd-compat.a -$(COMPAT): ../config.h -$(OPENBSD): ../config.h -$(PORTS): ../config.h +$(COMPAT): ../config.h $(COMPAT_INCLUDES) +$(OPENBSD): ../config.h $(COMPAT_INCLUDES) +$(PORTS): ../config.h $(COMPAT_INCLUDES) libopenbsd-compat.a: $(COMPAT) $(OPENBSD) $(PORTS) $(AR) rv $@ $(COMPAT) $(OPENBSD) $(PORTS) -- 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 alon.barlev at gmail.com Wed Jan 9 00:39:15 2008 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 8 Jan 2008 15:39:15 +0200 Subject: OpenSSH PKCS#11merge In-Reply-To: <20080108041546.13057.qmail@cdy.org> References: <200709250733.47491.alon.barlev@gmail.com> <9e0cf0bf0709290108h1a4be251t5943454f1c510adc@mail.gmail.com> <9e0cf0bf0709290636q5c87566fk5fa4107dad1fb8db@mail.gmail.com> <20070929142628.13104.qmail@cdy.org> <9e0cf0bf0709290938m407f95f0g52665f1cc2d29c3f@mail.gmail.com> <20080108041546.13057.qmail@cdy.org> Message-ID: <9e0cf0bf0801080539p3520a56boa447a020a90166f7@mail.gmail.com> Hello, Thank you so much for the input! I was unaware that the agent can call these functions. However, I believe that it is somewhat confusing to introduce a passphrase dialog for ok/cancel input... :) I released a new version of my patch: http://alon.barlev.googlepages.com/openssh-4.7pkcs11-0.21.tar.bz2 This version uses the ssh-askpass interface. I also splitted the patches so it will be clear what goes to where and why. Available for OpenSSH and Portable OpenSSH versions, and X.509 functionality. I will appreciate any more comments you or anyone else may have! Best Regards, Alon Bar-Lev. On 1/8/08, Peter Stuge wrote: > Ok. > > On Sat, Sep 29, 2007 at 06:38:57PM +0200, Alon Bar-Lev wrote: > > > You mentioned extending the agent protocol. Can you expand on > > > that a little? Is it really neccessary? > > So my point here is that the agent is the only process that can be > trusted to communicated with the user. ssh-add and others that are > talking to the agent may be running somewhere else and may be > compromised. The agent should always have final say. > > Compare with how ssh-add -c is implemented. Look for the confirm flag > in ssh-agent.c. > > > > > Can't the agent figure out when it needs help from the user just > > > from how it is being used without actually being instructed by > > > anyone? > > By this I mean that the agent is already able to determine when user > input is required. And there is also an existing mechanism in place > in ssh-agent for acquiring user input. > > > > This is the major change all smartcard components requires, there > > are some opened issues in bugzilla regarding this. > > Which ones do you mean? Please point them out. > > > > Smartcards are dynamic in nature unlike file based keys, smartcards > > can be removed and inserted by the users, also the session between > > the application and the smartcard is sometime time limited. > > ssh-agent already handles limitied lifetime for file based keys. I > think that code can be reused. > > > > There are two kinds of user prompts that an smartcard enabled > > application needs to have: > > > > 1. Token prompt - When key should be used but the hardware device > > is not available the application should prompt the user to insert > > his token. > > Certainly. I think this should be a prompt just like the one for keys > added with the confirmation constraint. > > > > This is very important when re-negotiation is performed, as users > > don't expect session disconnect because their token is not > > available. > > Hm, which re-negotiation do you mean? AFAIK the user's key is never > used once authenticated between SSH client and server is completed. > Rekeying etc only deals with session keys, right? > > > > 2. Passphrase prompt - Private key is used first time on session, > > may be triggered when: > > a. A new session is created. > > b. Card was removed and inserted, this actually forces application > > to create a new session. > > c. Provider forces session duration timeout, this also forces > > application to create a new session. > > Yup. I think simply calling read_passphrase() in ssh-agent.c is the > best way to do this. > > > > Because I did not wanted to touch more than I needed, I currently > > implemented these callbacks using external program the ssh-agent > > execute when needed. > > No need for the prompt_prog stuff, see the mechanism in readpass.c. > > > > But a much cleaner solution would be modifying the ssh-agent > > protocol so that it inform the forground application to perform the > > prompt. > > Thing is, we do not want the agent to proxy information from the > network to tokens. The agent should read this information directly > from the user. > > > > BTW: I don't understood why ssh does not execute ssh-agent > > internally if one is not available... GnuPG does this and it seems > > to minimize code duplication... > > Probably because the agent causes a considerable change in behavior > when agent forwarding is enabled. > > Forcing an agent whenever someone uses a key to authenticate would be > a regression IMO. I like the fact that the agent is optional and > distinct from agent forwarding. > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From jvijayku at yahoo.co.in Wed Jan 9 01:23:42 2008 From: jvijayku at yahoo.co.in (vijay kumar jayarama) Date: Tue, 8 Jan 2008 19:53:42 +0530 (IST) Subject: Support user certificate through PAM Message-ID: <384594.9252.qm@web8503.mail.in.yahoo.com> Hi We use pam to authenticate users password using RADIUS. There is now a requirement to support these RADIUS users through certificate based authentication instead of password. I was thinking whether the current X.509 patch supporting certificate can be modfied to use PAM ?. Or else, Since keyboard interactive uses PAM anyway, Is there any easy way to pass user certificate to pam which can in turn use it to do authentication ? Or is there any modifications I can do to the code to support either of the above. Any clarifications regarding these is really appreciated thank you Vijay Meet people who discuss and share your passions. Go to http://in.promos.yahoo.com/groups From stuge-openssh-unix-dev at cdy.org Wed Jan 9 09:42:44 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Tue, 8 Jan 2008 23:42:44 +0100 Subject: OpenSSH PKCS#11merge In-Reply-To: <9e0cf0bf0801080539p3520a56boa447a020a90166f7@mail.gmail.com> References: <200709250733.47491.alon.barlev@gmail.com> <9e0cf0bf0709290108h1a4be251t5943454f1c510adc@mail.gmail.com> <9e0cf0bf0709290636q5c87566fk5fa4107dad1fb8db@mail.gmail.com> <20070929142628.13104.qmail@cdy.org> <9e0cf0bf0709290938m407f95f0g52665f1cc2d29c3f@mail.gmail.com> <20080108041546.13057.qmail@cdy.org> <9e0cf0bf0801080539p3520a56boa447a020a90166f7@mail.gmail.com> Message-ID: <20080108224244.26725.qmail@cdy.org> Hi, On Tue, Jan 08, 2008 at 03:39:15PM +0200, Alon Bar-Lev wrote: > Thank you so much for the input! > I was unaware that the agent can call these functions. > However, I believe that it is somewhat confusing to introduce a > passphrase dialog for ok/cancel input... :) Also see the ask_permission() call in readpass.c which is used for keys that are added with the confirmation constraint - it will only read a yes/no answer. > I released a new version of my patch: > http://alon.barlev.googlepages.com/openssh-4.7pkcs11-0.21.tar.bz2 > > This version uses the ssh-askpass interface. I'll have a look. Not tonight though. > I also splitted the patches so it will be clear what goes to where > and why. > > Available for OpenSSH and Portable OpenSSH versions, and X.509 > functionality. Cool! Have you made any research on pkcs#11 in OpenBSD? I asked around in #openbsd on freenode some time ago but noone there had heard any strong opinions either for or against it. OpenBSD has support for hardware crypto, but that's all in the kernel and I suppose applications all use whatever native API:s there are, which then may or may not be accelerated. Might be interesting to check out. OpenVPN supposedly can make use of the hw crypto acceleration. I don't know at all about the scope of OBSD hw crypto support. Perhaps a p11 wrapper for the OBSD native API would be useful. :) //Peter From mouring at eviladmin.org Wed Jan 9 09:53:42 2008 From: mouring at eviladmin.org (Ben Lindstrom) Date: Tue, 8 Jan 2008 16:53:42 -0600 (CST) Subject: OpenSSH PKCS#11merge In-Reply-To: <20080108224244.26725.qmail@cdy.org> References: <200709250733.47491.alon.barlev@gmail.com> <9e0cf0bf0709290108h1a4be251t5943454f1c510adc@mail.gmail.com> <9e0cf0bf0709290636q5c87566fk5fa4107dad1fb8db@mail.gmail.com> <20070929142628.13104.qmail@cdy.org> <9e0cf0bf0709290938m407f95f0g52665f1cc2d29c3f@mail.gmail.com> <20080108041546.13057.qmail@cdy.org> <9e0cf0bf0801080539p3520a56boa447a020a90166f7@mail.gmail.com> <20080108224244.26725.qmail@cdy.org> Message-ID: On Tue, 8 Jan 2008, Peter Stuge wrote: [..] >> I also splitted the patches so it will be clear what goes to where >> and why. >> >> Available for OpenSSH and Portable OpenSSH versions, and X.509 >> functionality. > > Cool! Have you made any research on pkcs#11 in OpenBSD? I asked > around in #openbsd on freenode some time ago but noone there had > heard any strong opinions either for or against it. > > OpenBSD has support for hardware crypto, but that's all in the kernel > and I suppose applications all use whatever native API:s there are, > which then may or may not be accelerated. > > Might be interesting to check out. OpenVPN supposedly can make use of > the hw crypto acceleration. I don't know at all about the scope of > OBSD hw crypto support. Perhaps a p11 wrapper for the OBSD native API > would be useful. :) > IIRC, any application using OpenSSL with a supported encryption hardware gains the performance boost under OpenBSD. I know I did some research a few years ago and almost picked up a Soekris with a VPN card. Just started considering how much CPU cycles my home server uses and realized I wouldn't be happy with it. - Ben From stuge-openssh-unix-dev at cdy.org Wed Jan 9 15:25:52 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Wed, 9 Jan 2008 05:25:52 +0100 Subject: OpenSSH PKCS#11merge In-Reply-To: <20080108224244.26725.qmail@cdy.org> References: <200709250733.47491.alon.barlev@gmail.com> <9e0cf0bf0709290108h1a4be251t5943454f1c510adc@mail.gmail.com> <9e0cf0bf0709290636q5c87566fk5fa4107dad1fb8db@mail.gmail.com> <20070929142628.13104.qmail@cdy.org> <9e0cf0bf0709290938m407f95f0g52665f1cc2d29c3f@mail.gmail.com> <20080108041546.13057.qmail@cdy.org> <9e0cf0bf0801080539p3520a56boa447a020a90166f7@mail.gmail.com> <20080108224244.26725.qmail@cdy.org> Message-ID: <20080109042552.22760.qmail@cdy.org> Hi again, I could not resist looking at the code a bit. On Tue, Jan 08, 2008 at 11:42:44PM +0100, Peter Stuge wrote: > On Tue, Jan 08, 2008 at 03:39:15PM +0200, Alon Bar-Lev wrote: > > However, I believe that it is somewhat confusing to introduce a > > passphrase dialog for ok/cancel input... :) > > ask_permission() I see you already found it. I've only had a quick look at 2000_all_pkcs11.patch and found some simple but serious issues: _pkcs11_ssh_pin_prompt() does not check for snprintf() failure, which means that uninitialized memory may be passed to read_passphrase() and at least in theory this is a buffer overflow vulnerability. Also, there is a possible memory leak, since passphrase is not always xfree()d; if the read passphrase is empty or longer than the max pin length. In _pkcs11_convert_to_ssh_key(), the choice of local variable names make the code rather unreadable. It's not good to have one parameter called key and a variable called _key. Please try to find better names for all similar instances. There may be other similar problems that I have not found because I have not read the patch very carefully. I really like where this is going though. :) //Peter From jonhson.ian at gmail.com Wed Jan 9 15:46:48 2008 From: jonhson.ian at gmail.com (Ian jonhson) Date: Wed, 9 Jan 2008 12:46:48 +0800 Subject: how to test the performance of modified openssh Message-ID: <8f34198c0801082046m30965521n680e372cbb6f3721@mail.gmail.com> Hi all, I have modified the openssh and added a new authentication module in it. But I don't know how to compare the performance between the modified version and original version. Are there any benchmark designed for openssh? Or, what applications are classic to openssh and should be recommended to do this kind of tests? Regards, Ian From vinschen at redhat.com Wed Jan 9 20:01:15 2008 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 9 Jan 2008 10:01:15 +0100 Subject: have configure generate header dependencies automatically In-Reply-To: <20080108061224.GA9231@gate.dtucker.net> References: <20080108061224.GA9231@gate.dtucker.net> Message-ID: <20080109090115.GC5097@calimero.vinschen.de> On Jan 8 17:12, Darren Tucker wrote: > Hi all. > > While working on something I got bitten by a mismatch between .o files > due to a changed struct. This is easily prevented. > > Building proper dependency information into the Makefiles would be major > surgery and require ongoing maintenance (although some of that could be > automated by parsing the .depend files generated on OpenBSD). I don't know if that's helpful, but there's also the gcc -MMD option to create local dependencies per compilation unit. It's pretty easy to use in Makefiles. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From alon.barlev at gmail.com Thu Jan 10 00:04:39 2008 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed, 9 Jan 2008 15:04:39 +0200 Subject: OpenSSH PKCS#11merge In-Reply-To: <20080109042552.22760.qmail@cdy.org> References: <200709250733.47491.alon.barlev@gmail.com> <9e0cf0bf0709290108h1a4be251t5943454f1c510adc@mail.gmail.com> <9e0cf0bf0709290636q5c87566fk5fa4107dad1fb8db@mail.gmail.com> <20070929142628.13104.qmail@cdy.org> <9e0cf0bf0709290938m407f95f0g52665f1cc2d29c3f@mail.gmail.com> <20080108041546.13057.qmail@cdy.org> <9e0cf0bf0801080539p3520a56boa447a020a90166f7@mail.gmail.com> <20080108224244.26725.qmail@cdy.org> <20080109042552.22760.qmail@cdy.org> Message-ID: <9e0cf0bf0801090504n2c3d3be3oa9722dc934d8de62@mail.gmail.com> Hello, On 1/9/08, Peter Stuge wrote: > Cool! Have you made any research on pkcs#11 in OpenBSD? I asked > around in #openbsd on freenode some time ago but noone there had > heard any strong opinions either for or against it. PKCS#11 is just an interface... I don't think people should be against it... :) > OpenBSD has support for hardware crypto, but that's all in the kernel > and I suppose applications all use whatever native API:s there are, > which then may or may not be accelerated. True. This is the problem with people reinvent the wheel. > Might be interesting to check out. OpenVPN supposedly can make use of > the hw crypto acceleration. I don't know at all about the scope of > OBSD hw crypto support. Perhaps a p11 wrapper for the OBSD native API > would be useful. :) OpenVPN uses OpenSSL engines to accelerate the symmetric operations... The asymmetric operations can be performed using PKCS#11. The problem is that OpenSSL as OpenBSD and others (Linux) choose to define its own proprietary interface to cryptography module, so both applications and cryptographic modules, must support its interface. Because the lack of standardization in Open Source communities, introducing external (software or hardware) accelerators or devices is a complex task. Most developers choose to drop the idea. PKCS#11 is far than being ideal... But at least it something many agree on. > I could not resist looking at the code a bit. Great! Thank you for your help! > _pkcs11_ssh_pin_prompt() does not check for snprintf() failure, which > means that uninitialized memory may be passed to read_passphrase() > and at least in theory this is a buffer overflow vulnerability. Fixed. BTW: Looking at other parts of OpenSSH, there are many snprintfs without this... > Also, there is a possible memory leak, since passphrase is not always > xfree()d; if the read passphrase is empty or longer than the max pin > length. Fixed. Thanks! BTW: When in terminal mode, there is no way to differentiate between user enter empty passphrase or wish to cancel... I expected that D will do the trick. > In _pkcs11_convert_to_ssh_key(), the choice of local variable names > make the code rather unreadable. It's not good to have one parameter > called key and a variable called _key. Please try to find better > names for all similar instances. Fixed to internal_XXXX. > I really like where this is going though. :) That's is great! Released another version: http://alon.barlev.googlepages.com/openssh-4.7pkcs11-0.22.tar.bz2 This time I also added man updates. Best Regards, Alon Bar-Lev. From carson at taltos.org Thu Jan 10 02:37:24 2008 From: carson at taltos.org (Carson Gaspar) Date: Wed, 09 Jan 2008 07:37:24 -0800 Subject: have configure generate header dependencies automatically In-Reply-To: <20080109090115.GC5097@calimero.vinschen.de> References: <20080108061224.GA9231@gate.dtucker.net> <20080109090115.GC5097@calimero.vinschen.de> Message-ID: <4784EA34.5000402@taltos.org> Corinna Vinschen wrote: ... > I don't know if that's helpful, but there's also the gcc -MMD option to > create local dependencies per compilation unit. It's pretty easy to use > in Makefiles. And is entirely gcc-specific. For those of us who don't build with gcc, please don't. Or rather please make it optional if you do. -- Carson (who just had to take a weed whacker to some Makefiles last night because of this) From dtucker at zip.com.au Thu Jan 10 09:11:18 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 10 Jan 2008 09:11:18 +1100 Subject: have configure generate header dependencies automatically In-Reply-To: <4784EA34.5000402@taltos.org> References: <20080108061224.GA9231@gate.dtucker.net> <20080109090115.GC5097@calimero.vinschen.de> <4784EA34.5000402@taltos.org> Message-ID: <47854686.7090800@zip.com.au> Carson Gaspar wrote: > Corinna Vinschen wrote: > ... >> I don't know if that's helpful, but there's also the gcc -MMD option to >> create local dependencies per compilation unit. It's pretty easy to use >> in Makefiles. > > And is entirely gcc-specific. For those of us who don't build with gcc, > please don't. Or rather please make it optional if you do. There has been much effort expended by many people to make OpenSSH build with a variety of compilers (and on a variety of platforms) and I for one would not like to see that change. That said, I think something like that (or mkdep from OpenBSD as mentioned in my original mail) would be OK as long as either the result is checked into CVS (not done at build time) or is an optional extra. The down side of this strategy is that the output of those types of tools is usually dependent on the compiler flags passed to the tool. Hence my "if all you have is a hammer, every problem looks like a nail" solution using configure :-) -- 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 jonhson.ian at gmail.com Thu Jan 10 15:53:08 2008 From: jonhson.ian at gmail.com (Ian jonhson) Date: Thu, 10 Jan 2008 12:53:08 +0800 Subject: how to test the performance of modified openssh In-Reply-To: <70621a460801090545m4cf25080m2799c1faec11becb@mail.gmail.com> References: <8f34198c0801082046m30965521n680e372cbb6f3721@mail.gmail.com> <70621a460801090545m4cf25080m2799c1faec11becb@mail.gmail.com> Message-ID: <8f34198c0801092053o72a02e90l2202e0d10b040b59@mail.gmail.com> > When Chris and I were testing the HPN patch we downloaded 5 or so different > versions and compiled them all in their directories. We then launched them > against each other by calling them on their paths. (Building some scripts to > do this) There are some tricks to this though. For example you must call > sshd with a full path name, not relative. Another is that when you scp > remotely to an sshd that you executed like /home/user/opensshd-xxx/sshd the > scp binary that is launched remotely is going to be the system one and not > the one in that directory. > I have solved the problems, and guaranteed that client and server would run openssh with specified version. > As for metrics that you want to look for the two big things you want to > attack are latency and throughput. How to measure the latency and throughput? Are there any tools or samples to do these? I ever thought about openssh applications such as BLAST, etc, because I can compare the performance of its applications between modified openssh and original one. However, the method maybe is not enough, since only one application is used to testing. I need more classical and representative applications to show the difference. > If you want to be complete with your > testing test both ssh interactive, piping something over ssh, scp, and sftp. > Technologically, testing of interaction and piping something with ssh, scp and sftp should finally turn down to quantity to illuminate comparison. But what sample data should be used and what methodology is adopted is main problem in my test. I would like to know whether someone had worked in this topic in developers. And how to deal with it in early version? Are there any rules I should obey? etc. Thanks again, Ian From stuge-openssh-unix-dev at cdy.org Fri Jan 11 11:17:46 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 11 Jan 2008 01:17:46 +0100 Subject: how to test the performance of modified openssh In-Reply-To: <8f34198c0801092053o72a02e90l2202e0d10b040b59@mail.gmail.com> References: <8f34198c0801082046m30965521n680e372cbb6f3721@mail.gmail.com> <70621a460801090545m4cf25080m2799c1faec11becb@mail.gmail.com> <8f34198c0801092053o72a02e90l2202e0d10b040b59@mail.gmail.com> Message-ID: <20080111001746.17431.qmail@cdy.org> On Thu, Jan 10, 2008 at 12:53:08PM +0800, Ian jonhson wrote: > But what sample data should be used and what methodology is adopted > is main problem in my test. This depends entirely on your metric. What is the purpose of your measurements? > I would like to know whether someone had worked in this topic in > developers. I don't think so, no. > And how to deal with it in early version? Are there any rules I > should obey? etc. What? What rules?! The only rules that apply to OpenSSH is the license, but I don't think that's what you mean - or? And what do you mean with early version? Sorry - I don't understand what you want to do. :\ //Peter From mouring at eviladmin.org Sat Jan 12 06:55:52 2008 From: mouring at eviladmin.org (Ben Lindstrom) Date: Fri, 11 Jan 2008 13:55:52 -0600 (CST) Subject: how to test the performance of modified openssh In-Reply-To: <8f34198c0801082046m30965521n680e372cbb6f3721@mail.gmail.com> References: <8f34198c0801082046m30965521n680e372cbb6f3721@mail.gmail.com> Message-ID: The only performance testing I've ever seen was a "max transfer rate" test. Which lead to deciding the encryption order and discussions about v2 vs v1 preformance differences. Along with Internet2 testing to find a better way of gaining preformance on massive pipes. In both cases I believe the test was pretty much a "dd if=/dev/urandom .. | ssh '| cat /dev/null'" style testing or transferring of real data. Timing the time it takes to move XX amount of data then doing the math. I don't believe anyone has done any testing on the cost of authentication. Truth of the matter is if it is near instance I doubt anyone really cares (I sure never have =). But if you want to test authentication cost a simple "time ssh site /bin/true" I'm sure would be close enough.. This isn't a realtime event so what is a few microseconds between friends. =) However, to get true stats you may want to disable hashing and encryption. - Ben On Wed, 9 Jan 2008, Ian jonhson wrote: > Hi all, > > I have modified the openssh and added a new authentication module in it. > But I don't know how to compare the performance between the modified version > and original version. Are there any benchmark designed for openssh? Or, what > applications are classic to openssh and should be recommended to do this kind > of tests? > > Regards, > > Ian > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From rapier at psc.edu Sat Jan 12 07:36:44 2008 From: rapier at psc.edu (Chris Rapier) Date: Fri, 11 Jan 2008 15:36:44 -0500 Subject: how to test the performance of modified openssh In-Reply-To: References: <8f34198c0801082046m30965521n680e372cbb6f3721@mail.gmail.com> Message-ID: <4787D35C.9080601@psc.edu> Ben Lindstrom wrote: > The only performance testing I've ever seen was a "max transfer rate" > test. This is the tests we most commonly use when developing HPN-SSH. We're actually in the process of developing some methods to test application layer latency though. > Which lead to deciding the encryption order and discussions about > v2 vs v1 preformance differences. Along with Internet2 testing to find a > better way of gaining preformance on massive pipes. > > In both cases I believe the test was pretty much a "dd if=/dev/urandom .. > | ssh '| cat /dev/null'" style testing or transferring of real data. > Timing the time it takes to move XX amount of data then doing the math. I also use Iperf over a SSH tunnel to do tests. It can give you some useful options (mutliple streams, different RWINs, MSS, and multiple streasm, disable nagle, etc) and statistics (1sec avgs, etc). Unfortunately, it uncovered an odd situation with the HPN-SSH code though that I'm still trying to resolve (the window doesn't grow. :\). > I don't believe anyone has done any testing on the cost of > authentication. Truth of the matter is if it is near instance I doubt > anyone really cares (I sure never have =). I care! :) Not a whole lot because we generally see the authentication process as sunk cost. It matters a lot on low bandwidth long delay connections involving small transfers. Its more difficult to amortize the cost of authentication in those instances. > But if you want to test authentication cost a simple "time ssh site > /bin/true" I'm sure would be close enough.. This isn't a realtime event > so what is a few microseconds between friends. =) However, to get true > stats you may want to disable hashing and encryption. In this situation one could also use tcpdumps and look at the packet timing. From dkg-openssh.com at fifthhorseman.net Sat Jan 12 07:29:30 2008 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 11 Jan 2008 15:29:30 -0500 Subject: how to test the performance of modified openssh In-Reply-To: (Ben Lindstrom's message of "Fri\, 11 Jan 2008 13\:55\:52 -0600 \(CST\)") References: <8f34198c0801082046m30965521n680e372cbb6f3721@mail.gmail.com> Message-ID: <874pdkkswl.fsf@squeak.fifthhorseman.net> On Fri 2008-01-11 14:55:52 -0500, Ben Lindstrom wrote: > In both cases I believe the test was pretty much a "dd if=/dev/urandom .. > | ssh '| cat /dev/null'" style testing or transferring of real data. > Timing the time it takes to move XX amount of data then doing the math. Be aware that if you're concerned about a CPU bottleneck for openssh, dd'ing from /dev/urandom is going to confound your results. Pulling only 5MB of data from /dev/urandom chews up over 2.5 seconds of CPU time (inside the kernel, no less!) on a 1.2GHz P3 running Linux 2.6.22. here's two different ways of looking at it: [0 dkg at squeak ~]$ time dd if=/dev/urandom bs=1K count=5K > /dev/null 5120+0 records in 5120+0 records out 5242880 bytes (5.2 MB) copied, 2.69792 seconds, 1.9 MB/s real 0m2.723s user 0m0.016s sys 0m2.696s [0 dkg at squeak ~]$ (sleep 2 && dd if=/dev/urandom bs=1K count=5K > /dev/null 2>/dev/null) & vmstat 1 10 [1] 14475 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 2 0 420188 6352 4776 76720 3 2 52 32 5 2 7 1 90 2 0 0 420188 6364 4776 76720 0 0 0 0 75 206 0 0 100 0 1 0 420188 6364 4776 76720 0 0 0 0 75 117 0 2 98 0 1 0 420188 6364 4776 76720 0 0 0 0 255 83 0 100 0 0 1 0 420188 6364 4776 76720 0 0 0 0 266 111 0 100 0 0 0 0 420188 6432 4776 76720 0 0 0 0 278 143 0 67 33 0 0 0 420188 6452 4776 76720 0 0 0 0 109 131 0 0 100 0 0 0 420188 6452 4776 76720 0 0 0 0 87 119 0 0 100 0 0 0 420188 6452 4776 76720 0 0 0 0 212 213 0 1 99 0 1 0 420188 6452 4776 76720 0 0 0 0 132 152 0 0 100 0 [1]+ Done ( sleep 2 && dd if=/dev/urandom bs=1K count=5K >/dev/null 2>/dev/null ) [0 dkg at squeak ~]$ So if ssh is contending with the kernel's PRNG and the CPU is pegged at 100%, you'll see a throughput performance degradation as a result. It's probably better to dd from /dev/urandom to a large (RAM-backed) file and feed a continuous loop from the file for throughput tests to avoid this problem. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080111/24aaaec3/attachment.bin From dtucker at zip.com.au Sat Jan 12 09:29:03 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 12 Jan 2008 09:29:03 +1100 Subject: how to test the performance of modified openssh In-Reply-To: <4787D35C.9080601@psc.edu> References: <8f34198c0801082046m30965521n680e372cbb6f3721@mail.gmail.com> <4787D35C.9080601@psc.edu> Message-ID: <4787EDAF.2080705@zip.com.au> Chris Rapier wrote: > Ben Lindstrom wrote: >> The only performance testing I've ever seen was a "max transfer rate" >> test. > > This is the tests we most commonly use when developing HPN-SSH. We're > actually in the process of developing some methods to test application > layer latency though. For testing raw throughput I use "dd if=/dev/zero bs=1024 | ssh server ssh dd of=/dev/null bs=1k" (making sure compression is off) which takes any disk IO out of the picture but still does IO in chunks. If I care about disk IO (eg fiddling with scp) then I'll just grab a random large file and use it for the test data. >> Which lead to deciding the encryption order and discussions about >> v2 vs v1 preformance differences. Along with Internet2 testing to find a >> better way of gaining preformance on massive pipes. >> >> In both cases I believe the test was pretty much a "dd if=/dev/urandom .. >> | ssh '| cat /dev/null'" style testing or transferring of real data. >> Timing the time it takes to move XX amount of data then doing the math. > > I also use Iperf over a SSH tunnel to do tests. It can give you some > useful options (mutliple streams, different RWINs, MSS, and multiple > streasm, disable nagle, etc) and statistics (1sec avgs, etc). > Unfortunately, it uncovered an odd situation with the HPN-SSH code > though that I'm still trying to resolve (the window doesn't grow. :\). Chris: make sure you have clientloop.c rev 1.171. There's a latent bug that sets the max packet size to nonsensically large values for remote port forwards, which may or may not be affecting you. >> I don't believe anyone has done any testing on the cost of >> authentication. Truth of the matter is if it is near instance I doubt >> anyone really cares (I sure never have =). > > I care! :) Not a whole lot because we generally see the authentication > process as sunk cost. It matters a lot on low bandwidth long delay > connections involving small transfers. Its more difficult to amortize > the cost of authentication in those instances. I've also done the "time ssh server true" thing Ben suggested when looking at things that potentially change the connection establishment time (not that common, but things like Diffie-Hellman tweaks, random reseeding or the recent protocol 1 ephemeral server key thing). The catch is that if your authentication require user interaction then you have a massive extra variable which you would need to account for. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Sat Jan 12 13:52:30 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 12 Jan 2008 13:52:30 +1100 Subject: have configure generate header dependencies automatically In-Reply-To: <47854686.7090800@zip.com.au> References: <20080108061224.GA9231@gate.dtucker.net> <20080109090115.GC5097@calimero.vinschen.de> <4784EA34.5000402@taltos.org> <47854686.7090800@zip.com.au> Message-ID: <20080112025230.GA14809@gate.dtucker.net> On Thu, Jan 10, 2008 at 09:11:18AM +1100, Darren Tucker wrote: [...] > That said, I think something like that (or mkdep from OpenBSD as > mentioned in my original mail) would be OK as long as either the result > is checked into CVS (not done at build time) or is an optional extra. > > The down side of this strategy is that the output of those types of > tools is usually dependent on the compiler flags passed to the tool. > Hence my "if all you have is a hammer, every problem looks like a nail" > solution using configure :-) Here's one possible solution. It preprocesses the entire tree and strips out everything except the #includes, processes the tree with gcc -MM and stores the result. Because the #ifdefs have been removed, the result is effectively the dependencies for every possible configuration (all at once). At configure time, if the dependency info is available then it's appended to the Makefile, otherwise it's a no-op. If we check the depend files into CVS and make sure they're current when building releases then I think it would work out. If anyone wants to try this (particularly with a non-gcc compiler and vendor make) I have put up a snapshot with this change here: http://www.zip.com.au/~dtucker/tmp/openssh-depend3.tar.gz Index: Makefile.in =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/Makefile.in,v retrieving revision 1.285 diff -u -p -r1.285 Makefile.in --- Makefile.in 11 Jun 2007 04:01:42 -0000 1.285 +++ Makefile.in 12 Jan 2008 01:28:23 -0000 @@ -230,6 +230,7 @@ distprep: catman-do $(AUTORECONF) -rm -rf autom4te.cache (cd scard && $(MAKE) -f Makefile.in distprep) + sh mkdepend.sh install: $(CONFIGFILES) ssh_prng_cmds.out $(MANPAGES) $(TARGETS) install-files install-sysconf host-key check-config install-nokeys: $(CONFIGFILES) ssh_prng_cmds.out $(MANPAGES) $(TARGETS) install-files install-sysconf Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/configure.ac,v retrieving revision 1.389 diff -u -p -r1.389 configure.ac --- configure.ac 2 Jan 2008 07:08:45 -0000 1.389 +++ configure.ac 12 Jan 2008 01:30:01 -0000 @@ -4003,6 +4003,13 @@ AC_CONFIG_FILES([Makefile buildpkg.sh op scard/Makefile ssh_prng_cmds survey.sh]) AC_OUTPUT +for i in . openbsd-compat; do + dep="$srcdir/$i/depend" + if test -f "$dep"; then + cat $srcdir/$i/depend >>Makefile + fi +done + # Print summary of options # Someone please show me a better way :) Index: mkdepend.sh =================================================================== RCS file: mkdepend.sh diff -N mkdepend.sh --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ mkdepend.sh 12 Jan 2008 01:29:32 -0000 @@ -0,0 +1,41 @@ +#!/bin/sh +# $Id $ +# Author Darren Tucker 2008. Hereby placed in the public domain. +# + +rm -rf .depend depend openbsd-compat/depend +mkdir -p .depend/openbsd-compat +touch .depend/config.h + +for i in *.c openbsd-compat/*.c; do + egrep '#.*include.*"' ${i} >.depend/${i} +done + +# +# Generate a stripped source tree containing all of the possible includes. +# Protect headers against multiple includes to prevent loops. +# +for i in *.h openbsd-compat/*.h; do + echo "#ifndef ${i}" | tr .\\-/ ___ >.depend/${i} + echo "#define ${i}" | tr .\\-/ ___ >>.depend/${i} + egrep '#.*include.*"' ${i} >>.depend/${i} + echo "#endif" >>.depend/${i} +done + +echo "# Machine generated output from mkdepend below. Do not edit." >depend +cp depend openbsd-compat/depend + +d=`pwd` + +# process stripped tree to produce dependency files +(cd ${d} && for i in *.c; do + gcc -I ${d} -I ${d}/openbsd-compat -MM ${i} + done) | perl -pe "s|${d}/||g" >>depend + +(cd ${d}/openbsd-compat && for i in *.c; do + gcc -I ${d} -I ${d}/openbsd-compat -MM ${i} +done) \ + | perl -pe "s|${d}/openbsd-compat/||g" \ + | perl -pe "s|${d}/|../|g" >>openbsd-compat/depend + +rm -rf .depend -- 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 jonhson.ian at gmail.com Sat Jan 12 15:47:24 2008 From: jonhson.ian at gmail.com (Ian jonhson) Date: Sat, 12 Jan 2008 12:47:24 +0800 Subject: how to test the performance of modified openssh In-Reply-To: <4787D35C.9080601@psc.edu> References: <8f34198c0801082046m30965521n680e372cbb6f3721@mail.gmail.com> <4787D35C.9080601@psc.edu> Message-ID: <8f34198c0801112047r39b59359m8cfc3f6c0e9046cc@mail.gmail.com> > > I don't believe anyone has done any testing on the cost of > > authentication. Truth of the matter is if it is near instance I doubt > > anyone really cares (I sure never have =). > > I care! :) Not a whole lot because we generally see the authentication > process as sunk cost. It matters a lot on low bandwidth long delay > connections involving small transfers. Its more difficult to amortize > the cost of authentication in those instances. > I agree. If the authentication time is too long, users will feel nervous. I have found some of users evaluate the performance mostly from their first login remote server. If the time spent in login is too long, they will believe the performance of whole ssh is too low. Here, the time of first login is determined mostly by authentication module. From strbenjr at yahoo.com Mon Jan 14 23:18:11 2008 From: strbenjr at yahoo.com (Ben H.) Date: Mon, 14 Jan 2008 04:18:11 -0800 (PST) Subject: Regarding the "X509v3 Certificates" patch Message-ID: <50627.81436.qm@web33011.mail.mud.yahoo.com> Dear List, Regarding the "X509v3 Certificates" patch ... (See links below) - http://marc.info/?l=openssh-unix-dev&m=110976923021961&w=2 - http://marc.info/?l=openssh-unix-dev&m=110973268111830&w=2 - http://roumenpetrov.info/openssh How would I apply this patch to the OpenSSH currently in FreeBSD(.org) and/or PC-BSD(.org)?? Please CC: me on the reply because I am not subscribed to this list. Thanks in advance for your reply. Ben Hacker, Jr. strbenjr{a}yahoo.com -- -- -- From rapier at psc.edu Tue Jan 15 02:56:49 2008 From: rapier at psc.edu (Chris Rapier) Date: Mon, 14 Jan 2008 10:56:49 -0500 Subject: how to test the performance of modified openssh In-Reply-To: <4787EDAF.2080705@zip.com.au> References: <8f34198c0801082046m30965521n680e372cbb6f3721@mail.gmail.com> <4787D35C.9080601@psc.edu> <4787EDAF.2080705@zip.com.au> Message-ID: <478B8641.9030601@psc.edu> > Chris: make sure you have clientloop.c rev 1.171. There's a latent bug > that sets the max packet size to nonsensically large values for remote > port forwards, which may or may not be affecting you. Thanks for the hint. I'll check what my revs are and recompile. > I've also done the "time ssh server true" thing Ben suggested when > looking at things that potentially change the connection establishment > time (not that common, but things like Diffie-Hellman tweaks, random > reseeding or the recent protocol 1 ephemeral server key thing). I'm just curious but do any of the authentication procedures, aside from interactive ones, have more challenge response or data exchanges than any of the others? In quite a few situations RTT is going to have an overwhelming effect on perceived performance. > The catch is that if your authentication require user interaction then > you have a massive extra variable which you would need to account for. Users suck. ;) From rapier at psc.edu Tue Jan 15 05:21:24 2008 From: rapier at psc.edu (Chris Rapier) Date: Mon, 14 Jan 2008 13:21:24 -0500 Subject: how to test the performance of modified openssh In-Reply-To: <4787EDAF.2080705@zip.com.au> References: <8f34198c0801082046m30965521n680e372cbb6f3721@mail.gmail.com> <4787D35C.9080601@psc.edu> <4787EDAF.2080705@zip.com.au> Message-ID: <478BA824.2050402@psc.edu> > Chris: make sure you have clientloop.c rev 1.171. There's a latent bug > that sets the max packet size to nonsensically large values for remote > port forwards, which may or may not be affecting you. Just a quick question, the version shipped with 4.7 is 1.181. 1.171 seems to be around 1.5 years old. Version 1.185 says it corrects overly large maximum packet sizes. Should I downgrade to 1.171 or go up to 1.185? From dtucker at zip.com.au Tue Jan 15 06:26:59 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 15 Jan 2008 06:26:59 +1100 Subject: how to test the performance of modified openssh In-Reply-To: <478BA824.2050402@psc.edu> References: <8f34198c0801082046m30965521n680e372cbb6f3721@mail.gmail.com> <4787D35C.9080601@psc.edu> <4787EDAF.2080705@zip.com.au> <478BA824.2050402@psc.edu> Message-ID: <478BB783.4030905@zip.com.au> Chris Rapier wrote: > >> Chris: make sure you have clientloop.c rev 1.171. There's a latent >> bug that sets the max packet size to nonsensically large values for >> remote port forwards, which may or may not be affecting you. > > Just a quick question, the version shipped with 4.7 is 1.181. 1.171 > seems to be around 1.5 years old. Version 1.185 says it corrects overly > large maximum packet sizes. Should I downgrade to 1.171 or go up to 1.185? Ah, I see the discrepancy: it's Portable's 1.171 but it's OpenBSD's 1.185 (the latter is what you'll see in the $OpenBSD tag at the start of the file). Specifically, you want this change: diff -u -p -r1.170 -r1.171 --- clientloop.c 28 Dec 2007 15:45:07 -0000 1.170 +++ clientloop.c 28 Dec 2007 22:37:10 -0000 1.171 @@ -1,4 +1,4 @@ -/* $OpenBSD: clientloop.c,v 1.184 2007/12/28 15:32:24 dtucker Exp $ */ +/* $OpenBSD: clientloop.c,v 1.185 2007/12/28 22:34:47 dtucker Exp $ */ /* * Author: Tatu Ylonen * Copyright (c) 1995 Tatu Ylonen , Espoo, Finland @@ -1745,7 +1745,7 @@ client_request_forwarded_tcpip(const cha } c = channel_new("forwarded-tcpip", SSH_CHANNEL_CONNECTING, sock, sock, -1, - CHAN_TCP_WINDOW_DEFAULT, CHAN_TCP_WINDOW_DEFAULT, 0, + CHAN_TCP_WINDOW_DEFAULT, CHAN_TCP_PACKET_DEFAULT, 0, originator_address, 1); xfree(originator_address); xfree(listen_address); @@ -1803,7 +1803,7 @@ client_request_agent(const char *request return NULL; c = channel_new("authentication agent connection", SSH_CHANNEL_OPEN, sock, sock, -1, - CHAN_X11_WINDOW_DEFAULT, CHAN_TCP_WINDOW_DEFAULT, 0, + CHAN_X11_WINDOW_DEFAULT, CHAN_TCP_PACKET_DEFAULT, 0, "authentication agent connection", 1); c->force_drain = 1; return c; -- 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 open-ssh at tlinx.org Wed Jan 16 14:46:34 2008 From: open-ssh at tlinx.org (Linda Walsh) Date: Tue, 15 Jan 2008 19:46:34 -0800 Subject: Optional 'test' or benchmark cipher Message-ID: <478D7E1A.2030007@tlinx.org> I hope this is the right list, as I'm desiring a feature addition in openssh. I would like the option to have a 'null' cipher (after the initial authorization, similar to 'delayed' for compression). It would have to be enabled on both client and server and server would never use it unless it was both enabled and asked for by the client. I'd strongly prefer it be able to be enabled on a per-host basis on both client and server rather than a global (that may be the default way to treat all ciphers, but not sure). I'd like to use it primarily for internal benchmarks, though I suppose if the password is encrypted, one might be able to transfer non-sensitive or pre-encrypted data over the larger net. Virtually all of my machines seem to be cpu bound (even though 1 pair of newer machines shouldn't be; Not quite sure why I'm not getting more throughput there (yet). Anyway -- being able to "drop" the encryption entirely and use a straight-through connection for the data (emphasizing that I'd prefer not sending cleartext passwords). Keeping the password encrypted allows wider usage across the internet of pre-encrypted or non-sensitive, compressed data. (I'm sorta surprised a null algorithm hasn't already been made available, at least for testing during development.) Hopefully it wouldn't be thought of as a security risk with the appropriate safeguards in place. Linda Walsh From rapier at psc.edu Thu Jan 17 03:03:27 2008 From: rapier at psc.edu (Chris Rapier) Date: Wed, 16 Jan 2008 11:03:27 -0500 Subject: Optional 'test' or benchmark cipher In-Reply-To: <478D7E1A.2030007@tlinx.org> References: <478D7E1A.2030007@tlinx.org> Message-ID: <478E2ACF.7060600@psc.edu> Linda Walsh wrote: > I hope this is the right list, as I'm desiring a feature addition > in openssh. I would like the option to have a 'null' cipher (after > the initial authorization, similar to 'delayed' for compression). > It would have to be enabled on both client and server and server > would never use it unless it was both enabled and asked for by > the client. You should look at HPN-SSH at http://www.psc.edu/networking/projects/hpn-ssh This implements the NONE cipher exactly as you describe with the caveat that it still generate HMACs. Authentication is fully encrypted and it then it switches to the NONE cipher. One important caveat is that you *cannot* use this NONE cipher in interactive sessions. Its only available for bulk data transfers. HPN-SSH does implement a different way of handling the flow control window but you can disable that if you want something more similar to the default functionality of OpenSSH. If you need any help with it or have any questions feel free to ask me since I wrote it. > I'd strongly prefer it be able to be enabled on a per-host > basis on both client and server rather than a global (that may > be the default way to treat all ciphers, but not sure). > > I'd like to use it primarily for internal benchmarks, though > I suppose if the password is encrypted, one might be able to > transfer non-sensitive or pre-encrypted data over the larger > net. Virtually all of my machines seem to be cpu bound (even > though 1 pair of newer machines shouldn't be; Not quite sure > why I'm not getting more throughput there (yet). > > Anyway -- being able to "drop" the encryption entirely and > use a straight-through connection for the data (emphasizing > that I'd prefer not sending cleartext passwords). Keeping > the password encrypted allows wider usage across the > internet of pre-encrypted or non-sensitive, compressed > data. > > (I'm sorta surprised a null algorithm hasn't already been > made available, at least for testing during development.) > > Hopefully it wouldn't be thought of as a security risk with > the appropriate safeguards in place. I do not believe this would ever be included in the main OpenSSH code as it does break some near explicit assumptions about SSH (though it doesn't violate the RFC). From imorgan at nas.nasa.gov Thu Jan 17 03:41:11 2008 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 16 Jan 2008 08:41:11 -0800 Subject: Optional 'test' or benchmark cipher In-Reply-To: <478D7E1A.2030007@tlinx.org> References: <478D7E1A.2030007@tlinx.org> Message-ID: <20080116164111.GA28374@linux55.nas.nasa.gov> On Tue, Jan 15, 2008 at 19:46:34 -0800, Linda Walsh wrote: > I hope this is the right list, as I'm desiring a feature addition > in openssh. I would like the option to have a 'null' cipher (after > the initial authorization, similar to 'delayed' for compression). > It would have to be enabled on both client and server and server > would never use it unless it was both enabled and asked for by > the client. As Chris Rapier has pointed out, the HPN-SSH patch adds this capability. > > I'd strongly prefer it be able to be enabled on a per-host > basis on both client and server rather than a global (that may > be the default way to treat all ciphers, but not sure). I don't know if the HPN-SSH patch supports that functionaliy on the server side. > > I'd like to use it primarily for internal benchmarks, though > I suppose if the password is encrypted, one might be able to > transfer non-sensitive or pre-encrypted data over the larger > net. Virtually all of my machines seem to be cpu bound (even > though 1 pair of newer machines shouldn't be; Not quite sure > why I'm not getting more throughput there (yet). What are you typically seeing for your transfer rates? What cipher/MAC combination are you using and what version of OpenSSL? Also, what version of OpenSSH? > > Anyway -- being able to "drop" the encryption entirely and > use a straight-through connection for the data (emphasizing > that I'd prefer not sending cleartext passwords). Keeping > the password encrypted allows wider usage across the > internet of pre-encrypted or non-sensitive, compressed > data. > > (I'm sorta surprised a null algorithm hasn't already been > made available, at least for testing during development.) Why add a potential security hole merely for the sake of testing? I would think you'd want to test ssh the way it is actually intended to work. > > Hopefully it wouldn't be thought of as a security risk with > the appropriate safeguards in place. > > Linda Walsh > The topic of adding a NONE cipher has comes up on this list from time to time. Each time it has been shot down - for good reasons in my opinion. -- Iain Morgan From kos at arhont.com Thu Jan 17 02:39:57 2008 From: kos at arhont.com (Konstantin V. Gavrilenko) Date: Wed, 16 Jan 2008 15:39:57 +0000 Subject: x509 patch for SSH Message-ID: <478E254D.1070505@arhont.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys, been trying the x509 patch for ssh from Roumen, it works great. However, I can't figure out couple of things, and been trying to solve it for couple of days already. I'am using OpenSSH_4.7p1-hpn12v19, OpenSSL 0.9.8g with 6.1 version of your patch. The serverside hostkey is configured correctly, to present x509v3-sign-rsa dynowork / # ssh-keyscan pingo # pingo SSH-2.0-OpenSSH_4.7p1-hpn12v19 pingo x509v3-sign-rsa Subject:CN=pingo.dmz.arhont.com,OU=IT,O=Arhont Ltd,C=GB Hoever, in the situation, when the clients that haven't been patched to support x509, just could not connect giving the following error: no hostkey alg Is it possible to circumvent this apart from also specifying the dss key, that non-patched clients would understand. The second problem is with clients that are patched, but for one reason or another there is no x509 store setup on the client. They just give out the following error: ssh_x509store_cb: subject='CN=pingo.dmz.arhont.com,OU=IT,O=Arhont Ltd,C=GB', error 20 at 0 depth lookup:unable to get local issuer certificate ssh_verify_cert: verify error, code=20, msg='unable to get local issuer certificate' key_verify failed for server_host_key Is it possible to have a situation when if there is no x509 store set up on the client, it would simply revert to the password based authentication? I have tried setting PubkeyAlgorithms ssh-dss PreferredAuthentications keyboard-interactive but with no effect, same error appears. I would appreciate your help. - -- Respectfully, Konstantin V. Gavrilenko Arhont Ltd - Information Security web: http://www.arhont.com http://www.wi-foo.com e-mail: k.gavrilenko at arhont.com tel: +44 (0) 870 44 31337 fax: +44 (0) 117 969 0141 PGP: Key ID - 0xE81824F4 PGP: Server - keyserver.pgp.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHjiVNxwtGg+gYJPQRAniCAJ0aqw5Ia8Ti6+dGVWGL0KmbTPiAIwCfQeOa G9Ql9I6oPOO9Hyx2N/PAVQc= =LYji -----END PGP SIGNATURE----- From archer at eskimo.com Thu Jan 17 04:02:12 2008 From: archer at eskimo.com (Curt, WE7U) Date: Wed, 16 Jan 2008 09:02:12 -0800 (PST) Subject: Optional 'test' or benchmark cipher In-Reply-To: <20080116164111.GA28374@linux55.nas.nasa.gov> References: <478D7E1A.2030007@tlinx.org> <20080116164111.GA28374@linux55.nas.nasa.gov> Message-ID: On Wed, 16 Jan 2008, Iain Morgan wrote: > The topic of adding a NONE cipher has comes up on this list from time to > time. Each time it has been shot down - for good reasons in my opinion. Yea, thanks a lot... Any hams that want to use SSH for authentication over the air but not encryption of the data cannot do so, whereas we used to be able to with earlier versions of some SSH or other. Legal requirements from the FCC prevent us from using any codes or ciphers for actual data transfer over the airwaves, but we are allowed to do authentication. Curt, one of those hams that'd like to be able to use SSH again over ham radio TCP/IP. -- Curt, WE7U: XASTIR: "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U The world DOES revolve around me: I picked the coordinate system! From mouring at eviladmin.org Thu Jan 17 05:09:11 2008 From: mouring at eviladmin.org (Ben Lindstrom) Date: Wed, 16 Jan 2008 12:09:11 -0600 (CST) Subject: Optional 'test' or benchmark cipher In-Reply-To: <478E2ACF.7060600@psc.edu> References: <478D7E1A.2030007@tlinx.org> <478E2ACF.7060600@psc.edu> Message-ID: On Wed, 16 Jan 2008, Chris Rapier wrote: > Linda Walsh wrote: >> I hope this is the right list, as I'm desiring a feature addition >> in openssh. I would like the option to have a 'null' cipher (after >> the initial authorization, similar to 'delayed' for compression). >> It would have to be enabled on both client and server and server >> would never use it unless it was both enabled and asked for by >> the client. > > You should look at HPN-SSH at http://www.psc.edu/networking/projects/hpn-ssh > > This implements the NONE cipher exactly as you describe with the caveat > that it still generate HMACs. Authentication is fully encrypted and it > then it switches to the NONE cipher. One important caveat is that you > *cannot* use this NONE cipher in interactive sessions. Its only > available for bulk data transfers. > Hmm.. I believe Markus established a few years ago that the HMAC is more costly in terms of preformance than most of the ciphers. If one skims back through the list I think he gave preformance numbers which resulted in our default HMAC/Cipher combination (could be I also saw them via a different list. That was too long ago) .. And I suspect that would have been around the late 2.x release to the early 3.x release... - Ben From rapier at psc.edu Thu Jan 17 06:45:19 2008 From: rapier at psc.edu (Chris Rapier) Date: Wed, 16 Jan 2008 14:45:19 -0500 Subject: Optional 'test' or benchmark cipher In-Reply-To: <20080116164111.GA28374@linux55.nas.nasa.gov> References: <478D7E1A.2030007@tlinx.org> <20080116164111.GA28374@linux55.nas.nasa.gov> Message-ID: <478E5ECF.8030905@psc.edu> Iain Morgan wrote: > I don't know if the HPN-SSH patch supports that functionaliy on the > server side. Ya know, I never thought about it. My feeling was always that if a server wanted to support it then they'd support it and leave it up to the users to decide if they wanted to make use of it. I'll look into this more when I get back from some conferences I'm going to. Speaking of which, if anyone here is goign to the APAN/Joint Techs meeting in Hawaii or the Mardi Gras '08 conferences I'll be presenting on this work. > What are you typically seeing for your transfer rates? What cipher/MAC > combination are you using and what version of OpenSSL? Also, what > version of OpenSSH? Its important to realize that a number of factors go in to throughput and the bottleneck might not be where you think it is. This is why I usually start by benchmarking things with some sort of lightweight test like Iperf. You can even use it with a sample data file to see how your disk I/O is impacting performance. At that point you tune the system to maximize Iperf performance. Then you start with the SSH tests to get a better idea of the overhead imposed. > Why add a potential security hole merely for the sake of testing? I > would think you'd want to test ssh the way it is actually intended to > work. Well... NONE *is* part of the protocol in that its not explicitly banned (its a 'should not' instead of a 'must not'). Under the right circumstances and implementation it doesn't, in my view, impose an unacceptable risk. Even so, use of NONE is a very effective way to determine where internal application bottlenecks might lie. > The topic of adding a NONE cipher has comes up on this list from time to > time. Each time it has been shot down - for good reasons in my opinion. Applications like GridFTP provide secure authentication but don't encrypt or do message authentication on the bulk data. While I'm not a huge fan of GridFTP I don't find any fault in their decision to take this route. From rapier at psc.edu Thu Jan 17 07:09:06 2008 From: rapier at psc.edu (Chris Rapier) Date: Wed, 16 Jan 2008 15:09:06 -0500 Subject: Optional 'test' or benchmark cipher In-Reply-To: References: <478D7E1A.2030007@tlinx.org> <478E2ACF.7060600@psc.edu> Message-ID: <478E6462.1080801@psc.edu> Ben Lindstrom wrote: > Hmm.. I believe Markus established a few years ago that the HMAC is more > costly in terms of preformance than most of the ciphers. I'm not sure I'd agree with that. On our test systems hmac-md5 has a throughput of 404MB/s on 8KiB data blocks while aes128-cbc has a throughput of 120MB/s. If HMAC was as or more expensive than the cipher I'd expect to see less lopsided figures. From openssh at roumenpetrov.info Thu Jan 17 06:39:22 2008 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Wed, 16 Jan 2008 21:39:22 +0200 Subject: x509 patch for SSH In-Reply-To: <478E254D.1070505@arhont.com> References: <478E254D.1070505@arhont.com> Message-ID: <478E5D6A.4020400@roumenpetrov.info> Hi Konstantin, Please, find answers in quoted text. Konstantin V. Gavrilenko wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi guys, > > been trying the x509 patch for ssh from Roumen, it works great. > However, I can't figure out couple of things, and been trying to solve > it for couple of days already. > > I'am using OpenSSH_4.7p1-hpn12v19, OpenSSL 0.9.8g > with 6.1 version of your patch. > > The serverside hostkey is configured correctly, to present x509v3-sign-rsa > > dynowork / # ssh-keyscan pingo > # pingo SSH-2.0-OpenSSH_4.7p1-hpn12v19 > pingo x509v3-sign-rsa Subject:CN=pingo.dmz.arhont.com,OU=IT,O=Arhont > Ltd,C=GB > > > Hoever, in the situation, when the clients that haven't been patched to > support x509, just could not connect giving the following error: > > no hostkey alg > Correct. In sshd_config(HostKey=...) you could list keys from appropriate type. Client with x509 support will dive same result if HostKeyAlgorithms is set to ssh-rsa,ssh-dss in ~/.ssh/config for that host. > Is it possible to circumvent this apart from also specifying the dss > key, that non-patched clients would understand. > > > The second problem is with clients that are patched, but for one reason > or another there is no x509 store setup on the client. > So in this case client could not create trusted certificate chain and verification will reject give certificate. That is part of PKI and you could test what is result with openssl verify ... without trusted certificates. > They just give out the following error: > > ssh_x509store_cb: subject='CN=pingo.dmz.arhont.com,OU=IT,O=Arhont > Ltd,C=GB', error 20 at 0 depth lookup:unable to get local issuer certificate > ssh_verify_cert: verify error, code=20, msg='unable to get local issuer > certificate' > key_verify failed for server_host_key > > > Is it possible to have a situation when if there is no x509 store set up > on the client, it would simply revert to the password based authentication? > In reported case client could not trust host key as result will reject to continue. But you could switch to rsa/dss host-keys (HostKeyAlgorithms ssh-rsa,ssh-dss) for that host and then to set order of authentication methods in PreferredAuthentications. > I have tried setting > PubkeyAlgorithms ssh-dss > The client will use only ssh-dss keys to authenticate to server. HostKeyAlgorithms is for accepted host-keys. > PreferredAuthentications keyboard-interactive > May be you should append "password" if you like to use password authentication if previous listed are rejected by server. > but with no effect, same error appears. > Sure if server don't offer ssh-dss host-key. > I would appreciate your help. > > - -- > Respectfully, > Konstantin V. Gavrilenko > > Arhont Ltd - Information Security > > web: http://www.arhont.com > http://www.wi-foo.com > e-mail: k.gavrilenko at arhont.com > > tel: +44 (0) 870 44 31337 > fax: +44 (0) 117 969 0141 > > PGP: Key ID - 0xE81824F4 > PGP: Server - keyserver.pgp.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.7 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHjiVNxwtGg+gYJPQRAniCAJ0aqw5Ia8Ti6+dGVWGL0KmbTPiAIwCfQeOa > G9Ql9I6oPOO9Hyx2N/PAVQc= > =LYji > -----END PGP SIGNATURE----- > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > Roumen -- Get X.509 certificates support in OpenSSH: http://roumenpetrov.info/openssh/ From open-ssh at tlinx.org Thu Jan 17 12:47:02 2008 From: open-ssh at tlinx.org (Linda Walsh) Date: Wed, 16 Jan 2008 17:47:02 -0800 Subject: Optional 'test' or benchmark cipher In-Reply-To: <20080116164111.GA28374@linux55.nas.nasa.gov> References: <478D7E1A.2030007@tlinx.org> <20080116164111.GA28374@linux55.nas.nasa.gov> Message-ID: <478EB396.30406@tlinx.org> Iain Morgan wrote: > > As Chris Rapier has pointed out, the HPN-SSH patch adds this capability. > I don't know if the HPN-SSH patch supports that functionaliy on the > server side. ---- Sounds like it is unlikely to provide an "easy" way to remove the data encryption from the equation. I'm not clear if the HPN-SSH "patch" is a patch over Ossh or a different, but depending on how much change HPN-SSH adds, I might be benchmarking something that is unrepresentative of Ossh. > What are you typically seeing for your transfer rates? What cipher/MAC > combination are you using and what version of OpenSSL? Also, what > version of OpenSSH? ---- Most are under 12MB/s (which, I know, sounds like very good 100Mbs performance -- cept that I'm expecting Gigabit performance. Interfaces are running at 1G verified w/"ethtool" and "lights on the switches involved". I looped through all of the ciphers transferring a 256MB uncompressible (bzip2'ed) file (No compression enabled on any machine, BTW). The fastest cipher was the first tried (default) aes128-cbc. Most were significantly slower (~3-10X). But the fastest was 16.7MB/s, with the rest under 11.9 (and one ~1.1MB (unexplained slowness between 2 fastest machines). The win machine has 3-switches between it and the other 3 -- they are all off the same switch. > Why add a potential security hole merely for the sake of testing? I > would think you'd want to test ssh the way it is actually intended to > work. ---- I want to test it both ways. How can I easily tell what is due to my network's speed, the SSH protocol, or even the implementation? How is it a security hole? I am proposing that it must be explicitly enabled in sshd_config (allowed on a per-host basis, as it is likely only something someone would use with certain "safe" (likely internal-private) networks. Also, in order to make certain it comes from a valid machine, session authentication should be done "as normal". Only after authentication would null be allowed. For safety on the client, I'm fine with using a 3-factor enabling protocol: 1) enabled/disabled in sitewide ssh_config 2) enabled in user's config, and 3) specify its use on the ssh (or scp) command line with a "--no-data-encrypt" flag. That should spell it out very clearly enough to prevent "accidents". What security holes would I be missing? I can see this not being used just for testing, but also for sending pre-encrypted files -- why encrypt them again? > The topic of adding a NONE cipher has comes up on this list from time to > time. Each time it has been shot down - for good reasons in my opinion. --- The linux kernel includes some non-encrypting ciphers that can be compiled in -- a null cipher and a compressing cipher if memory serves. No one has ever indicated it to be a security hole. Perhaps they are not identical situations, but there is precedence, of a sort. Hardware setup and more detail available if desired. Linda From dkg-openssh.com at fifthhorseman.net Thu Jan 17 16:20:14 2008 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 17 Jan 2008 00:20:14 -0500 Subject: Optional 'test' or benchmark cipher In-Reply-To: <478EB396.30406@tlinx.org> (Linda Walsh's message of "Wed\, 16 Jan 2008 17\:47\:02 -0800") References: <478D7E1A.2030007@tlinx.org> <20080116164111.GA28374@linux55.nas.nasa.gov> <478EB396.30406@tlinx.org> Message-ID: <87sl0xuiy9.fsf@squeak.fifthhorseman.net> On Wed 2008-01-16 20:47:02 -0500, Linda Walsh wrote: > I want to test it both ways. How can I easily tell what is due to my > network's speed, You should be able see what your network is capable of with dd and netcat. On $HOST_A: nc -l -p 12345 | dd of=/dev/null and on $HOST_B: dd if=/dev/zero | nc $HOST_A 12345 That sets a good baseline for what's possible, since it benchmarks the TCP/IP and link layer relatively cleanly. > the SSH protocol When you are testing your ssh throughput, you should also watch your system's statistics (vmstat is a good tool for this on Linux) to see what's hitting a bottleneck. Is your CPU working solidly? Are you swapping? Are you I/O bound? See a recent thread "how to test the performance of modified openssh" on this list for some examples: http://marc.info/?t=119985415800002&r=1&w=2 > or even the implementation? If you want to distinguish between different implementations, you should set up different ssh daemons and clients on identical hosts, using the same authentication strategies and configurations, and benchmark comparisons between the different toolsets. For free software choices on unix-y systems, you might consider lsh, dropbear, mindterm (free for personal use), and putty in addition to OpenSSH. The various combinations of clients and servers could have an effect also. Could be a lot to test, even without getting to the non-free alternatives, but it would be a worthwhile comparison. Please post a link to any findings you come up with. I'm sure many people on this list (ok, at least myself) will be interested. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080117/4fc35041/attachment.bin From kos at arhont.com Thu Jan 17 23:28:58 2008 From: kos at arhont.com (Konstantin V. Gavrilenko) Date: Thu, 17 Jan 2008 12:28:58 +0000 Subject: x509 patch for SSH In-Reply-To: <478E5D6A.4020400@roumenpetrov.info> References: <478E254D.1070505@arhont.com> <478E5D6A.4020400@roumenpetrov.info> Message-ID: <478F4A0A.5080504@arhont.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -------- Original Message -------- Subject: Re: x509 patch for SSH From: Roumen Petrov To: k.gavrilenko at arhont.com CC: openssh-unix-dev at mindrot.org Date: Wed Jan 16 2008 19:39:22 GMT+0000 (BST) > Hi Konstantin, > > Please, find answers in quoted text. > > > Konstantin V. Gavrilenko wrote: > Hi guys, > > been trying the x509 patch for ssh from Roumen, it works great. > However, I can't figure out couple of things, and been trying to solve > it for couple of days already. > > I'am using OpenSSH_4.7p1-hpn12v19, OpenSSL 0.9.8g > with 6.1 version of your patch. > > The serverside hostkey is configured correctly, to present > x509v3-sign-rsa > > dynowork / # ssh-keyscan pingo > # pingo SSH-2.0-OpenSSH_4.7p1-hpn12v19 > pingo x509v3-sign-rsa Subject:CN=pingo.dmz.arhont.com,OU=IT,O=Arhont > Ltd,C=GB > > > Hoever, in the situation, when the clients that haven't been patched to > support x509, just could not connect giving the following error: > > no hostkey alg > >> Correct. >> In sshd_config(HostKey=...) you could list keys from appropriate type. >> Client with x509 support will dive same result if HostKeyAlgorithms is >> set to ssh-rsa,ssh-dss in ~/.ssh/config for that host. Roumen, thanks for the help. I guess I was under assumption that by default all four methods are enabled on the client side, and it will try all of the supported advertised by the server. In my case, x509v3-rsa and ssh-dss, rather then quiting after the first incapable one. > > > Is it possible to circumvent this apart from also specifying the dss > key, that non-patched clients would understand. > > > The second problem is with clients that are patched, but for one reason > or another there is no x509 store setup on the client. > >> So in this case client could not create trusted certificate chain and >> verification will reject give certificate. >> That is part of PKI and you could test what is result with openssl >> verify ... without trusted certificates. Yes, I understand that it will break the verification check and result in error 20, that is due to the openssl verify behavior. > > > They just give out the following error: > > ssh_x509store_cb: subject='CN=pingo.dmz.arhont.com,OU=IT,O=Arhont > Ltd,C=GB', error 20 at 0 depth lookup:unable to get local issuer > certificate > ssh_verify_cert: verify error, code=20, msg='unable to get local issuer > certificate' > key_verify failed for server_host_key > > > Is it possible to have a situation when if there is no x509 store set up > on the client, it would simply revert to the password based > authentication? > >> In reported case client could not trust host key as result will reject >> to continue. >> But you could switch to rsa/dss host-keys (HostKeyAlgorithms >> ssh-rsa,ssh-dss) for that host and then to set order of authentication >> methods in PreferredAuthentications. The funny thing is that when I remove the ssh_ca.pem on the client, this gives out the error 20. Then I set the "HostKeyAlgorithms ssh-dss", it works and allows for a passwordless login using the client cert (providing the client cert is mentioned in the AuthorisedKeyFile) I guess it is a workaround, but can also be considered to be a bug > > > I have tried setting > PubkeyAlgorithms ssh-dss > >> The client will use only ssh-dss keys to authenticate to server. >> HostKeyAlgorithms is for accepted host-keys. > > > PreferredAuthentications keyboard-interactive > >> May be you should append "password" if you like to use password >> authentication if previous listed are rejected by server. Good point, I forgot about it, sorry. > > > but with no effect, same error appears. > >> Sure if server don't offer ssh-dss host-key. No, apparently server was offering both, ssh-dss and x509v3-sign-rsa I just didn't include the full output of the ssh-keyscan. Thanks for your help Roumen. > > > I would appreciate your help. > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> > Roumen - -- Respectfully, Konstantin V. Gavrilenko Managing Director Arhont Ltd - Information Security web: http://www.arhont.com http://www.wi-foo.com e-mail: k.gavrilenko at arhont.com tel: +44 (0) 870 44 31337 fax: +44 (0) 117 969 0141 PGP: Key ID - 0xE81824F4 PGP: Server - keyserver.pgp.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHj0oKxwtGg+gYJPQRAvpTAJ436B44u2bNW0w56slZcDq1ED/AkgCgjabF gu4bjVlzdt1gVRxPHulLOYk= =11Bj -----END PGP SIGNATURE----- From imorgan at nas.nasa.gov Fri Jan 18 04:17:12 2008 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 17 Jan 2008 09:17:12 -0800 Subject: Optional 'test' or benchmark cipher In-Reply-To: <478EB396.30406@tlinx.org> References: <478D7E1A.2030007@tlinx.org> <20080116164111.GA28374@linux55.nas.nasa.gov> <478EB396.30406@tlinx.org> Message-ID: <20080117171712.GA26455@linux55.nas.nasa.gov> On Wed, Jan 16, 2008 at 17:47:02 -0800, Linda Walsh wrote: > > What are you typically seeing for your transfer rates? What cipher/MAC > > combination are you using and what version of OpenSSL? Also, what > > version of OpenSSH? > ---- > Most are under 12MB/s (which, I know, sounds like very good > 100Mbs performance -- cept that I'm expecting Gigabit performance. > > Interfaces are running at 1G verified w/"ethtool" and "lights on > the switches involved". > > I looped through all of the ciphers transferring a 256MB > uncompressible (bzip2'ed) file (No compression enabled on any machine, BTW). The fastest cipher was the first tried (default) aes128-cbc. Most were > significantly slower (~3-10X). But the fastest was 16.7MB/s, with > the rest under 11.9 (and one ~1.1MB (unexplained slowness between 2 fastest > machines). The win machine has 3-switches between it and the other 3 -- > they are all off the same switch. That certainly seems a bit odd to me. Typically arcfour will give you the best performance. And if you are using OpenSSH 4.7 on both ends, I would suggest using umac-64 for the MAC. A quick test yesterday with a 790MB file showed a transfer rate of 28MB/s between two hosts. One was running 4.7p1 built against a recent version of OpenSSL. The other system was a stock RHEL 4 system, which reduced the performance somewhat. On another architecture, I've seen transfer rates around 60 MB/s. You might want to run 'openssl speed' and see what numbers you are getting. It may be that your build of OpenSSL is not optimal for some reason. -- Iain Morgan From rapier at psc.edu Fri Jan 18 04:31:37 2008 From: rapier at psc.edu (Chris Rapier) Date: Thu, 17 Jan 2008 12:31:37 -0500 Subject: Optional 'test' or benchmark cipher In-Reply-To: <478EB396.30406@tlinx.org> References: <478D7E1A.2030007@tlinx.org> <20080116164111.GA28374@linux55.nas.nasa.gov> <478EB396.30406@tlinx.org> Message-ID: <478F90F9.8010103@psc.edu> Linda Walsh wrote: > Sounds like it is unlikely to provide an "easy" way to remove > the data encryption from the equation. Why do you say that? > I'm not clear if the HPN-SSH "patch" is a patch over Ossh or > a different, but depending on how much change HPN-SSH adds, I might > be benchmarking something that is unrepresentative of Ossh. Its a patch against OpenSSH with support for all of the recent releases. It's primary goal is to open up the receive window limitation that imposed by the multiplexing. If the BDP of your path is greater than 64k in the case of 4.6 (or less) or around 1.25MB for 4.7 it can increase your throughput assuming the network and end hosts are well tuned. This performance increase is often large enough to make CPU overhead the limiting bottleneck - which is why we incorporated the NONE cipher switching. >> What are you typically seeing for your transfer rates? What cipher/MAC >> combination are you using and what version of OpenSSL? Also, what >> version of OpenSSH? > ---- > Most are under 12MB/s (which, I know, sounds like very good > 100Mbs performance -- cept that I'm expecting Gigabit performance. > > Interfaces are running at 1G verified w/"ethtool" and "lights on > the switches involved". I'm not sure if you mentioned this or not but are you pegging your CPU? As an aside, using a multicore machine won't help you much as SSH is limited to using one core. Anyway, diagnosing network performance problems can be a complicated proceedure because any number of failures all manifest as the same problem - slow throughput. You should start by making sure that you your TCP receive buffers are large enough to accommodate the throughput you are trying to achieve. They need to be at least the same as the bandwidth delay product (bandwidth and the narrowest point multiplied by the round trip time). If they aren't then increase them using the appropriate methods. You can find out more about this from http://www.psc.edu/networking/projects/tcptune > I want to test it both ways. How can I easily tell what is due to > my network's speed, the SSH protocol, or even the implementation? Start by doing baseline measurements of the network speed. If you haven't looked at it yet Iperf is your best solution for that. Since it doesn't rely on pipes, the filesystem, or anything like that its your lightest weight option. Since it can also run in UDP mode it can even give you information on any unexpected packet loss. Then rerun the tests using a sample file to see how much of a bottleneck disk I/O is. At that point you can determine how much of an impact the application is having. > How is it a security hole? I am proposing that it must be explicitly enabled in sshd_config (allowed on a per-host basis, as it is likely only > something someone would use with certain "safe" (likely internal-private) > networks. Also, in order to make certain it comes from a valid machine, > session authentication should be done "as normal". Only after > authentication would null be allowed. And pretty much that's all been implemented in the HPN-SSH patch. You can't embed the NoneEnabled directive in a Match block at this time. It may or may not be possible but its a good idea and something I'll be looking into over the next few weeks. > That should spell it out very clearly enough to prevent > "accidents". What security holes would I be missing? If you enable NONE switching for interactive data you do actually open a security hole. People *should* have the expectation that anything they type into a secure shell should be, well, secure. I do not think that necessarily applies to bulk data transfer though - with proper safeguards in place. But really, I'm not entirely sure what you want. If you *just* want to benchmark things with and without encryption its not that hard to hack the none cipher back into the cipher lists. If you want a more general solution that can be used in a production environment then you should probably just use the HPN-SSH patch. From openssh at roumenpetrov.info Fri Jan 18 07:44:34 2008 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Thu, 17 Jan 2008 22:44:34 +0200 Subject: x509 patch for SSH In-Reply-To: <478F4A0A.5080504@arhont.com> References: <478E254D.1070505@arhont.com> <478E5D6A.4020400@roumenpetrov.info> <478F4A0A.5080504@arhont.com> Message-ID: <478FBE32.3080002@roumenpetrov.info> Konstantin V. Gavrilenko wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > - -------- Original Message -------- > Subject: Re: x509 patch for SSH > From: Roumen Petrov > To: k.gavrilenko at arhont.com > CC: openssh-unix-dev at mindrot.org > Date: Wed Jan 16 2008 19:39:22 GMT+0000 (BST) > > >> Hi Konstantin, >> >> Please, find answers in quoted text. >> >> >> Konstantin V. Gavrilenko wrote: >> Hi guys, >> >> been trying the x509 patch for ssh from Roumen, it works great. >> However, I can't figure out couple of things, and been trying to solve >> it for couple of days already. >> >> I'am using OpenSSH_4.7p1-hpn12v19, OpenSSL 0.9.8g >> with 6.1 version of your patch. >> >> The serverside hostkey is configured correctly, to present >> x509v3-sign-rsa >> >> dynowork / # ssh-keyscan pingo >> # pingo SSH-2.0-OpenSSH_4.7p1-hpn12v19 >> pingo x509v3-sign-rsa Subject:CN=pingo.dmz.arhont.com,OU=IT,O=Arhont >> Ltd,C=GB >> >> >> Hoever, in the situation, when the clients that haven't been patched to >> support x509, just could not connect giving the following error: >> >> no hostkey alg >> >> >>> Correct. >>> In sshd_config(HostKey=...) you could list keys from appropriate type. >>> Client with x509 support will dive same result if HostKeyAlgorithms is >>> set to ssh-rsa,ssh-dss in ~/.ssh/config for that host. >>> > > Roumen, thanks for the help. > I guess I was under assumption that by default all four methods are > enabled on the client side, and it will try all of the supported > advertised by the server. In my case, x509v3-rsa and ssh-dss, rather > then quiting after the first incapable one. > Yes, by default client/server send list with all supported key in order of preference. From OpenSSH server side list depend of host-keys set by sshd_config and loaded. About "try all of the supported" - No, please read standard - RFC4253 "The Secure Shell (SSH) Transport Layer Protocol", 7.1. Algorithm Negotiation, server_host_key_algorithms: The first algorithm on the client's name-list that satisfies the requirements and is also supported by the server MUST be chosen. If there is no such algorithm, both sides MUST disconnect. >> Is it possible to circumvent this apart from also specifying the dss >> key, that non-patched clients would understand. >> >> >> The second problem is with clients that are patched, but for one reason >> or another there is no x509 store setup on the client. >> >> >>> So in this case client could not create trusted certificate chain and >>> verification will reject give certificate. >>> That is part of PKI and you could test what is result with openssl >>> verify ... without trusted certificates. >>> > > Yes, I understand that it will break the verification check and result > in error 20, that is due to the openssl verify behavior. > Not openssl, it is PKI requirement. >> They just give out the following error: >> >> ssh_x509store_cb: subject='CN=pingo.dmz.arhont.com,OU=IT,O=Arhont >> Ltd,C=GB', error 20 at 0 depth lookup:unable to get local issuer >> certificate >> ssh_verify_cert: verify error, code=20, msg='unable to get local issuer >> certificate' >> key_verify failed for server_host_key >> >> >> Is it possible to have a situation when if there is no x509 store set up >> on the client, it would simply revert to the password based >> authentication? >> >> >>> In reported case client could not trust host key as result will reject >>> to continue. >>> But you could switch to rsa/dss host-keys (HostKeyAlgorithms >>> ssh-rsa,ssh-dss) for that host and then to set order of authentication >>> methods in PreferredAuthentications. >>> > > The funny thing is that when I remove the ssh_ca.pem on the client, this > gives out the error 20. Then I set the "HostKeyAlgorithms ssh-dss", it > works and allows for a passwordless login using the client cert > (providing the client cert is mentioned in the AuthorisedKeyFile) > I guess it is a workaround, but can also be considered to be a bug > See above (rfc4253...). Don't miss server host-keys and user identities. [SNIP] Roumen -- Get X.509 certificates support in OpenSSH: http://roumenpetrov.info/openssh/ From stevensm at gmail.com Fri Jan 18 02:43:32 2008 From: stevensm at gmail.com (Michael Stevens) Date: Thu, 17 Jan 2008 10:43:32 -0500 Subject: Optional 'test' or benchmark cipher In-Reply-To: <478EB396.30406@tlinx.org> References: <478D7E1A.2030007@tlinx.org> <20080116164111.GA28374@linux55.nas.nasa.gov> <478EB396.30406@tlinx.org> Message-ID: <70621a460801170743l62c28388ve7122a3692deed6f@mail.gmail.com> > > Sounds like it is unlikely to provide an "easy" way to remove > the data encryption from the equation. > > I'm not clear if the HPN-SSH "patch" is a patch over Ossh or > a different, but depending on how much change HPN-SSH adds, I might > be benchmarking something that is unrepresentative of Ossh. The HPN patch lets you select none for encryption. You need to have it on both ends to make full use of the patch. To use none you have to have HPN severs on both sides and specify none on the command line. The patch still does the HMAC because we didn't find a significant overhead from that and still wanted the functionality. HPN is a relatively small patch to OpenSSH. When you say OSSH I assume you are talking about OpenSSH and not Bj?rn's OSSH. OpenSSH != OSSH. > > Most are under 12MB/s (which, I know, sounds like very good > 100Mbs performance -- cept that I'm expecting Gigabit performance. > > Did you test blowfish and arcfour? I recall that these were faster than aes128-cbc when I tested this a few years back with two linux 2.6.x machines. Like Chris said, you should test what speeds you can get without openssh by using iperf. Compare that to OpenSSH to see the overhead you are getting from OpenSSH. > > I want to test it both ways. How can I easily tell what is due to > my network's speed, the SSH protocol, or even the implementation? > How is it a security hole? I am proposing that it must be explicitly enabled in sshd_config (allowed on a per-host basis, as it is likely only > something someone would use with certain "safe" (likely internal-private) > networks. Also, in order to make certain it comes from a valid machine, > session authentication should be done "as normal". Only after > authentication would null be allowed. > Test the performance minus any ssh using iperf or some other point to point testing program. If you want to know the throughput you need to calculate how much data you are transferring vs. overhead per transaction, I suggest reading the ssh protocol specs (RFC 4251 etc.). To see what the implementation overhead is take a look at the difference between your ssh less transfter, calculated ssh protocol overhead, and then what you are able to get with none, and a few other ciphers. If you want to enable none for the HMAC talk to Chris or I because we have done this before. Mike From open-ssh at tlinx.org Fri Jan 18 16:05:23 2008 From: open-ssh at tlinx.org (Linda Walsh) Date: Thu, 17 Jan 2008 21:05:23 -0800 Subject: Optional 'test' or benchmark cipher In-Reply-To: <478F90F9.8010103@psc.edu> References: <478D7E1A.2030007@tlinx.org> <20080116164111.GA28374@linux55.nas.nasa.gov> <478EB396.30406@tlinx.org> <478F90F9.8010103@psc.edu> Message-ID: <47903393.3080906@tlinx.org> Chris Rapier wrote: > Its a patch against OpenSSH with support for all of the recent releases. > It's primary goal is to open up the receive window limitation that > imposed by the multiplexing. If the BDP of your path is greater than 64k > in the case of 4.6 (or less) or around 1.25MB for 4.7 it can increase > your throughput assuming the network and end hosts are well tuned. ---- BDP? ... > I'm not sure if you mentioned this or not but are you pegging your CPU? > As an aside, using a multicore machine won't help you much as SSH is > limited to using one core. --- One of the machines is pegged: an aging 2x1GHz PIII. It's hard to say what is happening where, since I'm working with 3 different machine types (4 if you count 1 running WinXP vs. other running Linux). [much stuff about network tuning deleted] ---- The file transfer speed between via scp to a a cpu-limited target (ish, below) is 10.4MB. The same file transfered over CIFS, a file-system protocol, runs at 28.7MB/s. Network tuning isn't the issue, though "end-to-end" latency caused by ssh may be. Someone asked why I wanted to put a null cipher into the default product: One reason -- if I'm transferring a CD.iso or DVD(8.5G) image where either is from one of my CD's or DVD's, I don't need the encryption for the data. I would still want the password encrypted as a matter of policy. I figure that "ssh" with a null cipher "has" to be better than "SMB/CIFS" or NFS. The "oddest" result is pairing my two top-performer workstations with each other (one running windows(ath), the other suse-64bit(asa). Scp from the windows box -> the linux is ***horrible*** (and I'm not pointing fingers at 'ssh', just thought it might be a fairly good "tcp-stream" based xfer if it wasn't slowed down unnecessarily by the slow encryptions. Currently I have no "sshd" running on "ath" (Win), so "copies" to or from are initiated from the windows box. But copying to "asa" uses less than 1% of the cpu on either box but is limited to <1MB/s. Turning the same connection around and initiating a copy from the winbox (ath) from "asa" to the windows box yields the "highest" ssh throughput (expected to be faster since both are faster machines) at "16.7MB/s". Max cpu use is 33% on "asa" (and less on the Win-box, "ath") -- so neither of those ops are cpu limited. I'm NOT wanting you to figure out what is going on there -- its obviously some hardware/software mismatch and ssh could only be a minuscule contributor -- though the 16.7MB/s worries me a bit in that neither machine is cpu-bound. But 'note', using one of the cpu bound machines (ish), got 10.4MB upstream and 12.5 downstream with ssh, though SMB/CIFS speed from the same machine was 28.7MB/s -- likely near fastest I'll get with that protocol due to latency. > Start by doing baseline measurements of the network speed. If you > haven't looked at it yet Iperf is your best solution for that. Since it > doesn't rely on pipes, the filesystem, or anything like that its your > lightest weight option. Since it can also run in UDP mode it can even > give you information on any unexpected packet loss. Then rerun the tests > using a sample file to see how much of a bottleneck disk I/O is. At that > point you can determine how much of an impact the application is having. --- Haven't found a source for Iperf yet. But I get nearly 2x performance over SSH with just using SMB. I doubt disk is playing much of a role (note, that the 250MB file I'm xfering fits in the buffer cache of 3 out of 4 of the machines). > And pretty much that's all been implemented in the HPN-SSH patch. You > can't embed the NoneEnabled directive in a Match block at this time. It > may or may not be possible but its a good idea and something I'll be > looking into over the next few weeks. --- Was preferring to have the standard ssh support it. Obviously, I have the sources and can hack something with-or-without a patch, but I don't want to get into modifying or doing a "special compile" for yet another piece of software (have done it with a few, and eventually I tend to give up my 'special mods' over simplicity). >> That should spell it out very clearly enough to prevent >> "accidents". What security holes would I be missing? > > If you enable NONE switching for interactive data you do actually open a > security hole. People *should* have the expectation that anything they > type into a secure shell should be, well, secure. I do not think that > necessarily applies to bulk data transfer though - with proper > safeguards in place. ---- Well, one of the "requirements", in my proposal was to force the user (interactive or not) to include a switch on the ssh/scp command line, spelling out that encryption was turned off for the data. If the user expects security when choosing a --use-no-encryption option, well, Unix has traditionally allowed people to shoot themselves in the foot if they really want to enough. :-) Additionally, I don't want the non-encryption turned on by default (which I might get if the options were in the config files). > > But really, I'm not entirely sure what you want. --- I want to be able to turn off encryption on the 'normal' openssh product, under specific circumstances, including benchmarking to see what openssh's "end-to-end" latency is, but also for xfering large files over an internal network. While CIFS works well one one of the computers is Windows, It _seems_ to have lower performance between linux machines. > If you *just* want to > benchmark things with and without encryption its not that hard to hack > the none cipher back into the cipher lists. If you want a more general > solution that can be used in a production environment then you should > probably just use the HPN-SSH patch. --- What is "HPN"...I don't recognize it as a cipher. As for "production"... if I wanted this at a company, I'd tend to believe I was "insane". "Deliberately disabling encryption at the server and client in a production environment"? Simply CYA politics should put someone off doing that -- at least over any public network. But the places where I'd want to use it are on "internal networks", where I still wouldn't want my password "open", but for running bulk transfers it can "likely" be a good speed boost. Nearly all of the "internal networks" I've been on in the past 7-9 years or so have used some form of ssh -- usually (AFAIK) Openssh. -------------------------- FWIW, the machines I was testing between: Disk Mach Speed Mem Speed Ossh Ossl ID "OS" Processer GHz GB MB/s ver ver Ath Cygwin/WinXP2 2xCore2-Duo 3.2 3 78.67 4.7p1 .9.8g Ish SuS93+262312 2 x PIII 1 1 55.56 3.9p1 .9.7g Ast SuS103+262312 Celeron 0.9 0.5 27.05 4.6p1 .9.8e Asa SuS103+262312-64 2xCore2-Duo 2 4 170.60 4.6p1 .9.8e Heading notes: OS - linux machines have same kern version: 2.6.23.12 (vanilla) Asa using 64bit version; others 32bit Proc - Hyperthreads OFF; ia32 or x86-64 Mem - Usable mem by OS DiskSpeeds - as measured by "hdparm --direct -t "; used fastest of 5 runs From rapier at psc.edu Sat Jan 19 02:38:28 2008 From: rapier at psc.edu (Chris Rapier) Date: Fri, 18 Jan 2008 10:38:28 -0500 Subject: Optional 'test' or benchmark cipher In-Reply-To: <47903393.3080906@tlinx.org> References: <478D7E1A.2030007@tlinx.org> <20080116164111.GA28374@linux55.nas.nasa.gov> <478EB396.30406@tlinx.org> <478F90F9.8010103@psc.edu> <47903393.3080906@tlinx.org> Message-ID: <4790C7F4.7000800@psc.edu> Linda Walsh wrote: > BDP? ... Bandwidth delay product. Since network transfers aren't instantaneous there is data in transit between two hosts at any time. Any path has a maximum amount of this outstanding data it can hold which is determined by multiplying the bandwidth by the round trip time. If you can keep as much data in transit as the carrying capacity of the path you end up using the network much more efficiently. So if you have a patch with a 2MB BDP and you only have 64KB of data in transit at any time you are only using 3% of the network capacity. The receiving host regulates how much outstanding data there is at anytime with the receive window. So if your receive window is 64KB then the end host will only allow 64KB to be unACKed (or outstanding or in transit) for each round trip time. So this end up limiting your throughput if the BDP is greater than the receive window. As such its important to increase the receive window to at least the same size as the BDP. In multiplexed applications like SSH its necessary to include an application layer receive window. This rides on top of the underlying TCP receive window and your effective receive window for the application will be the minimum of the two. SSH, up until 4.7, had a 64KB receive window. Its been boosted to ~1MB and that really helps a lot of people. This is still small for the faster networks which is where HPN-SSH comes in as we tie the application window to the TCP window. So as long as the TCP window is properly sized the application window will be as well. > One of the machines is pegged: an aging 2x1GHz PIII. It's hard to > say what is happening where, since I'm working with 3 different machine types > (4 if you count 1 running WinXP vs. other running Linux). Yeah, thats a bottleneck right there. None cipher will do a lot for you. > The file transfer speed between via scp to a a cpu-limited > target (ish, below) is 10.4MB. The same file transfered over CIFS, > a file-system protocol, runs at 28.7MB/s. Network tuning isn't the > issue, though "end-to-end" latency caused by ssh may be. Someone It may be but the amount of latency imposed tends to be small. I've not taken the time to quantify this though. I need to skip some stuff as I'mn giving a presentation in a few minutes but I wanted to address a couple of ther things before I do... > Haven't found a source for Iperf yet. But I get nearly > 2x performance over SSH with just using SMB. I doubt disk is playing > much of a role (note, that the 250MB file I'm xfering fits in the > buffer cache of 3 out of 4 of the machines). http://dast.nlanr.net/Projects/Iperf > Was preferring to have the standard ssh support it. Obviously, > I have the sources and can hack something with-or-without a patch, but > I don't want to get into modifying or doing a "special compile" for yet > another piece of software (have done it with a few, and eventually I tend > to give up my 'special mods' over simplicity). I understand entirely. in place. > ---- > Well, one of the "requirements", in my proposal was to force > the user (interactive or not) to include a switch on the ssh/scp command > line, spelling out that encryption was turned off for the data. In the HPN-SSH code the client must use both -oNoneEnabled=yes and -oNoneSwitch=yes in order to use the None switch. NoneEnabled can be set the ssh_config but NoneSwitch must come on the command line. When it enters the NONE cipher it spits out a warning to stderr so users are aware that the switch happened. > I want to be able to turn off encryption on the 'normal' openssh > product, under specific circumstances, including benchmarking to see > what openssh's "end-to-end" latency is, but also for xfering large > files over an internal network. While CIFS works well one one of the > computers is Windows, It _seems_ to have lower performance between > linux machines. While I would like to see the None switch in the base code I'm not entirely sure its going to happen. > What is "HPN"...I don't recognize it as a cipher. Its not a cipher. It stands for High Performance Networking and is a set of modifications to improve SSH performance. Its typically geared towards fast networks but it does have some benefits for people in your situation. More ifnormation can be found at http://www.psc.edu/networking/projects/hpn-ssh Currently its being used by NASA, several governmental organizations, its part of HP-UX, several linux distros, its available though FreeBSD, many supercomputing centers use it, a bunch of financial institutions, tech companies, and so forth. Its not, in anyway, a fork of OpenSSH. > As for "production"... > if I wanted this at a company, I'd tend to believe I was "insane". > "Deliberately disabling encryption at the server and client in a > production environment"? A lot of widely used applications do not encrypt bulk data transfers even if they use encryption for authentication. So I'm not sure I would say it was insane, just a different approach. From kos at arhont.com Sat Jan 19 03:26:30 2008 From: kos at arhont.com (Konstantin V. Gavrilenko) Date: Fri, 18 Jan 2008 16:26:30 +0000 Subject: x509 patch for SSH In-Reply-To: <478FBE32.3080002@roumenpetrov.info> References: <478E254D.1070505@arhont.com> <478E5D6A.4020400@roumenpetrov.info> <478F4A0A.5080504@arhont.com> <478FBE32.3080002@roumenpetrov.info> Message-ID: <4790D336.8040107@arhont.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roumen, one last thing, what exactly does MandatoryCRL option sets? Since when it is set to no, the ssh_crl.pem does get checked whether the cert is revoked or not. However, when I set it to yes, I get the following error I get an error code 3, like this Jan 17 14:46:12 pingo sshd[25026]: debug3: key_match:found matching certificate Jan 17 14:46:12 pingo sshd[25026]: debug1: matching key found: file /etc/ssh/authorized_keys, line 2 Jan 17 14:46:12 pingo sshd[25026]: Found matching RSA+cert key: 42:1d:66:a3:67:67:e3:82:03:ad:9f:1c:b0:3e:fb:2c Jan 17 14:46:12 pingo sshd[25026]: debug3: ssh_x509cert_check: for 'CN=revoked.arhont.com,OU=IT,O=Arhont Ltd,C=GB' Jan 17 14:46:12 pingo sshd[25026]: debug3: ssh_x509revoked_cb: Issuer: CN=Arhont Root CA,O=Arhont Ltd,C=GB Jan 17 14:46:12 pingo sshd[25026]: debug3: ssh_x509revoked_cb: Subject: CN=Arhont Root CA,O=Arhont Ltd,C=GB Jan 17 14:46:12 pingo sshd[25026]: debug3: ssh_check_crl: Issuer: CN=Arhont Root CA,O=Arhont Ltd,C=GB; Last Update: Jan 17 13:29:17 2008 GMT; Next Update: Jan 18 13:29:17 2008 GMT Jan 17 14:46:12 pingo sshd[25026]: debug3: ssh_x509revoked_cb: Issuer: CN=Arhont Root CA,O=Arhont Ltd,C=GB Jan 17 14:46:12 pingo sshd[25026]: debug3: ssh_x509revoked_cb: Subject: CN=revoked.arhont.com,OU=IT,O=Arhont Ltd,C=GB Jan 17 14:46:12 pingo sshd[25026]: error: ssh_x509revoked_cb: unable to get issued CRL Jan 17 14:46:12 pingo sshd[25026]: error: ssh_verify_cert: verify error, code=3, msg='unable to get certificate CRL' Jan 17 14:46:12 pingo sshd[25026]: debug3: ssh_x509cert_check: return - -1(error) Jan 17 14:46:12 pingo sshd[25026]: x509 certificate check reject matching key When I use openssl verify -crl_check everything is fine. yours, kos - -------- Original Message -------- Subject: Re: x509 patch for SSH From: Roumen Petrov To: k.gavrilenko at arhont.com CC: openssh-unix-dev at mindrot.org Date: Thu Jan 17 2008 20:44:34 GMT+0000 (BST) > Konstantin V. Gavrilenko wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> - -------- Original Message -------- >> Subject: Re: x509 patch for SSH >> From: Roumen Petrov >> To: k.gavrilenko at arhont.com >> CC: openssh-unix-dev at mindrot.org >> Date: Wed Jan 16 2008 19:39:22 GMT+0000 (BST) >> >> >>> Hi Konstantin, >>> >>> Please, find answers in quoted text. >>> >>> >>> Konstantin V. Gavrilenko wrote: >>> Hi guys, >>> >>> been trying the x509 patch for ssh from Roumen, it works great. >>> However, I can't figure out couple of things, and been trying to solve >>> it for couple of days already. >>> >>> I'am using OpenSSH_4.7p1-hpn12v19, OpenSSL 0.9.8g >>> with 6.1 version of your patch. >>> >>> The serverside hostkey is configured correctly, to present >>> x509v3-sign-rsa >>> >>> dynowork / # ssh-keyscan pingo >>> # pingo SSH-2.0-OpenSSH_4.7p1-hpn12v19 >>> pingo x509v3-sign-rsa Subject:CN=pingo.dmz.arhont.com,OU=IT,O=Arhont >>> Ltd,C=GB >>> >>> >>> Hoever, in the situation, when the clients that haven't been patched to >>> support x509, just could not connect giving the following error: >>> >>> no hostkey alg >>> >>>> Correct. >>>> In sshd_config(HostKey=...) you could list keys from appropriate type. >>>> Client with x509 support will dive same result if HostKeyAlgorithms is >>>> set to ssh-rsa,ssh-dss in ~/.ssh/config for that host. >>>> >> >> Roumen, thanks for the help. >> I guess I was under assumption that by default all four methods are >> enabled on the client side, and it will try all of the supported >> advertised by the server. In my case, x509v3-rsa and ssh-dss, rather >> then quiting after the first incapable one. >> > Yes, by default client/server send list with all supported key in order > of preference. > From OpenSSH server side list depend of host-keys set by sshd_config and > loaded. > > About "try all of the supported" - No, please read standard - RFC4253 > "The Secure Shell (SSH) Transport Layer Protocol", > > 7.1. Algorithm Negotiation, server_host_key_algorithms: > The first algorithm on the client's name-list > that satisfies the requirements and is also supported by the > server MUST be chosen. If there is no such algorithm, both > sides MUST disconnect. > > >>> Is it possible to circumvent this apart from also specifying the dss >>> key, that non-patched clients would understand. >>> >>> >>> The second problem is with clients that are patched, but for one reason >>> or another there is no x509 store setup on the client. >>> >>>> So in this case client could not create trusted certificate chain and >>>> verification will reject give certificate. >>>> That is part of PKI and you could test what is result with openssl >>>> verify ... without trusted certificates. >>>> >> >> Yes, I understand that it will break the verification check and result >> in error 20, that is due to the openssl verify behavior. >> > Not openssl, it is PKI requirement. > > >>> They just give out the following error: >>> >>> ssh_x509store_cb: subject='CN=pingo.dmz.arhont.com,OU=IT,O=Arhont >>> Ltd,C=GB', error 20 at 0 depth lookup:unable to get local issuer >>> certificate >>> ssh_verify_cert: verify error, code=20, msg='unable to get local issuer >>> certificate' >>> key_verify failed for server_host_key >>> >>> >>> Is it possible to have a situation when if there is no x509 store set up >>> on the client, it would simply revert to the password based >>> authentication? >>> >>>> In reported case client could not trust host key as result will reject >>>> to continue. >>>> But you could switch to rsa/dss host-keys (HostKeyAlgorithms >>>> ssh-rsa,ssh-dss) for that host and then to set order of authentication >>>> methods in PreferredAuthentications. >>>> >> >> The funny thing is that when I remove the ssh_ca.pem on the client, this >> gives out the error 20. Then I set the "HostKeyAlgorithms ssh-dss", it >> works and allows for a passwordless login using the client cert >> (providing the client cert is mentioned in the AuthorisedKeyFile) >> I guess it is a workaround, but can also be considered to be a bug >> > See above (rfc4253...). Don't miss server host-keys and user identities. > > > [SNIP] > Roumen > > - -- Respectfully, Konstantin V. Gavrilenko Arhont Ltd - Information Security web: http://www.arhont.com http://www.wi-foo.com e-mail: k.gavrilenko at arhont.com tel: +44 (0) 870 44 31337 fax: +44 (0) 117 969 0141 PGP: Key ID - 0xE81824F4 PGP: Server - keyserver.pgp.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHkNM1xwtGg+gYJPQRAuaqAJ4o7ye9JnoNiCNfM1Vf9cJ07uZLRgCeOTZg ZIJ6SHEzyElGgBsaX2GZzf4= =Xb0F -----END PGP SIGNATURE----- From open-ssh at tlinx.org Sat Jan 19 08:46:53 2008 From: open-ssh at tlinx.org (Linda Walsh) Date: Fri, 18 Jan 2008 13:46:53 -0800 Subject: Optional 'test' or benchmark cipher In-Reply-To: <4790C7F4.7000800@psc.edu> References: <478D7E1A.2030007@tlinx.org> <20080116164111.GA28374@linux55.nas.nasa.gov> <478EB396.30406@tlinx.org> <478F90F9.8010103@psc.edu> <47903393.3080906@tlinx.org> <4790C7F4.7000800@psc.edu> Message-ID: <47911E4D.6000609@tlinx.org> Chris Rapier wrote: > > > Linda Walsh wrote: > >> BDP? ... > > Bandwidth delay product. Since network transfers aren't instantaneous > there is data in transit between two hosts at any time. Any path has a > maximum amount of this outstanding data it can hold which is determined > by multiplying the bandwidth by the round trip time. If you can keep as > much data in transit as the carrying capacity of the path you end up > using the network much more efficiently. So if you have a patch with a > 2MB BDP and you only have 64KB of data in transit at any time you are > only using 3% of the network capacity. --- Ahhh. I understand the concept. I've just approached it in a different way, since from an application point of view, the "delay" (in my setup) is mostly due to OS and network-stack (OSI model) inefficiencies. My last "round" of network communication "analysis" (limited to my internal network) showed that my worst delays came from WinXP's network stack. With 100Mb/s, I was getting close to the limits of the media (80% saturation, which I didn't think was "unreasonable" given off-the-shelf networking stacks. When I upgraded my internal paths to 1G, full-duplex, switched router, I went so far (for testing purposes, to eliminate all the switches (all 3 of them) between my Win-client and my Samba-server. No different in throughput. I made sure all of my switches and the network cards under test had the jumbo-frames feature. That boosted throughput significantly, but unfortunately, unlike dynamic window-sizing, MTU tests aren't stored between computers but are stored per-segment. I sorta think it is a 'bug' but using a larger MTU, I noticed things appeared to work fine on interactive use (small packets), but any bulk transfers that used the larger packet sizes were **SILENTLY** truncated, so I couldn't expect dynamic MTU adjustment per path. "If only" besides MTU /interface, MTU could be stored / host, but there was no way to easily (quickly) compute MTU size "on the fly". Even if there were, there was no place to store it. I think I came to the conclusion that a separate "MTU-database" (much like the routing database) would need to be constructed with the end user needing to accurately find out the jumbo size each comptuter supported. Got real messy. I also "hoped" that the two faster machines might have large parts of their latency reduced by running on faster machines, but not too helpful in my scenario. I did make sure my TCP-window sizes were setup to their max supported (at the time, think it was 256K). Still didn't help since the rtt between the fastest computers was sufficiently low as to not allow multiple segments to be outstanding at Gigabit speeds between physical interfaces (I did try using different logical interfaces between paths, but was defeated when the logical merged into the common physical. Not all of my machines could support another network card that supported jumbo frames (and vendors didn't agree on the size of "jumbo" (sigh). Unfortunately, it would have required some reworking of the TCP/IP protocol in a non-backwards compatible method, to support different jumbo packet sizes based on the final target. When I updated some of my HW to two Dell-690 workstations (at the time still running I'd hoped to up the packet size or hoped for some speed improvements, but the built-in GB controllers in Dell's workstations didn't support jumbo packets, and the RTT of 1500-byte packets didn't allow for multiple packets to be outstanding (as the transceivers were saturated). The end-to-end latency increased proportional to greater top-level application delay (which was why ssh's delay was more important that raw bandwidth). Oddly (side note), adding back the two switches between the fastest machines had no measurable effect on the ping end-to-end minimum latency. Thus my desire to "decrease" end-to-end latency at the application level and my desire to try a null-cipher in ssh, as I already knew the application was the limiting factor (compared to CIFS) it was half as slow or so). Increasing ssh's outstanding packets might help the app-to-app latency, but I wanted to bench the null-cipher, figuring that would reduce my ssh-to-ssh latency to the minimum possible (removing cipher, only thing left is overhead of ssh's "packetizing" of the data. > In multiplexed applications like SSH its necessary to include an > application layer receive window. --- yup -- which was why I wanted to bench the apps throughput sans the compute-heavy encrypting -- giving me an upper bound. > This rides on top of the underlying > TCP receive window and your effective receive window for the application > will be the minimum of the two. SSH, up until 4.7, had a 64KB receive > window. Its been boosted to ~1MB and that really helps a lot of people. --- Should help long-haul, fast connections with higher latencies. >> One of the machines is pegged: an aging 2x1GHz PIII. It's hard to >> say what is happening where, since I'm working with 3 different >> machine types >> (4 if you count 1 running WinXP vs. other running Linux). > > Yeah, thats a bottleneck right there. None cipher will do a lot for you. --- Hoped there would be some cipher that would run faster, but that wasn't my finding. At least I could "highlight" the effect on speed of the slower CPU vs. same network conditions for faster CPU machines without adding in constant (not related to path length or latency) delay due to crypto-calculations. >> The file transfer speed between via scp to a a cpu-limited >> target (ish, below) is 10.4MB. The same file transfered over CIFS, >> a file-system protocol, runs at 28.7MB/s. Network tuning isn't the >> issue, though "end-to-end" latency caused by ssh may be. Someone > > It may be but the amount of latency imposed tends to be small. I've not > taken the time to quantify this though. --- That's where I was headed. SMB gave me the fastest performance of app-to-app performance. >> Haven't found a source for Iperf yet. But I get nearly >> 2x performance over SSH with just using SMB. I doubt disk is playing >> much of a role (note, that the 250MB file I'm xfering fits in the >> buffer cache of 3 out of 4 of the machines). > > http://dast.nlanr.net/Projects/Iperf --- found it -- wouldn't "config&make" on my windows machine. Even so, the latency indicated by ping for 8K packets seemed to be the l imiting factor, since the ping-time to the lower-cpu-power, "ish" was 10-15% faster, indicating the app-to-app delay was more related to higher-OSI level latencies ( including the application perf). > >> Was preferring to have the standard ssh support it. Obviously, >> I have the sources and can hack something with-or-without a patch, but >> I don't want to get into modifying or doing a "special compile" for yet >> another piece of software (have done it with a few, and eventually I tend >> to give up my 'special mods' over simplicity). > > In the HPN-SSH code the client must use both > -oNoneEnabled=yes and -oNoneSwitch=yes in order to use the None switch. > NoneEnabled can be set the ssh_config but NoneSwitch must come on the > command line. When it enters the NONE cipher it spits out a warning to > stderr so users are aware that the switch happened. --- And that wouldn't be enough to protect users from any increased security risk (would still want host-specific enabling on host -- to only allow such connections "internally", or to specific external hosts. > > While I would like to see the None switch in the base code I'm not > entirely sure its going to happen. ---- Well, that's an annoyance -- Other than user-protection, what other problems would there be with that feature? Seems like protections are almost all in place to prevent accidental security flaws. Are their other technical reasons, or are the remaining reasons based on politics or people's personal egos. While I would think the first could be solved, the latter two aren't usually worth the effort to fight -- though making it clear that it isn't a technical reason and is someone's personal preference isn't always the easiest to ascertain. :~! >> What is "HPN"...I don't recognize it as a cipher. > > Its not a cipher. It stands for High Performance Networking and is a set > of modifications to improve SSH performance. Its typically geared > towards fast networks but it does have some benefits for people in your > situation. More ifnormation can be found at > http://www.psc.edu/networking/projects/hpn-ssh --- Ahhh...will have to check it out. > Currently its being used by NASA, several governmental organizations, > its part of HP-UX, several linux distros, its available though FreeBSD, > many supercomputing centers use it, a bunch of financial institutions, > tech companies, and so forth. --- Sure seems like it would be useful to add to the standard product since HPN-requiring sites only start with government entities, but eventually trickle down into the civilian sector. >> As for "production"... >> if I wanted this at a company, I'd tend to believe I was "insane". >> "Deliberately disabling encryption at the server and client in a >> production environment"? > > A lot of widely used applications do not encrypt bulk data transfers > even if they use encryption for authentication. So I'm not sure I would > say it was insane, just a different approach. ---- I was just thinking of some case where their might have been some "accident" where something important got transfered unencrypted -- and higher ups would look for a scapegoat (ignoring the fact that it is perfectly safe under the conditions for which it was intended). All too often managers and other "performance-averaging" types that don't care if it is safe in the "designed" uses...they just want to blame someone who is doing anything out of the norm. Not that I'd have any experience with such "Dilbertian" management structures. :~/ Will put the HPN on my list -- though it sounds like rebuilding all the clients/servers to 4.7 might also be a good first step just to check if app-to-app latency is helped by the possibility of larger window sizes. Thanks... From openssh at roumenpetrov.info Sun Jan 20 01:50:35 2008 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Sat, 19 Jan 2008 16:50:35 +0200 Subject: x509 patch for SSH In-Reply-To: <4790D336.8040107@arhont.com> References: <478E254D.1070505@arhont.com> <478E5D6A.4020400@roumenpetrov.info> <478F4A0A.5080504@arhont.com> <478FBE32.3080002@roumenpetrov.info> <4790D336.8040107@arhont.com> Message-ID: <47920E3B.8050503@roumenpetrov.info> Konstantin V. Gavrilenko wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Roumen, > > one last thing, what exactly does MandatoryCRL option sets? > > Since when it is set to no, the ssh_crl.pem does get checked whether the > cert is revoked or not. > However, when I set it to yes, I get the following error > [SNIP] > > Jan 17 14:46:12 pingo sshd[25026]: error: ssh_x509revoked_cb: unable to > get issued CRL > [SNIP] When MandatoryCRL is no, check for revoked only if CRL is found in X.509 store. When MandatoryCRL option is set and certificate attribute "CRL Distribution Point" is set, corresponding CRL must exist in X.506 store. Roumen -- Get X.509 certificates support in OpenSSH: http://roumenpetrov.info/openssh/ From mallo_caveira1 at terra.com.br Sun Jan 20 09:53:52 2008 From: mallo_caveira1 at terra.com.br (mallo_caveira1 at terra.com.br) Date: Sat, 19 Jan 2008 20:53:52 -0200 (BRST) Subject: [Mensagem Automatica] =?iso-8859-1?q?Aus=EAncia=2E?= In-Reply-To: <20080119225338.E2F2323AE8A@candelo.hst.terra.com.br> References: <20080119225338.E2F2323AE8A@candelo.hst.terra.com.br> Message-ID: <20080119225352.6629F23AE92@candelo.hst.terra.com.br> This message is an automatic response. Mensagem [Delivered Message (mallo_caveira1 at terra.com.br)] recebida. Caros amigos, Estarei em f?rias. Pe?o por favor em n?o enviar mensagens para n?o sobrecarregar a caixa. Grato. Feliz 2008! From gandalf at le-vert.net Mon Jan 21 00:42:32 2008 From: gandalf at le-vert.net (=?ISO-8859-1?Q?=22Adam_C=E9cile_=28Le=5FVert=29=22?=) Date: Sun, 20 Jan 2008 14:42:32 +0100 Subject: OpenSSH + GeodeLX + Linux + Cryptodev = Corrupted MAC on input. Message-ID: <47934FC8.4030602@le-vert.net> Hello, I just set up Debian Lenny on a PCEngines ALIX. This board have a GeodeLX processor with hardware crypto accelerator, so I patched my kernel to get cryptodev support. Everything is fine when playin with openssl, but openssh just crash when a large amount of data is transfered. A small example: alix:~# scp 100meg.test localhost:/dev/null root at localhost's password: 100meg.test 0% 0 0.0KB/s --:-- ETAReceived disconnect from 127.0.0.1: 2: Corrupted MAC on input. lost connection alix:~# If I unload cryptodev kernel modules, averything works fine again. I found this guy which reported to have the same issue: http://www.docunext.com/wiki/My_Notes_on_Patching_2.6.22_with_OCF#The_Results Tested with OpenSSH 4.6p1 and 4.7p1. Any help would be appreciated. Best regards, Adam. PS: If you don't know at all what's wrong, could you please tell me how to disable cryptodev in sshd (without rebuilding the package wihout --with-ssl-engine) ? Please always CC me, I'm not subscribed. From spamfake at mac.com Mon Jan 21 06:56:04 2008 From: spamfake at mac.com (Richard Mitchell) Date: Sun, 20 Jan 2008 14:56:04 -0500 Subject: route information Message-ID: <38E56CA3-396A-43B9-96AE-014B36FC4072@mac.com> Would it be possible to add a debug option that displays each host name as it connects to them? I create tunnels that sometimes uses 3 intermediate machines before getting to the final destinations (I'm sure others create tunnels that are much deeper). To debug a problem, it would be helpful to see each connection being made. ssh -v[v[v]] doesn't display the hostnames (or I'm missing it in all the other verbage). To farther build upon that, showing ping times between each host and total ping time between the source and destination would be great! Standard ping and traceroute programs don't provide this information because they don't follow the ssh route/tunnel but instead use the standard system routing. Thanks, Richard Mitchell spamfake at mac.com From flavien-ssh at lebarbe.net Mon Jan 21 09:09:05 2008 From: flavien-ssh at lebarbe.net (Flavien Lebarbe) Date: Sun, 20 Jan 2008 23:09:05 +0100 Subject: route information In-Reply-To: <38E56CA3-396A-43B9-96AE-014B36FC4072@mac.com> References: <38E56CA3-396A-43B9-96AE-014B36FC4072@mac.com> Message-ID: <20080120220905.GG21540@flavien.org> Richard Mitchell ecrivait : > Would it be possible to add a debug option that displays each host > name as it connects to them? > > I create tunnels that sometimes uses 3 intermediate machines before > getting to the final destinations (I'm sure others create tunnels that > are much deeper). To debug a problem, it would be helpful to see each > connection being made. If I establish a tunnel : $ ssh -R 3000:host2:2222 host1 sleep 2000 And then in another terminal: $ ssh -p 3000 host1 The second ssh process has no idea that the connection it is making to host1 is forwarded to host2. It talks through a socket with host1, and that's it. It happens that the "active" end is not on host1 but that host1 accepts the connection, connects to host2, and then forwards data to host2, (the sshd-child initiaded by the first ssh command does that). There is no way for the second ssh process to know about it. So it looks to me that what you're asking for is not possible. Regards, Flavien. From spamfake at mac.com Mon Jan 21 09:22:26 2008 From: spamfake at mac.com (Richard Mitchell) Date: Sun, 20 Jan 2008 17:22:26 -0500 Subject: route information In-Reply-To: <20080120220905.GG21540@flavien.org> References: <38E56CA3-396A-43B9-96AE-014B36FC4072@mac.com> <20080120220905.GG21540@flavien.org> Message-ID: <844B4193-77FD-473C-8BBE-6B77FAEE2293@mac.com> On Jan 20, 2008, at 17:09, Flavien Lebarbe wrote: > Richard Mitchell ecrivait : >> Would it be possible to add a debug option that displays each host >> name as it connects to them? >> >> I create tunnels that sometimes uses 3 intermediate machines before >> getting to the final destinations (I'm sure others create tunnels >> that >> are much deeper). To debug a problem, it would be helpful to see >> each >> connection being made. > > > If I establish a tunnel : > $ ssh -R 3000:host2:2222 host1 sleep 2000 > > And then in another terminal: > $ ssh -p 3000 host1 > > The second ssh process has no idea that the connection it is making > to host1 is forwarded to host2. It talks through a socket with host1, > and that's it. It happens that the "active" end is not on host1 but > that host1 accepts the connection, connects to host2, and then > forwards data to host2, (the sshd-child initiaded by the first ssh > command does that). There is no way for the second ssh process to > know about it. So it looks to me that what you're asking for is not > possible. > > Regards, > > Flavien. Hmmm, yes, I guess you are right. I just issue a single command, like: ssh hostD and all of the intermediate steps just happen. I'm using a script, netcat-proxy: #!/bin/sh # $Id: netcat-proxy,v 1.2 2006/05/05 00:21:28 mitchell Exp $ bouncehost=$1 target=$2 port=22 if [ "$3" != "" ]; then port=$3; fi # echo "bouncehost: " $bouncehost # echo "target : " $target # echo "port : " $port ssh $bouncehost nc -w 1 $target $port and then in my config file have: ProxyCommand ~/bin/netcat-proxy hostC %h Giving the illusion that a single ssh command has been issued. And I guess having an option for each ssh to display its endpoints wouldn't work either. Where my ssh hostD would return generate something like: hostA to hostB hostB to hostC hostC to hostD % where each line is being generated from each individual ssh. Richard Mitchell From dtucker at zip.com.au Mon Jan 21 12:02:43 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 21 Jan 2008 12:02:43 +1100 Subject: route information In-Reply-To: <844B4193-77FD-473C-8BBE-6B77FAEE2293@mac.com> References: <38E56CA3-396A-43B9-96AE-014B36FC4072@mac.com> <20080120220905.GG21540@flavien.org> <844B4193-77FD-473C-8BBE-6B77FAEE2293@mac.com> Message-ID: <4793EF33.8060008@zip.com.au> Richard Mitchell wrote: [...] > # echo "bouncehost: " $bouncehost > # echo "target : " $target > # echo "port : " $port If you're going to do this then you would be better off with echo "bouncehost: $bouncehost" >/dev/tty 2>/dev/null so that the output goes to the controlling terminal (if you have one) rather than stdout. This means that anything expecting the ssh connection to be clean (eg scp, rsync) will still work. > ssh $bouncehost nc -w 1 $target $port I have a hack that adds "portforward from stdin/out" which is useful for this kind of thing as it does not require netcat on the intermediate host (eg "ssh -N -L stdio:$target:$port $bouncehost"). The syntax is ugly but it works. -- 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 stuge-openssh-unix-dev at cdy.org Mon Jan 21 13:01:50 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Mon, 21 Jan 2008 03:01:50 +0100 Subject: route information In-Reply-To: <4793EF33.8060008@zip.com.au> References: <38E56CA3-396A-43B9-96AE-014B36FC4072@mac.com> <20080120220905.GG21540@flavien.org> <844B4193-77FD-473C-8BBE-6B77FAEE2293@mac.com> <4793EF33.8060008@zip.com.au> Message-ID: <20080121020150.3702.qmail@cdy.org> On Mon, Jan 21, 2008 at 12:02:43PM +1100, Darren Tucker wrote: > I have a hack that adds "portforward from stdin/out" which is > useful for this kind of thing as it does not require netcat on the > intermediate host (eg "ssh -N -L stdio:$target:$port $bouncehost"). > The syntax is ugly but it works. What does the patch look like? //Peter From dtucker at zip.com.au Mon Jan 21 13:39:30 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 21 Jan 2008 13:39:30 +1100 Subject: route information In-Reply-To: <20080121020150.3702.qmail@cdy.org> References: <38E56CA3-396A-43B9-96AE-014B36FC4072@mac.com> <20080120220905.GG21540@flavien.org> <844B4193-77FD-473C-8BBE-6B77FAEE2293@mac.com> <4793EF33.8060008@zip.com.au> <20080121020150.3702.qmail@cdy.org> Message-ID: <20080121023930.GA6230@gate.dtucker.net> On Mon, Jan 21, 2008 at 03:01:50AM +0100, Peter Stuge wrote: > On Mon, Jan 21, 2008 at 12:02:43PM +1100, Darren Tucker wrote: > > I have a hack that adds "portforward from stdin/out" which is > > useful for this kind of thing as it does not require netcat on the > > intermediate host (eg "ssh -N -L stdio:$target:$port $bouncehost"). > > The syntax is ugly but it works. > > What does the patch look like? Something like this. It doesn't seem to shut down the channel cleanly (which doesn't matter in this case) but other than that it seems to work. Index: channels.c =================================================================== RCS file: /cvs/openssh/channels.c,v retrieving revision 1.255 diff -u -p -r1.255 channels.c --- channels.c 28 Dec 2007 15:43:51 -0000 1.255 +++ channels.c 21 Jan 2008 02:37:17 -0000 @@ -1240,8 +1240,16 @@ port_open_helper(Channel *c, char *rtype { int direct; char buf[1024]; - char *remote_ipaddr = get_peer_ipaddr(c->sock); - int remote_port = get_peer_port(c->sock); + char *remote_ipaddr; + int remote_port; + + if (strcmp(c->ctype, "stdio-forward") == 0) { + remote_ipaddr = xstrdup("STDIO"); + remote_port = 0; + } else { + remote_ipaddr = get_peer_ipaddr(c->sock); + remote_port = get_peer_port(c->sock); + } direct = (strcmp(rtype, "direct-tcpip") == 0); @@ -2341,6 +2349,29 @@ channel_set_af(int af) } static int +channel_setup_stdio_fwd(const char *host_to_connect, u_short port_to_connect) +{ + Channel *c; + int in, out; + + in = dup(STDIN_FILENO); + out = dup(STDOUT_FILENO); + if (in < 0 || out < 0) + fatal("channel_setup_stdio_fwd: dup() in/out failed"); + + c = channel_new("stdio-forward", SSH_CHANNEL_OPENING, in, out, + -1, CHAN_TCP_WINDOW_DEFAULT, CHAN_TCP_PACKET_DEFAULT, + 0, "stdio-forward", 1); + + strlcpy(c->path, host_to_connect, sizeof(c->path)); + c->host_port = port_to_connect; + c->listening_port = 0; + + port_open_helper(c, "direct-tcpip"); + return 1; +} + +static int channel_setup_fwd_listener(int type, const char *listen_addr, u_short listen_port, const char *host_to_connect, u_short port_to_connect, int gateway_ports) { @@ -2362,6 +2393,11 @@ channel_setup_fwd_listener(int type, con error("Forward host name too long."); return 0; } + + /* check for STDIO special case */ + if (listen_port == 0) + return channel_setup_stdio_fwd(host_to_connect, + port_to_connect); /* * Determine whether or not a port forward listens to loopback, Index: readconf.c =================================================================== RCS file: /cvs/openssh/readconf.c,v retrieving revision 1.141 diff -u -p -r1.141 readconf.c --- readconf.c 1 Jan 2008 09:32:26 -0000 1.141 +++ readconf.c 21 Jan 2008 02:37:17 -0000 @@ -240,7 +240,8 @@ add_local_forward(Options *options, cons Forward *fwd; #ifndef NO_IPPORT_RESERVED_CONCEPT extern uid_t original_real_uid; - if (newfwd->listen_port < IPPORT_RESERVED && original_real_uid != 0) + if (newfwd->listen_port > 0 && newfwd->listen_port < IPPORT_RESERVED && + original_real_uid != 0) fatal("Privileged ports can only be forwarded by root."); #endif if (options->num_local_forwards >= SSH_MAX_FORWARDS_PER_DIRECTION) @@ -1217,7 +1218,7 @@ fill_default_options(Options * options) int parse_forward(Forward *fwd, const char *fwdspec) { - int i; + int i, stdio_fwd = 0; char *p, *cp, *fwdarg[4]; memset(fwd, '\0', sizeof(*fwd)); @@ -1239,7 +1240,10 @@ parse_forward(Forward *fwd, const char * switch (i) { case 3: fwd->listen_host = NULL; - fwd->listen_port = a2port(fwdarg[0]); + if (strcmp(fwdarg[0], "stdio") == 0) + stdio_fwd = 1; + else + fwd->listen_port = a2port(fwdarg[0]); fwd->connect_host = xstrdup(cleanhostname(fwdarg[1])); fwd->connect_port = a2port(fwdarg[2]); break; @@ -1256,7 +1260,7 @@ parse_forward(Forward *fwd, const char * xfree(p); - if (fwd->listen_port == 0 || fwd->connect_port == 0) + if ((!stdio_fwd && fwd->listen_port == 0) || fwd->connect_port == 0) goto fail_free; if (fwd->connect_host != NULL && -- 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 stuge-openssh-unix-dev at cdy.org Mon Jan 21 14:43:01 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Mon, 21 Jan 2008 04:43:01 +0100 Subject: route information In-Reply-To: <20080121023930.GA6230@gate.dtucker.net> References: <38E56CA3-396A-43B9-96AE-014B36FC4072@mac.com> <20080120220905.GG21540@flavien.org> <844B4193-77FD-473C-8BBE-6B77FAEE2293@mac.com> <4793EF33.8060008@zip.com.au> <20080121020150.3702.qmail@cdy.org> <20080121023930.GA6230@gate.dtucker.net> Message-ID: <20080121034301.25137.qmail@cdy.org> On Mon, Jan 21, 2008 at 01:39:30PM +1100, Darren Tucker wrote: > On Mon, Jan 21, 2008 at 03:01:50AM +0100, Peter Stuge wrote: > > On Mon, Jan 21, 2008 at 12:02:43PM +1100, Darren Tucker wrote: > > > I have a hack that adds "portforward from stdin/out" which is > > > > What does the patch look like? > > Something like this. I like it! Could it even be extended to do stdio also for the remote port? What does upstream think? I think it would be a nifty feature without too much clutter. //Peter From dtucker at zip.com.au Tue Jan 22 08:11:17 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 22 Jan 2008 08:11:17 +1100 Subject: OpenSSH + GeodeLX + Linux + Cryptodev = Corrupted MAC on input. In-Reply-To: <47934FC8.4030602@le-vert.net> References: <47934FC8.4030602@le-vert.net> Message-ID: <47950A75.9020603@zip.com.au> Adam C?cile (Le_Vert) wrote: > I just set up Debian Lenny on a PCEngines ALIX. This board have a > GeodeLX processor with hardware crypto accelerator, so I patched my > kernel to get cryptodev support. > Everything is fine when playin with openssl, but openssh just crash when > a large amount of data is transfered. > > A small example: > alix:~# scp 100meg.test localhost:/dev/null > root at localhost's password: > 100meg.test > 0% 0 0.0KB/s --:-- ETAReceived disconnect from 127.0.0.1: 2: > Corrupted MAC on input. > lost connection > alix:~# > > If I unload cryptodev kernel modules, averything works fine again. Given that it works without the hardware driver, it sounds like some kind of problem with the crypto engine or the interface to it. Can you run OpenSSL's self-test "make tests" and if so do they pass? -- 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 jonhson.ian at gmail.com Wed Jan 23 07:16:09 2008 From: jonhson.ian at gmail.com (Ian jonhson) Date: Wed, 23 Jan 2008 04:16:09 +0800 Subject: x509 patch for SSH In-Reply-To: <47920E3B.8050503@roumenpetrov.info> References: <478E254D.1070505@arhont.com> <478E5D6A.4020400@roumenpetrov.info> <478F4A0A.5080504@arhont.com> <478FBE32.3080002@roumenpetrov.info> <4790D336.8040107@arhont.com> <47920E3B.8050503@roumenpetrov.info> Message-ID: <8f34198c0801221216u5732c731o6af85fdc7abdd6d5@mail.gmail.com> Is the x598 support going to be embedded in mainstream? On Jan 19, 2008 10:50 PM, Roumen Petrov wrote: > Konstantin V. Gavrilenko wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Roumen, > > > > one last thing, what exactly does MandatoryCRL option sets? > > > > Since when it is set to no, the ssh_crl.pem does get checked whether the > > cert is revoked or not. > > However, when I set it to yes, I get the following error > > [SNIP] > > > > Jan 17 14:46:12 pingo sshd[25026]: error: ssh_x509revoked_cb: unable to > > get issued CRL > > [SNIP] > > When MandatoryCRL is no, check for revoked only if CRL is found in X.509 store. > > > When MandatoryCRL option is set and certificate attribute "CRL Distribution Point" is set, > > corresponding CRL must exist in X.506 store. > > > Roumen > > -- > Get X.509 certificates support in OpenSSH: > http://roumenpetrov.info/openssh/ > > > _______________________________________________ > > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From jonhson.ian at gmail.com Wed Jan 23 07:21:56 2008 From: jonhson.ian at gmail.com (Ian jonhson) Date: Wed, 23 Jan 2008 04:21:56 +0800 Subject: x509 patch for SSH In-Reply-To: <8f34198c0801221216u5732c731o6af85fdc7abdd6d5@mail.gmail.com> References: <478E254D.1070505@arhont.com> <478E5D6A.4020400@roumenpetrov.info> <478F4A0A.5080504@arhont.com> <478FBE32.3080002@roumenpetrov.info> <4790D336.8040107@arhont.com> <47920E3B.8050503@roumenpetrov.info> <8f34198c0801221216u5732c731o6af85fdc7abdd6d5@mail.gmail.com> Message-ID: <8f34198c0801221221x4128cd46p308c9590f3015df5@mail.gmail.com> BTW, why I can not open the following website again, http://roumenpetrov.info/openssh/ Is it changed? On Jan 23, 2008 4:16 AM, Ian jonhson wrote: > Is the x598 support going to be embedded in mainstream? > > > > On Jan 19, 2008 10:50 PM, Roumen Petrov wrote: > > Konstantin V. Gavrilenko wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Roumen, > > > > > > one last thing, what exactly does MandatoryCRL option sets? > > > > > > Since when it is set to no, the ssh_crl.pem does get checked whether the > > > cert is revoked or not. > > > However, when I set it to yes, I get the following error > > > [SNIP] > > > > > > Jan 17 14:46:12 pingo sshd[25026]: error: ssh_x509revoked_cb: unable to > > > get issued CRL > > > [SNIP] > > > > When MandatoryCRL is no, check for revoked only if CRL is found in X.509 store. > > > > > > When MandatoryCRL option is set and certificate attribute "CRL Distribution Point" is set, > > > > corresponding CRL must exist in X.506 store. > > > > > > Roumen > > > > -- > > Get X.509 certificates support in OpenSSH: > > http://roumenpetrov.info/openssh/ > > > > > > _______________________________________________ > > > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > From openssh at roumenpetrov.info Wed Jan 23 17:54:05 2008 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Wed, 23 Jan 2008 08:54:05 +0200 Subject: x509 patch for SSH In-Reply-To: <8f34198c0801221221x4128cd46p308c9590f3015df5@mail.gmail.com> References: <478E254D.1070505@arhont.com> <478E5D6A.4020400@roumenpetrov.info> <478F4A0A.5080504@arhont.com> <478FBE32.3080002@roumenpetrov.info> <4790D336.8040107@arhont.com> <47920E3B.8050503@roumenpetrov.info> <8f34198c0801221216u5732c731o6af85fdc7abdd6d5@mail.gmail.com> <8f34198c0801221221x4128cd46p308c9590f3015df5@mail.gmail.com> Message-ID: <4796E48D.7070202@roumenpetrov.info> Ian jonhson wrote: > BTW, why I can not open the following website again, > > http://roumenpetrov.info/openssh/ > > > Is it changed? > No. Site is online. > On Jan 23, 2008 4:16 AM, Ian jonhson wrote: > >> Is the x598 support going to be embedded in mainstream? >> >> [SNIP] >> Roumen From e5pivovarov at hotmail.com Fri Jan 25 16:50:22 2008 From: e5pivovarov at hotmail.com (E Pivovarov) Date: Thu, 24 Jan 2008 21:50:22 -0800 Subject: OpenSSH for OS/390 Message-ID: I have been trying to compile OpenSSH_4.7p1 for OS/390 and got really stuck. IBM released a build of v3.8.1p1 several years ago, but I do not know whether anyone else has ever managed to compile it for OS/390 or OS/z. The first problem is that the build apparently performs ssh transport exchange using EBCDIC character encoding instead of ASCII (which breaks RFC 4253) and I am not sure how to do the conversion properly so that it will not corrupt truely binary data. The second problem is that connection fails even for ssh client and deamon that belong to the same build. Here is the output of sshd (the client has received SSH2_MSG_SERVICE_ACCEPT and is running dispatch_run): debug1: attempt 0 failures 0 debug3: mm_getpwnamallow entering debug3: mm_request_send entering: type 6 debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM debug3: mm_request_receive_expect entering: type 7 debug3: mm_request_receive entering debug3: monitor_read: checking request 6 debug3: mm_answer_pwnamallow debug3: Trying to reverse map address 10.55.27.21. debug2: parse_server_config: config reprocess config len 209 debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 debug3: mm_request_send entering: type 7 debug2: monitor_read: 6 used once, disabling now debug3: mm_request_receive entering mm_getpwnamallow: option block size mismatch It appears that some of the debugging messages are coming from the parent thread and some from the child thread. All I can add is that the buffer "m" in mm_getpwnamallow() has alloc=32768, offset=52, end=10055 and also that buffer_get_string() returns len=7, which is rather different from sizeof(*newopts)=9988, indeed. I am really lost here and cannot figure out what is wrong. Can anybody advise me on how to fix it or perhaps there is already a patch? Thanks, Eugene _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan From aharasymiw at shoppersdrugmart.ca Sat Jan 26 04:17:42 2008 From: aharasymiw at shoppersdrugmart.ca (Andrew Harasymiw) Date: Fri, 25 Jan 2008 12:17:42 -0500 Subject: Availablity of OpenSSH on SCO Unixware 7.1.2 Message-ID: <278FF45ECEEC9047BF088C218BFF0C4402F23C97@CORPEX04.sdmnet.ca> I have been asked to investigate the use of OpenSSH on some of our systems. These systems are running SCO OpenUnix ( Unixware 7.1.2). Are you aware of any issues that may prevent me from using OpenSSH on this version of SCO. Thank you Andrew Harasymiw Senior Technical Analyst Shoppers Drug Mart Office: (416) 493-1220 Ext: 5225 Cell: (416) 553-4616 Email: aharasymiw at shoppersdrugmart.ca From rob at nofocus.org Sat Jan 26 07:21:34 2008 From: rob at nofocus.org (Robert Banz) Date: Fri, 25 Jan 2008 12:21:34 -0800 Subject: Availablity of OpenSSH on SCO Unixware 7.1.2 In-Reply-To: <278FF45ECEEC9047BF088C218BFF0C4402F23C97@CORPEX04.sdmnet.ca> References: <278FF45ECEEC9047BF088C218BFF0C4402F23C97@CORPEX04.sdmnet.ca> Message-ID: Have you tried it yet? OpenSSH builds and works fine on a wide variety of systems... -rob On Jan 25, 2008, at 9:17 AM, Andrew Harasymiw wrote: > I have been asked to investigate the use of OpenSSH on some of our > systems. > > > > These systems are running SCO OpenUnix ( Unixware 7.1.2). > > > > Are you aware of any issues that may prevent me from using OpenSSH on > this version of SCO. From tim at multitalents.net Sat Jan 26 08:45:08 2008 From: tim at multitalents.net (Tim Rice) Date: Fri, 25 Jan 2008 13:45:08 -0800 (PST) Subject: Availablity of OpenSSH on SCO Unixware 7.1.2 In-Reply-To: <278FF45ECEEC9047BF088C218BFF0C4402F23C97@CORPEX04.sdmnet.ca> References: <278FF45ECEEC9047BF088C218BFF0C4402F23C97@CORPEX04.sdmnet.ca> Message-ID: On Fri, 25 Jan 2008, Andrew Harasymiw wrote: > I have been asked to investigate the use of OpenSSH on some of our > systems. > > These systems are running SCO OpenUnix ( Unixware 7.1.2). > > Are you aware of any issues that may prevent me from using OpenSSH on > this version of SCO. OpenSSH works fine on UnixWare 7.x/OpenUNIX 8 I have 7.1.1 & 7.1.4 running here. Keep in mind you will need to build OpenSSL first. I migrated off of 7.1.2 to 7.1.3 back in Dec 2003 and I can't remember if it has a built-in random number generator (/dev/random, /dev/urandom). If I remember correctly, 7.1.2 was the first release to have it. Check on your system. If it doesn't have it, you'll need to build/install prng then build/install OpenSSL, then OpenSSH. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net Supporting UnixWare since the 1.1 days. From dtucker at zip.com.au Sun Jan 27 22:13:16 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 27 Jan 2008 22:13:16 +1100 Subject: OpenSSH for OS/390 In-Reply-To: References: Message-ID: <20080127111316.GA8333@gate.dtucker.net> On Thu, Jan 24, 2008 at 09:50:22PM -0800, E Pivovarov wrote: > I have been trying to compile OpenSSH_4.7p1 for OS/390 and got really > stuck. IBM released a build of v3.8.1p1 several years ago, but I do > not know whether anyone else has ever managed to compile it for OS/390 > or OS/z. > The first problem is that the build apparently performs ssh transport > exchange using EBCDIC character encoding instead of ASCII (which breaks > RFC 4253) and I am not sure how to do the conversion properly so that > it will not corrupt truely binary data. I vaguely recall someone posting about that quite some time back, I would check the list archive... ah, here we are: http://marc.info/?l=openssh-unix-dev&m=106561577824857&w=2 > The second problem is that connection fails even for ssh client and > deamon that belong to the same build. Here is the output of sshd (the > client has received SSH2_MSG_SERVICE_ACCEPT and is running dispatch_run): [...] > It appears that some of the debugging messages are coming from the > parent thread and some from the child thread. All I can add is that the > buffer "m" in mm_getpwnamallow() has alloc=32768, offset=52, end=10055 and > also that buffer_get_string() returns len=7, which is rather different > from sizeof(*newopts)=9988, indeed. I am really lost here and cannot > figure out what is wrong. That looks pretty wrong but I can't think of any reason it would happen. Does this patch make any difference, what is the output of the XXX lines? Index: monitor.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/monitor.c,v retrieving revision 1.126 diff -u -p -r1.126 monitor.c --- monitor.c 2 Dec 2007 12:02:15 -0000 1.126 +++ monitor.c 27 Jan 2008 11:05:01 -0000 @@ -607,6 +607,7 @@ mm_answer_pwnamallow(int sock, Buffer *m char *username; struct passwd *pwent; int allowed = 0; + u_int len; debug3("%s", __func__); @@ -645,7 +646,9 @@ mm_answer_pwnamallow(int sock, Buffer *m buffer_put_cstring(m, pwent->pw_shell); out: - buffer_put_string(m, &options, sizeof(options)); + len = sizeof(options); + logit("XXX sending option block, size %u", len); + buffer_put_string(m, &options, len); if (options.banner != NULL) buffer_put_cstring(m, options.banner); debug3("%s: sending MONITOR_ANS_PWNAM: %d", __func__, allowed); Index: monitor_wrap.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/monitor_wrap.c,v retrieving revision 1.76 diff -u -p -r1.76 monitor_wrap.c --- monitor_wrap.c 2 Dec 2007 12:02:15 -0000 1.76 +++ monitor_wrap.c 27 Jan 2008 11:02:04 -0000 @@ -240,8 +240,10 @@ mm_getpwnamallow(const char *username) out: /* copy options block as a Match directive may have changed some */ newopts = buffer_get_string(&m, &len); + logit("XXX got option block size %u", len); if (len != sizeof(*newopts)) - fatal("%s: option block size mismatch", __func__); + fatal("%s: option block size mismatch expected %u got %u", + __func__, sizeof(*newopts), len); if (newopts->banner != NULL) newopts->banner = buffer_get_string(&m, NULL); copy_set_server_options(&options, newopts, 1); -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From openssh at roumenpetrov.info Sun Jan 27 23:41:01 2008 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Sun, 27 Jan 2008 14:41:01 +0200 Subject: have configure generate header dependencies automatically Message-ID: <479C7BDD.8020208@roumenpetrov.info> Hi Darren, > On Thu, Jan 10, 2008 at 09:11:18AM +1100, Darren Tucker wrote: > [...] >> That said, I think something like that (or mkdep from OpenBSD as >> mentioned in my original mail) would be OK as long as either the result >> is checked into CVS (not done at build time) or is an optional extra. >> >> The down side of this strategy is that the output of those types of >> tools is usually dependent on the compiler flags passed to the tool. >> Hence my "if all you have is a hammer, every problem looks like a nail" >> solution using configure :-) > > Here's one possible solution. It preprocesses the entire tree and > strips out everything except the #includes, processes the tree > with gcc -MM and stores the result. Because the #ifdefs have been > removed, the result is effectively the dependencies for every possible > configuration (all at once). > > At configure time, if the dependency info is available then it's > appended to the Makefile, otherwise it's a no-op. If we check the > depend files into CVS and make sure they're current when building > releases then I think it would work out. > > If anyone wants to try this (particularly with a non-gcc compiler > and vendor make) I have put up a snapshot with this change here: > http://www.zip.com.au/~dtucker/tmp/openssh-depend3.tar.gz > > Index: Makefile.in > =================================================================== > [SNIP] What about makedepend or ccmakedep command ? I think that dependency should be generated only if is requested. As example Makefile.in to end with: ===== depend: (cd openbsd-compat && $(MAKE)) makedepend -- $(CFLAGS) -- $(srcdir)/*.c ===== If the commands above are not so good then I don't have objections depend-files to be distributed with source. In this case proposed by you shell script mkdepend.sh could be used to generate them before source packages to be created. I don't agree with changes in configure. The command config.status can recreate makefiles and dependency will lost. I attach file "bootstrap.sh" to show sample solution - macro AC_CONFIG_COMMANDS. Since the dependency is suitable mostly for developers I prefer solution based on new tag(in makefile{.in}) without dependency information to be distributed with source code. Regards, Roumen -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bootstrap.sh Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080127/5e9165c9/attachment.ksh From e5pivovarov at hotmail.com Mon Jan 28 09:36:37 2008 From: e5pivovarov at hotmail.com (E Pivovarov) Date: Sun, 27 Jan 2008 14:36:37 -0800 Subject: OpenSSH for OS/390 In-Reply-To: <20080127111316.GA8333@gate.dtucker.net> References: <20080127111316.GA8333@gate.dtucker.net> Message-ID: On Sun, 27 Jan 2008 22:13:16 +1100 Darren Tucker wrote:> I vaguely recall someone posting about that quite some time back, I would> check the list archive... ah, here we are:> http://marc.info/?l=openssh-unix-dev&m=106561577824857&w=2 Thanks!! Actually this should be very helpful, indeed. >> It appears that some of the debugging messages are coming from the>> parent thread and some from the child thread. All I can add is that the>> buffer "m" in mm_getpwnamallow() has alloc=32768, offset=52, end=10055 and>> also that buffer_get_string() returns len=7, which is rather different>> from sizeof(*newopts)=9988, indeed. I am really lost here and cannot>> figure out what is wrong.> > That looks pretty wrong but I can't think of any reason it would happen.> Does this patch make any difference, what is the output of the XXX lines? I believe that I have figured it out. The root of the problem is that passwd structure on z/OS and OS/390 is rather different from that on Unix because there is no /etc/passwd on the mainframe. (The errors were caused by my somewhat naive patch was not consistent.) Perhaps to do a proper password authentication one has to integrate OpenSSH with RACF. However, the thread to which you have referred me seems to address this issue, too. Thanks, Eugene _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan From ml at t-b-o-h.net Tue Jan 29 14:40:18 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H) Date: Mon, 28 Jan 2008 22:40:18 -0500 (EST) Subject: Frequent "Connection reset by peer" Message-ID: <200801290340.m0T3eINs070644@vjofn.tucs-beachin-obx-house.com> Hi, Is there a way to tell why I'm getting frequent "Connection reset by peer" all of a sudden? I'm using a FreeBSD machine, plugged via eithernet to a Linksys router running DD-WRT, to another Linksys 50 feet away running DD-WRT, both of them WDS'd together, plugged via ethernet to another FreeBSD machine. With debug cranked, I see : debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i0/0 o0/0 fd 4/5) debug3: channel 0: close_fds r 4 w 5 e 6 Read from remote host 10.0.0.1: Connection reset by peer Connection to 10.0.0.1 closed. debug1: Transferred: stdin 0, stdout 0, stderr 90 bytes in 106.9 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.8 debug1: Exit status -1 Thanks, Tuc From dtucker at zip.com.au Tue Jan 29 16:11:32 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 29 Jan 2008 16:11:32 +1100 Subject: Frequent "Connection reset by peer" In-Reply-To: <200801290340.m0T3eINs070644@vjofn.tucs-beachin-obx-house.com> References: <200801290340.m0T3eINs070644@vjofn.tucs-beachin-obx-house.com> Message-ID: <479EB584.2000406@zip.com.au> Tuc at T-B-O-H wrote: > Is there a way to tell why I'm getting frequent > "Connection reset by peer" all of a sudden? > > I'm using a FreeBSD machine, plugged via eithernet to a Linksys > router running DD-WRT, to another Linksys 50 feet away running DD-WRT, > both of them WDS'd together, plugged via ethernet to another FreeBSD machine. > With debug cranked, I see : 1) check the SSH server's logs to see if there's any logged message corresponding to the disconnects. If the problem is easy to reproduce, you could run sshd in debug mode in the foreground (eg "/path/to/sshd -ddde -p 2022" then connect to port 22). 2) if that doesn't have anything, or has the same "connection reset by peer message" then you probably will need to run tcpdump or similar to see which end is generating the TCP RST (in theory it should be only generated by one of the TCP endpoints but it could also be generated by, eg an intermediate NAT box). -- 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 rapier at psc.edu Wed Jan 30 05:47:54 2008 From: rapier at psc.edu (Chris Rapier) Date: Tue, 29 Jan 2008 13:47:54 -0500 Subject: Available: Multi-threaded AES-CTR Cipher Message-ID: <479F74DA.4080301@psc.edu> On multiple core systems OpenSSH is limited to using a single core for all operations. On these systems this can result in a transfer being processor bound even though additional CPU resources exist. In order to open up this bottleneck we've developed a multi-threaded version of the AES-CTR cipher. Unlike CBC mode, since there is no dependency between cipher blocks in CTR mode we parallelize cipher block operations among multiple threads. Furthermore, since the AES_encrypt operations do not depend on the data to be ciphered we pre-generate the effective keystream. The main thread still handles the packetization, MAC computation, and associated I/O but the computationally expensive AES_encrypt operations are offloaded to one or more additional cores. In our tests this resulted in a performance improvement of up to 125% on systems that were previously CPU bound. In fact, utilizing less than four cores we were able to achieve near line rate on a GigE LAN connection with 128, 192, and 256-bit AES. More details on the implementation can be found at http://www.internet2.edu/presentations/jt2008jan/20080122-rapier-bennett.htm starting at slide 30. Results can be found on slide 46. As the resulting cipher stream is indistinguishable from the original single-threaded implementation of AES-CTR there are no known issues with backward compatibility. This patch should be thought of as experimental at this point. While it has performed well in test environments it is not yet, to our knowledge, deployed in critical production environments and the threading can impose a performance penalty on single core systems (but only when using AES-CTR). We're still exploring methods to have single-threaded and multi-threaded implementations of CTR mode exist side by side. The patch itself can be found at http://www.psc.edu/networking/projects/hpn-ssh/ or more specifically http://www.psc.edu/networking/projects/hpn-ssh/openssh4.7-CTR-threading.diff Additionally, this patch will apply on top of the HPN-SSH12v20 patch. It will, within a week or so, be incorporated into the HPN suite of patches as HPN13. If you have any problems applying the patch please let us know. Any comments, suggestions, or critiques you may have are welcome and appreciated. From ml at t-b-o-h.net Wed Jan 30 07:28:20 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Tue, 29 Jan 2008 15:28:20 -0500 (EST) Subject: [openssh] Re: Frequent "Connection reset by peer" In-Reply-To: <479EB584.2000406@zip.com.au> Message-ID: <200801292028.m0TKSKFR022786@himinbjorg.tucs-beachin-obx-house.com> > > Tuc at T-B-O-H wrote: > > Is there a way to tell why I'm getting frequent > > "Connection reset by peer" all of a sudden? > > > > I'm using a FreeBSD machine, plugged via eithernet to a Linksys > > router running DD-WRT, to another Linksys 50 feet away running DD-WRT, > > both of them WDS'd together, plugged via ethernet to another FreeBSD machine. > > With debug cranked, I see : > > 1) check the SSH server's logs to see if there's any logged message > corresponding to the disconnects. If the problem is easy to reproduce, > you could run sshd in debug mode in the foreground (eg "/path/to/sshd > -ddde -p 2022" then connect to port 22). > > 2) if that doesn't have anything, or has the same "connection reset by > peer message" then you probably will need to run tcpdump or similar to > see which end is generating the TCP RST (in theory it should be only > generated by one of the TCP endpoints but it could also be generated by, > eg an intermediate NAT box). > Hi, Thanks for the reply... 1) Nothing out of the ordinary in the logs. Last bit of logging from the server before/after it happens : debug3: tty_parse_modes: 93 0 debug1: server_input_channel_req: channel 0 request shell reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug1: PAM: setting PAM_TTY to "/dev/ttyp4" debug2: fd 5 setting TCP_NODELAY debug2: channel 0: rfd 10 isatty debug2: fd 10 setting O_NONBLOCK debug2: fd 9 is O_NONBLOCK debug1: Setting controlling tty using TIOCSCTTY. debug3: mm_answer_pty: tty /dev/ttyp4 ptyfd 3 debug3: mm_request_receive entering Read error from remote host 10.0.0.1: Connection reset by peer debug1: do_cleanup debug1: PAM: cleanup debug3: PAM: sshpam_thread_cleanup entering debug1: do_cleanup debug1: PAM: cleanup debug3: PAM: sshpam_thread_cleanup entering debug1: session_pty_cleanup: session 0 release /dev/ttyp4 2) TCPDUMP available to anyone that wants it via email (21K) The last "good" packet between the SSH server and client looked pretty normal, has Flags of PSH and ACK. The next packet comes from the router closest to the SSH server. There is no sequence or acknowledgement number, but its claiming to originate from the same port that the client originally was using. The window size is 1/2 of what the client/server window was. Its sending to the SSH server an ACK. The next packet is from the SSH server to the router, there is no sequence number, window size is 0, Flags are RST. Next packet is from the SSH server to the client, marked as a TCP retransmission, same sequence as the last "good" packet, PSH,ACK Last packet is from SSH client to server, with RST Flag set. So why is the router jumping into the middle of the conversation and being a spoil sport? Thanks, Tuc From dtucker at zip.com.au Wed Jan 30 13:08:58 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 30 Jan 2008 13:08:58 +1100 Subject: [openssh] Re: Frequent "Connection reset by peer" In-Reply-To: <200801292028.m0TKSKFR022786@himinbjorg.tucs-beachin-obx-house.com> References: <200801292028.m0TKSKFR022786@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <479FDC3A.9010106@zip.com.au> Tuc at T-B-O-H.NET wrote: >> Tuc at T-B-O-H wrote: >>> Is there a way to tell why I'm getting frequent >>> "Connection reset by peer" all of a sudden? >>> >>> I'm using a FreeBSD machine, plugged via eithernet to a Linksys >>> router running DD-WRT, to another Linksys 50 feet away running DD-WRT, >>> both of them WDS'd together, plugged via ethernet to another FreeBSD machine. >>> With debug cranked, I see : >> 1) check the SSH server's logs to see if there's any logged message >> corresponding to the disconnects. If the problem is easy to reproduce, >> you could run sshd in debug mode in the foreground (eg "/path/to/sshd >> -ddde -p 2022" then connect to port 22). >> >> 2) if that doesn't have anything, or has the same "connection reset by >> peer message" then you probably will need to run tcpdump or similar to >> see which end is generating the TCP RST (in theory it should be only >> generated by one of the TCP endpoints but it could also be generated by, >> eg an intermediate NAT box). >> > Hi, > > Thanks for the reply... > > 1) Nothing out of the ordinary in the logs. > > Last bit of logging from the server before/after it happens : > > debug3: tty_parse_modes: 93 0 > debug1: server_input_channel_req: channel 0 request shell reply 0 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req shell > debug1: PAM: setting PAM_TTY to "/dev/ttyp4" > debug2: fd 5 setting TCP_NODELAY > debug2: channel 0: rfd 10 isatty > debug2: fd 10 setting O_NONBLOCK > debug2: fd 9 is O_NONBLOCK > debug1: Setting controlling tty using TIOCSCTTY. > debug3: mm_answer_pty: tty /dev/ttyp4 ptyfd 3 > debug3: mm_request_receive entering > Read error from remote host 10.0.0.1: Connection reset by peer > debug1: do_cleanup > debug1: PAM: cleanup > debug3: PAM: sshpam_thread_cleanup entering > debug1: do_cleanup > debug1: PAM: cleanup > debug3: PAM: sshpam_thread_cleanup entering > debug1: session_pty_cleanup: session 0 release /dev/ttyp4 > > 2) TCPDUMP available to anyone that wants it via email (21K) > > The last "good" packet between the SSH server and client looked > pretty normal, has Flags of PSH and ACK. > > The next packet comes from the router closest to the SSH server. > There is no sequence or acknowledgement number, but its claiming > to originate from the same port that the client originally was > using. The window size is 1/2 of what the client/server window > was. Its sending to the SSH server an ACK. > > The next packet is from the SSH server to the router, there > is no sequence number, window size is 0, Flags are RST. > > Next packet is from the SSH server to the client, marked > as a TCP retransmission, same sequence as the last "good" > packet, PSH,ACK Check the IP TOS bits on the packets as I think that's around the point that it sets IPTOS_LOWDELAY. I have heard that some NAT/firewall devices can't handle a connection where the TOS changes mid-connection. If you have netcat installed, you can try this: ssh -o "ProxyCommand nc %h %p" yourserver as a quick test. > Last packet is from SSH client to server, with RST Flag > set. > > So why is the router jumping into the middle of > the conversation and being a spoil sport? > > Thanks, Tuc > -- 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 ml at t-b-o-h.net Wed Jan 30 14:18:19 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Tue, 29 Jan 2008 22:18:19 -0500 (EST) Subject: [openssh] Re: Frequent "Connection reset by peer" In-Reply-To: <479FDC3A.9010106@zip.com.au> Message-ID: <200801300318.m0U3IJ3J030324@himinbjorg.tucs-beachin-obx-house.com> > > Tuc at T-B-O-H.NET wrote: > >> Tuc at T-B-O-H wrote: > >>> Is there a way to tell why I'm getting frequent > >>> "Connection reset by peer" all of a sudden? > >>> > >>> I'm using a FreeBSD machine, plugged via eithernet to a Linksys > >>> router running DD-WRT, to another Linksys 50 feet away running DD-WRT, > >>> both of them WDS'd together, plugged via ethernet to another FreeBSD machine. > >>> With debug cranked, I see : > >> 1) check the SSH server's logs to see if there's any logged message > >> corresponding to the disconnects. If the problem is easy to reproduce, > >> you could run sshd in debug mode in the foreground (eg "/path/to/sshd > >> -ddde -p 2022" then connect to port 22). > >> > >> 2) if that doesn't have anything, or has the same "connection reset by > >> peer message" then you probably will need to run tcpdump or similar to > >> see which end is generating the TCP RST (in theory it should be only > >> generated by one of the TCP endpoints but it could also be generated by, > >> eg an intermediate NAT box). > >> > > Hi, > > > > Thanks for the reply... > > > > 1) Nothing out of the ordinary in the logs. > > > > Last bit of logging from the server before/after it happens : > > > > debug3: tty_parse_modes: 93 0 > > debug1: server_input_channel_req: channel 0 request shell reply 0 > > debug1: session_by_channel: session 0 channel 0 > > debug1: session_input_channel_req: session 0 req shell > > debug1: PAM: setting PAM_TTY to "/dev/ttyp4" > > debug2: fd 5 setting TCP_NODELAY > > debug2: channel 0: rfd 10 isatty > > debug2: fd 10 setting O_NONBLOCK > > debug2: fd 9 is O_NONBLOCK > > debug1: Setting controlling tty using TIOCSCTTY. > > debug3: mm_answer_pty: tty /dev/ttyp4 ptyfd 3 > > debug3: mm_request_receive entering > > Read error from remote host 10.0.0.1: Connection reset by peer > > debug1: do_cleanup > > debug1: PAM: cleanup > > debug3: PAM: sshpam_thread_cleanup entering > > debug1: do_cleanup > > debug1: PAM: cleanup > > debug3: PAM: sshpam_thread_cleanup entering > > debug1: session_pty_cleanup: session 0 release /dev/ttyp4 > > > > 2) TCPDUMP available to anyone that wants it via email (21K) > > > > The last "good" packet between the SSH server and client looked > > pretty normal, has Flags of PSH and ACK. > > > > The next packet comes from the router closest to the SSH server. > > There is no sequence or acknowledgement number, but its claiming > > to originate from the same port that the client originally was > > using. The window size is 1/2 of what the client/server window > > was. Its sending to the SSH server an ACK. > > > > The next packet is from the SSH server to the router, there > > is no sequence number, window size is 0, Flags are RST. > > > > Next packet is from the SSH server to the client, marked > > as a TCP retransmission, same sequence as the last "good" > > packet, PSH,ACK > > Check the IP TOS bits on the packets as I think that's around the point > that it sets IPTOS_LOWDELAY. I have heard that some NAT/firewall > devices can't handle a connection where the TOS changes mid-connection. > > If you have netcat installed, you can try this: > > ssh -o "ProxyCommand nc %h %p" yourserver > > as a quick test. > There is no NAT enabled devices between system. There are no SPI firewalls between systems. The 2 systems go out eithernet to a Linksys Router running DD-WRT thats basically been put into "DUMB" mode and WDS'd together. I think wireshark calls TOS "Differentiated Services Field". About 31 packets in I see my client sending to the server 0x10, which isn't that IPTOS_LOWDELAY? (From FreeBSD netinet/ip.h : #define IPTOS_LOWDELAY 0x10 Trouble doesn't seem to star until about 104 packets in. TOS is set to 0x10 about 76 times in the entire conversation. I ran what you said, and the first one ran for about 2 minutes and then : Connection to 10.0.0.6 closed by remote host. Connection to 10.0.0.6 closed. And the 2nd time about 20 seconds before the same. Thanks, Tuc From nyh at math.technion.ac.il Thu Jan 31 17:18:12 2008 From: nyh at math.technion.ac.il (Nadav Har'El) Date: Thu, 31 Jan 2008 08:18:12 +0200 Subject: [openssh] Re: Frequent "Connection reset by peer" In-Reply-To: <200801300318.m0U3IJ3J030324@himinbjorg.tucs-beachin-obx-house.com> References: <479FDC3A.9010106@zip.com.au> <200801300318.m0U3IJ3J030324@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <20080131061812.GA3620@fermat.math.technion.ac.il> On Tue, Jan 29, 2008, Tuc at T-B-O-H.NET wrote about "Re: [openssh] Re: Frequent "Connection reset by peer"": > I ran what you said, and the first one ran for about > 2 minutes and then : > > Connection to 10.0.0.6 closed by remote host. > Connection to 10.0.0.6 closed. > > And the 2nd time about 20 seconds before the same. If I understood correctly, what you ran just opened a connection, but passed no data for two minutes. Is it possible that your router simply disconnects inactive TCP connections after two minutes, in the pretext of saving memory, guard against DOS attacks, or who knows what? You can try setting ServerAliveInterval in your client to something less than two minutes, and see if it helps. E.g., in your ~/.ssh/config put ServerAliveInterval 60 -- Nadav Har'El | Thursday, Jan 31 2008, 24 Shevat 5768 nyh at math.technion.ac.il |----------------------------------------- Phone +972-523-790466, ICQ 13349191 |He who has more is not happier than he http://nadav.harel.org.il |who wants less. From dtucker at zip.com.au Thu Jan 31 22:15:34 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 31 Jan 2008 22:15:34 +1100 Subject: [openssh] Re: Frequent "Connection reset by peer" In-Reply-To: <20080131061812.GA3620@fermat.math.technion.ac.il> References: <479FDC3A.9010106@zip.com.au> <200801300318.m0U3IJ3J030324@himinbjorg.tucs-beachin-obx-house.com> <20080131061812.GA3620@fermat.math.technion.ac.il> Message-ID: <47A1ADD6.9010205@zip.com.au> Nadav Har'El wrote: > On Tue, Jan 29, 2008, Tuc at T-B-O-H.NET wrote about "Re: [openssh] Re: Frequent "Connection reset by peer"": >> I ran what you said, and the first one ran for about >> 2 minutes and then : >> >> Connection to 10.0.0.6 closed by remote host. >> Connection to 10.0.0.6 closed. >> >> And the 2nd time about 20 seconds before the same. > > If I understood correctly, what you ran just opened a connection, but passed > no data for two minutes. Is it possible that your router simply disconnects > inactive TCP connections after two minutes, in the pretext of saving memory, > guard against DOS attacks, or who knows what? Good point, and that reminds me: another thing to check for, particularly if you have links with differing MTUs, is fragmentation problems: http://www.snailbook.com/faq/mtu-mismatch.auto.html A dead giveaway for this problem is if you see a non-zero and increasing number in the SendQ column in the "netstat" output for the SSH connection (on either server or client end of the connection). -- 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.