From dkg at fifthhorseman.net Fri Jul 1 00:04:17 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 30 Jun 2011 10:04:17 -0400 Subject: Privilege Separation Design Question In-Reply-To: References: <20110616192803.GA27882@munich.citi.umich.edu> <20110630122853.GA3465@munich.citi.umich.edu> <20110630125057.GB3465@munich.citi.umich.edu> Message-ID: <4E0C8261.4020704@fifthhorseman.net> On 06/30/2011 09:48 AM, Hans Harder wrote: > Also if you do that in the middle of automatic script activity, I have > no idea what will go wrong I agree, this strikes me as a disaster waiting to happen. Eric, have you considered doing re-authorization without re-authentication? It seems to me that you could take that approach much more cleanly (and simply terminate any ongoing connections that are found to be no-longer-authorized). --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From guettli at thomas-guettler.de Fri Jul 1 01:22:31 2011 From: guettli at thomas-guettler.de (Thomas Guettler) Date: Thu, 30 Jun 2011 17:22:31 +0200 Subject: Enhance sftp protocol: get SHA hash of file In-Reply-To: <4E0B8A26.5070506@thomas-guettler.de> References: <4E0B050B.7000701@thomas-guettler.de> <4E0B8A26.5070506@thomas-guettler.de> Message-ID: <4E0C94B7.6010001@thomas-guettler.de> ... >> Rather than reinventing the wheel, you might take a look at the (expired) >> Draft which proposed the "check-file-name" and "check-file-handle" SFTP >> extensions: >> >> http://tools.ietf.org/html/draft-ietf-secsh-filexfer-extensions-00 >> >> These extensions have been implemented by various SFTP clients and >> servers. > > Thank you very much! I googled for server which support > check-file-hanlde, but I found only proftpd which supports it. > > The ietf extension is even better than my first proposal: You can > give a blocksize and get N hash values with one response. > > I not a fluent c programmer. Any volunteers to implement this? Hi, I opened a "search for help" on openhatch: http://openhatch.org/+projects/sftp%20get%20hash%20value Maybe someone can help us ... Thomas From cal.leeming at simplicitymedialtd.co.uk Fri Jul 1 00:59:51 2011 From: cal.leeming at simplicitymedialtd.co.uk (Cal Leeming [Simplicity Media Ltd]) Date: Thu, 30 Jun 2011 15:59:51 +0100 Subject: Privilege Separation Design Question In-Reply-To: <4E0C8261.4020704@fifthhorseman.net> References: <20110616192803.GA27882@munich.citi.umich.edu> <20110630122853.GA3465@munich.citi.umich.edu> <20110630125057.GB3465@munich.citi.umich.edu> <4E0C8261.4020704@fifthhorseman.net> Message-ID: To do this, you'd need to de-attach the SSH session from that shell, and drop them into a purpose built environment to perform the authentication. However, I am not sure it is possible to do this without causing problems on the existing shell (I don't know the SSH code well enough). Another option, is that you could drop the user into a controlled 'screen' session, and enforce your rules within that..? Cal On Thu, Jun 30, 2011 at 3:04 PM, Daniel Kahn Gillmor wrote: > On 06/30/2011 09:48 AM, Hans Harder wrote: > > Also if you do that in the middle of automatic script activity, I have > > no idea what will go wrong > > I agree, this strikes me as a disaster waiting to happen. > > Eric, have you considered doing re-authorization without > re-authentication? It seems to me that you could take that approach > much more cleanly (and simply terminate any ongoing connections that are > found to be no-longer-authorized). > > --dkg > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > From hans at atbas.org Fri Jul 1 01:38:56 2011 From: hans at atbas.org (Hans Harder) Date: Thu, 30 Jun 2011 17:38:56 +0200 Subject: Privilege Separation Design Question In-Reply-To: <4E0C8261.4020704@fifthhorseman.net> References: <20110616192803.GA27882@munich.citi.umich.edu> <20110630122853.GA3465@munich.citi.umich.edu> <20110630125057.GB3465@munich.citi.umich.edu> <4E0C8261.4020704@fifthhorseman.net> Message-ID: And then we haven't even talked about tunnels.... From cal.leeming at simplicitymedialtd.co.uk Fri Jul 1 01:44:10 2011 From: cal.leeming at simplicitymedialtd.co.uk (Cal Leeming [Simplicity Media Ltd]) Date: Thu, 30 Jun 2011 16:44:10 +0100 Subject: Privilege Separation Design Question In-Reply-To: References: <20110616192803.GA27882@munich.citi.umich.edu> <20110630122853.GA3465@munich.citi.umich.edu> <20110630125057.GB3465@munich.citi.umich.edu> <4E0C8261.4020704@fifthhorseman.net> Message-ID: Oh jeez, I had totally forgot about that. To be honest, a heavily modified screen shell looks like the way forward, rather than modifying the SSH bins. Cal On Thu, Jun 30, 2011 at 4:38 PM, Hans Harder wrote: > And then we haven't even talked about tunnels.... > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From imorgan at nas.nasa.gov Fri Jul 1 03:06:51 2011 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 30 Jun 2011 10:06:51 -0700 Subject: Privilege Separation Design Question In-Reply-To: References: <20110616192803.GA27882@munich.citi.umich.edu> <20110630122853.GA3465@munich.citi.umich.edu> <20110630125057.GB3465@munich.citi.umich.edu> <4E0C8261.4020704@fifthhorseman.net> Message-ID: <20110630170651.GB13389@linux124.nas.nasa.gov> I wonder if the (not yet committed) roaming feature could be (ab)used to meet this need. If both the client and server had support for the feature, it might be feasible to break sshd's TCP connection and then wait for the client to reauthenticate. -- Iain Morgan On Thu, Jun 30, 2011 at 10:44:10 -0500, Cal Leeming [Simplicity Media Ltd] wrote: > Oh jeez, I had totally forgot about that. > > To be honest, a heavily modified screen shell looks like the way forward, > rather than modifying the SSH bins. > > Cal > > On Thu, Jun 30, 2011 at 4:38 PM, Hans Harder wrote: > > > And then we haven't even talked about tunnels.... > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Iain Morgan From andreas at zzlevo.net Fri Jul 1 07:10:53 2011 From: andreas at zzlevo.net (Andreas Gunnarsson) Date: Thu, 30 Jun 2011 23:10:53 +0200 Subject: Privilege Separation Design Question In-Reply-To: <20110630170651.GB13389@linux124.nas.nasa.gov> References: <20110616192803.GA27882@munich.citi.umich.edu> <20110630122853.GA3465@munich.citi.umich.edu> <20110630125057.GB3465@munich.citi.umich.edu> <4E0C8261.4020704@fifthhorseman.net> <20110630170651.GB13389@linux124.nas.nasa.gov> Message-ID: <20110630211053.GA3780@zzlevo.net> On Thu, Jun 30, 2011 at 10:06:51AM -0700, Iain Morgan wrote: > I wonder if the (not yet committed) roaming feature could be (ab)used > to meet this need. If both the client and server had support for the > feature, it might be feasible to break sshd's TCP connection and then > wait for the client to reauthenticate. Possibly, but just breaking the TCP connection won't be enough. The point of roaming is to make it possible to re-establish the connection automatically without user authentication. If anyone wants to add an option to the roaming patch that requires reauthentication on resume then it's probably not too difficult, but I haven't given it much thought. The old roaming patch most likely won't apply cleanly to the current source, and I suspect that the sandbox feature requires some non-trivial modifications to the roaming functionality. I'll try to find the time to update the patch, but it won't happen for at least a couple of weeks. Andreas From mark at cacr.caltech.edu Fri Jul 1 07:34:55 2011 From: mark at cacr.caltech.edu (Mark Bartelt) Date: Thu, 30 Jun 2011 14:34:55 -0700 (PDT) Subject: sshd and .bashrc Message-ID: <20110630213455.44CB214C6AC@ingleside.caltech.edu> The short version: There's a "#define USE_PIPES" in the middle of session.c; it would be better if it were in (e.g.) defines.h or some other .h file. (If in fact it needs to be defined at all; I'm not convinced that it does.) Here's the (much) longer version: I recently installed the latest OpenSSH on some of our servers (RHEL5, which provides the 4.3 release) and soon afterward we received a complaint from one of our users, reporting that his .bashrc file was no longer being sourced when he ran remote commands via a non-interactive single-command connection. He was right. The problem stemmed from the fact that bash contains the following in run_startup_files(), which gets called to determine which dotfiles (if any) to source ... if (interactive_shell == 0 && no_rc == 0 && login_shell == 0 && act_like_sh == 0 && command_execution_string) { #ifdef SSH_SOURCE_BASHRC run_by_ssh = (find_variable ("SSH_CLIENT") != (SHELL_VAR *)0) || (find_variable ("SSH2_CLIENT") != (SHELL_VAR *)0); #else run_by_ssh = 0; #endif /* If we were run by sshd or we think we were run by rshd, execute ~/.bashrc if we are a top-level shell. */ if ((run_by_ssh || isnetconn (fileno (stdin))) && shell_level < 2) ... and RedHat's bash is built with SSH_SOURCE_BASHRC not defined, so everything depends on isnetconn(); in fact, that seems to be bash's default, since one finds this in a (very old) entry in their CHANGES file: This document details the changes between this version, bash-2.05a-release, and the previous version, bash-2.05a-rc1. [ ... ] z. Bash no longer attempts to discover if it's being run by sshd in order to run the startup files. If the SSH_SOURCE_BASHRC is uncommented in config-top.h it will attempt to do so as previously, but that's commented out in the distributed version. But it turns out that bash's isnetconn() function was returning 0, which in turn was caused by getpeername() failing (errno == ENOTSOCK) when it was being used to get information about stdin. And sure enough, the child process spawned by Redhat's sshd showed the following for standard input (reported by "lsof") ... 0u unix 0xffff81033fec2b80 10237328 socket ... whereas the same child process spawned by the sshd which I'd just built had this ... 0r FIFO 0,6 3093574 pipe So what was responsible for this difference? It turns out that there's some code in session.c (specifically, in the do_exec_no_pty() function) conditionalized with ... #ifdef USE_PIPES [ ... ] #else [ ... ] #endif ... so this might lead one to believe that there would be something in one of the .h files that would govern which of those chunks of code would get used, particularly in light of the fact that defines.h contains ... /* * Define this to use pipes instead of socketpairs for communicating with the * client program. Socketpairs do not seem to work on all systems. * * configure.ac sets this for a few OS's which are known to have problems * but you may need to set it yourself */ /* #define USE_PIPES 1 */ ... and the configure script creates a config.h with ... /* Use PIPES instead of a socketpair() */ /* #undef USE_PIPES */ ... both of which would lead one to infer that USE_PIPES is _not_ defined by default. But back in session.c, more then four hundred lines from the beginning of the file, we find this ... #define USE_PIPES ... just before the start of the do_exec_no_pty() function! This wasn't always there; it appeared for the first time in the 5.1p1 release (it's not in 5.0p1). So first, I'm curious as to why it was felt necessary to make USE_PIPES the default; and secondly, even if there is a good reason for it to be the default, shouldn't the "#define" be in a .h file, so that it will be obvious what the setting is for people who might want to change it? Burying it down in the middle of session.c just seems like an unwise decision ... --------------- Mark Bartelt Center for Advanced Computing Research California Institute of Technology Pasadena, California 91125 626 395 2522 626 584 5917 fax 626 628 3994 e-fax mark at cacr.caltech.edu http://www.cacr.caltech.edu/~mark From imorgan at nas.nasa.gov Fri Jul 1 10:35:31 2011 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 30 Jun 2011 17:35:31 -0700 Subject: sshd and .bashrc In-Reply-To: <20110630213455.44CB214C6AC@ingleside.caltech.edu> References: <20110630213455.44CB214C6AC@ingleside.caltech.edu> Message-ID: <20110701003531.GC13389@linux124.nas.nasa.gov> I don't mean to flame you, but this bash idiosyncracy has been talked to death time and time again on this list. Please consult the archive. On Thu, Jun 30, 2011 at 16:34:55 -0500, Mark Bartelt wrote: > The short version: There's a "#define USE_PIPES" > in the middle of session.c; it would be better if > it were in (e.g.) defines.h or some other .h file. > (If in fact it needs to be defined at all; I'm not > convinced that it does.) Here's the (much) longer > version: > > I recently installed the latest OpenSSH on some of > our servers (RHEL5, which provides the 4.3 release) > and soon afterward we received a complaint from one > of our users, reporting that his .bashrc file was no > longer being sourced when he ran remote commands via > a non-interactive single-command connection. He was > right. The problem stemmed from the fact that bash > contains the following in run_startup_files(), which > gets called to determine which dotfiles (if any) to > source ... > > if (interactive_shell == 0 && no_rc == 0 && login_shell == 0 && > act_like_sh == 0 && command_execution_string) > { > #ifdef SSH_SOURCE_BASHRC > run_by_ssh = (find_variable ("SSH_CLIENT") != (SHELL_VAR *)0) || > (find_variable ("SSH2_CLIENT") != (SHELL_VAR *)0); > #else > run_by_ssh = 0; > #endif > /* If we were run by sshd or we think we were run by rshd, execute > ~/.bashrc if we are a top-level shell. */ > if ((run_by_ssh || isnetconn (fileno (stdin))) && shell_level < 2) > > ... and RedHat's bash is built with SSH_SOURCE_BASHRC > not defined, so everything depends on isnetconn(); in > fact, that seems to be bash's default, since one finds > this in a (very old) entry in their CHANGES file: > > This document details the changes between this version, bash-2.05a-release, > and the previous version, bash-2.05a-rc1. > [ ... ] > z. Bash no longer attempts to discover if it's being run by sshd in order to > run the startup files. If the SSH_SOURCE_BASHRC is uncommented in > config-top.h it will attempt to do so as previously, but that's commented > out in the distributed version. > > But it turns out that bash's isnetconn() function was > returning 0, which in turn was caused by getpeername() > failing (errno == ENOTSOCK) when it was being used to > get information about stdin. > > And sure enough, the child process spawned by Redhat's > sshd showed the following for standard input (reported > by "lsof") ... > > 0u unix 0xffff81033fec2b80 10237328 socket > > ... whereas the same child process spawned by the sshd > which I'd just built had this ... > > 0r FIFO 0,6 3093574 pipe > > So what was responsible for this difference? It turns > out that there's some code in session.c (specifically, > in the do_exec_no_pty() function) conditionalized with ... > > #ifdef USE_PIPES > [ ... ] > #else > [ ... ] > #endif > > ... so this might lead one to believe that there would be > something in one of the .h files that would govern which > of those chunks of code would get used, particularly in > light of the fact that defines.h contains ... > > /* > * Define this to use pipes instead of socketpairs for communicating with the > * client program. Socketpairs do not seem to work on all systems. > * > * configure.ac sets this for a few OS's which are known to have problems > * but you may need to set it yourself > */ > /* #define USE_PIPES 1 */ > > ... and the configure script creates a config.h with ... > > /* Use PIPES instead of a socketpair() */ > /* #undef USE_PIPES */ > > ... both of which would lead one to infer that USE_PIPES > is _not_ defined by default. But back in session.c, more > then four hundred lines from the beginning of the file, we > find this ... > > #define USE_PIPES > > ... just before the start of the do_exec_no_pty() function! > > This wasn't always there; it appeared for the first time in > the 5.1p1 release (it's not in 5.0p1). > > So first, I'm curious as to why it was felt necessary to make > USE_PIPES the default; and secondly, even if there is a good > reason for it to be the default, shouldn't the "#define" be > in a .h file, so that it will be obvious what the setting is > for people who might want to change it? > > Burying it down in the middle of session.c just seems like an > unwise decision ... > > --------------- > > Mark Bartelt > Center for Advanced Computing Research > California Institute of Technology > Pasadena, California 91125 > > 626 395 2522 > 626 584 5917 fax > 626 628 3994 e-fax > > mark at cacr.caltech.edu > > http://www.cacr.caltech.edu/~mark > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Iain Morgan From mark at cacr.caltech.edu Fri Jul 1 13:17:34 2011 From: mark at cacr.caltech.edu (Mark Bartelt) Date: Thu, 30 Jun 2011 20:17:34 -0700 (PDT) Subject: sshd and .bashrc Message-ID: <20110701031734.A585114C6AC@ingleside.caltech.edu> Actually, it doesn't surprise me at all that this has already been discussed before. And I did try searching the archives before sending my message; more on that below. But first, as for the topic itself ... The "bash" manpage is annoyingly vague about what the behaviour should be. On the one hand, the "FILES" section talks about the ".bashrc" file as the "individual per-interactive-shell startup file", which sort of implies that it's not used for connections which _don't_ cause an interactive shell to be run. But on the other hand, elsewhere it says ... Bash attempts to determine when it is being run by the remote shell daemon, usually rshd. If bash determines it is being run by rshd, it reads and executes commands from ~/.bashrc, if that file exists and is readable. That wording ("usually rshd") is obviously quite dated, but one could certainly argue that sshd _is_ the "remote shell daemon" these days. So it just seems better (to me, at least) if sshd would ensure that bash's behaviour were consistent with what's in the manpage. One could fault the distributors of "bash", for not making the "#define SSH_SOURCE_BASHRC" a default. But even so, I really don't understand why having sshd's default be _not_ to define USE_PIPES wouldn't be sensible, letting people define it when their environment requires it. And regardless of whether the consensus is that it's better to have it defined or not to have it defined, it just seems unwise to have that "#define USE_PIPES" buried down in the middle of a .c file, rather than at the very top, or (better) in a .h file; wouldn't that be more conformant with good C programming style? Finally, regarding the archives ... I actually did try doing a search. But when I asked it to search for "USE_PIPES", after it displayed the results my "USE_PIPES" in the search box had been replaced by "pipes", and the browser window title bar displayed "'pipes' in openssh-unix-dev", so for some reason it looked like it was chopping off part of the search term I gave it (even when I enclosed it in quotes), so it wasn't clear what fraction of the search results it was displaying would be relevant. If I entered "USE_PIPES" and ".bashrc" in the search box, it gave me four messages from April 2009, but those seemed to be dealing with whether socketpairs and pipes could be mixed in channels.c, so didn't necessarily seem relevant. (And the thread topic was "ssh localhost yes | true (follow up)", which also didn't seem like it was coconnected to the .bashrc issue.) Maybe better search criteria would have turned up the relevant old threads. But just offhand, do you happen to know why their search engine seems so insistent on transforming "USE_PIPES" to just plain "pipes"? --------------- Mark Bartelt Center for Advanced Computing Research California Institute of Technology Pasadena, California 91125 626 395 2522 626 584 5917 fax 626 628 3994 e-fax mark at cacr.caltech.edu http://www.cacr.caltech.edu/~mark From ras at anzio.com Sat Jul 2 01:10:22 2011 From: ras at anzio.com (Bob Rasmussen) Date: Fri, 1 Jul 2011 08:10:22 -0700 (PDT) Subject: Timing of banner Message-ID: A user at a Windows PC uses our SSH client software (Anzio) to access a Linux sshd. User would like the banner from the server to display BEFORE entering a login name. According to the SSH spec, this should be allowed. But the OpenSSH source seems to have specifically prevented this. Is there a good reason for this? Regards, ....Bob Rasmussen, President, Rasmussen Software, Inc. personal e-mail: ras at anzio.com company e-mail: rsi at anzio.com voice: (US) 503-624-0360 (9:00-6:00 Pacific Time) fax: (US) 503-624-0760 web: http://www.anzio.com street address: Rasmussen Software, Inc. 10240 SW Nimbus, Suite L9 Portland, OR 97223 USA From scott_n at xypro.com Sat Jul 2 03:27:44 2011 From: scott_n at xypro.com (Scott Neugroschl) Date: Fri, 1 Jul 2011 10:27:44 -0700 Subject: Timing of banner In-Reply-To: References: Message-ID: <78DD71C304F38B41885A242996B96F7302C04EFD@xyservd.XYPRO-23.LOCAL> Quoth Bob Rasmussen: > > A user at a Windows PC uses our SSH client software (Anzio) to access a > Linux sshd. User would like the banner from the server to display > BEFORE > entering a login name. > > According to the SSH spec, this should be allowed. But the OpenSSH > source > seems to have specifically prevented this. Is there a good reason for > this? > Please see the "Banner" option in sshd_config(5). From ras at anzio.com Sat Jul 2 03:35:17 2011 From: ras at anzio.com (Bob Rasmussen) Date: Fri, 1 Jul 2011 10:35:17 -0700 (PDT) Subject: Timing of banner In-Reply-To: <78DD71C304F38B41885A242996B96F7302C04EFD@xyservd.XYPRO-23.LOCAL> References: <78DD71C304F38B41885A242996B96F7302C04EFD@xyservd.XYPRO-23.LOCAL> Message-ID: On Fri, 1 Jul 2011, Scott Neugroschl wrote: > > Quoth Bob Rasmussen: > > > > A user at a Windows PC uses our SSH client software (Anzio) to access > a > > Linux sshd. User would like the banner from the server to display > > BEFORE > > entering a login name. > > > > According to the SSH spec, this should be allowed. But the OpenSSH > > source > > seems to have specifically prevented this. Is there a good reason for > > this? > > > > > > Please see the "Banner" option in sshd_config(5). I know how to cause the banner to appear, and am doing that. The question is related to the *timing* of the banner. Regards, ....Bob Rasmussen, President, Rasmussen Software, Inc. personal e-mail: ras at anzio.com company e-mail: rsi at anzio.com voice: (US) 503-624-0360 (9:00-6:00 Pacific Time) fax: (US) 503-624-0760 web: http://www.anzio.com street address: Rasmussen Software, Inc. 10240 SW Nimbus, Suite L9 Portland, OR 97223 USA From djm at mindrot.org Sat Jul 2 05:01:54 2011 From: djm at mindrot.org (Damien Miller) Date: Sat, 2 Jul 2011 05:01:54 +1000 (EST) Subject: sshd and .bashrc In-Reply-To: <20110701031734.A585114C6AC@ingleside.caltech.edu> References: <20110701031734.A585114C6AC@ingleside.caltech.edu> Message-ID: On Thu, 30 Jun 2011, Mark Bartelt wrote: > One could fault the distributors of "bash", for not making the > "#define SSH_SOURCE_BASHRC" a default. But even so, I really > don't understand why having sshd's default be _not_ to define > USE_PIPES wouldn't be sensible, letting people define it when > their environment requires it. No, we need pipes to properly support half-closed semantics in some cases that matter to the protocol (these are discussed in the archives). We should probably probably garbage-collect the dead socketpair code some time, but it is definitely not a knob we want users to play with. bash was doing the wrong thing varying its behaviour based on the type of fd it was talking to, so please turn your attention there. -d From djm at mindrot.org Sat Jul 2 05:09:14 2011 From: djm at mindrot.org (Damien Miller) Date: Sat, 2 Jul 2011 05:09:14 +1000 (EST) Subject: Timing of banner In-Reply-To: References: Message-ID: On Fri, 1 Jul 2011, Bob Rasmussen wrote: > A user at a Windows PC uses our SSH client software (Anzio) to access a > Linux sshd. User would like the banner from the server to display BEFORE > entering a login name. > > According to the SSH spec, this should be allowed. But the OpenSSH source > seems to have specifically prevented this. Is there a good reason for > this? We send the banner after the receipt of the first user authentication request. RFC4252 could be interpreted to allow sending the banner sooner, right after the "ssh-userauth" service has been requested, but we haven't tested this and doing so would remove the ability to vary the banner depending on the user who is connecting (as we can now with sshd_config "Banner" statements inside "Match" blocks). For the latter reason, we don't have any plans to send the banner earlier. -d From ras at anzio.com Sat Jul 2 05:20:33 2011 From: ras at anzio.com (Bob Rasmussen) Date: Fri, 1 Jul 2011 12:20:33 -0700 (PDT) Subject: Timing of banner In-Reply-To: References: Message-ID: Damien, thanks for the explanation. My user's point has a certain validity, I think: the user isn't seeing what they're logging into before giving a username. One might even consider it a security issue, identifying yourself before you know who you're talking to (although I realize the fingerprint verification mitigates this). I tried to achieve my goal by sending a 'none' authentication, getting the banner, then sending a different type (e.g., keyboard-interactive), but the server detected the change and closed the session. Is it possible that by loosening that restriction in the sshd, both goals could be met? On Sat, 2 Jul 2011, Damien Miller wrote: > On Fri, 1 Jul 2011, Bob Rasmussen wrote: > > > A user at a Windows PC uses our SSH client software (Anzio) to access a > > Linux sshd. User would like the banner from the server to display BEFORE > > entering a login name. > > > > According to the SSH spec, this should be allowed. But the OpenSSH source > > seems to have specifically prevented this. Is there a good reason for > > this? > > We send the banner after the receipt of the first user authentication > request. RFC4252 could be interpreted to allow sending the banner sooner, > right after the "ssh-userauth" service has been requested, but we haven't > tested this and doing so would remove the ability to vary the banner > depending on the user who is connecting (as we can now with sshd_config > "Banner" statements inside "Match" blocks). > > For the latter reason, we don't have any plans to send the banner earlier. > > -d > > Regards, ....Bob Rasmussen, President, Rasmussen Software, Inc. personal e-mail: ras at anzio.com company e-mail: rsi at anzio.com voice: (US) 503-624-0360 (9:00-6:00 Pacific Time) fax: (US) 503-624-0760 web: http://www.anzio.com street address: Rasmussen Software, Inc. 10240 SW Nimbus, Suite L9 Portland, OR 97223 USA From mark at cacr.caltech.edu Sat Jul 2 05:37:42 2011 From: mark at cacr.caltech.edu (Mark Bartelt) Date: Fri, 1 Jul 2011 12:37:42 -0700 (PDT) Subject: sshd and .bashrc Message-ID: <20110701193742.C6EF414C6AC@ingleside.caltech.edu> >> bash was doing the wrong thing varying its behaviour based on the >> type of fd it was talking to, so please turn your attention there. Fair enough; I'm basically agnostic on the issue of whether bash {is|isn't} doing the wrong thing. But regardless, I still feel that the change in sshd's behaviour shouldn't have been sprung on people without a big "hey, heads-up, bash users!" in one of the README files. It first appeared in the 5.1p1 release (it wasn't there in 5.0p1), and although the change was documented in that ChangeLog file, it's more than 800 lines down, with no suggestion about what the potential side-effects of the change might be. But if I've overlooked something in a location that people are more likely to pay attention to, feel free to point me in its direction. Just seems that when a change gets made which affects backward compatibility and interoperability, it would be best if folks were alerted about the potential impact of moving from an older release to the newer one. But my main gripe is the fact that the "#define USE_PIPES" was buried more than 400 lines down inside a .c source file, while the relevant header file (or at least the file which one might naively assume is relevant, defines.h) still (as of the 5.8p2 release) contains ... /* * Define this to use pipes instead of socketpairs for communicating with the * client program. Socketpairs do not seem to work on all systems. * * configure.ac sets this for a few OS's which are known to have problems * but you may need to set it yourself */ /* #define USE_PIPES 1 */ ... which suggests that, if that statement were left as it is (i.e. commented out), USE_PIPES would be undefined when sshd was built. From dkg at fifthhorseman.net Sat Jul 2 05:50:29 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 01 Jul 2011 15:50:29 -0400 Subject: Timing of banner In-Reply-To: References: Message-ID: <4E0E2505.8070307@fifthhorseman.net> On 07/01/2011 03:20 PM, Bob Rasmussen wrote: > My user's point has a certain validity, I think: the user isn't seeing > what they're logging into before giving a username. One might even > consider it a security issue, identifying yourself before you know who > you're talking to (although I realize the fingerprint verification > mitigates this). From a security standpoint, the fingerprint verification doesn't just mitigate this; it is the *only* thing that addresses this security concern. Reliance on a trivially replayable banner for identifying the host would be an insecure practice. i haven't thought through the rest of the tradeoffs (there may well be a case to be made for an earlier banner in the opening handshake/negotiation); i just wanted to be clear that the argument by security (for users to identify the host) is flawed. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From keisial at gmail.com Sat Jul 2 08:30:16 2011 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sat, 02 Jul 2011 00:30:16 +0200 Subject: Timing of banner In-Reply-To: References: Message-ID: <4E0E4A78.2060700@gmail.com> Bob Rasmussen wrote: > Damien, thanks for the explanation. > > My user's point has a certain validity, I think: the user isn't seeing > what they're logging into before giving a username. One might even > consider it a security issue, identifying yourself before you know who > you're talking to (although I realize the fingerprint verification > mitigates this). You should train your user to check whatever clues your client provides of the target, such as "the window title displays: server5.example.org [Verified]" You could also add your own "banner" to the client, by making it show something like Connecting to server5.example.org The server is the same I met previously. As you are the ones making the client software, the options are endless. You could for instance allow showing aliases instead of full domain names. From djm at mindrot.org Sat Jul 2 10:05:54 2011 From: djm at mindrot.org (Damien Miller) Date: Sat, 2 Jul 2011 10:05:54 +1000 (EST) Subject: sshd and .bashrc In-Reply-To: <20110701193742.C6EF414C6AC@ingleside.caltech.edu> References: <20110701193742.C6EF414C6AC@ingleside.caltech.edu> Message-ID: On Fri, 1 Jul 2011, Mark Bartelt wrote: > >> bash was doing the wrong thing varying its behaviour based on the > >> type of fd it was talking to, so please turn your attention there. > > Fair enough; I'm basically agnostic on the issue of whether bash > {is|isn't} doing the wrong thing. But regardless, I still feel > that the change in sshd's behaviour shouldn't have been sprung > on people without a big "hey, heads-up, bash users!" in one of > the README files. It first appeared in the 5.1p1 release (it > wasn't there in 5.0p1), and although the change was documented > in that ChangeLog file, it's more than 800 lines down, with no > suggestion about what the potential side-effects of the change > might be. We didn't mention it because we didn't notice it, and because OpenSSH had already used pipes on several platform for years without anyone complaining (to me at least). -d From imorgan at nas.nasa.gov Sat Jul 2 10:38:48 2011 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 1 Jul 2011 17:38:48 -0700 Subject: sshd and .bashrc In-Reply-To: References: <20110701193742.C6EF414C6AC@ingleside.caltech.edu> Message-ID: <20110702003848.GD14465@linux124.nas.nasa.gov> On Fri, Jul 01, 2011 at 19:05:54 -0500, Damien Miller wrote: > On Fri, 1 Jul 2011, Mark Bartelt wrote: > > > >> bash was doing the wrong thing varying its behaviour based on the > > >> type of fd it was talking to, so please turn your attention there. > > > > Fair enough; I'm basically agnostic on the issue of whether bash > > {is|isn't} doing the wrong thing. But regardless, I still feel > > that the change in sshd's behaviour shouldn't have been sprung > > on people without a big "hey, heads-up, bash users!" in one of > > the README files. It first appeared in the 5.1p1 release (it > > wasn't there in 5.0p1), and although the change was documented > > in that ChangeLog file, it's more than 800 lines down, with no > > suggestion about what the potential side-effects of the change > > might be. > > We didn't mention it because we didn't notice it, and because > OpenSSH had already used pipes on several platform for years without > anyone complaining (to me at least). > > -d Hi Damien, Perhaps this issue needs to be added to the FAQ. I skimmed through it earlier, but didn't see a reference to the .bashrc issue. -- Iain Morgan From mark at cacr.caltech.edu Sat Jul 2 10:58:43 2011 From: mark at cacr.caltech.edu (Mark Bartelt) Date: Fri, 1 Jul 2011 17:58:43 -0700 (PDT) Subject: sshd and .bashrc Message-ID: <20110702005843.7551114C6AC@ingleside.caltech.edu> >> We didn't mention it because we didn't notice it, and because >> OpenSSH had already used pipes on several platform for years >> without anyone complaining (to me at least). OK; I'll accept "we didn't notice it" as an adequate defence. ;-) I like Iain's suggestion about adding it to the FAQ (or perhaps to a README.bash file or some such). The first we learned about this was shortly after we'd deployed 5.8p2 (after having used a pre 5.1p1 release for a long, _long_ time) and one of our users (a principal investigator, no less!) sent us a message which had "URGENT:" in the subject line, reporting that something he'd done for a long time had suddenly stopped working. And maybe the stuff in defines.h (which might lead one to believe that USE_PIPES isn't defined unless it's uncommented there) could be removed or changed. Anyway, case closed, as far as I'm concerned. Thank to everybody for your replies. From lists at eitanadler.com Sat Jul 2 14:49:38 2011 From: lists at eitanadler.com (Eitan Adler) Date: Sat, 2 Jul 2011 04:49:38 +0000 Subject: Timing of banner In-Reply-To: <4E0E2505.8070307@fifthhorseman.net> References: <4E0E2505.8070307@fifthhorseman.net> Message-ID: On Fri, Jul 1, 2011 at 7:50 PM, Daniel Kahn Gillmor wrote: > On 07/01/2011 03:20 PM, Bob Rasmussen wrote: >> My user's point has a certain validity, I think: the user isn't seeing >> what they're logging into before giving a username. One might even >> consider it a security issue, identifying yourself before you know who >> you're talking to (although I realize the fingerprint verification >> mitigates this). > > From a security standpoint, the fingerprint verification doesn't just > mitigate this; it is the *only* thing that addresses this security > concern. ?Reliance on a trivially replayable banner for identifying the > host would be an insecure practice. The fingerprint doesn't address the issue completely. From a user's point of view there is no difference between logging into computer1 and logging into computer2 once they have already been authenticated by the fingerprint (actually this is a client side option, but one I would not rely on being set correctly). That is unless the computer has some kind of prompt telling you who they are it is easy to supply the right credentials to a wrong computer. This is not a security issue per se, but it can be useful to be notified which computer you are accessing. -- Eitan Adler From ssh at bunten.de Sat Jul 2 16:45:07 2011 From: ssh at bunten.de (ssh at bunten.de) Date: Sat, 2 Jul 2011 08:45:07 +0200 (CEST) Subject: Logging the suggested algorithms of the client during key exchange Message-ID: Hello, for a research project I am trying to log the algorithms suggested by the client during key exchange. I am using the source of version 5.8p2. I figured the function kex_buf2prop() in kex.c might be the place to log that information. I am calling logit() within the for loop -> for (i = 0; i < PROPOSAL_MAX; i++) { proposal[i] = buffer_get_cstring(&b,NULL); debug2("kex_parse_kexinit: %s", proposal[i]); if (first_kex_follows != NULL) { logit("[client prop] kex %i: '%s' from %s", i, proposal[i], get_remote_ipaddr()); } } Unfortunately, it does not log anything when run as a daemon. Only when run in debug ('-d' switch) I see the output. I used logit() in other parts to add logging and it works great. My question: What am i doing wrong and how can I log the proposed algorithms properly? (Please note: I am interested in the suggestions from the client and not the ciphers client and server finally use!) Any helpfull suggestion appreciated! Regards Andreas From dtucker at zip.com.au Sun Jul 3 09:17:49 2011 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 3 Jul 2011 09:17:49 +1000 Subject: Logging the suggested algorithms of the client during key exchange In-Reply-To: References: Message-ID: On Sat, Jul 2, 2011 at 4:45 PM, wrote: > for a research project I am trying to log the algorithms suggested by the > client during key exchange. [...] > Unfortunately, it does not log anything when run as a daemon. Only when run > in debug ('-d' switch) I see the output. I used logit() in other parts to > add logging and it works great. The key exchange is conducted by the pre-auth privsep slave which is chrooted (usually /var/empty), so unless you have a /dev/log inside the chroot the messages won't make it to syslog. djm has made some changes after the 5.8 releases that send log messages via the monitor, so this won't be necessary in future releases. You can either tell your syslog to listen on /var/empty/dev/log too or use a snapshot (http://www.mindrot.org/openssh_snap/). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4? 37C9 C982 80C7 8FF4 FA69 ? ? Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Sun Jul 3 17:58:01 2011 From: djm at mindrot.org (Damien Miller) Date: Sun, 3 Jul 2011 17:58:01 +1000 (EST) Subject: Logging the suggested algorithms of the client during key exchange In-Reply-To: References: Message-ID: On Sun, 3 Jul 2011, Darren Tucker wrote: > On Sat, Jul 2, 2011 at 4:45 PM, wrote: > > for a research project I am trying to log the algorithms suggested by the > > client during key exchange. > [...] > > Unfortunately, it does not log anything when run as a daemon. Only when run > > in debug ('-d' switch) I see the output. I used logit() in other parts to > > add logging and it works great. > > The key exchange is conducted by the pre-auth privsep slave which is > chrooted (usually /var/empty), so unless you have a /dev/log inside > the chroot the messages won't make it to syslog. > > djm has made some changes after the 5.8 releases that send log > messages via the monitor, so this won't be necessary in future > releases. > > You can either tell your syslog to listen on /var/empty/dev/log too or > use a snapshot (http://www.mindrot.org/openssh_snap/). Also, the selected ciphers, MACs and compression choices are already logged at level DEBUG so you shouldn't need to add logging yourself. -d From rapier at psc.edu Thu Jul 7 01:54:31 2011 From: rapier at psc.edu (rapier) Date: Wed, 06 Jul 2011 11:54:31 -0400 Subject: Logging the suggested algorithms of the client during key exchange In-Reply-To: References: Message-ID: <4E148537.4050007@psc.edu> I created something like this to do some basic server side logging with http://www.psc.edu/networking/projects/hpn-ssh/openssh5.8-server-logging.diff It doesn't do the proposal though. However, as Darren said you have to monitor a log in the chroot jail. From the direction to my patch... "This patch adds additional logging to the SSHD server including encryption used, remote address and port, user name, remote version information, total bytes transferred, and average throughput. In order to use this patch you *must* direct syslogd to use an additional logging socket. This socket will be located in the sshd chroot, typically /var/empty. As such you will need to create a /var/empty/dev directory and add '-a /var/empty/dev/log' to your syslogd configuration." Good luck! On 7/2/11 2:45 AM, ssh at bunten.de wrote: > Hello, > > for a research project I am trying to log the algorithms suggested by > the client during key exchange. > > I am using the source of version 5.8p2. I figured the function > kex_buf2prop() in kex.c might be the place to log that information. I am > calling logit() within the for loop -> > > for (i = 0; i < PROPOSAL_MAX; i++) { > proposal[i] = buffer_get_cstring(&b,NULL); > debug2("kex_parse_kexinit: %s", proposal[i]); > > if (first_kex_follows != NULL) { > logit("[client prop] kex %i: '%s' from %s", > i, proposal[i], get_remote_ipaddr()); > } > } > > Unfortunately, it does not log anything when run as a daemon. Only when > run in debug ('-d' switch) I see the output. I used logit() in other > parts to add logging and it works great. > > My question: What am i doing wrong and how can I log the proposed > algorithms properly? > > (Please note: I am interested in the suggestions from the client and not > the ciphers client and server finally use!) > > Any helpfull suggestion appreciated! > > Regards > Andreas > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From kevin at alinto.com Thu Jul 7 22:44:33 2011 From: kevin at alinto.com (Kevin Denis) Date: Thu, 07 Jul 2011 14:44:33 +0200 Subject: Use of ssh certificates in a multi server of different kind environment. Message-ID: <1310042673.4e15aa318f1f2@webmail.inmano.com> Hello, [if I'm not in the right mailing list, please advise it to me] I'm using ssh certificates for my servers and my users. I have questions about it: I can use the same CA in order to certify all my hosts. Every clients can use it, and it's a great setup. But, if I use the same CA for all my clients, it means that any clients can log in to any server because hosts trusts my CA. And it's not a desired behavior. So I made several CAs, one for each type of servers. One for webservers, one for svn servers, one for my cluster, end so on.. and it works, but I have to manage a lot of keys. And certify each kind of users with the right key. Is there a way to add in the client certificate the name of the host authorized to log in to? With that I could still use only one CA and certify anyone behind it, a kind of: ssh-keygen -s CAKey -I CA -n user1 -O destination_address server1,192.168.19.2 user_rsa_key.pub But the destination_address option doesn't exists... So, am I doing rights with my multiple CA? Or there is a better way? Thanks, Envoy? avec Inmano, ma messagerie renversante et gratuite : http://www.inmano.com From raubvogel at gmail.com Fri Jul 8 00:50:22 2011 From: raubvogel at gmail.com (Mauricio Tavares) Date: Thu, 7 Jul 2011 10:50:22 -0400 Subject: Use of ssh certificates in a multi server of different kind environment. In-Reply-To: <1310042673.4e15aa318f1f2@webmail.inmano.com> References: <1310042673.4e15aa318f1f2@webmail.inmano.com> Message-ID: On Thu, Jul 7, 2011 at 8:44 AM, Kevin Denis wrote: > Hello, > > [if I'm not in the right mailing list, please advise it to me] > > I'm using ssh certificates for my servers and my users. > I have questions about it: > > I can use the same CA in order to certify all my hosts. Every clients can use it, > and it's a great setup. But, if I use the same CA for all my clients, it means that > any clients can log in to any server because hosts trusts my CA. And it's not a > desired behavior. > > So I made several CAs, one for each type of servers. One for webservers, one > for svn servers, one for my cluster, end so on.. and it works, but I have to > manage a lot of keys. And certify each kind of users with the right key. > > Is there a way to add in the client certificate the name of the host authorized to > log in to? With that I could still use only one CA and certify anyone behind it, a > kind of: > ssh-keygen -s CAKey -I CA -n user1 -O destination_address > server1,192.168.19.2 user_rsa_key.pub > > But the destination_address option doesn't exists... > > So, am I doing rights with my multiple CA? Or there is a better way? > Can't your firewall/hosts.{allow,deny} files specify which IPs and subnets are allowed to login to your server? This will not solve your problem but could be a start. > Thanks, > > Envoy? avec Inmano, ma messagerie renversante et gratuite : http://www.inmano.com > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From dan at lightwave.net.ru Fri Jul 8 01:17:34 2011 From: dan at lightwave.net.ru (Dan Yefimov) Date: Thu, 07 Jul 2011 19:17:34 +0400 Subject: Use of ssh certificates in a multi server of different kind environment. In-Reply-To: <1310042673.4e15aa318f1f2@webmail.inmano.com> References: <1310042673.4e15aa318f1f2@webmail.inmano.com> Message-ID: <4E15CE0E.4070605@lightwave.net.ru> On 07.07.2011 16:44, Kevin Denis wrote: > Hello, > > [if I'm not in the right mailing list, please advise it to me] > > I'm using ssh certificates for my servers and my users. > I have questions about it: > > I can use the same CA in order to certify all my hosts. Every clients can use it, > and it's a great setup. But, if I use the same CA for all my clients, it means that > any clients can log in to any server because hosts trusts my CA. And it's not a > desired behavior. > > So I made several CAs, one for each type of servers. One for webservers, one > for svn servers, one for my cluster, end so on.. and it works, but I have to > manage a lot of keys. And certify each kind of users with the right key. > > Is there a way to add in the client certificate the name of the host authorized to > log in to? With that I could still use only one CA and certify anyone behind it, a > kind of: > ssh-keygen -s CAKey -I CA -n user1 -O destination_address > server1,192.168.19.2 user_rsa_key.pub > > But the destination_address option doesn't exists... > > So, am I doing rights with my multiple CA? Or there is a better way? > I think, you should pay attention to Kerberos, instead of client certificates. -- Sincerely Yours, Dan. From imorgan at nas.nasa.gov Fri Jul 8 02:34:40 2011 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 7 Jul 2011 09:34:40 -0700 Subject: Use of ssh certificates in a multi server of different kind environment. In-Reply-To: <1310042673.4e15aa318f1f2@webmail.inmano.com> References: <1310042673.4e15aa318f1f2@webmail.inmano.com> Message-ID: <20110707163439.GA14466@linux124.nas.nasa.gov> On Thu, Jul 07, 2011 at 07:44:33 -0500, Kevin Denis wrote: > Hello, > > I'm using ssh certificates for my servers and my users. > I have questions about it: > > I can use the same CA in order to certify all my hosts. Every clients can use it, > and it's a great setup. But, if I use the same CA for all my clients, it means that > any clients can log in to any server because hosts trusts my CA. And it's not a > desired behavior. > > So I made several CAs, one for each type of servers. One for webservers, one > for svn servers, one for my cluster, end so on.. and it works, but I have to > manage a lot of keys. And certify each kind of users with the right key. > > Is there a way to add in the client certificate the name of the host authorized to > log in to? With that I could still use only one CA and certify anyone behind it, a > kind of: > ssh-keygen -s CAKey -I CA -n user1 -O destination_address > server1,192.168.19.2 user_rsa_key.pub > > But the destination_address option doesn't exists... > > So, am I doing rights with my multiple CA? Or there is a better way? > > Thanks, > > Envoy? avec Inmano, ma messagerie renversante et gratuite : http://www.inmano.com > While the certificates do not provide a means of restricting their use to authenticating against specific servers, there are a variety of ways to accomplish a similar end. The most obvious is to only provision accounts on servers for users who are authorized to access them. However, there may be some circumstances where this is not practical. Another approach would be to use the AllowGroups keyword in the sshd_config and only assign users to the allowed groups if they are authorized to access the system. Thus, you might have a group for each class of server for which you wish to authorize access. You can also provide access control via a PAM such as pam_access.so. If you are using a recent enough version of OpenSSH, you could also use the AuthorizedPrincipalsFile keyword to specify which principals can login to a given account. You could then adjust these files on a host-by-host basis. -- Iain Morgan From vnagrik at gmail.com Thu Jul 7 08:14:42 2011 From: vnagrik at gmail.com (Vinay Nagrik) Date: Wed, 6 Jul 2011 15:14:42 -0700 Subject: Bug: openssh-4.3p2-72.el5_6.3.src.rpm Message-ID: Hello Group, I downloaded openssh-4.3p2-72.el5_6.3.src.rpm built the rpm and installed it. However, sshd daemon does not start when the host comes up. When I try to start it manually it says *Starting sshd: Auto configuration failed 29545 Error: 0E065068 configuration file routine: STR_COPY: variable has no value: conf_def.c:629: line 233 * and when I try to login from outside it fails. Obviously because daemon has not started. *The system works flawlessly with the old version of openssh i.e.* * openssh-4.3p2-36.el5_4.3.src.rpm* I think it is a bug. Has anyone encountered the similar problem. Please help. Thanks nagrik From djm at mindrot.org Fri Jul 8 13:17:13 2011 From: djm at mindrot.org (Damien Miller) Date: Fri, 8 Jul 2011 13:17:13 +1000 (EST) Subject: Use of ssh certificates in a multi server of different kind environment. In-Reply-To: <1310042673.4e15aa318f1f2@webmail.inmano.com> References: <1310042673.4e15aa318f1f2@webmail.inmano.com> Message-ID: On Thu, 7 Jul 2011, Kevin Denis wrote: > Hello, > > [if I'm not in the right mailing list, please advise it to me] > > I'm using ssh certificates for my servers and my users. > I have questions about it: > > I can use the same CA in order to certify all my hosts. Every clients can use it, > and it's a great setup. But, if I use the same CA for all my clients, it means that > any clients can log in to any server because hosts trusts my CA. And it's not a > desired behavior. > > So I made several CAs, one for each type of servers. One for webservers, one > for svn servers, one for my cluster, end so on.. and it works, but I have to > manage a lot of keys. And certify each kind of users with the right key. > > Is there a way to add in the client certificate the name of the host authorized to > log in to? With that I could still use only one CA and certify anyone behind it, a > kind of: Yes, you can do this using principals: ssh-keygen -s CAKey -I username -n username at host1.allowed,username at host2.allowed key Set "AuthorizedPrincipalsFile .ssh/authorized_principals" in sshd_config on each of the hosts that trust CAKey. Finally, populate ~/.ssh/authorized_principals for each user you want to allow to contain "username at host.name". Hosts where the name from authorized_principals match the name in the ssh-keygen principals list will permit access to the user. This would be easier if it were possible to expand the host's name in authorized_principals. Then you could have "%u@%h" or somesuch in each one and it would do the right thing everywhere. -d From bob at proulx.com Fri Jul 8 14:45:59 2011 From: bob at proulx.com (Bob Proulx) Date: Thu, 7 Jul 2011 22:45:59 -0600 Subject: Bug: openssh-4.3p2-72.el5_6.3.src.rpm In-Reply-To: References: Message-ID: <20110708044559.GA430@hysteria.proulx.com> Vinay Nagrik wrote: > I downloaded openssh-4.3p2-72.el5_6.3.src.rpm built the rpm and > installed it. However, sshd daemon does not start when the host > comes up. This is very unlikely to be an upstream OpenSSH problem. You would probably have better luck asking your question on a RHEL/CentOS list. > When I try to start it manually it says > *Starting sshd: Auto configuration failed > 29545 Error: 0E065068 configuration file routine: STR_COPY: variable > has no value: > conf_def.c:629: line 233 I am not running RHEL/CentOS but a very quick web search turned up this reference: http://southbrain.com/south/2011/04/centosredhat-56-sshd-problem-8.html That reads to me to be the same as your reported problem. Bob From kevin at alinto.com Sun Jul 10 01:07:30 2011 From: kevin at alinto.com (Kevin Denis) Date: Sat, 09 Jul 2011 17:07:30 +0200 Subject: Use of ssh certificates in a multi server of different kind environment. In-Reply-To: References: <1310042673.4e15aa318f1f2@webmail.inmano.com> Message-ID: <1310224050.4e186eb26c643@webmail.inmano.com> En r?ponse ? Damien Miller : > Yes, you can do this using principals: > I'l try that, thank you.. > This would be easier if it were possible to expand > the host's name in authorized_principals. Then > you could have "%u@%h" or somesuch in > each one and it would do the right thing everywhere. > Sure, it would be a great setup! Kevin > _______________________________________________ Envoy? avec Inmano, ma messagerie renversante et gratuite : http://www.inmano.com From brakeb at gmail.com Wed Jul 13 11:33:19 2011 From: brakeb at gmail.com (Bryan) Date: Tue, 12 Jul 2011 20:33:19 -0500 Subject: How to compile OpenSSH on HP-UX10 Message-ID: I did this as a project back in the early 2002, and I had a nice little how-to to walk me through it. Many work places and moves, and I've lost it. I have a friend who asked me about this recently, and I can't seem to find anything on the web, or the how-to I used (not surprised). If I remember correctly, you needed an up-to-date zlib, egd (or prng), OpenSSL, tcpwrappers, and OpenSSH. Have I forgotten anything? I remember you had to build zlib, then egd, then it gets fuzzy. He wants to enable FIPS as well. I've built OpenSSL/OpenSSH with fips for Windows, but is something like that possible with HP-UX? if anyone has a how-to with directions, my friend (and I) would appreciate. I don't have access to that horrid OS anymore, so I can't help him short of what I gave him... which isn't much.. From andyb1 at andy-t.org Wed Jul 13 11:55:41 2011 From: andyb1 at andy-t.org (Andy Tsouladze) Date: Tue, 12 Jul 2011 20:55:41 -0500 (CDT) Subject: How to compile OpenSSH on HP-UX10 In-Reply-To: References: Message-ID: > If I remember correctly, you needed an up-to-date zlib, egd (or prng), > OpenSSL, tcpwrappers, and OpenSSH. It's been quite a few years since I touched HP-UX, but here is what comes to mind: > Have I forgotten anything? I remember you had to build zlib, then > egd, then it gets fuzzy. You do need zlib and openssl. tcp-wrappers are not required, so you need this only if you want to use them. Openssh does not absolutely need egd/prng - it can generate entropy from a predefined set of system processes (ps, netstat, etc.) - but if you can, you should get prng. Besides, you will need a compiler and related tools. The compilermust be other than the one used for the kernel. So it is either HP-UX C compiler, if you have a license for it, or GCC. If you do not have HP-UX C compiler, in all likelihood you also miss all header files. They are not installed by default unless you install buy and install the compiler. So you have to install header files separately. On the other hand, I remember there used to be very good repositories of precompiled freeware tools for HP-UX. It might be easier to use them. Here is one: ftp://ftp.thewrittenword.com/packages/by-architecture/hppa1.1-hp-hpux10.20/ Regards, Andy > > He wants to enable FIPS as well. I've built OpenSSL/OpenSSH with fips > for Windows, but is something like that possible with HP-UX? > > if anyone has a how-to with directions, my friend (and I) would > appreciate. I don't have access to that horrid OS anymore, so I can't > help him short of what I gave him... which isn't much.. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > Dr Andy Tsouladze Sr Unix/Storage SysAdmin From bob at proulx.com Wed Jul 13 13:20:55 2011 From: bob at proulx.com (Bob Proulx) Date: Tue, 12 Jul 2011 21:20:55 -0600 Subject: How to compile OpenSSH on HP-UX10 In-Reply-To: References: Message-ID: <20110713032055.GC25223@hysteria.proulx.com> Andy Tsouladze wrote: > Openssh does not absolutely need egd/prng - it can generate entropy > from a predefined set of system processes (ps, netstat, etc.) - but > if you can, you should get prng. Check your HP-UX for /dev/random and /dev/urandom as this has been patched into most of the recent versions. I just checked an 11.11 machine and it had it available now. I don't recall when this feature became available there but it is quite possible that you won't need egd or prngd anymore. > On the other hand, I remember there used to be very good > repositories of precompiled freeware tools for HP-UX. It might be > easier to use them. > Here is one: ftp://ftp.thewrittenword.com/packages/by-architecture/hppa1.1-hp-hpux10.20/ Of course. As in I would agree with your statement too. But of course /someone/ must be able to compile it. :-) Bob From tim at multitalents.net Wed Jul 13 15:41:58 2011 From: tim at multitalents.net (Tim Rice) Date: Tue, 12 Jul 2011 22:41:58 -0700 (PDT) Subject: How to compile OpenSSH on HP-UX10 In-Reply-To: References: Message-ID: On Tue, 12 Jul 2011, Andy Tsouladze wrote: > Openssh does not absolutely need egd/prng - it > can generate entropy from a predefined set of system processes (ps, netstat, > etc.) - but if you can, you should get prng. While that is true for the released versions so far, you will need a random number generator for 5.9 and later. The entropy gathering bits have been ripped out. -- Tim Rice tim at multitalents.net From deengert at anl.gov Thu Jul 14 04:57:21 2011 From: deengert at anl.gov (Douglas E. Engert) Date: Wed, 13 Jul 2011 13:57:21 -0500 Subject: How to compile OpenSSH on HP-UX10 In-Reply-To: References: Message-ID: <4E1DEA91.3040908@anl.gov> On 7/12/2011 8:33 PM, Bryan wrote: > I did this as a project back in the early 2002, and I had a nice > little how-to to walk me through it. Many work places and moves, and > I've lost it. I have a friend who asked me about this recently, and I > can't seem to find anything on the web, or the how-to I used (not > surprised). > > If I remember correctly, you needed an up-to-date zlib, egd (or prng), > OpenSSL, tcpwrappers, and OpenSSH. > > Have I forgotten anything? I remember you had to build zlib, then > egd, then it gets fuzzy. > > He wants to enable FIPS as well. I've built OpenSSL/OpenSSH with fips > for Windows, but is something like that possible with HP-UX? > > if anyone has a how-to with directions, my friend (and I) would > appreciate. I don't have access to that horrid OS anymore, so I can't > help him short of what I gave him... which isn't much.. For what it is worth, my configure/build scripts from OpenSSH-5.1 had this for HPUX, but I never build 5.1 for HP. The scripts where carried over from previous versions and still had the HP parameters: [...] MYCFLAGS="-O" MYCPPFLAGS="" MYLDFLAGS="" MYPAM="yes" MYRAND="" {...] MYK5= (to krb5 directory) MYZLIB= (to zlib) MYWRAPPER= (to wrapper) MYSSL= (to OpenSSL) [...] # configure tests SSL and Kerberos and we need to make sure # the libs we want to build against are in LD_LIBRARY_PATH # Note: on Linux LD_LIBRARY_PATH does not override -rpath!!! # This can cause problems in configure testing the header and libs # and both 0.9.7d and 0.9.7e are called 0.9.7 # hp_ux102 has similar problems. LD_LIBRARY_PATH=$MYSSL/lib:$MYK5/lib SHLIB_PATH=$MYSSL/lib:$MYK5/lib LIBPATH=$MYSSL/lib:$MYK5/lib DYLD_LIBRARY_PATH=$MYSSL/lib:$MYK5/lib export LD_LIBRARY_PATH export SHLIB_PATH export LIBPATH export DYLD_LIBRARY_PATH [...] case $SYS in [... other system types] hp_ux102) MYLDFLAGS="$MYLDFLAGS -Wl,+vnocompatwarnings,+b,/krb5/lib -Wl,+cdp,$MYSSL/lib:/krb5/lib,+cdp,$MYK5/lib:/krb5/lib" MYWRAPPER="no" MYRAND="" MYPAM="no" MYCPPFLAGS="$MYCPPFLAGS -DUNSUPPORTED_POSIX_THREADS_HACK -D__hpux" ;; hp_ux*) MYLDFLAGS="$MYLDFLAGS -Wl,+vnocompatwarnings,+b,/krb5/lib -Wl,+cdp,$MYSSL/lib:/krb5/lib,+cdp,$MYK5/lib:/krb5/lib" MYWRAPPER="no" MYRAND="--with-prngd-socket=yes" MYCPPFLAGS="$MYCPPFLAGS -DUNSUPPORTED_POSIX_THREADS_HACK -D__hpux" ;; ia64_hpux112*) MYLDFLAGS="$MYLDFLAGS -Wl,+vnocompatwarnings,+b,/krb5/lib -Wl,+cdp,$MYSSL/lib:/krb5/lib,+cdp,$MYK5/lib:/krb5/lib" MYWRAPPER="no" MYRAND="--with-prngd-socket=yes" # hpux 11.23 had xom.h, used to need to fix rpcsec_gss.h # MYCPPFLAGS="$MYCPPFLAGS -DUSE_POSIX_THREADS -D__hpux -Dgss_OID_desc_struct=OM_object_identifier" MYCPPFLAGS="$MYCPPFLAGS -DUNSUPPORTED_POSIX_THREADS_HACK -D__hpux" ;; esac [...] ../src/configure \ --with-cflags="$MYCFLAGS" \ --with-ldflags="$MYLDFLAGS" \ --with-cppflags="$MYCPPFLAGS" \ --prefix=/krb5 \ --sysconfdir=/etc/ssh \ --localstatedir=/var \ --with-zlib=$MYZLIB \ --with-ssl-dir=$MYSSL \ --with-kerberos5=$MYK5 \ --with-tcp-wrappers=$MYWRAPPER \ --with-mantype=man \ --with-pam=$MYPAM \ --with-rsh=/krb5/bin/rsh \ $MYRAND \ --with-rpath=no \ --disable-suid-ssh > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From joshuat at gmail.com Thu Jul 14 13:12:00 2011 From: joshuat at gmail.com (Joshua Teitelbaum) Date: Wed, 13 Jul 2011 20:12:00 -0700 Subject: Yes/No Pedantic Patch Message-ID: Hello developers. I have made a yes/no 'pedantic' patch that affects how ssh command line and other agents that employ yes/no prompts interpret results. The nature of the patch is the following: When prompted with things like: ----SNIP---- ./ssh localhost The authenticity of host 'localhost (127.0.0.1)' can't be established. RSA key fingerprint is 36:f3:12:f4:20:5b:a5:22:31:01:d7:a8:5e:88:93:a3. Are you sure you want to continue connecting (yes/no)? ----SNIP---- Mr Jeffery Paul (sneak) thought it would be nice to just be able to type 'y' or 'n' respectively in lieu of the full yes/no. The patch I made affords yes/no prompts to be answered with single character y/n behavior as the default while affording both a new command line option -E and config file option y_n_pedantic 0|1to preserve the long form. May I send someone the patch I made for review? Is this a good idea? In closing I love ssh. The world does. Jeffrey Paul does, but he's terse :) -- http://www.cryptomail.org NOW 100% defunct! From mfriedl at gmail.com Fri Jul 15 00:40:25 2011 From: mfriedl at gmail.com (Markus Friedl) Date: Thu, 14 Jul 2011 16:40:25 +0200 Subject: Yes/No Pedantic Patch In-Reply-To: References: Message-ID: no, i don't want to make it easier to say "yes" here. only harder. -m On Thu, Jul 14, 2011 at 5:12 AM, Joshua Teitelbaum wrote: > Hello developers. > I have made a yes/no 'pedantic' patch that affects how ssh command line and > other agents that employ yes/no prompts interpret results. > > The nature of the patch is the following: > When prompted with things like: > ----SNIP---- > ./ssh ?localhost > The authenticity of host 'localhost (127.0.0.1)' can't be established. > RSA key fingerprint is 36:f3:12:f4:20:5b:a5:22:31:01:d7:a8:5e:88:93:a3. > Are you sure you want to continue connecting (yes/no)? > ----SNIP---- > > Mr Jeffery Paul (sneak) thought it would be nice to just be able to type 'y' > or 'n' respectively in lieu of the full yes/no. > The patch I made affords yes/no prompts to be answered with single character > y/n behavior as the default while affording both a new command line option > -E and config file option y_n_pedantic 0|1to preserve the long form. > > May I send someone the patch I made for review? > Is this a good idea? > > In closing I love ssh. > The world does. > Jeffrey Paul does, but he's terse :) > > > -- > http://www.cryptomail.org NOW 100% defunct! > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From cal.leeming at simplicitymedialtd.co.uk Fri Jul 15 00:42:58 2011 From: cal.leeming at simplicitymedialtd.co.uk (Cal Leeming [Simplicity Media Ltd]) Date: Thu, 14 Jul 2011 15:42:58 +0100 Subject: Yes/No Pedantic Patch In-Reply-To: References: Message-ID: This is going to sound silly but, I actually prefer typing "yes" rather than "y". Does that mean I am weird?? :X On Thu, Jul 14, 2011 at 3:40 PM, Markus Friedl wrote: > no, i don't want to make it easier to say "yes" here. only harder. > > -m > > On Thu, Jul 14, 2011 at 5:12 AM, Joshua Teitelbaum > wrote: > > Hello developers. > > I have made a yes/no 'pedantic' patch that affects how ssh command line > and > > other agents that employ yes/no prompts interpret results. > > > > The nature of the patch is the following: > > When prompted with things like: > > ----SNIP---- > > ./ssh localhost > > The authenticity of host 'localhost (127.0.0.1)' can't be established. > > RSA key fingerprint is 36:f3:12:f4:20:5b:a5:22:31:01:d7:a8:5e:88:93:a3. > > Are you sure you want to continue connecting (yes/no)? > > ----SNIP---- > > > > Mr Jeffery Paul (sneak) thought it would be nice to just be able to type > 'y' > > or 'n' respectively in lieu of the full yes/no. > > The patch I made affords yes/no prompts to be answered with single > character > > y/n behavior as the default while affording both a new command line > option > > -E and config file option y_n_pedantic 0|1to preserve the long form. > > > > May I send someone the patch I made for review? > > Is this a good idea? > > > > In closing I love ssh. > > The world does. > > Jeffrey Paul does, but he's terse :) > > > > > > -- > > http://www.cryptomail.org NOW 100% defunct! > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From joshuat at gmail.com Fri Jul 15 02:28:45 2011 From: joshuat at gmail.com (Joshua Teitelbaum) Date: Thu, 14 Jul 2011 09:28:45 -0700 Subject: Yes/No Pedantic Patch In-Reply-To: References: Message-ID: GOD HATES Y/N :D It's been a pleasure and a wonderful journey. We will continue to type 'yes' in lieu of 'y' and each time, know that Markus we're saying yes *to* you and because of you. For those with a morbid curiosity, the patch is at http://blogmeariver.com/YNPEDANTIC.tar.gz Thanks and keep up the good work. --josh On Thu, Jul 14, 2011 at 7:42 AM, Cal Leeming [Simplicity Media Ltd] < cal.leeming at simplicitymedialtd.co.uk> wrote: > This is going to sound silly but, I actually prefer typing "yes" rather > than "y". > > Does that mean I am weird?? :X > > > On Thu, Jul 14, 2011 at 3:40 PM, Markus Friedl wrote: > >> no, i don't want to make it easier to say "yes" here. only harder. >> >> -m >> >> On Thu, Jul 14, 2011 at 5:12 AM, Joshua Teitelbaum >> wrote: >> > Hello developers. >> > I have made a yes/no 'pedantic' patch that affects how ssh command line >> and >> > other agents that employ yes/no prompts interpret results. >> > >> > The nature of the patch is the following: >> > When prompted with things like: >> > ----SNIP---- >> > ./ssh localhost >> > The authenticity of host 'localhost (127.0.0.1)' can't be established. >> > RSA key fingerprint is 36:f3:12:f4:20:5b:a5:22:31:01:d7:a8:5e:88:93:a3. >> > Are you sure you want to continue connecting (yes/no)? >> > ----SNIP---- >> > >> > Mr Jeffery Paul (sneak) thought it would be nice to just be able to type >> 'y' >> > or 'n' respectively in lieu of the full yes/no. >> > The patch I made affords yes/no prompts to be answered with single >> character >> > y/n behavior as the default while affording both a new command line >> option >> > -E and config file option y_n_pedantic 0|1to preserve the long form. >> > >> > May I send someone the patch I made for review? >> > Is this a good idea? >> > >> > In closing I love ssh. >> > The world does. >> > Jeffrey Paul does, but he's terse :) >> > >> > >> > -- >> > http://www.cryptomail.org NOW 100% defunct! >> > _______________________________________________ >> > openssh-unix-dev mailing list >> > openssh-unix-dev at mindrot.org >> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> > >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> > > -- http://www.cryptomail.org NOW 100% defunct! From nkadel at gmail.com Mon Jul 18 02:07:03 2011 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sun, 17 Jul 2011 12:07:03 -0400 Subject: FAQ for Red Hat 6.x is now confusing with RHEL 6.0 and 6.1 releases. Message-ID: The old entry in the FAQ, quoted below, is now confusing through no fault of the FAQ author. > 3.5 - Password authentication doesn't work (eg on Slackware 7.0 or Red Hat 6.x) The problem is that Red Hat has now published Red Hat Enterprise Linux 6.0 and 6.1, normally written RHEL 6.0. Some software purchasers and new admins are not aware that Red Hat 6.0 was actually the name of a much older release, in 1999. Is it perhaps time to drop that FAQ entry, or point it more specifically to the old release? Perhaps adding a line like this? 3.5 - Password authentication doesn't work (eg on Slackware 7.0 or Red Hat 6.x). [ Note: this applied to Red Hat 6.x, not the much newer Red Hat Enterprise Linux 6.x. ] I've actually had recruiters confuse my knowledge of older Red Hat releases with RHEL releases: I've done both, so it wasn't a problem for me, but others can be confused by this. From cmadams at hiwaay.net Tue Jul 19 06:09:27 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 18 Jul 2011 15:09:27 -0500 Subject: FAQ for Red Hat 6.x is now confusing with RHEL 6.0 and 6.1 releases. In-Reply-To: References: Message-ID: <20110718200927.GA24540@hiwaay.net> Once upon a time, Nico Kadel-Garcia said: > The problem is that Red Hat has now published Red Hat Enterprise Linux > 6.0 and 6.1, normally written RHEL 6.0. Some software purchasers and > new admins are not aware that Red Hat 6.0 was actually the name of a > much older release, in 1999. No, "Red Hat" was never the name of a distribution. You are referring to "Red Hat Linux". When properly named, RHL and RHEL are easily distinguished. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From pink.banana.fish at gmail.com Mon Jul 18 06:10:16 2011 From: pink.banana.fish at gmail.com (Rory McNamara) Date: Sun, 17 Jul 2011 21:10:16 +0100 Subject: openSSH 5.8p2 BindPort patch Message-ID: Hi, i have written a patch for openSSH 5.8p2 which allows the user to set the local source port. The patch is as follows: diff -rupN openssh-5.8p2//readconf.c openssh-5.8p2-srcport//readconf.c --- openssh-5.8p2//readconf.c 2010-11-20 04:19:38.000000000 +0000 +++ openssh-5.8p2-srcport//readconf.c 2011-07-17 20:57:52.385044096 +0100 @@ -125,7 +125,7 @@ typedef enum { oGlobalKnownHostsFile2, oUserKnownHostsFile2, oPubkeyAuthentication, oKbdInteractiveAuthentication, oKbdInteractiveDevices, oHostKeyAlias, oDynamicForward, oPreferredAuthentications, oHostbasedAuthentication, - oHostKeyAlgorithms, oBindAddress, oPKCS11Provider, + oHostKeyAlgorithms, oBindAddress, oBindPort, oPKCS11Provider, oClearAllForwardings, oNoHostAuthenticationForLocalhost, oEnableSSHKeysign, oRekeyLimit, oVerifyHostKeyDNS, oConnectTimeout, oAddressFamily, oGssAuthentication, oGssDelegateCreds, @@ -210,6 +210,7 @@ static struct { { "preferredauthentications", oPreferredAuthentications }, { "hostkeyalgorithms", oHostKeyAlgorithms }, { "bindaddress", oBindAddress }, + { "bindport", oBindPort }, #ifdef ENABLE_PKCS11 { "smartcarddevice", oPKCS11Provider }, { "pkcs11provider", oPKCS11Provider }, @@ -634,6 +635,10 @@ parse_string: charptr = &options->bind_address; goto parse_string; + case oBindPort: + charptr = &options->bind_port; + goto parse_string; + case oPKCS11Provider: charptr = &options->pkcs11_provider; goto parse_string; @@ -1133,6 +1138,7 @@ initialize_options(Options * options) options->log_level = SYSLOG_LEVEL_NOT_SET; options->preferred_authentications = NULL; options->bind_address = NULL; + options->bind_port = NULL; options->pkcs11_provider = NULL; options->enable_ssh_keysign = - 1; options->no_host_authentication_for_localhost = - 1; diff -rupN openssh-5.8p2//readconf.h openssh-5.8p2-srcport//readconf.h --- openssh-5.8p2//readconf.h 2010-11-20 04:19:38.000000000 +0000 +++ openssh-5.8p2-srcport//readconf.h 2011-07-17 19:23:57.797387390 +0100 @@ -89,6 +89,7 @@ typedef struct { char *user_hostfile2; char *preferred_authentications; char *bind_address; /* local socket address for connection to sshd */ + char *bind_port; char *pkcs11_provider; /* PKCS#11 provider */ int verify_host_key_dns; /* Verify host key using DNS */ diff -rupN openssh-5.8p2//ssh.0 openssh-5.8p2-srcport//ssh.0 --- openssh-5.8p2//ssh.0 2011-05-05 02:58:10.000000000 +0100 +++ openssh-5.8p2-srcport//ssh.0 2011-07-17 21:00:05.153358189 +0100 @@ -4,7 +4,7 @@ NAME ssh - OpenSSH SSH client (remote login program) SYNOPSIS - ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec] + ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-B bind_port ] [-c cipher_spec] [-D [bind_address:]port] [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file] [-L [bind_address:]port:host:hostport] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] @@ -55,6 +55,10 @@ DESCRIPTION the connection. Only useful on systems with more than one address. + -B bind_port + Use bind_port port on the local machine as the source port of + the connection.address. + -C Requests compression of all data (including stdin, stdout, stderr, and data for forwarded X11 and TCP connections). The compression algorithm is the same used by gzip(1), and the @@ -215,6 +219,7 @@ DESCRIPTION AddressFamily BatchMode BindAddress + BindPort ChallengeResponseAuthentication CheckHostIP Cipher diff -rupN openssh-5.8p2//ssh.1 openssh-5.8p2-srcport//ssh.1 --- openssh-5.8p2//ssh.1 2010-11-20 04:21:03.000000000 +0000 +++ openssh-5.8p2-srcport//ssh.1 2011-07-17 20:56:13.265387325 +0100 @@ -45,6 +45,7 @@ .Bk -words .Op Fl 1246AaCfgKkMNnqsTtVvXxYy .Op Fl b Ar bind_address +.Op Fl B Ar bind_port .Op Fl c Ar cipher_spec .Op Fl D Oo Ar bind_address : Oc Ns Ar port .Op Fl e Ar escape_char @@ -127,6 +128,9 @@ Use on the local machine as the source address of the connection. Only useful on systems with more than one address. +.It Fl B Ar bind_port +Use bind_port port on the local machine as the source port of +the connection. .It Fl C Requests compression of all data (including stdin, stdout, stderr, and data for forwarded X11 and TCP connections). @@ -406,6 +410,7 @@ For full details of the options listed b .It AddressFamily .It BatchMode .It BindAddress +.It BindPort .It ChallengeResponseAuthentication .It CheckHostIP .It Cipher diff -rupN openssh-5.8p2//ssh.c openssh-5.8p2-srcport//ssh.c --- openssh-5.8p2//ssh.c 2011-02-04 00:42:15.000000000 +0000 +++ openssh-5.8p2-srcport//ssh.c 2011-07-17 20:15:48.613053886 +0100 @@ -193,7 +193,7 @@ static void usage(void) { fprintf(stderr, -"usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]\n" +"usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-B bind_port ] [-c cipher_spec]\n" " [-D [bind_address:]port] [-e escape_char] [-F configfile]\n" " [-I pkcs11] [-i identity_file]\n" " [-L [bind_address:]port:host:hostport]\n" @@ -297,7 +297,7 @@ main(int ac, char **av) again: while ((opt = getopt(ac, av, "1246ab:c:e:fgi:kl:m:no:p:qstvx" - "ACD:F:I:KL:MNO:PR:S:TVw:W:XYy")) != -1) { + "AB:CD:F:I:KL:MNO:PR:S:TVw:W:XYy")) != -1) { switch (opt) { case '1': options.protocol = SSH_PROTO_1; @@ -568,6 +568,9 @@ main(int ac, char **av) case 'F': config = optarg; break; + case 'B': + options.bind_port = optarg; + break; default: usage(); } diff -rupN openssh-5.8p2//ssh_config.0 openssh-5.8p2-srcport//ssh_config.0 --- openssh-5.8p2//ssh_config.0 2011-05-05 02:58:10.000000000 +0100 +++ openssh-5.8p2-srcport//ssh_config.0 2011-07-17 20:50:26.881386898 +0100 @@ -66,6 +66,10 @@ DESCRIPTION one address. Note that this option does not work if UsePrivilegedPort is set to ``yes''. + BindPort + Use bind_port port on the local machine as the source port of the + connection. + ChallengeResponseAuthentication Specifies whether to use challenge-response authentication. The argument to this keyword must be ``yes'' or ``no''. The default diff -rupN openssh-5.8p2//ssh_config.5 openssh-5.8p2-srcport//ssh_config.5 --- openssh-5.8p2//ssh_config.5 2010-12-26 03:26:48.000000000 +0000 +++ openssh-5.8p2-srcport//ssh_config.5 2011-07-17 20:54:48.829387482 +0100 @@ -143,6 +143,9 @@ Note that this option does not work if .Cm UsePrivilegedPort is set to .Dq yes . +.It Cm BindPort +Use the specified port on the local machine as the +source port of the connection. .It Cm ChallengeResponseAuthentication Specifies whether to use challenge-response authentication. The argument to this keyword must be diff -rupN openssh-5.8p2//sshconnect.c openssh-5.8p2-srcport//sshconnect.c --- openssh-5.8p2//sshconnect.c 2011-01-16 12:17:59.000000000 +0000 +++ openssh-5.8p2-srcport//sshconnect.c 2011-07-17 20:19:20.093054511 +0100 @@ -214,7 +214,7 @@ ssh_create_socket(int privileged, struct fcntl(sock, F_SETFD, FD_CLOEXEC); /* Bind the socket to an alternative local IP address */ - if (options.bind_address == NULL) + if (options.bind_address == NULL && options.bind_port == NULL) return sock; memset(&hints, 0, sizeof(hints)); @@ -222,7 +222,7 @@ ssh_create_socket(int privileged, struct hints.ai_socktype = ai->ai_socktype; hints.ai_protocol = ai->ai_protocol; hints.ai_flags = AI_PASSIVE; - gaierr = getaddrinfo(options.bind_address, NULL, &hints, &res); + gaierr = getaddrinfo(options.bind_address, options.bind_port, &hints, &res); if (gaierr) { error("getaddrinfo: %s: %s", options.bind_address, ssh_gai_strerror(gaierr)); From newsletter at 1touradventure.com Wed Jul 20 09:40:07 2011 From: newsletter at 1touradventure.com (1Tour & Adventure) Date: Wed, 20 Jul 2011 07:40:07 +0800 Subject: Welcome to Sabah Message-ID: Hi everyone, have you ever come to Sabah for holiday, if not please do so, coz it is really amazing place to pay a visit to the nature and the pristine islands. Islands Excursion Mantanani Island Water Rafting If you are planning a trip to the Land Below the Wind, please don't miss local sparkling freshness seafood. ????? 1Tour & Adventure Sdn Bhd Lot.33, 1st Floor, Block D, Asia City. Kota Kinabalu Sabah 88300 Malaysia E-mail: enquiry at 1touradventure.com Telephone: +6088-222720 If you do not want to receive any more newsletters, http://www.exysoft.com/lists/lt.php?id=NR0GCgEFWFYJRVdVW0QEUQIHXQc%3D To update your preferences and to unsubscribe visit http://www.exysoft.com/lists/lt.php?id=NR0GCgEFWFYHRVdVW0QEUQIHXQc%3D Forward a Message to Someone http://www.exysoft.com/lists/lt.php?id=NR0GCgEFWFYIRVdVW0QEUQIHXQc%3D ????????spam bots????????????????javascript?????? - From noreply at exysoft.com Wed Jul 20 12:27:15 2011 From: noreply at exysoft.com (Webmaster) Date: Wed, 20 Jul 2011 10:27:15 +0800 Subject: Goodbye from our Newsletter Message-ID: <0ea257292cd94b736fbdbf3aa329b86c@www.exysoft.com> Goodbye from our Newsletter, sorry to see you go. You have been unsubscribed from our newsletters. This is the last email you will receive from us. We have added you to our "blacklist", which means that our newsletter system will refuse to send you any other email, without manual intervention by our administrator. If there is an error in this information, you can re-subscribe: please go to http://www.exysoft.com/lists/?p=subscribe and follow the steps. Thank you From nkadel at gmail.com Tue Jul 19 07:50:41 2011 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Mon, 18 Jul 2011 17:50:41 -0400 Subject: FAQ for Red Hat 6.x is now confusing with RHEL 6.0 and 6.1 releases. In-Reply-To: <20110718200927.GA24540@hiwaay.net> References: <20110718200927.GA24540@hiwaay.net> Message-ID: On Mon, Jul 18, 2011 at 4:09 PM, Chris Adams wrote: > Once upon a time, Nico Kadel-Garcia said: >> The problem is that Red Hat has now published Red Hat Enterprise Linux >> 6.0 and 6.1, normally written RHEL 6.0. Some software purchasers and >> new admins are not aware that Red Hat 6.0 was actually the name of a >> much older release, in 1999. > > No, "Red Hat" was never the name of a distribution. ?You are referring > to "Red Hat Linux". ?When properly named, RHL and RHEL are easily > distinguished. What that was true of the contents of "/etc/redhat-relase", even Red Hat referred to it as "Red Hat 6.0" and later "Red Hat 6.2" in their websites and sales literature. This remains in evidence in Red Hat's in public websites such as https://www.redhat.com/mailman/listinfo/zoot-list. >> Zoot-list -- Discussion list for Red Hat 6.2 A FAQ is not the place to try to rely on be correct rather than clear. Given that the first page of results searching Google for "Red Hat Linux 6.x" all refers the current RHEL 6.x releases. I suggest that updating the language of the FAQ for clarity would help avoid confusion about the current releases. Perhaps this would be workable? This problem occurred with the obsolete Slackware 7.0 and Red Hat 6.x Linux. The issue has not been reported for more recent Slackware or Red Hat Enterprise Linux 6.x releases. The problem is not one of correctness, in the FAQ, bur one of clarity for Linux. Add something like the above language would, I think, bo both correct and clear. From dtucker at zip.com.au Tue Jul 19 16:31:45 2011 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 19 Jul 2011 16:31:45 +1000 Subject: openSSH 5.8p2 BindPort patch In-Reply-To: References: Message-ID: On Mon, Jul 18, 2011 at 6:10 AM, Rory McNamara wrote: > Hi, i have written a patch for openSSH 5.8p2 which allows the user to > set the local source port. The patch is as follows: Note that you can also do this with a suitable ProxyCommand (eg openbsd's netcat): Host somehost ProxyCommand nc -p 1234 -s 10.0.0.1 %h %p -- 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 pink.banana.fish at gmail.com Tue Jul 19 20:42:00 2011 From: pink.banana.fish at gmail.com (Rory McNamara) Date: Tue, 19 Jul 2011 11:42:00 +0100 Subject: openSSH 5.8p2 BindPort patch In-Reply-To: References: Message-ID: Surely that would be slower, becuase the data has to pass through a pipe to get to nc? and also, in my specific use case, i need to use ProxyCommand for corkscrew to pass through a proxy with ntlm auth. Thanks P.S I'm new to mailing lists, do i click 'Reply', or 'Reply to all'? On Tue, Jul 19, 2011 at 7:31 AM, Darren Tucker wrote: > On Mon, Jul 18, 2011 at 6:10 AM, Rory McNamara > wrote: >> Hi, i have written a patch for openSSH 5.8p2 which allows the user to >> set the local source port. The patch is as follows: > > Note that you can also do this with a suitable ProxyCommand (eg > openbsd's netcat): > > Host somehost > ?ProxyCommand nc -p 1234 -s 10.0.0.1 %h %p > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4? 37C9 C982 80C7 8FF4 FA69 > ? ? Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > From dtucker at zip.com.au Tue Jul 19 21:41:46 2011 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 19 Jul 2011 21:41:46 +1000 Subject: openSSH 5.8p2 BindPort patch In-Reply-To: References: Message-ID: On Tue, Jul 19, 2011 at 8:42 PM, Rory McNamara wrote: > Surely that would be slower, becuase the data has to pass through a > pipe to get to nc? possibly, although it's more likely that it'll be IO bound on the network. Try it. > and also, in my specific use case, i need to use > ProxyCommand for corkscrew to pass through a proxy with ntlm auth. In that case, how do you do use the bindport at all? Using a proxycommand doesn't allocate a tcp socket. > P.S I'm new to mailing lists, do i click 'Reply', or 'Reply to all'? Depends. I always "reply all" unless the poster has set a reply-to field. -- 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 rstory at sparta.com Thu Jul 21 02:47:03 2011 From: rstory at sparta.com (Robert Story) Date: Wed, 20 Jul 2011 12:47:03 -0400 Subject: auto-accept keys matching DNSSEC-validated SSHFP records Message-ID: <20110720124703.2ff289b9@sparta.com> Hi, I submitted a patch back in November of 2009 to add local validation of DNSSEC record to openssh. I recent updated the patch for 5.8, and figured I do a little marketing while I'm at it. :-) Someone had previously submitted a patch which simply trusted the AD bit in the response, which is susceptible to spoofing by anyone who can inject packets between the resolver and the client. Our patch always fetches the signatures and verifies them locally. A new option, oStrictDnssecChecking, determines whether or not an untrusted response is treated as a failure, or if the result is returned with a warning. In addition to adding local validation, a new setting, oAutoAnswerValidatedKeys, allows the user to automatically accept new keys which match DNSSEC-validated SSHFP records. The default for this new option is off, so even if the record matches, the user will still be asked to confirm before connecting. The patch is here: https://bugzilla.mindrot.org/show_bug.cgi?id=1672 I dug up some test cases and output from my archives. These show the results seen when oAutoAnswerValidatedKeys is enabled. 1) ssh to a new host, DNSSEC-validated sshfp key: $ ./ssh bishop The authenticity of host 'bishop.vb (192.168.1.10)' was validated via DNSSEC. Warning: Permanently added 'bishop.vb,192.168.1.10' (RSA) to the list of known hosts. 2) subsequent ssh to existing host with key changes, but no DNS update $ ./ssh bishop @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 1a:48:3f:2c:54:29:60:c4:86:b9:78:bd:e9:64:1f:8d. Please contact your system administrator. Update the SSHFP RR in DNS with the new host key to get rid of this message. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 1a:48:3f:2c:54:29:60:c4:86:b9:78:bd:e9:64:1f:8d. Please contact your system administrator. Add correct host key in /home/rstory/.ssh/known_hosts to get rid of this message. Offending key in /home/rstory/.ssh/known_hosts:69 RSA host key for bishop.vb has changed and you have requested strict checking. Host key verification failed. 3) ssh to same host after SSHFP record updated and re-signed $ ./ssh bishop @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Howerver, a matching host key, validated by DNSSEC, was found. The fingerprint for the RSA key sent by the remote host is 1a:48:3f:2c:54:29:60:c4:86:b9:78:bd:e9:64:1f:8d. Please contact your system administrator. Add correct host key in /home/rstory/.ssh/known_hosts to get rid of this message. Offending key in /home/rstory/.ssh/known_hosts:69 The authenticity of host 'bishop.vb (192.168.1.10)' was validated via DNSSEC. Warning: Permanently added 'bishop.vb' (RSA) to the list of known hosts. 4) subsequent logins (no remote changes) $ ./ssh bishop Warning: the RSA host key for 'bishop.vb' differs from the key for the IP address '192.168.1.10' Offending key for IP in /home/rstory/.ssh/known_hosts:69 Matching host key in /home/rstory/.ssh/known_hosts:70 5) IP addr change $ ./ssh bishop Warning: Permanently added the RSA host key for IP address '192.168.1.9' to the list of known hosts. 6) IP addr change and key change, with DNSSEC signed SSHFP record $ ./ssh bishop @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: HOST IP ADDRESS HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ The RSA host key for bishop.vb has changed, and the key for the according IP address 192.168.1.10 is unknown. The IP address for the host and its host key have changed at the same time. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Howerver, a matching host key, validated by DNSSEC, was found. The fingerprint for the RSA key sent by the remote host is c3:2d:e8:9e:65:b2:17:22:36:aa:73:47:d7:cd:5e:ae. Please contact your system administrator. Add correct host key in /home/rstory/.ssh/known_hosts to get rid of this message. Offending key in /home/rstory/.ssh/known_hosts:69 The authenticity of host 'bishop.vb (192.168.1.10)' was validated via DNSSEC. Warning: Permanently added 'bishop.vb,192.168.1.10' (RSA) to the list of known hosts. Robert -- Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From pink.banana.fish at gmail.com Tue Jul 19 22:41:59 2011 From: pink.banana.fish at gmail.com (Rory McNamara) Date: Tue, 19 Jul 2011 13:41:59 +0100 Subject: openSSH 5.8p2 BindPort patch In-Reply-To: References: Message-ID: >possibly, although it's more likely that it'll be IO bound on the >network. Try it. ./ssh -B 10000 -i ~/.ssh/id_rsa USER at HOST -p 443 'find /' 3.046 seconds ./ssh -o "ProxyCommand=nc -p 10000 %h %p" -i ~/.ssh/id_rsa USER at HOST -p 443 'find /' 2.592 seconds This is over the internet, to a ddwrt router. This therefore shows that my patch is slower by 0.5 seconds in this instance. However, i still believe it is of benefit if you need to use something else for your ProxyCommand >In that case, how do you do use the bindport at all? Using a >proxycommand doesn't allocate a tcp socket. The proxy im trying to get through only allows ssl on ports 443 from port 443, i have no idea why, but it means i have to set the source port to be 443 and the destination port to be 443, as well as the proxycommand to be able to get through it. On Tue, Jul 19, 2011 at 12:41 PM, Darren Tucker wrote: > On Tue, Jul 19, 2011 at 8:42 PM, Rory McNamara > wrote: >> Surely that would be slower, becuase the data has to pass through a >> pipe to get to nc? > > possibly, although it's more likely that it'll be IO bound on the > network. ?Try it. > >> and also, in my specific use case, i need to use >> ProxyCommand for corkscrew to pass through a proxy with ntlm auth. > > In that case, how do you do use the bindport at all? ?Using a > proxycommand doesn't allocate a tcp socket. > >> P.S I'm new to mailing lists, do i click 'Reply', or 'Reply to all'? > > Depends. ?I always "reply all" unless the poster has set a reply-to field. > > -- > 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 alex at alex.org.uk Thu Jul 21 03:41:53 2011 From: alex at alex.org.uk (Alex Bligh) Date: Wed, 20 Jul 2011 18:41:53 +0100 Subject: auto-accept keys matching DNSSEC-validated SSHFP records In-Reply-To: <20110720124703.2ff289b9@sparta.com> References: <20110720124703.2ff289b9@sparta.com> Message-ID: <00707CB157E454132A2B8A83@Ximines.local> --On 20 July 2011 12:47:03 -0400 Robert Story wrote: > 3) ssh to same host after SSHFP record updated and re-signed > > $ ./ssh bishop > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > Howerver, a matching host key, validated by DNSSEC, was found. > The fingerprint for the RSA key sent by the remote host is > 1a:48:3f:2c:54:29:60:c4:86:b9:78:bd:e9:64:1f:8d. > Please contact your system administrator. > Add correct host key in /home/rstory/.ssh/known_hosts to get rid of this > message. Offending key in /home/rstory/.ssh/known_hosts:69 > The authenticity of host 'bishop.vb (192.168.1.10)' was validated via > DNSSEC. Warning: Permanently added 'bishop.vb' (RSA) to the list of known > hosts. I think the functionality I'd want here (I appreciate other people might differ) is no warning here. But the text of this warning is really confusing. Firstly it says "Add correct host key in /home/rstory/.ssh/known_hosts to get rid of this message.", then tells you (I think) that it has done just that. It should either be telling you that you need to do it (and not completing the connection), or not warning and completing the connection, I think. -- Alex Bligh From rstory at sparta.com Thu Jul 21 04:03:59 2011 From: rstory at sparta.com (Robert Story) Date: Wed, 20 Jul 2011 14:03:59 -0400 Subject: auto-accept keys matching DNSSEC-validated SSHFP records In-Reply-To: <00707CB157E454132A2B8A83@Ximines.local> References: <20110720124703.2ff289b9@sparta.com> <00707CB157E454132A2B8A83@Ximines.local> Message-ID: <20110720140359.28c28aaa@sparta.com> On Wed, 20 Jul 2011 18:41:53 +0100 Alex wrote: AB> > 3) ssh to same host after SSHFP record updated and re-signed AB> > AB> > $ ./ssh bishop AB> > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ AB> > @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ AB> > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ AB> > Howerver, a matching host key, validated by DNSSEC, was found. AB> > The fingerprint for the RSA key sent by the remote host is AB> > 1a:48:3f:2c:54:29:60:c4:86:b9:78:bd:e9:64:1f:8d. AB> > Please contact your system administrator. AB> > Add correct host key in /home/rstory/.ssh/known_hosts to get rid of this AB> > message. Offending key in /home/rstory/.ssh/known_hosts:69 AB> > The authenticity of host 'bishop.vb (192.168.1.10)' was validated via AB> > DNSSEC. Warning: Permanently added 'bishop.vb' (RSA) to the list of known AB> > hosts. AB> AB> I think the functionality I'd want here (I appreciate other people AB> might differ) is no warning here. AB> AB> But the text of this warning is really confusing. Firstly it says AB> "Add correct host key in /home/rstory/.ssh/known_hosts to get rid of this AB> message.", then tells you (I think) that it has done just that. It AB> should either be telling you that you need to do it (and not completing AB> the connection), or not warning and completing the connection, I think. I tried to minimize changes to existing code, so I left all the existing output in place with as little modification as possible. I'm fine with tweaking the output a bit. -- Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mfriedl at gmail.com Wed Jul 20 05:36:08 2011 From: mfriedl at gmail.com (Markus Friedl) Date: Tue, 19 Jul 2011 21:36:08 +0200 Subject: openSSH 5.8p2 BindPort patch In-Reply-To: References: Message-ID: On Sun, Jul 17, 2011 at 10:10 PM, Rory McNamara wrote: > Hi, i have written a patch for openSSH 5.8p2 which allows the user to > set the local source port. The patch is as follows: why do you need this? From pink.banana.fish at gmail.com Wed Jul 20 05:58:59 2011 From: pink.banana.fish at gmail.com (Rory McNamara) Date: Tue, 19 Jul 2011 20:58:59 +0100 Subject: openSSH 5.8p2 BindPort patch In-Reply-To: References: Message-ID: There's a firewall at school which only allows ss(l|h) connections from port 443 to port 443, it also requires basic/NTLM auth. This patch enables me to use corkscrew to to the auth and ssh to set the source port. There may be other case scenarios of which i am unaware. On Tue, Jul 19, 2011 at 8:36 PM, Markus Friedl wrote: > On Sun, Jul 17, 2011 at 10:10 PM, Rory McNamara > wrote: >> Hi, i have written a patch for openSSH 5.8p2 which allows the user to >> set the local source port. The patch is as follows: > > > why do you need this? > From nkadel at gmail.com Thu Jul 21 11:16:58 2011 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Wed, 20 Jul 2011 21:16:58 -0400 Subject: openSSH 5.8p2 BindPort patch In-Reply-To: References: Message-ID: On Tue, Jul 19, 2011 at 3:58 PM, Rory McNamara wrote: > There's a firewall at school which only allows ss(l|h) connections > from port 443 to port 443, it also requires basic/NTLM auth. This > patch enables me to use corkscrew to to the auth and ssh to set the > source port. There may be other case scenarios of which i am unaware. Interesting. What will they do to you if they find out you're doing this sort of short circuit around their firewalls and possibly their published policies? I'm not saying it's not worthwhile to be able to do this, just wondering about the social consequences if you're caught. I'm not personally a big believer in filtering speech, but there are enough "warez" servers hosted at schools against the wishes of the people who pay for the equipment and the bandwidth that I'm curious why you can't ask, or haven't asked, your admins to put a hole in the firewall precisely for SSH connections if you really need it. From joshuat at gmail.com Thu Jul 21 09:32:37 2011 From: joshuat at gmail.com (Joshua Teitelbaum) Date: Wed, 20 Jul 2011 16:32:37 -0700 Subject: openSSH 5.8p2 BindPort patch In-Reply-To: References: Message-ID: heheh it could be kind of fun to always appear to come from :13337 or something I dunno...but that's vanity. Or...it could be some wacky reason like some sysad/BOFH has some rules about source ports. Honestly I'm perplexed too, save the vanity reason :) On Tue, Jul 19, 2011 at 12:36 PM, Markus Friedl wrote: > On Sun, Jul 17, 2011 at 10:10 PM, Rory McNamara > wrote: > > Hi, i have written a patch for openSSH 5.8p2 which allows the user to > > set the local source port. The patch is as follows: > > > why do you need this? > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- http://www.cryptomail.org NOW 100% defunct! From pink.banana.fish at gmail.com Wed Jul 20 19:05:39 2011 From: pink.banana.fish at gmail.com (Rory McNamara) Date: Wed, 20 Jul 2011 10:05:39 +0100 Subject: openSSH 5.8p2 BindPort patch In-Reply-To: References: Message-ID: > That sounds quite broken since TCP connections are uniquely identified > by the 4-tuple of source IP, source port, destination IP, destination > port. ?If your proxy does what you describe it would limit you to only > one outbound SSL connection at any time and I would suspect something > is misconfigured. > [...] > I remain unconvinced that your patch has any effect at all in this case. Well maybe it is, i can't verify anything until september, but this is the only configuration i found to work. albeit with a modified putty, but the connection was the same. On Wed, Jul 20, 2011 at 5:12 AM, Darren Tucker wrote: > On Tue, Jul 19, 2011 at 10:41 PM, Rory McNamara > wrote: >>>possibly, although it's more likely that it'll be IO bound on the >>>network. ?Try it. >> ./ssh -B 10000 -i ~/.ssh/id_rsa USER at HOST -p 443 'find /' >> 3.046 seconds >> ./ssh -o "ProxyCommand=nc -p 10000 %h %p" -i ~/.ssh/id_rsa USER at HOST >> -p 443 'find /' >> 2.592 seconds >> >> This is over the internet, to a ddwrt router. >> This therefore shows that my patch is slower by 0.5 seconds in this >> instance. However, i still believe it is of benefit if you need to use >> something else for your ProxyCommand > > I disagree. ?With your patch: > > $ strace -e trace=bind ./ssh -B 12345 localhost true 2>&1 | grep AF_INET > bind(3, {sa_family=AF_INET, sin_port=htons(12345), > sin_addr=inet_addr("0.0.0.0")}, 16) = 0 > > $ strace -e trace=bind ./ssh -B 12345 -o proxycommand="nc %h %p" > localhost true 2>&1 | grep AF_INET > $ > > So when there's a proxycommand there's no bind at all. > >>>In that case, how do you do use the bindport at all? ?Using a >>>proxycommand doesn't allocate a tcp socket. >> >> The proxy im trying to get through only allows ssl on ports 443 from >> port 443, i have no idea why, > > That sounds quite broken since TCP connections are uniquely identified > by the 4-tuple of source IP, source port, destination IP, destination > port. ?If your proxy does what you describe it would limit you to only > one outbound SSL connection at any time and I would suspect something > is misconfigured. > >> but it means i have to set the source >> port to be 443 and the destination port to be 443, as well as the >> proxycommand to be able to get through it. > > I remain unconvinced that your patch has any effect at all in this case. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4? 37C9 C982 80C7 8FF4 FA69 > ? ? Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > From dtucker at zip.com.au Wed Jul 20 14:12:38 2011 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 20 Jul 2011 14:12:38 +1000 Subject: openSSH 5.8p2 BindPort patch In-Reply-To: References: Message-ID: On Tue, Jul 19, 2011 at 10:41 PM, Rory McNamara wrote: >>possibly, although it's more likely that it'll be IO bound on the >>network. ?Try it. > ./ssh -B 10000 -i ~/.ssh/id_rsa USER at HOST -p 443 'find /' > 3.046 seconds > ./ssh -o "ProxyCommand=nc -p 10000 %h %p" -i ~/.ssh/id_rsa USER at HOST > -p 443 'find /' > 2.592 seconds > > This is over the internet, to a ddwrt router. > This therefore shows that my patch is slower by 0.5 seconds in this > instance. However, i still believe it is of benefit if you need to use > something else for your ProxyCommand I disagree. With your patch: $ strace -e trace=bind ./ssh -B 12345 localhost true 2>&1 | grep AF_INET bind(3, {sa_family=AF_INET, sin_port=htons(12345), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 $ strace -e trace=bind ./ssh -B 12345 -o proxycommand="nc %h %p" localhost true 2>&1 | grep AF_INET $ So when there's a proxycommand there's no bind at all. >>In that case, how do you do use the bindport at all? ?Using a >>proxycommand doesn't allocate a tcp socket. > > The proxy im trying to get through only allows ssl on ports 443 from > port 443, i have no idea why, That sounds quite broken since TCP connections are uniquely identified by the 4-tuple of source IP, source port, destination IP, destination port. If your proxy does what you describe it would limit you to only one outbound SSL connection at any time and I would suspect something is misconfigured. > but it means i have to set the source > port to be 443 and the destination port to be 443, as well as the > proxycommand to be able to get through it. I remain unconvinced that your patch has any effect at all in this case. -- 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 pink.banana.fish at gmail.com Thu Jul 21 20:00:30 2011 From: pink.banana.fish at gmail.com (Rory McNamara) Date: Thu, 21 Jul 2011 11:00:30 +0100 Subject: openSSH 5.8p2 BindPort patch In-Reply-To: References: Message-ID: I have discussed the problem with both of my (previous) IT teachers, and they said it would probably be alright as long as I don't start doing anything stupid. We can't ask for an exception becuase the rules are maintained by the council, so it would be a lot more trouble than it's worth to get ssh unblocked. As well as the fact that the general attitude is that i shouldn't know what ssh is at this age (15/16) anyway. Next year, supposedly the IT technician is a lot more friendly (different site, same school), so i may talk to him about the various protections and what it would take to get a hole put in. But i can't do that until september when i go back. On Thu, Jul 21, 2011 at 2:16 AM, Nico Kadel-Garcia wrote: > On Tue, Jul 19, 2011 at 3:58 PM, Rory McNamara > wrote: >> There's a firewall at school which only allows ss(l|h) connections >> from port 443 to port 443, it also requires basic/NTLM auth. This >> patch enables me to use corkscrew to to the auth and ssh to set the >> source port. There may be other case scenarios of which i am unaware. > > Interesting. What will they do to you if they find out you're doing > this sort of short circuit around their firewalls and possibly their > published policies? I'm not saying it's not worthwhile to be able to > do this, just wondering about the social consequences if you're > caught. > > I'm not personally a big believer in filtering speech, but there are > enough "warez" servers hosted at schools against the wishes of the > people who pay for the equipment and the bandwidth that I'm curious > why you can't ask, or haven't asked, your admins to put a hole in the > firewall precisely for SSH connections if you really need it. > From nkadel at gmail.com Thu Jul 21 23:16:41 2011 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 21 Jul 2011 09:16:41 -0400 Subject: openSSH 5.8p2 BindPort patch In-Reply-To: References: Message-ID: On Thu, Jul 21, 2011 at 6:00 AM, Rory McNamara wrote: > I have discussed the problem with both of my (previous) IT teachers, > and they said it would probably be alright as long as I don't start > doing anything stupid. We can't ask for an exception becuase the rules > are maintained by the council, so it would be a lot more trouble than > it's worth to get ssh unblocked. As well as the fact that the general > attitude is that i shouldn't know what ssh is at this age (15/16) > anyway. Next year, supposedly the IT technician is a lot more friendly > (different site, same school), so i may talk to him about the various > protections and what it would take to get a hole put in. But i can't > do that until september when i go back. This makes some sense, thanks for sharing it. Perhaps you can negotiate a proxy, rather than a simple hole in the firewall, to allow access for SSH to source control repositories like sourceforge and github. From pink.banana.fish at gmail.com Thu Jul 21 23:50:49 2011 From: pink.banana.fish at gmail.com (Rory McNamara) Date: Thu, 21 Jul 2011 14:50:49 +0100 Subject: openSSH 5.8p2 BindPort patch In-Reply-To: References: Message-ID: But i don't need access to github/sourceforge. Well, not at school anyway. I will definitely have a chat with the IT tech next year to see what he thinks, but i doubt that they will change much, especially if i already have working ssh access to home etc. I might be able to aquire slightly higher privileges, becuase teachers get less blocked stuff, and as far as i know, this is decided at the proxy from the NTLM auth. I do have conflicting error messages for the proxies though, so there may be more than one (some errors come from a squid proxy, some from a ISA proxy) On Thu, Jul 21, 2011 at 2:16 PM, Nico Kadel-Garcia wrote: > On Thu, Jul 21, 2011 at 6:00 AM, Rory McNamara > wrote: >> I have discussed the problem with both of my (previous) IT teachers, >> and they said it would probably be alright as long as I don't start >> doing anything stupid. We can't ask for an exception becuase the rules >> are maintained by the council, so it would be a lot more trouble than >> it's worth to get ssh unblocked. As well as the fact that the general >> attitude is that i shouldn't know what ssh is at this age (15/16) >> anyway. Next year, supposedly the IT technician is a lot more friendly >> (different site, same school), so i may talk to him about the various >> protections and what it would take to get a hole put in. But i can't >> do that until september when i go back. > > This makes some sense, thanks for sharing it. Perhaps you can > negotiate a proxy, rather than a simple hole in the firewall, to allow > access for SSH to source control repositories like sourceforge and > github. > From alex at alex.org.uk Fri Jul 22 02:02:30 2011 From: alex at alex.org.uk (Alex Bligh) Date: Thu, 21 Jul 2011 17:02:30 +0100 Subject: openSSH 5.8p2 BindPort patch In-Reply-To: References: Message-ID: <951247101548DB6753C86A71@nimrod.local> --On 20 July 2011 14:12:38 +1000 Darren Tucker wrote: >> The proxy im trying to get through only allows ssl on ports 443 from >> port 443, i have no idea why, > > That sounds quite broken since TCP connections are uniquely identified > by the 4-tuple of source IP, source port, destination IP, destination > port. If your proxy does what you describe it would limit you to only > one outbound SSL connection at any time and I would suspect something > is misconfigured. It might well be broken, but that is an argument in favour of the patch: getting around broken firewalls is a classic use-case for ssh. Rory: you might also try running ssh on port 443 somewhere outside the firewall; I can't believe they will filter https connections by source port. -- Alex Bligh From pink.banana.fish at gmail.com Fri Jul 22 02:23:01 2011 From: pink.banana.fish at gmail.com (Rory McNamara) Date: Thu, 21 Jul 2011 17:23:01 +0100 Subject: openSSH 5.8p2 BindPort patch In-Reply-To: <951247101548DB6753C86A71@nimrod.local> References: <951247101548DB6753C86A71@nimrod.local> Message-ID: My home ssh is running on port 443, well, port forwarded 443->22, but it's the same pretty much. As far as i know, the error code is: Error Code: 502 Proxy Error. The specified Secure Sockets Layer (SSL) port is not allowed. ISA Server is not configured to allow SSL requests from this port. Most Web browsers use port 443 for SSL requests. I can't confirm it but that sounds about right. So setting a source port of 443, using the proxy, and a destination port of 443 gets through, with no errors, this may not be the only source port, but it's the only one i tried. Next time i can, i will MITM a connection from one of the school boxes to see what the source port for that is. On Thu, Jul 21, 2011 at 5:02 PM, Alex Bligh wrote: > > > --On 20 July 2011 14:12:38 +1000 Darren Tucker wrote: > >>> The proxy im trying to get through only allows ssl on ports 443 from >>> port 443, i have no idea why, >> >> That sounds quite broken since TCP connections are uniquely identified >> by the 4-tuple of source IP, source port, destination IP, destination >> port. ?If your proxy does what you describe it would limit you to only >> one outbound SSL connection at any time and I would suspect something >> is misconfigured. > > It might well be broken, but that is an argument in favour of the > patch: getting around broken firewalls is a classic use-case for > ssh. > > Rory: you might also try running ssh on port 443 somewhere outside > the firewall; I can't believe they will filter https connections > by source port. > > -- > Alex Bligh > From gert at greenie.muc.de Fri Jul 22 04:59:39 2011 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 21 Jul 2011 20:59:39 +0200 Subject: openSSH 5.8p2 BindPort patch In-Reply-To: References: <951247101548DB6753C86A71@nimrod.local> Message-ID: <20110721185938.GV8496@greenie.muc.de> Hi, On Thu, Jul 21, 2011 at 05:23:01PM +0100, Rory McNamara wrote: > My home ssh is running on port 443, well, port forwarded 443->22, but > it's the same pretty much. As far as i know, the error code is: > > Error Code: 502 Proxy Error. The specified Secure Sockets Layer (SSL) > port is not allowed. ISA Server is not configured to allow SSL > requests from this port. Most Web browsers use port 443 for SSL > requests. This error would surprise me a lot. None(!) of the unix web browsers run by normal users are able(!) to use a source port of 443, as it is a privileged port only root can use. Now, that error message with "... to allow SSL request *to* this port." is fairly typical if you try to use a proxy to CONNECT to a port 22 etc. (non-SSL ports). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From _ at maxb.eu Fri Jul 22 10:04:21 2011 From: _ at maxb.eu (Max Bowsher) Date: Fri, 22 Jul 2011 01:04:21 +0100 Subject: auth2-kbdint.c: Is it a bug that it mixes references to options.kbd_interactive_authentication and options.challenge_response_authentication ? Message-ID: <4E28BE85.1060502@maxb.eu> Hello, I was chasing some unexpected behaviour from OpenSSH, and have come across an oddity in the source code which may or may not be a bug. In auth2-kbdint.c, the Authmethod struct declares options.kbd_interactive_authentication as the enabled flag for this method. However in the implementation function a few lines above, it checks options.challenge_response_authentication to decide whether to actually proceed with the authentication. This results in the behaviour of "ChallengeResponseAuthentication no" also disabling keyboard-interactive authentication, even if "KbdInteractiveAuthentication yes" is specified. I'd call this a bug, but other places in the source code have interactions between these options, so I'm not sure whether it is intended or not. Also, the KbdInteractiveAuthentication option isn't explicitly documented in the manpages, so I'm unsure if it's actually intended to be used or not. Hoping someone can shed some light on this, Max. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From pink.banana.fish at gmail.com Fri Jul 22 21:05:40 2011 From: pink.banana.fish at gmail.com (Rory McNamara) Date: Fri, 22 Jul 2011 12:05:40 +0100 Subject: openSSH 5.8p2 BindPort patch In-Reply-To: <20110721185938.GV8496@greenie.muc.de> References: <951247101548DB6753C86A71@nimrod.local> <20110721185938.GV8496@greenie.muc.de> Message-ID: I remembered last night that i used chrome on debian with the proxy, and successfully accessed a https site. If i try to connect to port 22 without setting the sourceport, i get reset, probably from the firewall. If i try to connect to port 443 without setting the sourceport, that is the error i recieve. So i believe you are right that it only occurs if you use CONNECT. I can confirm that i tried connecting to port 443 and still got the error, as i documented what i tried as i went along On Thu, Jul 21, 2011 at 7:59 PM, Gert Doering wrote: > Hi, > > On Thu, Jul 21, 2011 at 05:23:01PM +0100, Rory McNamara wrote: >> My home ssh is running on port 443, well, port forwarded 443->22, but >> it's the same pretty much. As far as i know, the error code is: >> >> Error Code: 502 Proxy Error. The specified Secure Sockets Layer (SSL) >> port is not allowed. ISA Server is not configured to allow SSL >> requests from this port. Most Web browsers use port 443 for SSL >> requests. > > This error would surprise me a lot. ?None(!) of the unix web browsers > run by normal users are able(!) to use a source port of 443, as it is > a privileged port only root can use. > > Now, that error message with "... to allow SSL request *to* this port." > is fairly typical if you try to use a proxy to CONNECT to a port 22 > etc. (non-SSL ports). > > gert > -- > USENET is *not* the non-clickable part of WWW! > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? //www.muc.de/~gert/ > Gert Doering - Munich, Germany ? ? ? ? ? ? ? ? ? ? ? ? ? ? gert at greenie.muc.de > fax: +49-89-35655025 ? ? ? ? ? ? ? ? ? ? ? ?gert at net.informatik.tu-muenchen.de > From phil.pennock at globnix.org Sat Jul 23 06:30:15 2011 From: phil.pennock at globnix.org (Phil Pennock) Date: Fri, 22 Jul 2011 16:30:15 -0400 Subject: MacOSX & ssh-agent -l Message-ID: <20110722203015.GA63337@redoubt.spodhuis.org> Folks, MacOSX 10.6.x (Snow Leopard) runs { ssh-agent -l }; that's not an s/ssh-add/ssh-agent/ typo. It appears to be an undocumented addition (the man-pages were not updated). I *suspect* that it just tells the agent to honour whatever pre-existing value of $SSH_AUTH_SOCK it inherits and to try to listen to that. I don't know for sure. Does anyone have details on what exactly it does, please? I'm tempted to hack a more recent OpenSSH's ssh-agent to support it, so I can switch which agent is launched by launchd and then load ECDSA keys. Thanks, -Phil From peter at stuge.se Sat Jul 23 06:41:15 2011 From: peter at stuge.se (Peter Stuge) Date: Fri, 22 Jul 2011 22:41:15 +0200 Subject: MacOSX & ssh-agent -l In-Reply-To: <20110722203015.GA63337@redoubt.spodhuis.org> References: <20110722203015.GA63337@redoubt.spodhuis.org> Message-ID: <20110722204115.11012.qmail@stuge.se> Phil Pennock wrote: > Does anyone have details on what exactly it does, please? http://opensource.apple.com/source/OpenSSH/OpenSSH-142/openssh/ssh-agent.c Search for #ifdef __APPLE_LAUNCHD__ //Peter From keisial at gmail.com Sat Jul 23 08:03:06 2011 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sat, 23 Jul 2011 00:03:06 +0200 Subject: MacOSX & ssh-agent -l In-Reply-To: <20110722203015.GA63337@redoubt.spodhuis.org> References: <20110722203015.GA63337@redoubt.spodhuis.org> Message-ID: <4E29F39A.9010607@gmail.com> Phil Pennock wrote: > Folks, > > MacOSX 10.6.x (Snow Leopard) runs { ssh-agent -l }; that's not an > s/ssh-add/ssh-agent/ typo. It appears to be an undocumented addition > (the man-pages were not updated). > > I *suspect* that it just tells the agent to honour whatever pre-existing > value of $SSH_AUTH_SOCK it inherits and to try to listen to that. I > don't know for sure. > > Does anyone have details on what exactly it does, please? I don't have a Mac OS X to play with it, but if you have, sure you can test its behavior with and without that parameter, and what it does? Note you can get almost the same effect you want by doing: ssh-agent -a ${SSH_AUTH_SOCK:-$(mktemp -d --tmpdir ssh-XXXXXXXXXXXX)/agent.$$} From jcs at jcs.org Sat Jul 23 07:50:34 2011 From: jcs at jcs.org (joshua stein) Date: Fri, 22 Jul 2011 16:50:34 -0500 Subject: MacOSX & ssh-agent -l In-Reply-To: <20110722203015.GA63337@redoubt.spodhuis.org> References: <20110722203015.GA63337@redoubt.spodhuis.org> Message-ID: <20110722164615.f09a8d4e35@4034cfe6aa9eba7> > MacOSX 10.6.x (Snow Leopard) runs { ssh-agent -l }; that's not an > s/ssh-add/ssh-agent/ typo. It appears to be an undocumented addition > (the man-pages were not updated). look for the #ifdef __APPLE_LAUNCHD__ portions of: http://opensource.apple.com/source/OpenSSH/OpenSSH-166/openssh/ssh-agent.c > I *suspect* that it just tells the agent to honour whatever pre-existing > value of $SSH_AUTH_SOCK it inherits and to try to listen to that. I > don't know for sure. that's correct. launchd sets up the socket via /System/Library/LaunchAgents/org.openbsd.ssh-agent.plist and assigns it to $SSH_AUTH_SOCK. when ssh tries to read from that socket, it tells launchd to fire up ssh-agent. From morty at frakir.org Sun Jul 24 04:47:18 2011 From: morty at frakir.org (Mordechai T. Abzug) Date: Sat, 23 Jul 2011 14:47:18 -0400 Subject: openssh PTY allocation Message-ID: <20110723184718.GF24801@red-sonja> We recently upgraded to openss 5.8p2 from a somewhat older version. This broke openssh login to ScreenOS devices. These devices don't support PTY allocation. Apparently, ssh now reacts to PTY allocation failure by failing the login. This is a change from the previous behavior. The simple workaround is ssh -T $device. I see in the ChangeLog that some device would hang with PTY allocation disabled. So apparently, we have mutually exclusive bad behaviors. >From the ChangeLog: - djm at cvs.openbsd.org 2010/04/10 02:08:44 [clientloop.c] bz#1698: kill channel when pty allocation requests fail. Fixed stuck client if the server refuses pty allocation. ok dtucker@ "think so" markus@ There don't seem to be any ssh_config options that control PTY allocation behavior. Any way we can get some options? There should be at least one, maybe two ssh_config options to control PTY behavior: one to control the PTY failure behavior, something like ExitOnPTYFailure yes|no|no-warn, and one to give the equivalent of -T or -t, i.e. something like PTYEnable: yes|no|force-yes|yes-if-login. Note that, IME, for the ChangeLog case, that is a device that normally allows PTY creation and the PTY fails, the result looks like a hang but really isn't. Rather, what you have is a non-interactive shell. The shell works but doesn't display a prompt. So, for example, back under Solaris 2.6, if you allocated all 128 default PTYs and then login with ssh, the login will just sit there after login without displaying a prompt. But it really isn't hung -- you can run non-interactive commands and see the responses. Thanks. - Morty From dtucker at zip.com.au Sun Jul 24 11:24:45 2011 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 24 Jul 2011 11:24:45 +1000 Subject: openssh PTY allocation In-Reply-To: <20110723184718.GF24801@red-sonja> References: <20110723184718.GF24801@red-sonja> Message-ID: On Sun, Jul 24, 2011 at 4:47 AM, Mordechai T. Abzug wrote: > We recently upgraded to openss 5.8p2 from a somewhat older version. > This broke openssh login to ScreenOS devices. ?These devices don't > support PTY allocation. ?Apparently, ssh now reacts to PTY allocation > failure by failing the login. ?This is a change from the previous > behavior. ?The simple workaround is ssh -T $device. [...] > There don't seem to be any ssh_config options that control PTY > allocation behavior. ?Any way we can get some options? ?There should > be at least one, maybe two ssh_config options to control PTY behavior: > one to control the PTY failure behavior, something like > ExitOnPTYFailure yes|no|no-warn, and one to give the equivalent of -T > or -t, i.e. something like PTYEnable: yes|no|force-yes|yes-if-login. Damien already added a config option ("RequestTTY") but there hasn't been a release since then (this problem didn't become apparent until after the 5.8 release when people used it with the problem devices). RequestTTY Specifies whether to request a pseudo-tty for the session. The argument may be one of: ``no'' (never request a TTY), ``yes'' (always request a TTY when standard input is a TTY), ``force'' (always request a TTY) or ``auto'' (request a TTY when opening a login session). This option mirrors the -t and -T flags for ssh(1). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4? 37C9 C982 80C7 8FF4 FA69 ? ? Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From morty at frakir.org Sun Jul 24 13:16:59 2011 From: morty at frakir.org (Morty Abzug) Date: Sat, 23 Jul 2011 23:16:59 -0400 Subject: openssh PTY allocation In-Reply-To: References: <20110723184718.GF24801@red-sonja> Message-ID: <20110724031659.GF1290@red-sonja> On Sun, Jul 24, 2011 at 11:24:45AM +1000, Darren Tucker wrote: > Damien already added a config option ("RequestTTY") but there hasn't > been a release since then (this problem didn't become apparent until > after the 5.8 release when people used it with the problem devices). > > RequestTTY > Specifies whether to request a pseudo-tty for the session. The > argument may be one of: ``no'' (never request a TTY), ``yes'' > (always request a TTY when standard input is a TTY), ``force'' > (always request a TTY) or ``auto'' (request a TTY when opening a > login session). This option mirrors the -t and -T flags for > ssh(1). That sounds great. It is indeed one of the two features I asked for. But I think we still need a second option, in the event that a TTY/PTY is requested and fails, to decide what should happen. Something like ExitOnTTYFailure yes|no|no-warn. That way, sites where a TTY/PTY error is normal for many devices and not catastrophic for other devices don't need to configure RequestTTY for each device. Instead, we can just do a: Host * ExitOnTTYFailure no-warn RequestTTY auto The above corresponds to the behavior for openssh and ssh.com's ssh1 for many years. Similarly, sites where a TTY/PTY error is always a problem can just set: Host * ExitOnTTYFailure yes RequestTTY auto Only sites with a mixture of devices, some that don't support PTYs and some where PTY allocation failure is catastrophic, will need to do per-device RequestTTY. I suspect that the last case will be very rare. So most of us will be happy with global ExitOnTTYFailure settings and RequestTTY auto. - Morty From urs at isnogud.escape.de Sun Jul 24 08:23:47 2011 From: urs at isnogud.escape.de (Urs Thuermann) Date: 24 Jul 2011 00:23:47 +0200 Subject: Typo in sftp man page Message-ID: There is a small typo in the sftp(1) man page in openssh-5.8: --- ssh/sftp.1.orig 2010-12-04 01:18:01.000000000 +0100 +++ ssh/sftp.1 2011-07-24 00:22:12.000000000 +0200 @@ -479,7 +479,7 @@ .Ar remote-path must specify a directory. .Pp -If ether the +If either the .Fl P or .Fl p urs From mark at wrapped.cx Wed Jul 27 05:01:19 2011 From: mark at wrapped.cx (Mark Patruck) Date: Tue, 26 Jul 2011 21:01:19 +0200 Subject: ForwardX11Trusted=no and dead characters Message-ID: <20110726190119.GB8267@andromeda.mpnib.net> Hi, although i'm using X11Forwarding only in my local environment, i'd like to avoid setting 'ForwardX11Trusted' to 'yes'. When starting applications like 'freerdp' on the remote machine while 'ForwardX11Trusted' is _not_ set to 'yes' on the client, the characters \ = 51 = backslash | = 94 = pipe won't work. Any ideas? Thanks, -Mark -- Mark Patruck ( mark at wrapped.cx ) GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51 http://www.wrapped.cx From morty at frakir.org Wed Jul 27 13:01:37 2011 From: morty at frakir.org (Morty Abzug) Date: Tue, 26 Jul 2011 23:01:37 -0400 Subject: openssh PTY allocation In-Reply-To: <20110724031659.GF1290@red-sonja> References: <20110723184718.GF24801@red-sonja> <20110724031659.GF1290@red-sonja> Message-ID: <20110727030137.GH24801@red-sonja> [snip] We continue to have issues with login to ScreenOS devices. Apparently, the simple workaround of ssh -T $device breaks command editing. We're also have problems with scp to ScreenOS devices. Apparently, ScreenOS doesn't support "--" option termination. The following patch seems to "fix" both issues: diff -ur openssh-5.8p2-orig//clientloop.c openssh-5.8p2-morty/clientloop.c --- openssh-5.8p2-orig//clientloop.c Sun Jan 16 12:18:35 2011 +++ openssh-5.8p2-morty/clientloop.c Tue Jul 26 16:55:17 2011 @@ -1982,7 +1982,7 @@ memset(&ws, 0, sizeof(ws)); channel_request_start(id, "pty-req", 1); - client_expect_confirm(id, "PTY allocation", 1); + client_expect_confirm(id, "PTY allocation", 0); packet_put_cstring(term != NULL ? term : ""); packet_put_int((u_int)ws.ws_col); packet_put_int((u_int)ws.ws_row); diff -ur openssh-5.8p2-orig//scp.c openssh-5.8p2-morty/scp.c --- openssh-5.8p2-orig//scp.c Thu Jan 6 11:41:21 2011 +++ openssh-5.8p2-morty/scp.c Tue Jul 26 17:02:25 2011 @@ -273,7 +273,6 @@ addargs(&args, "-l"); addargs(&args, "%s", remuser); } - addargs(&args, "--"); addargs(&args, "%s", host); addargs(&args, "%s", cmd); @@ -322,7 +321,6 @@ addargs(&args, "-l"); addargs(&args, "%s", remuser); } - addargs(&args, "--"); addargs(&args, "%s", host); addargs(&args, "%s", cmd); @@ -601,12 +599,12 @@ host = cleanhostname(argv[i]); suser = NULL; } - xasprintf(&bp, "%s -f -- %s", cmd, src); + xasprintf(&bp, "%s -f %s", cmd, src); if (do_cmd(host, suser, bp, &remin, &remout) < 0) exit(1); (void) xfree(bp); host = cleanhostname(thost); - xasprintf(&bp, "%s -t -- %s", cmd, targ); + xasprintf(&bp, "%s -t %s", cmd, targ); if (do_cmd2(host, tuser, bp, remin, remout) < 0) exit(1); (void) xfree(bp); @@ -641,7 +639,6 @@ } else { host = cleanhostname(argv[i]); } - addargs(&alist, "--"); addargs(&alist, "%s", host); addargs(&alist, "%s", cmd); addargs(&alist, "%s", src); @@ -652,7 +649,7 @@ errs = 1; } else { /* local to remote */ if (remin == -1) { - xasprintf(&bp, "%s -t -- %s", cmd, targ); + xasprintf(&bp, "%s -t %s", cmd, targ); host = cleanhostname(thost); if (do_cmd(host, tuser, bp, &remin, &remout) < 0) @@ -685,7 +682,6 @@ addargs(&alist, "-r"); if (pflag) addargs(&alist, "-p"); - addargs(&alist, "--"); addargs(&alist, "%s", argv[i]); addargs(&alist, "%s", argv[argc-1]); if (do_local_cmd(&alist)) @@ -705,7 +701,7 @@ suser = pwd->pw_name; } host = cleanhostname(host); - xasprintf(&bp, "%s -f -- %s", cmd, src); + xasprintf(&bp, "%s -f %s", cmd, src); if (do_cmd(host, suser, bp, &remin, &remout) < 0) { (void) xfree(bp); ++errs; diff -ur openssh-5.8p2-orig//version.h openssh-5.8p2-morty/version.h --- openssh-5.8p2-orig//version.h Thu May 5 01:56:54 2011 +++ openssh-5.8p2-morty/version.h Tue Jul 26 17:02:39 2011 @@ -2,5 +2,5 @@ #define SSH_VERSION "OpenSSH_5.8" -#define SSH_PORTABLE "p2" +#define SSH_PORTABLE "p2-MORTY-p2" #define SSH_RELEASE SSH_VERSION SSH_PORTABLE From djm at mindrot.org Wed Jul 27 17:25:05 2011 From: djm at mindrot.org (Damien Miller) Date: Wed, 27 Jul 2011 17:25:05 +1000 (EST) Subject: openssh PTY allocation In-Reply-To: <20110723184718.GF24801@red-sonja> References: <20110723184718.GF24801@red-sonja> Message-ID: On Sat, 23 Jul 2011, Mordechai T. Abzug wrote: > We recently upgraded to openss 5.8p2 from a somewhat older version. > This broke openssh login to ScreenOS devices. These devices don't > support PTY allocation. Apparently, ssh now reacts to PTY allocation > failure by failing the login. This is a change from the previous > behavior. The simple workaround is ssh -T $device. The problem is a bug in ScreenOS, it refuses pty-req channel requests when the tty modes blob exceeds 256 bytes in length. If you want a workaround that preserves the usability of the tty, then comment out a couple of less-important modes in ttymodes.h and recompile -d From cmadams at hiwaay.net Thu Jul 28 00:16:17 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 27 Jul 2011 09:16:17 -0500 Subject: openssh PTY allocation In-Reply-To: References: <20110723184718.GF24801@red-sonja> Message-ID: <20110727141617.GB25731@hiwaay.net> Once upon a time, Damien Miller said: > The problem is a bug in ScreenOS, it refuses pty-req channel requests > when the tty modes blob exceeds 256 bytes in length. If you want a > workaround that preserves the usability of the tty, then comment out > a couple of less-important modes in ttymodes.h and recompile I hate to say it, but is there any way to get a reasonable work-around into upstream OpenSSH? Unfortunately, there are a ton of ScreenOS devices out there, and even if Juniper fixed the SSH bugs tomorrow, all those devices won't be updated overnight (if ever). This will be a serious irritation for network admins as OS distributions update to newer OpenSSH versions (where most users get their OpenSSH). Ideally, it would be something easy to enable on the command line (e.g. a short option, not "-o WorkAroundBrokenScreenOS=1"). I'd be willing to work on a patch if there is some hope it might be accepted. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mfriedl at gmail.com Thu Jul 28 07:13:28 2011 From: mfriedl at gmail.com (Markus Friedl) Date: Wed, 27 Jul 2011 23:13:28 +0200 Subject: openssh PTY allocation In-Reply-To: <20110727141617.GB25731@hiwaay.net> References: <20110723184718.GF24801@red-sonja> <20110727141617.GB25731@hiwaay.net> Message-ID: Do you have a banner vendor string that identifies all broken versions? On Wednesday, July 27, 2011, Chris Adams wrote: > Once upon a time, Damien Miller said: >> The problem is a bug in ScreenOS, it refuses pty-req channel requests >> when the tty modes blob exceeds 256 bytes in length. If you want a >> workaround that preserves the usability of the tty, then comment out >> a couple of less-important modes in ttymodes.h and recompile > > I hate to say it, but is there any way to get a reasonable work-around > into upstream OpenSSH? ?Unfortunately, there are a ton of ScreenOS > devices out there, and even if Juniper fixed the SSH bugs tomorrow, all > those devices won't be updated overnight (if ever). ?This will be a > serious irritation for network admins as OS distributions update to > newer OpenSSH versions (where most users get their OpenSSH). > > Ideally, it would be something easy to enable on the command line (e.g. > a short option, not "-o WorkAroundBrokenScreenOS=1"). ?I'd be willing to > work on a patch if there is some hope it might be accepted. > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From cmadams at hiwaay.net Thu Jul 28 07:24:37 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 27 Jul 2011 16:24:37 -0500 Subject: openssh PTY allocation In-Reply-To: References: <20110723184718.GF24801@red-sonja> <20110727141617.GB25731@hiwaay.net> Message-ID: <20110727212437.GF25731@hiwaay.net> Once upon a time, Markus Friedl said: > Do you have a banner vendor string that identifies all broken versions? Well, I can't say all broken versions, but it is my understanding that this affects current ScreenOS versions (and probably old versions as well). I'd have to set up a test to try different versions, but it appears that all ScreenOS devices use the banner "SSH-2.0-NetScreen" (NetScreen is the name of the product line from before Juniper bought them; they have not changed that internally). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From morty at frakir.org Fri Jul 29 01:52:47 2011 From: morty at frakir.org (Morty Abzug) Date: Thu, 28 Jul 2011 11:52:47 -0400 Subject: openssh PTY allocation In-Reply-To: References: <20110723184718.GF24801@red-sonja> Message-ID: <20110728155247.GL1290@red-sonja> On Wed, Jul 27, 2011 at 05:25:05PM +1000, Damien Miller wrote: > The problem is a bug in ScreenOS, it refuses pty-req channel requests > when the tty modes blob exceeds 256 bytes in length. If you want a > workaround that preserves the usability of the tty, then comment out > a couple of less-important modes in ttymodes.h and recompile Any suggestions on which modes are less important? I already came up with a different workaround. Here is the TTY portion of the approach: diff -ur openssh-5.8p2-orig//clientloop.c openssh-5.8p2-morty/clientloop.c --- openssh-5.8p2-orig//clientloop.c Sun Jan 16 12:18:35 2011 +++ openssh-5.8p2-morty/clientloop.c Tue Jul 26 16:55:17 2011 @@ -1982,7 +1982,7 @@ memset(&ws, 0, sizeof(ws)); channel_request_start(id, "pty-req", 1); - client_expect_confirm(id, "PTY allocation", 1); + client_expect_confirm(id, "PTY allocation", 0); packet_put_cstring(term != NULL ? term : ""); packet_put_int((u_int)ws.ws_col); packet_put_int((u_int)ws.ws_row); Which approach is better? I'd be happy to submit a patch that adds an option to implement the preferred approach. - Morty From gert at greenie.muc.de Fri Jul 29 02:00:38 2011 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 28 Jul 2011 18:00:38 +0200 Subject: openssh PTY allocation In-Reply-To: <20110728155247.GL1290@red-sonja> References: <20110723184718.GF24801@red-sonja> <20110728155247.GL1290@red-sonja> Message-ID: <20110728160038.GC8496@greenie.muc.de> Hi, On Thu, Jul 28, 2011 at 11:52:47AM -0400, Morty Abzug wrote: > On Wed, Jul 27, 2011 at 05:25:05PM +1000, Damien Miller wrote: > > > The problem is a bug in ScreenOS, it refuses pty-req channel requests > > when the tty modes blob exceeds 256 bytes in length. If you want a > > workaround that preserves the usability of the tty, then comment out > > a couple of less-important modes in ttymodes.h and recompile > > Any suggestions on which modes are less important? In that context, I think CS7, PARENB, PARODDB, IXON, IXOFF, IXANY, IUCLC, PARMRK would be the ones I'd skip, given that use of 7-bit and parity terminals is unlikely, and that the netscreens are not going to honour xon/xoff flow control (IXON/IXOFF/IXANY) anyway. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From mfriedl at gmail.com Fri Jul 29 01:59:39 2011 From: mfriedl at gmail.com (Markus Friedl) Date: Thu, 28 Jul 2011 17:59:39 +0200 Subject: openssh PTY allocation In-Reply-To: <20110728155247.GL1290@red-sonja> References: <20110723184718.GF24801@red-sonja> <20110728155247.GL1290@red-sonja> Message-ID: make it conditional on "SSH-2.0-NetScreen" cf compat.c On Thu, Jul 28, 2011 at 5:52 PM, Morty Abzug wrote: > On Wed, Jul 27, 2011 at 05:25:05PM +1000, Damien Miller wrote: > >> The problem is a bug in ScreenOS, it refuses pty-req channel requests >> when the tty modes blob exceeds 256 bytes in length. If you want a >> workaround that preserves the usability of the tty, then comment out >> a couple of less-important modes in ttymodes.h and recompile > > Any suggestions on which modes are less important? > > I already came up with a different workaround. ?Here is the TTY > portion of the approach: > > diff -ur openssh-5.8p2-orig//clientloop.c openssh-5.8p2-morty/clientloop.c > --- openssh-5.8p2-orig//clientloop.c ? ?Sun Jan 16 12:18:35 2011 > +++ openssh-5.8p2-morty/clientloop.c ? Tue Jul 26 16:55:17 2011 > @@ -1982,7 +1982,7 @@ > ? ? ? ? ? ? ? ? ? ? ? ?memset(&ws, 0, sizeof(ws)); > > ? ? ? ? ? ? ? ?channel_request_start(id, "pty-req", 1); > - ? ? ? ? ? ? ? client_expect_confirm(id, "PTY allocation", 1); > + ? ? ? ? ? ? ? client_expect_confirm(id, "PTY allocation", 0); > ? ? ? ? ? ? ? ?packet_put_cstring(term != NULL ? term : ""); > ? ? ? ? ? ? ? ?packet_put_int((u_int)ws.ws_col); > ? ? ? ? ? ? ? ?packet_put_int((u_int)ws.ws_row); > > Which approach is better? ?I'd be happy to submit a patch that adds an > option to implement the preferred approach. > > - Morty > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From jonathan.underwood at gmail.com Fri Jul 29 02:35:24 2011 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 28 Jul 2011 17:35:24 +0100 Subject: intermittent problems obtaining shell with gssapi-with-mic Message-ID: Hi, I am seeing a rather strange issue with openssh-5.3p1 (both client and server) under scientific linux 6. The systems in question are set up to authenticate against a Kerberos server. ssh'ing between machines works fine 99% of the time with the gssapi-with-mic method. But on occasion an ssh session will fail to spawn a sheel for the user after authentication. An example -vvv output in this situation is below: $ ssh -vvv callista OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to callista [128.40.5.73] port 22. debug1: Connection established. debug1: identity file /home/jgu/.ssh/identity type -1 debug1: identity file /home/jgu/.ssh/id_rsa type -1 debug1: identity file /home/jgu/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.3 debug2: fd 4 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug3: Wrote 792 bytes for a total of 813 debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug3: Wrote 24 bytes for a total of 837 debug2: dh_gen_key: priv key bits set: 140/256 debug2: bits set: 537/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: Wrote 144 bytes for a total of 981 debug3: check_host_in_hostfile: filename /home/jgu/.ssh/known_hosts debug3: check_host_in_hostfile: match line 11 debug3: check_host_in_hostfile: filename /home/jgu/.ssh/known_hosts debug3: check_host_in_hostfile: match line 11 debug1: Host 'callista' is known and matches the RSA host key. debug1: Found key in /home/jgu/.ssh/known_hosts:11 debug2: bits set: 511/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug3: Wrote 16 bytes for a total of 997 debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug3: Wrote 48 bytes for a total of 1045 debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/jgu/.ssh/identity ((nil)) debug2: key: /home/jgu/.ssh/id_rsa ((nil)) debug2: key: /home/jgu/.ssh/id_dsa ((nil)) debug3: Wrote 64 bytes for a total of 1109 debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-keyex debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-keyex debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug2: we did not send a packet, disable method debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug3: Trying to reverse map address 128.40.5.73. debug2: we sent a gssapi-with-mic packet, wait for reply debug3: Wrote 96 bytes for a total of 1205 debug3: Wrote 704 bytes for a total of 1909 debug3: Wrote 64 bytes for a total of 1973 debug1: Authentication succeeded (gssapi-with-mic). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting no-more-sessions at openssh.com debug1: Entering interactive session. debug3: Wrote 128 bytes for a total of 2101 debug2: callback start debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 debug1: Sending environment. debug3: Ignored env MKLROOT debug3: Ignored env MANPATH debug3: Ignored env ORBIT_SOCKETDIR debug3: Ignored env HOSTNAME debug3: Ignored env IMSETTINGS_INTEGRATE_DESKTOP debug3: Ignored env INTEL_LICENSE_FILE debug3: Ignored env GPG_AGENT_INFO debug3: Ignored env SHELL debug3: Ignored env TERM debug3: Ignored env HISTSIZE debug3: Ignored env XDG_SESSION_COOKIE debug3: Ignored env LIBRARY_PATH debug3: Ignored env GTK_RC_FILES debug3: Ignored env WINDOWID debug3: Ignored env FPATH debug3: Ignored env QTDIR debug3: Ignored env QTINC debug3: Ignored env IMSETTINGS_MODULE debug3: Ignored env USER debug3: Ignored env LS_COLORS debug3: Ignored env LD_LIBRARY_PATH debug3: Ignored env CPATH debug3: Ignored env SSH_AUTH_SOCK debug3: Ignored env GNOME_KEYRING_SOCKET debug3: Ignored env COBBLER_SERVER debug3: Ignored env USERNAME debug3: Ignored env SESSION_MANAGER debug3: Ignored env NLSPATH debug3: Ignored env PATH debug3: Ignored env DESKTOP_SESSION debug3: Ignored env MAIL debug3: Ignored env QT_IM_MODULE debug3: Ignored env PWD debug1: Sending env XMODIFIERS = @im=none debug2: channel 0: request env confirm 0 debug3: Ignored env GDM_KEYBOARD_LAYOUT debug3: Ignored env KDE_IS_PRELINKED debug1: Sending env LANG = en_GB.utf8 debug2: channel 0: request env confirm 0 debug3: Ignored env GNOME_KEYRING_PID debug3: Ignored env GDM_LANG debug3: Ignored env MODULEPATH debug3: Ignored env LOADEDMODULES debug3: Ignored env KDEDIRS debug3: Ignored env GDMSESSION debug3: Ignored env HISTCONTROL debug3: Ignored env KRB5CCNAME debug3: Ignored env SSH_ASKPASS debug3: Ignored env HOME debug3: Ignored env SHLVL debug3: Ignored env GNOME_DESKTOP_SESSION_ID debug3: Ignored env LOGNAME debug3: Ignored env CVS_RSH debug3: Ignored env QTLIB debug3: Ignored env DBUS_SESSION_BUS_ADDRESS debug3: Ignored env MODULESHOME debug3: Ignored env LESSOPEN debug3: Ignored env WINDOWPATH debug3: Ignored env DISPLAY debug3: Ignored env INCLUDE debug3: Ignored env G_BROKEN_FILENAMES debug3: Ignored env XAUTHORITY debug3: Ignored env COLORTERM debug3: Ignored env module debug3: Ignored env _ debug2: channel 0: request shell confirm 1 debug2: fd 4 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug3: Wrote 512 bytes for a total of 2613 debug2: channel_input_status_confirm: type 99 id 0 debug2: PTY allocation request accepted on channel 0 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_status_confirm: type 99 id 0 debug2: shell request accepted on channel 0 At this point the session hangs seemingly forever and a command prompt never appears. When I see this issue, it isn't resolved by restarting the sshd server, and it continues to be an issue if I kill the session and start again. However, if I then do a ssh -o GSSAPIAuthentication=no callista I enter the password and log in successfully, as expected. Subsequently if I disconnect, and then retry without GSSAPIAuthentication=no everything is fine again. I am having a hard time with debugging this any further, any advice would be happily received. Please cc me on any responses as I am not subscribed to the list. Thanks in advance, Jonathan. From morty at frakir.org Fri Jul 29 04:34:07 2011 From: morty at frakir.org (Morty Abzug) Date: Thu, 28 Jul 2011 14:34:07 -0400 Subject: openssh PTY allocation In-Reply-To: <20110728160038.GC8496@greenie.muc.de> References: <20110723184718.GF24801@red-sonja> <20110728155247.GL1290@red-sonja> <20110728160038.GC8496@greenie.muc.de> Message-ID: <20110728183407.GM1290@red-sonja> On Thu, Jul 28, 2011 at 06:00:38PM +0200, Gert Doering wrote: > Hi, > > On Thu, Jul 28, 2011 at 11:52:47AM -0400, Morty Abzug wrote: > > On Wed, Jul 27, 2011 at 05:25:05PM +1000, Damien Miller wrote: > > > > > The problem is a bug in ScreenOS, it refuses pty-req channel requests > > > when the tty modes blob exceeds 256 bytes in length. If you want a > > > workaround that preserves the usability of the tty, then comment out > > > a couple of less-important modes in ttymodes.h and recompile > > > > Any suggestions on which modes are less important? > > In that context, I think CS7, PARENB, PARODDB, IXON, IXOFF, IXANY, IUCLC, > PARMRK would be the ones I'd skip, given that use of 7-bit and parity > terminals is unlikely, and that the netscreens are not going to honour > xon/xoff flow control (IXON/IXOFF/IXANY) anyway. Thanks. I tested with #ifdef all of the above (CS7, PARENB, PARODDB, IXON, IXOFF, IXANY, IUCLC, and PARMRK.) This worked to get to one of our firewalls (ScreenOS 6.3.0r7.0) but not another (ScreenOS 5.3.0r3.0). So the problem appears to depend to some extent on ScreenOS version or some other variable that is device-specific. Meanwhile, I have that other workaround, i.e. to make the ssh client not consider PTY allocation failure a fatal exit. It appears to work for all of our ScreenOS devices. Questions/comments: (1) From a patch perspective, which approach is preferable -- making PTY allocation failure not a fatal error, or commenting out a bunch of ttymodes? [Assuming a set of ttymodes can be found that makes this work, of course.] I would lean towards the former approach, since it seems inherently more robust/consistent. (2) Commenting out stuff in ttymodes.h thing appears to be a compile-time option. Is there a way to make it a run-time option? (3) What would be a good name for an option to workaround this? I lean towards ExitOnTTYFailure. (4) What would be a good name for an option to workaround the scp "--" problem? - Morty From ondrej.sury at nic.cz Fri Jul 29 03:49:41 2011 From: ondrej.sury at nic.cz (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Thu, 28 Jul 2011 13:49:41 -0400 Subject: Support for ECDSA and SHA-2 (SHA-256) in the SSHFP record Message-ID: <0F1A09E5-42E0-4B66-A317-155BB94BC5C2@nic.cz> Hi, I was sure I sent this to openssh at openssh.com, but cannot find that email now in my Sent mailbox, so I am sending it to the developers list. I took a liberty and wrote an I-D with accompanying patch (with contributions from Ondrej Caletka) to support ECDSA in the SSHFP DNS resource record. The I-D is here: https://tools.ietf.org/html/draft-os-ietf-sshfp-ecdsa-sha2 (and the source XML here: https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/changes/draft-os-ietf-sshfp-ecdsa-sha2-00.xml) The patch to vanilla 5.8 here: https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/changes/ssh-sshfp-ecdsa.patch Please Cc: me as I am not (and don't intend to be) subscribed to the list. I will check the archives occasionally, but Cc: would be appreciated. Thanks, O. -- Ond?ej Sur? vedouc? v?zkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato?e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From phil.pennock at globnix.org Fri Jul 29 10:01:34 2011 From: phil.pennock at globnix.org (Phil Pennock) Date: Thu, 28 Jul 2011 20:01:34 -0400 Subject: intermittent problems obtaining shell with gssapi-with-mic In-Reply-To: References: Message-ID: <20110729000134.GA41512@redoubt.spodhuis.org> On 2011-07-28 at 17:35 +0100, Jonathan Underwood wrote: > I am seeing a rather strange issue with openssh-5.3p1 (both client and > server) under scientific linux 6. The systems in question are set up > to authenticate against a Kerberos server. ssh'ing between machines > works fine 99% of the time with the gssapi-with-mic method. But on > occasion an ssh session will fail to spawn a sheel for the user after > authentication. An example -vvv output in this situation is below: > At this point the session hangs seemingly forever and a command prompt > never appears. When I see this issue, it isn't resolved by restarting > the sshd server, and it continues to be an issue if I kill the session > and start again. However, if I then do a > > ssh -o GSSAPIAuthentication=no callista > > I enter the password and log in successfully, as expected. > Subsequently if I disconnect, and then retry without > GSSAPIAuthentication=no everything is fine again. > > I am having a hard time with debugging this any further, any advice > would be happily received. If your home directory NFS mounted, with Kerberised authentication against the NFS server? If so, then when things fail, your credentials on the remote machine have expired and /home/$you is not mounted, and logging in with a password supplied to the remote site is getting /home/$you mounted. Try instead: ssh -o GSSAPIDelegateCredentials=yes callista If that works, then since you're willing to supply your password to the remote side, you presumably trust it enough to delegate a Kerberos TGT to it. Add GSSAPIDelegateCredentials=yes to the ~/.ssh/config entry for this host. -Phil From olecom at gmail.com Fri Jul 29 16:01:17 2011 From: olecom at gmail.com (Oleg Verych) Date: Fri, 29 Jul 2011 09:01:17 +0300 Subject: =?UTF-8?Q?sshd=E2=80=99s_ForceCommand_and_ssh=E2=80=99s_=22=E2=80=93N_Do_not_execu?= =?UTF-8?Q?te_a_remote_command=22?= Message-ID: Hallo. If `sshd` is configured to have a ForceCommand, no `ssh ?N` must skip this *forced* server?s setup, isn?t it? But it isn?t so. Thus, admin may think that the command is forced by a server, but user can skip that. In such case only port forwarding is available, but anyway *force* is meaningless, IMHO. -- sed 'sed && sh + olecom = love'? < References: <20110723184718.GF24801@red-sonja> <20110728155247.GL1290@red-sonja> <20110728160038.GC8496@greenie.muc.de> <20110728183407.GM1290@red-sonja> Message-ID: Try this compat hack: Index: ttymodes.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/ttymodes.c,v retrieving revision 1.29 diff -u -p -r1.29 ttymodes.c --- ttymodes.c 2 Nov 2008 00:16:16 -0000 1.29 +++ ttymodes.c 29 Jul 2011 07:58:29 -0000 @@ -295,8 +295,11 @@ tty_make_modes(int fd, struct termios *t put_arg(&buf, tio.c_cc[NAME]); #define TTYMODE(NAME, FIELD, OP) \ - buffer_put_char(&buf, OP); \ - put_arg(&buf, ((tio.FIELD & NAME) != 0)); + if (!compat20 || (datafellows & SSH_BUG_SCREENOS_PTY) == 0 || \ + buffer_len(&buf) < 256 - 5) { \ + buffer_put_char(&buf, OP); \ + put_arg(&buf, ((tio.FIELD & NAME) != 0)); \ + } #include "ttymodes.h" Index: compat.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/compat.c,v retrieving revision 1.78 diff -u -p -r1.78 compat.c --- compat.c 11 Sep 2008 14:22:37 -0000 1.78 +++ compat.c 29 Jul 2011 07:58:29 -0000 @@ -146,6 +146,8 @@ compat_datafellows(const char *version) SSH_BUG_IGNOREMSG }, { "*SSH Compatible Server*", /* Netscreen */ SSH_BUG_PASSWORDPAD }, + { "NetScreen", + SSH_BUG_SCREENOS_PTY }, { "*OSU_0*," "OSU_1.0*," "OSU_1.1*," Index: compat.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/compat.h,v retrieving revision 1.42 diff -u -p -r1.42 compat.h --- compat.h 11 Sep 2008 14:22:37 -0000 1.42 +++ compat.h 29 Jul 2011 07:58:29 -0000 @@ -58,6 +58,7 @@ #define SSH_OLD_FORWARD_ADDR 0x01000000 #define SSH_BUG_RFWD_ADDR 0x02000000 #define SSH_NEW_OPENSSH 0x04000000 +#define SSH_BUG_SCREENOS_PTY 0x08000000 void enable_compat13(void); void enable_compat20(void); On Thu, 28 Jul 2011, Morty Abzug wrote: > On Thu, Jul 28, 2011 at 06:00:38PM +0200, Gert Doering wrote: > > Hi, > > > > On Thu, Jul 28, 2011 at 11:52:47AM -0400, Morty Abzug wrote: > > > On Wed, Jul 27, 2011 at 05:25:05PM +1000, Damien Miller wrote: > > > > > > > The problem is a bug in ScreenOS, it refuses pty-req channel requests > > > > when the tty modes blob exceeds 256 bytes in length. If you want a > > > > workaround that preserves the usability of the tty, then comment out > > > > a couple of less-important modes in ttymodes.h and recompile > > > > > > Any suggestions on which modes are less important? > > > > In that context, I think CS7, PARENB, PARODDB, IXON, IXOFF, IXANY, IUCLC, > > PARMRK would be the ones I'd skip, given that use of 7-bit and parity > > terminals is unlikely, and that the netscreens are not going to honour > > xon/xoff flow control (IXON/IXOFF/IXANY) anyway. > > Thanks. > > I tested with #ifdef all of the above (CS7, PARENB, PARODDB, IXON, > IXOFF, IXANY, IUCLC, and PARMRK.) This worked to get to one of our > firewalls (ScreenOS 6.3.0r7.0) but not another (ScreenOS 5.3.0r3.0). > So the problem appears to depend to some extent on ScreenOS version or > some other variable that is device-specific. > > Meanwhile, I have that other workaround, i.e. to make the ssh client > not consider PTY allocation failure a fatal exit. It appears to work > for all of our ScreenOS devices. > > Questions/comments: > > (1) From a patch perspective, which approach is preferable -- making > PTY allocation failure not a fatal error, or commenting out a > bunch of ttymodes? [Assuming a set of ttymodes can be found that > makes this work, of course.] I would lean towards the former > approach, since it seems inherently more robust/consistent. > > (2) Commenting out stuff in ttymodes.h thing appears to be a > compile-time option. Is there a way to make it a run-time option? > > (3) What would be a good name for an option to workaround this? I > lean towards ExitOnTTYFailure. > > (4) What would be a good name for an option to workaround the scp "--" > problem? > > - Morty > From jonathan.underwood at gmail.com Fri Jul 29 18:23:48 2011 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 29 Jul 2011 09:23:48 +0100 Subject: intermittent problems obtaining shell with gssapi-with-mic In-Reply-To: <20110729000134.GA41512@redoubt.spodhuis.org> References: <20110729000134.GA41512@redoubt.spodhuis.org> Message-ID: Hi Phil, Thanks for your reply - comments below On 29 July 2011 01:01, Phil Pennock wrote: > If your home directory NFS mounted, with Kerberised authentication > against the NFS server? > Yes, indeed. > If so, then when things fail, your credentials on the remote machine > have expired and /home/$you is not mounted, and logging in with a > password supplied to the remote site is getting /home/$you mounted. > > Try instead: > ?ssh -o GSSAPIDelegateCredentials=yes callista > I should have mentioned that I already had DelegateCredentials turned on when I see this problem. In the past, when there's been problems mounting the home directory, the login has still proceeded dumping me to the root directory and complaining that access was denied to $HOME. This doesn't happen in the current case though. Also, on the NFS server, where I have ramped up debugging in rpcsvcgssd I see no errors reported. So, alas, I don't think it's an expired ticket. I will double check this all once more though, just for sanity. Cheers, Jonathan. From djm at mindrot.org Sun Jul 31 04:21:52 2011 From: djm at mindrot.org (Damien Miller) Date: Sun, 31 Jul 2011 04:21:52 +1000 (EST) Subject: Support for ECDSA and SHA-2 (SHA-256) in the SSHFP record In-Reply-To: <0F1A09E5-42E0-4B66-A317-155BB94BC5C2@nic.cz> References: <0F1A09E5-42E0-4B66-A317-155BB94BC5C2@nic.cz> Message-ID: Thanks for starting work on this - SSHFP records for ECDSA keys were on my TODO list, but I haven't yet got around to them. I briefly skimmed your draft - one question I have is whether it is better to roll up all the ECDSA key types under one SSHFP RR type. It would be quite ugly to have to allocate SSHFP RR type numbers for each possible ECDSA curve type, but using a single one might make exploitation of SHA256 preimage attacks easier. The latter is a theoretical concern, so I think a single RR type is probably correct. It would probably be best to continue discussion of this on the IETF SSH list. -d On Thu, 28 Jul 2011, Ond?ej Sur? wrote: > Hi, > > I was sure I sent this to openssh at openssh.com, but cannot find that email now in my Sent mailbox, so I am sending it to the developers list. > > I took a liberty and wrote an I-D with accompanying patch (with contributions from Ondrej Caletka) to support ECDSA in the SSHFP DNS resource record. > > The I-D is here: https://tools.ietf.org/html/draft-os-ietf-sshfp-ecdsa-sha2 (and the source XML here: https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/changes/draft-os-ietf-sshfp-ecdsa-sha2-00.xml) > > The patch to vanilla 5.8 here: https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/changes/ssh-sshfp-ecdsa.patch > > Please Cc: me as I am not (and don't intend to be) subscribed to the list. I will check the archives occasionally, but Cc: would be appreciated. > > Thanks, > O. > -- > Ond?ej Sur? > vedouc? v?zkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato?e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury at nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From ondrej.sury at nic.cz Sun Jul 31 10:54:41 2011 From: ondrej.sury at nic.cz (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Sat, 30 Jul 2011 20:54:41 -0400 Subject: Support for ECDSA and SHA-2 (SHA-256) in the SSHFP record In-Reply-To: References: <0F1A09E5-42E0-4B66-A317-155BB94BC5C2@nic.cz> Message-ID: Hi Damien, On 30. 7. 2011, at 14:21, Damien Miller wrote: > Thanks for starting work on this - SSHFP records for ECDSA keys were on > my TODO list, but I haven't yet got around to them. > I briefly skimmed your draft - one question I have is whether it is > better to roll up all the ECDSA key types under one SSHFP RR type. > It would be quite ugly to have to allocate SSHFP RR type numbers for > each possible ECDSA curve type, but using a single one might make > exploitation of SHA256 preimage attacks easier. My knowledge of cryptography is not so strong, so that's probably good question for security area advisory group as well. > The latter is a theoretical concern, so I think a single RR type is > probably correct. I'll be happy to accept any changes to the draft. I already had the different ECDSA curves in the draft, but it was suggested by my fellow AD that one is probably enough. > It would probably be best to continue discussion of this on the IETF SSH > list. I thought that secsh was concluded, but it seems that the mailing list is still up. Ccing there as well. Anyone who responds please get rid of openssh-unix-dev list when replying, so we don't spam them with ietf flames :) O. > On Thu, 28 Jul 2011, Ond?ej Sur? wrote: > >> Hi, >> >> I was sure I sent this to openssh at openssh.com, but cannot find that email now in my Sent mailbox, so I am sending it to the developers list. >> >> I took a liberty and wrote an I-D with accompanying patch (with contributions from Ondrej Caletka) to support ECDSA in the SSHFP DNS resource record. >> >> The I-D is here: https://tools.ietf.org/html/draft-os-ietf-sshfp-ecdsa-sha2 (and the source XML here: https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/changes/draft-os-ietf-sshfp-ecdsa-sha2-00.xml) >> >> The patch to vanilla 5.8 here: https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/changes/ssh-sshfp-ecdsa.patch >> >> Please Cc: me as I am not (and don't intend to be) subscribed to the list. I will check the archives occasionally, but Cc: would be appreciated. >> >> Thanks, >> O. >> -- >> Ond?ej Sur? >> vedouc? v?zkumu/Head of R&D department >> ------------------------------------------- >> CZ.NIC, z.s.p.o. -- Laborato?e CZ.NIC >> Americka 23, 120 00 Praha 2, Czech Republic >> mailto:ondrej.sury at nic.cz http://nic.cz/ >> tel:+420.222745110 fax:+420.222745112 >> ------------------------------------------- >> >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> -- Ond?ej Sur? vedouc? v?zkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato?e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 -------------------------------------------