From djm at mindrot.org Fri Apr 1 11:47:13 2011 From: djm at mindrot.org (Damien Miller) Date: Fri, 1 Apr 2011 11:47:13 +1100 (EST) Subject: [PATCH] Use canonical hostname for DNS SSHFP lookup In-Reply-To: References: <20101128113312.GC854@pitr.home.jan> Message-ID: On Mon, 29 Nov 2010, Damien Miller wrote: > > On Sun, 28 Nov 2010, Jan Andres wrote: > > > In the current implementation, ssh always uses the hostname supplied by > > the user directly for the SSHFP DNS record lookup. This causes problems > > when using the domain search path, e.g. I have "search example.com" in my > > resolv.conf and then do a "ssh host", I will connect to host.example.com, > > but ssh will query the DNS for an SSHFP record of "host.", not > > "host.example.com.". > > > > The patch below attempts to fix this issue by having getaddrinfo() > > return the canonical host name from the lookup, and passes this on so it > > can be used in the SSHFP record query. > > > > As a side-effect, the patch will completely suppress the SSHFP lookup if > > establishing an SSH1 connection, as RSA1 keys cannot be stored in SSHFP > > records anyway. > > > > The getaddrinfo() implementation in openbsd-compat/fake-rfc2553.c is > > also updated to support the AI_CANONNAME flag. > > > > I don't use OpenBSD, so the patch was prepared against the latest > > snapshot of the portable OpenSSH version. Sorry if this causes any > > inconvenience. > > I looked at this a while ago and rejected this approach as trusting the > DNS too much. See the thread "Re: Question about host certificates" on > this list from mid-June this year. > > What we really (IMHO) need is better feedback from the local resolver as > to how it transformed the name before external resolution. > > There is a hackish workaround for recent OpenSSH - in ~/.ssh/config you > can do: > > Hostname *.* *:* :* > Hostname %h > Hostname * > Hostname %h.your.domain.com I have just learned that Windows 7 has a flag that does exactly what we need here: AI_FQDN. This is its description: > If the AI_FQDN is set and a flat name (single label) is specified, > GetAddrInfoW will return the fully qualified domain name that the name > eventually resolved to. The fully qualified domain name is returned in > the ai_canonname member in the associated addrinfoW structure. This > is different than AI_CANONNAME bit flag that returns the canonical > name registered in DNS which may be different than the fully qualified > domain name that the flat name resolved to. Only one of the AI_FQDN > and AI_CANONNAME bits can be set. The GetAddrInfoW function will fail > if both flags are present with EAI_BADFLAGS. Now we just need the Unix variants to follow... -d From imorgan at nas.nasa.gov Sat Apr 2 03:13:41 2011 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 1 Apr 2011 09:13:41 -0700 Subject: [PATCH] Use canonical hostname for DNS SSHFP lookup In-Reply-To: References: <20101128113312.GC854@pitr.home.jan> Message-ID: <20110401161341.GB6338@linux124.nas.nasa.gov> On Thu, Mar 31, 2011 at 19:47:13 -0500, Damien Miller wrote: > On Mon, 29 Nov 2010, Damien Miller wrote: > > > > > On Sun, 28 Nov 2010, Jan Andres wrote: > > > > > In the current implementation, ssh always uses the hostname supplied by > > > the user directly for the SSHFP DNS record lookup. This causes problems > > > when using the domain search path, e.g. I have "search example.com" in my > > > resolv.conf and then do a "ssh host", I will connect to host.example.com, > > > but ssh will query the DNS for an SSHFP record of "host.", not > > > "host.example.com.". > > > > > > The patch below attempts to fix this issue by having getaddrinfo() > > > return the canonical host name from the lookup, and passes this on so it > > > can be used in the SSHFP record query. > > > > > > As a side-effect, the patch will completely suppress the SSHFP lookup if > > > establishing an SSH1 connection, as RSA1 keys cannot be stored in SSHFP > > > records anyway. > > > > > > The getaddrinfo() implementation in openbsd-compat/fake-rfc2553.c is > > > also updated to support the AI_CANONNAME flag. > > > > > > I don't use OpenBSD, so the patch was prepared against the latest > > > snapshot of the portable OpenSSH version. Sorry if this causes any > > > inconvenience. > > > > I looked at this a while ago and rejected this approach as trusting the > > DNS too much. See the thread "Re: Question about host certificates" on > > this list from mid-June this year. > > > > What we really (IMHO) need is better feedback from the local resolver as > > to how it transformed the name before external resolution. > > > > There is a hackish workaround for recent OpenSSH - in ~/.ssh/config you > > can do: > > > > Hostname *.* *:* :* > > Hostname %h > > Hostname * > > Hostname %h.your.domain.com > > I have just learned that Windows 7 has a flag that does exactly what we > need here: AI_FQDN. This is its description: > > > If the AI_FQDN is set and a flat name (single label) is specified, > > GetAddrInfoW will return the fully qualified domain name that the name > > eventually resolved to. The fully qualified domain name is returned in > > the ai_canonname member in the associated addrinfoW structure. This > > is different than AI_CANONNAME bit flag that returns the canonical > > name registered in DNS which may be different than the fully qualified > > domain name that the flat name resolved to. Only one of the AI_FQDN > > and AI_CANONNAME bits can be set. The GetAddrInfoW function will fail > > if both flags are present with EAI_BADFLAGS. > > Now we just need the Unix variants to follow... > > -d > _______________________________________________ Perhaps OpenBSD 5.0 can start the trend? ;-) -- Iain Morgan From djm at mindrot.org Sat Apr 2 08:11:31 2011 From: djm at mindrot.org (Damien Miller) Date: Sat, 2 Apr 2011 08:11:31 +1100 (EST) Subject: [PATCH] Use canonical hostname for DNS SSHFP lookup In-Reply-To: <20110401161341.GB6338@linux124.nas.nasa.gov> References: <20101128113312.GC854@pitr.home.jan> <20110401161341.GB6338@linux124.nas.nasa.gov> Message-ID: On Fri, 1 Apr 2011, Iain Morgan wrote: > > I have just learned that Windows 7 has a flag that does exactly what we > > need here: AI_FQDN. This is its description: > > > > > If the AI_FQDN is set and a flat name (single label) is specified, > > > GetAddrInfoW will return the fully qualified domain name that the name > > > eventually resolved to. The fully qualified domain name is returned in > > > the ai_canonname member in the associated addrinfoW structure. This > > > is different than AI_CANONNAME bit flag that returns the canonical > > > name registered in DNS which may be different than the fully qualified > > > domain name that the flat name resolved to. Only one of the AI_FQDN > > > and AI_CANONNAME bits can be set. The GetAddrInfoW function will fail > > > if both flags are present with EAI_BADFLAGS. > > > > Now we just need the Unix variants to follow... > > > > -d > > _______________________________________________ > > Perhaps OpenBSD 5.0 can start the trend? ;-) A colleague is already working on it :) From djm at mindrot.org Mon Apr 4 13:35:41 2011 From: djm at mindrot.org (Damien Miller) Date: Mon, 4 Apr 2011 13:35:41 +1000 (EST) Subject: [PATCH] Use canonical hostname for DNS SSHFP lookup In-Reply-To: References: <20101128113312.GC854@pitr.home.jan> <20110401161341.GB6338@linux124.nas.nasa.gov> Message-ID: On Sat, 2 Apr 2011, Damien Miller wrote: > > Perhaps OpenBSD 5.0 can start the trend? ;-) > > A colleague is already working on it :) Patches for OpenBSD's libc to add AI_FQDN and basic patches to OpenSSH to use the new option are on the tech at openbsd.org mailing thread at: http://marc.info/?t=130170279900001&r=1&w=2 -d From kb at open.ch Thu Apr 7 17:12:08 2011 From: kb at open.ch (Konrad Bucheli) Date: Thu, 07 Apr 2011 09:12:08 +0200 Subject: new option ssh-add -v to verify if key is loaded into the agent Message-ID: <4D9D63C8.6060909@open.ch> Dear openssh developers In a shell script I need to verify if a key belonging to a given public key file is already loaded into the agent. To achieve this, I added a new option -v to ssh-add which does this verification. The patch bases on openssh v5.8p1. The regression test agent.sh was extended to test this new feature. Is there any chance for inclusion of attached patch? Cheers Konrad -- konrad bucheli security engineer open systems ag raeffelstrasse 29 ch-8045 zurich t: +41 44 455 74 00 f: +41 44 455 74 01 kb at open.ch http://www.open.ch -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-5.8p1-sshadd-verify.patch Type: text/x-patch Size: 9028 bytes Desc: not available URL: From ibape-mg at ibape-mg.com.br Fri Apr 8 00:39:48 2011 From: ibape-mg at ibape-mg.com.br (IBAPE-MG) Date: Thu, 7 Apr 2011 11:39:48 -0300 Subject: Durabilidade e Patologia das Estruturas de Concreto ( 11:39:48 ) Message-ID: From keisial at gmail.com Fri Apr 8 07:06:53 2011 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Thu, 07 Apr 2011 23:06:53 +0200 Subject: new option ssh-add -v to verify if key is loaded into the agent In-Reply-To: <4D9D63C8.6060909@open.ch> References: <4D9D63C8.6060909@open.ch> Message-ID: <4D9E276D.7020001@gmail.com> Konrad Bucheli wrote: > Dear openssh developers > > In a shell script I need to verify if a key belonging to a given public > key file is already loaded into the agent. To achieve this, I added a > new option -v to ssh-add which does this verification. I'm not sure -v would be the right letter for that. -c (check) or -t (test) would be suitable names, but those options are already taken... From dkg at fifthhorseman.net Fri Apr 8 07:20:05 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 07 Apr 2011 17:20:05 -0400 Subject: new option ssh-add -v to verify if key is loaded into the agent In-Reply-To: <4D9D63C8.6060909@open.ch> References: <4D9D63C8.6060909@open.ch> Message-ID: <4D9E2A85.3090705@fifthhorseman.net> On 04/07/2011 03:12 AM, Konrad Bucheli wrote: > In a shell script I need to verify if a key belonging to a given public > key file is already loaded into the agent. To achieve this, I added a > new option -v to ssh-add which does this verification. Couldn't this already be implemented by grepping the output of ssh-add -L ? Is there a compelling need to introduce (and maintain) a new command-line argument for this? --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 andyb1 at andy-t.org Fri Apr 8 07:44:09 2011 From: andyb1 at andy-t.org (Andy Tsouladze) Date: Thu, 7 Apr 2011 16:44:09 -0500 (CDT) Subject: new option ssh-add -v to verify if key is loaded into the agent In-Reply-To: <4D9E2A85.3090705@fifthhorseman.net> References: <4D9D63C8.6060909@open.ch> <4D9E2A85.3090705@fifthhorseman.net> Message-ID: On Thu, 7 Apr 2011, Daniel Kahn Gillmor wrote: > On 04/07/2011 03:12 AM, Konrad Bucheli wrote: >> In a shell script I need to verify if a key belonging to a given public >> key file is already loaded into the agent. To achieve this, I added a >> new option -v to ssh-add which does this verification. > > Couldn't this already be implemented by grepping the output of > ssh-add -L ? Is there a compelling need to introduce (and maintain) a > new command-line argument for this? ssh-add without any argument shows which keys are loaded, like this: % ssh-add Identity added: /home/andyt/.ssh/id_rsa (/home/andyt/.ssh/id_rsa) For some reason, man page does not mention this. Regards, Andy Dr Andy Tsouladze Sr Unix/Storage SysAdmin From openssh at roumenpetrov.info Fri Apr 8 05:11:06 2011 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Thu, 07 Apr 2011 22:11:06 +0300 Subject: new option ssh-add -v to verify if key is loaded into the agent In-Reply-To: <4D9D63C8.6060909@open.ch> References: <4D9D63C8.6060909@open.ch> Message-ID: <4D9E0C4A.30901@roumenpetrov.info> Konrad Bucheli wrote: > Dear openssh developers > > In a shell script I need to verify if a key belonging to a given public > key file is already loaded into the agent. To achieve this, I added a > new option -v to ssh-add which does this verification. > What is rationale to write 100 lines of C-code instead 1 line in shell script ? > The patch bases on openssh v5.8p1. The regression test agent.sh was > extended to test this new feature. > > Is there any chance for inclusion of attached patch? > > Cheers > > Konrad > Roumen -- Get X.509 certificates support in OpenSSH: http://roumenpetrov.info/openssh/ From peter at stuge.se Fri Apr 8 07:50:29 2011 From: peter at stuge.se (Peter Stuge) Date: Thu, 7 Apr 2011 23:50:29 +0200 Subject: new option ssh-add -v to verify if key is loaded into the agent In-Reply-To: References: <4D9D63C8.6060909@open.ch> <4D9E2A85.3090705@fifthhorseman.net> Message-ID: <20110407215029.9517.qmail@stuge.se> Andy Tsouladze wrote: > ssh-add without any argument shows which keys are loaded, like this: Not quite. > % ssh-add > Identity added: /home/andyt/.ssh/id_rsa (/home/andyt/.ssh/id_rsa) Here ssh-add reports that it has added your private key. This suggests that you have no passphrase on your key. Should fix that. :) But more importantly, using the filename is not reliable, because by the time ssh-add -l or -L is called, the file with that name on disk may have changed. //Peter From cyrille.lefevre-lists at laposte.net Fri Apr 8 07:43:26 2011 From: cyrille.lefevre-lists at laposte.net (Cyrille Lefevre) Date: Thu, 07 Apr 2011 23:43:26 +0200 Subject: new option ssh-add -v to verify if key is loaded into the agent In-Reply-To: <4D9E2A85.3090705@fifthhorseman.net> References: <4D9D63C8.6060909@open.ch> <4D9E2A85.3090705@fifthhorseman.net> Message-ID: <4D9E2FFE.6000301@laposte.net> Le 07/04/2011 23:20, Daniel Kahn Gillmor a ?crit : > On 04/07/2011 03:12 AM, Konrad Bucheli wrote: >> In a shell script I need to verify if a key belonging to a given public >> key file is already loaded into the agent. To achieve this, I added a >> new option -v to ssh-add which does this verification. > > Couldn't this already be implemented by grepping the output of > ssh-add -L ? Is there a compelling need to introduce (and maintain) a > new command-line argument for this? Hi, one implemented, there is nothing to do. also, think performance, ssh-add -v xxx vs ssh-add -L | grep ...$ 1 process vs 2 processes, even if negligeable, it's 1 fork less. 2 years ago, I've rewritten a script to use ssh control master, I win 20+ % on a 100% PCU usage, the server wasn't changed... Regards, Cyrille Lefevre -- mailto:Cyrille.Lefevre-lists at laposte.net From kb at open.ch Fri Apr 8 15:41:29 2011 From: kb at open.ch (Konrad Bucheli) Date: Fri, 08 Apr 2011 07:41:29 +0200 Subject: new option ssh-add -v to verify if key is loaded into the agent In-Reply-To: <4D9E2A85.3090705@fifthhorseman.net> References: <4D9D63C8.6060909@open.ch> <4D9E2A85.3090705@fifthhorseman.net> Message-ID: <4D9EA009.1040304@open.ch> On 04/07/11 23:20, Daniel Kahn Gillmor wrote: > On 04/07/2011 03:12 AM, Konrad Bucheli wrote: >> In a shell script I need to verify if a key belonging to a given public >> key file is already loaded into the agent. To achieve this, I added a >> new option -v to ssh-add which does this verification. > > Couldn't this already be implemented by grepping the output of > ssh-add -L ? Is there a compelling need to introduce (and maintain) a > new command-line argument for this? My problem is that the agent is not under my control. So I could just believe what he is telling me (output of ssh-add -L). But I would like to verify that he is not lying. So this patch verifies cryptographically with challenge/response that the agent has really loaded the private key, identical to the public key authentication via ssh-agent. Cheers Konrad From jean-michel.elyn at mailz.org Fri Apr 8 23:24:32 2011 From: jean-michel.elyn at mailz.org (Jean-Michel Elyn (MAILZ)) Date: Fri, 08 Apr 2011 15:24:32 +0200 Subject: Host selection in ssh_config Message-ID: <4D9F0C90.2050307@mailz.org> Hello there, I'm a little afraid of writing here, hope I don't make any mistake doing so. I'm trying for days and searching the web too, but no obvious solution, no reply from the specialized forum I wrote in. Here is the situation: I would like to have a lighter security inside our domain, without changing when going outside. By "lighter security" I mean at least, no host key check; we often install and re-install hosts and managing all that public keys is heavy. Then my goal is to have two different configurations when targeting a host: * inside our domain: "StrictHostKeyChecking no" and "UserKnownHostsFile /dev/null". * into the Wild: "StrictHostKeyChecking yes" and "UserKnownHostsFile ~/.ssh/known_hosts". And now my problem: The easiest way to sort target hosts, I thought, was to select our domain in ssh_config: # inside Host *.our_domain parameters # outside Host * parameters However, the hostname used is the one written in the command, I suppose: "ssh a_host.our_domain" works fine! But "ssh a_host" does not. Of course we all avoid writing our domain. So I wanted to check whether a domain is provided (a point "." should exist): # inside Host !*.* parameters # outside Host * parameters Unfortunately it doesn't work... I tried many other possibilities but all failed. Is there a solution to that problem? If yes how to do? If not is it a bug? Thanks for your help. Jean-Michel. From imorgan at nas.nasa.gov Sat Apr 9 03:24:03 2011 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 8 Apr 2011 10:24:03 -0700 Subject: Host selection in ssh_config In-Reply-To: <4D9F0C90.2050307@mailz.org> References: <4D9F0C90.2050307@mailz.org> Message-ID: <20110408172403.GA4804@linux124.nas.nasa.gov> On Fri, Apr 08, 2011 at 08:24:32 -0500, Jean-Michel Elyn (MAILZ) wrote: > Hello there, > > I'm a little afraid of writing here, hope I don't make any mistake doing > so. I'm trying for days and searching the web too, but no obvious > solution, no reply from the specialized forum I wrote in. > > Here is the situation: > I would like to have a lighter security inside our domain, without > changing when going outside. By "lighter security" I mean at least, no > host key check; we often install and re-install hosts and managing all > that public keys is heavy. Then my goal is to have two different > configurations when targeting a host: Before going any further, it should be pointed out that disabling the host key checking _significantly_ degrades the security of SSH. I would stongly recommend that you consider the other side of the problem: Simplifying the management of host keys. There are basically three approaches to this issue: - Ensure that host keys are preserved across system upgrades/reinstalls, i.e. save the keys prior to an install and restore them afterwards. - Providing a centralized location for distributing an 'official' ssh_known_hosts file for your domain. The file could be updated either via an automated process (using ssh-keyscan) or manually. Systems could periodically retrieve the ssh_known_hosts file via wget, cfengine, etc. - Host certificates might also be an option. (This assumes that both the the clients and servers are running a recent enough version to support certificates.) In this case, the host key (and certificate does not need to be preserved across system installs. A new cettificate can simply be generated for the system when needed. The advantage that this method has is that maintenance of the ssh_known_hosts file is minimal. > > * inside our domain: "StrictHostKeyChecking no" and "UserKnownHostsFile > /dev/null". > * into the Wild: "StrictHostKeyChecking yes" and "UserKnownHostsFile > ~/.ssh/known_hosts". > > And now my problem: > The easiest way to sort target hosts, I thought, was to select our > domain in ssh_config: > > # inside > Host *.our_domain > parameters > # outside > Host * > parameters > > However, the hostname used is the one written in the command, I suppose: > "ssh a_host.our_domain" works fine! But "ssh a_host" does not. Of course > we all avoid writing our domain. So I wanted to check whether a domain > is provided (a point "." should exist): > > # inside > Host !*.* > parameters > # outside > Host * > parameters > > Unfortunately it doesn't work... I tried many other possibilities but > all failed. Is there a solution to that problem? If yes how to do? If > not is it a bug? Thanks for your help. > > Jean-Michel. > _______________________________________________ The second approach (with Host *.* and Host *) should work. However, you might want to also include a Host *.your.domain section in case a local FQDN is used. Note also that if you have occasion to ssh to an explicit IP address, the Host *.* section would be used unless you have made other provisions. You might want something like: Host *.your.domain xxx.yyy.zzz.* blah blah Host *.* blah blah Host * blah blah Note that ssh uses the first instance of an applicable parameter, not simply the parameters from the first applicable section. Thus if you set some parameters in the Host * section, you will want to explicitly set those parameters in the other sections as well. For example, if you set UserKnownHostsFile in the Host * section. You will need to explicitly set it in the other sections. -- Iain Morgan From lists at eitanadler.com Sat Apr 9 04:02:08 2011 From: lists at eitanadler.com (Eitan Adler) Date: Fri, 8 Apr 2011 14:02:08 -0400 Subject: new option ssh-add -v to verify if key is loaded into the agent In-Reply-To: <4D9EA009.1040304@open.ch> References: <4D9D63C8.6060909@open.ch> <4D9E2A85.3090705@fifthhorseman.net> <4D9EA009.1040304@open.ch> Message-ID: > My problem is that the agent is not under my control. So I could just > believe what he is telling me (output of ssh-add -L). But I would like > to verify that he is not lying. So this patch verifies cryptographically > with challenge/response that the agent has really loaded the private > key, identical to the public key authentication via ssh-agent. Giving an agent outside of your control access to your private key is not a smart thing to do. -- Eitan Adler From jean-michel.elyn at mailz.org Sat Apr 9 10:07:09 2011 From: jean-michel.elyn at mailz.org (Jean-Michel Elyn (MAILZ)) Date: Sat, 09 Apr 2011 02:07:09 +0200 Subject: Host selection in ssh_config [SOLVED] In-Reply-To: <20110408172403.GA4804@linux124.nas.nasa.gov> References: <4D9F0C90.2050307@mailz.org> <20110408172403.GA4804@linux124.nas.nasa.gov> Message-ID: <4D9FA32D.7010305@mailz.org> Hello Iain, First of all, I would like to thank you for your fast and synthetic reply, even giving other possibilities than the one I was looking for. I'm going to reply to all of them: That's right, not checking host keys degrades security. However, being inside our organization provides a good protection against outside attacks; we rely on some specialists focused on that topic. The first solution you gave, saving private-public keys of all our hosts seems to me not secure enough unless encrypted. But then the burden to manage is non negligible: Saving keys, encrypting them, backing them up, decrypting them on demand... The second solution is the one we are currently using, saving the public key of each host in a central place, collecting all of them to make a common ssh_known_hosts file, then distributing this file to all hosts every day. This is boring to have to wait the day after when installing a host (we have more than one thousand computers running Linux). Or we need to manually run all the scripts to have few updated machines each time we (re-) install one. The third solution seems interesting. Unfortunately the ssh-keygen we have on our distributions (derived from rhel4 and 5: openssh 4.3) does not include certificate options such as -I, -h or -s. Too old, too bad. Finally the second approach seems to me the best one. Well, I suppose it can be a bit refined by forcing strong security when connecting to some important servers inside our organization, but that's one step ahead. I needed first to solve the difficulty I had. I understood from your example that pattern list in Host line is space separated, not comma separated patterns. So if I write Host *.our.domain xxx.yyy.* it works well! This was one of my mistakes. Another one was I read help (ssh_config's man pages) from many sources but the one from our hosts does not tell anything about "!", because it must be a too old version. So finally I've got an ssh_config that works: # 1) inside with FQN or IP address Host *.our.domain xxx.yyy.* parameters for weak security # 2) outside (of course with FQN) Host *.* parameters for strong security # 3) inside with no domain provided Host * parameters for weak security Thank you very much for your precious help to solve this problem. Jean-Michel. On 04/08/2011 07:24 PM, Iain Morgan wrote: > On Fri, Apr 08, 2011 at 08:24:32 -0500, Jean-Michel Elyn (MAILZ) wrote: >> Hello there, >> >> I'm a little afraid of writing here, hope I don't make any mistake doing >> so. I'm trying for days and searching the web too, but no obvious >> solution, no reply from the specialized forum I wrote in. >> >> Here is the situation: >> I would like to have a lighter security inside our domain, without >> changing when going outside. By "lighter security" I mean at least, no >> host key check; we often install and re-install hosts and managing all >> that public keys is heavy. Then my goal is to have two different >> configurations when targeting a host: > Before going any further, it should be pointed out that disabling the > host key checking _significantly_ degrades the security of SSH. I would > stongly recommend that you consider the other side of the problem: > Simplifying the management of host keys. > > There are basically three approaches to this issue: > > - Ensure that host keys are preserved across system upgrades/reinstalls, > i.e. save the keys prior to an install and restore them afterwards. > - Providing a centralized location for distributing an 'official' > ssh_known_hosts file for your domain. The file could be updated either > via an automated process (using ssh-keyscan) or manually. Systems > could periodically retrieve the ssh_known_hosts file via wget, > cfengine, etc. > - Host certificates might also be an option. (This assumes that both the > the clients and servers are running a recent enough version to support > certificates.) In this case, the host key (and certificate does not > need to be preserved across system installs. A new cettificate can > simply be generated for the system when needed. The advantage that > this method has is that maintenance of the ssh_known_hosts file is > minimal. >> * inside our domain: "StrictHostKeyChecking no" and "UserKnownHostsFile >> /dev/null". >> * into the Wild: "StrictHostKeyChecking yes" and "UserKnownHostsFile >> ~/.ssh/known_hosts". >> >> And now my problem: >> The easiest way to sort target hosts, I thought, was to select our >> domain in ssh_config: >> >> # inside >> Host *.our_domain >> parameters >> # outside >> Host * >> parameters >> >> However, the hostname used is the one written in the command, I suppose: >> "ssh a_host.our_domain" works fine! But "ssh a_host" does not. Of course >> we all avoid writing our domain. So I wanted to check whether a domain >> is provided (a point "." should exist): >> >> # inside >> Host !*.* >> parameters >> # outside >> Host * >> parameters >> >> Unfortunately it doesn't work... I tried many other possibilities but >> all failed. Is there a solution to that problem? If yes how to do? If >> not is it a bug? Thanks for your help. >> >> Jean-Michel. >> _______________________________________________ > The second approach (with Host *.* and Host *) should work. However, you > might want to also include a Host *.your.domain section in case a local > FQDN is used. Note also that if you have occasion to ssh to an explicit > IP address, the Host *.* section would be used unless you have made > other provisions. You might want something like: > > Host *.your.domain xxx.yyy.zzz.* > blah blah > > Host *.* > blah blah > > Host * > blah blah > > Note that ssh uses the first instance of an applicable parameter, not > simply the parameters from the first applicable section. Thus if you set > some parameters in the Host * section, you will want to explicitly set > those parameters in the other sections as well. For example, if you set > UserKnownHostsFile in the Host * section. You will need to explicitly > set it in the other sections. > From keisial at gmail.com Sun Apr 10 09:41:27 2011 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sun, 10 Apr 2011 01:41:27 +0200 Subject: new option ssh-add -v to verify if key is loaded into the agent In-Reply-To: <4D9E0C4A.30901@roumenpetrov.info> References: <4D9D63C8.6060909@open.ch> <4D9E0C4A.30901@roumenpetrov.info> Message-ID: <4DA0EEA7.6090902@gmail.com> Roumen Petrov wrote: > Konrad Bucheli wrote: >> Dear openssh developers >> >> In a shell script I need to verify if a key belonging to a given public >> key file is already loaded into the agent. To achieve this, I added a >> new option -v to ssh-add which does this verification. >> > What is rationale to write 100 lines of C-code instead 1 line in > shell script ? I suspect that when you start trying to take all quirks into account, the C code will be much easier. From dws at open.ch Tue Apr 12 16:38:07 2011 From: dws at open.ch (David Schweikert) Date: Tue, 12 Apr 2011 08:38:07 +0200 Subject: new option ssh-add -v to verify if key is loaded into the agent In-Reply-To: References: <4D9D63C8.6060909@open.ch> <4D9E2A85.3090705@fifthhorseman.net> <4D9EA009.1040304@open.ch> Message-ID: <20110412063802.GA4385@open.ch> Hi, On Fri, Apr 08, 2011 at 14:02:08 -0400, Eitan Adler wrote: > > My problem is that the agent is not under my control. So I could just > > believe what he is telling me (output of ssh-add -L). But I would like > > to verify that he is not lying. So this patch verifies cryptographically > > with challenge/response that the agent has really loaded the private > > key, identical to the public key authentication via ssh-agent. > > Giving an agent outside of your control access to your private key is > not a smart thing to do. I think that you, and the other people that replied to the original post until now, don't understand what we are trying to achieve with this. Whenever you connect to a SSH server using public key authentication, the server verifies your identity with a challenge meant to prove that you have access to the private key. This works with an ssh-agent by passing that challenge over to the agent and getting the answer from the agent back to the server. Note the fact that this is done such that, you can't fetch the full private key from the agent. The new "ssh-add -v" option does the same thing, but without the server. It can challenge the ssh-agent to verify that the agent really has access to a private key. It does so without merely believing what the agent says, but by using the same challenge method as the server does for authentication. This can be used, for example, to implement two factor authentication without major code rewrite in openssh: you can instruct the SSH server to do password authentication, and then you can additionally also check the SSH key (provided that agent forwarding is set) via "ssh-add -v" (using ForceCommand). That's probably a rather fancy use case, but it is very important to us. Anyway: this code adds proper, cryptographical verification that an agent has a certain private key loaded. We think that this function could be useful to others as well. Cheers David From jgibson at spscommerce.com Wed Apr 13 02:07:20 2011 From: jgibson at spscommerce.com (Jeff Gibson) Date: Tue, 12 Apr 2011 11:07:20 -0500 Subject: advisory file locks in linux - do they work? Message-ID: <4DA478B8.7050409@spscommerce.com> Hi - I'm trying to verify if OpenSSH/SFTP will in fact lock files with advisory file locking in Linux. I can test locking with the linux "flock" command to verify that file locking does work - but when I upload or download a file with SFTP it will not detect a lock. I'm asking about Linux specifically because about a year ago I was doing a similar process in Solaris 9 and it seemed to work. OS'n I've tried this on- RHEL5.5 with OpenSSH 5.6p1 (compiled) Ubuntu 10.10 with OpenSSH 5.5p1 Test # get 100MB testfile from remote box via sftp (sftp to remote host, get testfile) # While that's running use the following command to check for the lock: flock -xn testfile -c "echo test > testfile" #flock command returns an exit status of 0. Expected result is 1 (failure). Test "test" is in testfile Control Test # Open a stream of data to testfile and set exclusive advisory lock flock -xn testfile -c "cat /dev/random > testfile" # Test for lock by trying to set another exclusive lock flock -xn testfile -c "echo test > testfile" Result is 1 (failure because the file is locked. Text "test" is not in testfile.) USENET - sorry for the double post, apparently you don't forward to the email list? From djm at mindrot.org Wed Apr 13 11:28:44 2011 From: djm at mindrot.org (Damien Miller) Date: Wed, 13 Apr 2011 11:28:44 +1000 (EST) Subject: advisory file locks in linux - do they work? In-Reply-To: <4DA478B8.7050409@spscommerce.com> References: <4DA478B8.7050409@spscommerce.com> Message-ID: On Tue, 12 Apr 2011, Jeff Gibson wrote: > Hi - I'm trying to verify if OpenSSH/SFTP will in fact lock files with > advisory file locking in Linux. no From bob at proulx.com Thu Apr 14 02:45:36 2011 From: bob at proulx.com (Bob Proulx) Date: Wed, 13 Apr 2011 10:45:36 -0600 Subject: advisory file locks in linux - do they work? In-Reply-To: <4DA478B8.7050409@spscommerce.com> References: <4DA478B8.7050409@spscommerce.com> Message-ID: <20110413164536.GA18908@hysteria.proulx.com> Jeff Gibson wrote: > Hi - I'm trying to verify if OpenSSH/SFTP will in fact lock files > with advisory file locking in Linux. You seem to think that all programs do file locking? Or perhaps you are aware that they do not but you think they /should/ use file locking and this is your way of lobbying to add it? By the way ... Most other programs such as 'cp', 'mv', 'cat', 'rsync', do not do file locking either. File locking is actually a rather trouble prone technique and tends to have problems in practice on networked filesystems such as NFS. It is almost always better to avoid it and use techniques that do not require it. For one random example the Maildir format often works better than mbox format since there is no need for file locking with Maildirs. > I can test locking with the linux "flock" command to verify that > file locking does work - but when I upload or download a file with > SFTP it will not detect a lock. Correct. But as you are aware the Unix philosophy is to use small programs that each do one thing well and then to integrate them. Your use of the flock command from util-linux-ng is an example. There is no need to add file locking to sftp. Instead use the flock program (or other similar programs) to semaphore between processes. > # get 100MB testfile from remote box via sftp > (sftp to remote host, get testfile) > # While that's running use the following command to check for the lock: > flock -xn testfile -c "echo test > testfile" > #flock command returns an exit status of 0. Expected result is 1 > (failure). Test "test" is in testfile Since you already know about the 'flock -c cmd' then you already know how to add this to sftp in your process. # Use 'sleep 20' here to simulate a large file transfer that takes a while. flock testfile -c "sleep 20 ; echo get testfile | sftp remote.example.com" & sleep 2 # give time for the above to get going and lock the file flock testfile -c "echo testfile is not locked now" As such there is no need for file locking to be added to any particular program. You have the control to semaphore between any process that you wish to coordinate. This is much more flexible and powerful than creating an infinite number of infinitely large monolithic programs that contain all possible functionality. Bob From jgibson at spscommerce.com Thu Apr 14 04:17:41 2011 From: jgibson at spscommerce.com (Jeff Gibson) Date: Wed, 13 Apr 2011 13:17:41 -0500 Subject: advisory file locks in linux - do they work? In-Reply-To: <20110413164536.GA18908@hysteria.proulx.com> References: <4DA478B8.7050409@spscommerce.com> <20110413164536.GA18908@hysteria.proulx.com> Message-ID: <4DA5E8C5.7000303@spscommerce.com> On 04/13/2011 11:45 AM, Bob Proulx wrote: > You seem to think that all programs do file locking? Or perhaps you > are aware that they do not but you think they /should/ use file > locking and this is your way of lobbying to add it? Whoa - Please don't start attacking. I had just read on some websites that SFTP supported it (perhaps this was not OpenSSH), and I *thought* I had it working on Solaris at one point. Guess not. Anyway it's good to know this so I don't spend any more time trying to get it to work! :) > Since you already know about the 'flock -c cmd' then you already know > how to add this to sftp in your process. > > Perhaps I wasn't very clear - we have clients connecting to us via SFTP - We cannot reasonably expect them to know enough about UNIX/SFTP to do the above, and many of the 3rd party programs they use are closed source with limited feature sets. Instead I was hoping that it was possible for the internal-sftp process to automatically lock incoming files. As I have now learned, OpenSSH/SFTP does not support this natively. However, we have had an internal developer add the functionality and so far it seems to work. > As such there is no need for file locking to be added to any > particular program. You have the control to semaphore between any > process that you wish to coordinate. This is much more flexible and > powerful than creating an infinite number of infinitely large > monolithic programs that contain all possible functionality. > OK - so is there a way to do this with the internal-sftp command while using a chroot directory? I guess I'm not grokking how to do this on the server-side without adding code or copying binaries to the user's directory. Anyway, thanks for you time. JG From contato at projetowebnew.com.br Tue Apr 26 01:25:03 2011 From: contato at projetowebnew.com.br (projeto web) Date: Mon, 25 Apr 2011 16:25:03 +0100 Subject: Projeto Web - Precisando Fazer ou Atualizar Seu Site Message-ID: <60d827b91a01d7a09afd16bfa69a0494@gigamailingmkt.com.br> Seu cliente de email n?o pode visualizar esse email. Para ver a vers?o online, por favor visite: http://gigamailingmkt.com.br/display.php?M=1357193&C=afbd8c0a7cef88684669c5a52d0f9fad&S=106&L=102&N=103 Se n?o deseja mais receber esses emails clique:http://gigamailingmkt.com.br/unsubscribe.php?M=1357193&N=106&L=102&C=afbd8c0a7cef88684669c5a52d0f9fad From hnine at isis.vanderbilt.edu Thu Apr 28 01:44:43 2011 From: hnine at isis.vanderbilt.edu (Harmon Nine) Date: Wed, 27 Apr 2011 10:44:43 -0500 Subject: Bug in remote gui app execution via cygwin sshd Message-ID: <7AB1C26C64423249964AB392C6EBF0E005CF15B7@discovery.isis.vanderbilt.edu> Hello. Platform: Windows XP Package: Cygwin openssh There appears to be a bug in the ssh-daemon in version 5.8p1-1 of the openssh package for cygwin. The bug does not present itself on systems running sshd from the 5.1p1-10 version of cygwin openssh. The bug is as follows: A remote system R has Cygwin sshd running from version 5.8p1-1 of openssh. The daemon is running as a service, configured using ssh-host-config. Further, the service is running under the "Local System account", and in its properties as a service, "Allow service to interact with desktop" has been checked. A user on a local machine logs into R using ssh. Then, in the resulting shell, the user executes a gui app such as notepad. On the remote machine R, what appears on the display, rather than the gui for the notepad app, is a rectangular area with what appears to be a title-bar at the top, although what this bar contains is a long white or multi-colored rectangle. The "window" itself displays the contents of what was behind it when it was spawned, and keeps displaying this when moved. Beyond the ability to move it, the rectangle is non-functional. If R is running sshd from version 5.1p1-10 of cygwin openssh, with the same configuration, a functional notepad app is spawned. This doesn't appear to be due to any windows updates, as we have updated all of our machines recently. Those with 5.8p1-1 have the bug, and those with 5.1p1-10 do not. Any help/information is appreciated. -- Harmon From javier.vila at darstelecom.es Fri Apr 29 03:54:14 2011 From: javier.vila at darstelecom.es (Javier Vila Lopez) Date: Thu, 28 Apr 2011 19:54:14 +0200 Subject: authentication ok but connection disconnects Message-ID: <000b01cc05cd$49b38c80$dd1aa580$@vila@darstelecom.es> To whom it corresponds, I have been trying to connect my RHEL4 machine through public key authentication against a windows server 2003 machine running OpenSSH for Windows v3.8.1p1-1. I set up everything: keys, user, etc. Doing sftp -vv user@ I see that authentication went ok but somehow, connection hangs up. I removed anti-virus and other security software on the ws2003 machine that could cause this error and same results. Can anyone please help me? I am getting desperate here: don?t know what else to try. Please find attached my sshd_config file plus the output I get when performing the sftp command on my linux machine. Thanks in advance. Best Regards Javier Vila L?pez DARS Telecom, S.L Ingeniero de Sistemas - System Engineer +34 690133111 javier.vila at darstelecom.es C. Gabriela Mistral, 2 28035 - MADRID * P Antes de imprimir piensa en el Medio Ambiente *. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: output_sftp.txt URL: From djm at mindrot.org Fri Apr 29 18:25:06 2011 From: djm at mindrot.org (Damien Miller) Date: Fri, 29 Apr 2011 18:25:06 +1000 (EST) Subject: authentication ok but connection disconnects In-Reply-To: <000b01cc05cd$49b38c80$dd1aa580$@vila@darstelecom.es> References: <000b01cc05cd$49b38c80$dd1aa580$@vila@darstelecom.es> Message-ID: On Thu, 28 Apr 2011, Javier Vila Lopez wrote: > To whom it corresponds, > > I have been trying to connect my RHEL4 machine through public key > authentication against a windows server 2003 machine running OpenSSH for > Windows v3.8.1p1-1. That's very old. We are up to 5.8 now. > Can anyone please help me? I am getting desperate here: don?t know what else > to try. You should use a more recent version on the server, but what you really need is to look at the logs from the server. -d From keisial at gmail.com Sat Apr 30 06:11:20 2011 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Fri, 29 Apr 2011 22:11:20 +0200 Subject: authentication ok but connection disconnects In-Reply-To: <000b01cc05cd$49b38c80$dd1aa580$@vila@darstelecom.es> References: <000b01cc05cd$49b38c80$dd1aa580$@vila@darstelecom.es> Message-ID: <4DBB1B68.6030602@gmail.com> Javier Vila Lopez escribi?: > To whom it corresponds, > > > > I have been trying to connect my RHEL4 machine through public key > authentication against a windows server 2003 machine running OpenSSH for > Windows v3.8.1p1-1. > > > > I set up everything: keys, user, etc. Doing sftp -vv user@ I see that > authentication went ok but somehow, connection hangs up. I removed > anti-virus and other security software on the ws2003 machine that could > cause this error and same results. Maybe you don't have a shell to be opened?