<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: ssh and using Authorized Keys File ?? in Operating System - Linux</title>
    <link>https://community.hpe.com/t5/operating-system-linux/ssh-and-using-authorized-keys-file/m-p/5258283#M52600</link>
    <description>&lt;!--!*#--&gt;So, if I understand your description, the&lt;BR /&gt;actual problem here is that you can't use&lt;BR /&gt;SSH to log in as a user whose password has&lt;BR /&gt;expired.  (So, not really much to do with the&lt;BR /&gt;"authorized_keys" file, which isn't&lt;BR /&gt;changing.)  If that's correct, ...&lt;BR /&gt;&lt;BR /&gt;&amp;gt; They are allowed direct login to these&lt;BR /&gt;&amp;gt; ID's, [...]&lt;BR /&gt;&lt;BR /&gt;&amp;gt; [...] even though there is no direct login&lt;BR /&gt;&amp;gt; to the ID's [...]&lt;BR /&gt;&lt;BR /&gt;I'm confused.&lt;BR /&gt;&lt;BR /&gt;&amp;gt; We are required by our security group [...]&lt;BR /&gt;&lt;BR /&gt;Apparently, you need to pursue this problem&lt;BR /&gt;with them.  I know nothing, but I suspect&lt;BR /&gt;that any scheme which allows a user with an&lt;BR /&gt;expired password to log in would be a _real_&lt;BR /&gt;security problem.  (Which is different from&lt;BR /&gt;an intentional service disruption caused by&lt;BR /&gt;a lame policy decision made by "our security&lt;BR /&gt;group".)&lt;BR /&gt;&lt;BR /&gt;If no one actually uses a password to log in&lt;BR /&gt;as one of these Admin users -- passwordless&lt;BR /&gt;SSH connections only -- then I would think&lt;BR /&gt;that "our security group" could set&lt;BR /&gt;complex/random passwords for them, passwords&lt;BR /&gt;which are known to no one.  Then, who could&lt;BR /&gt;care if they ever expire?  And if long-life&lt;BR /&gt;passwords are still considered a problem,&lt;BR /&gt;even if no one actually uses (or even knows)&lt;BR /&gt;them, then let "our security group" change&lt;BR /&gt;them whenever it wants to, so long as it&lt;BR /&gt;doesn't ever let them expire.&lt;BR /&gt;&lt;BR /&gt;If "our security group" is not entirely&lt;BR /&gt;populated by morons, then it should be&lt;BR /&gt;possible to agree on a policy which satisfies&lt;BR /&gt;any rational security requirements while&lt;BR /&gt;allowing necessary work to get done.  In some&lt;BR /&gt;cases of nonsensical policies, there may be&lt;BR /&gt;no technical solution.  The real mystery here&lt;BR /&gt;is what "our security group" is expecting to&lt;BR /&gt;achieve by having these passwords expire.&lt;BR /&gt;Especially if no one is actually using them.&lt;BR /&gt;&lt;BR /&gt;Alternatively, one might be able to extract&lt;BR /&gt;the password expiration date from the&lt;BR /&gt;authorization data base, and run a "cron"&lt;BR /&gt;job which automatically sends increasingly&lt;BR /&gt;nasty e-mail messages to "our security group" &lt;BR /&gt;as password expiration dates grow nigh.&lt;BR /&gt;Sometimes a non-technical ("social&lt;BR /&gt;engineering") solution can substitute for a&lt;BR /&gt;technical solution.  (Or, ideally, educate&lt;BR /&gt;"our security group" regarding the benefits&lt;BR /&gt;of a more enlightened policy.)</description>
    <pubDate>Sat, 09 Oct 2010 00:14:14 GMT</pubDate>
    <dc:creator>Steven Schweda</dc:creator>
    <dc:date>2010-10-09T00:14:14Z</dc:date>
    <item>
      <title>ssh and using Authorized Keys File ??</title>
      <link>https://community.hpe.com/t5/operating-system-linux/ssh-and-using-authorized-keys-file/m-p/5258282#M52599</link>
      <description>We have several what we call Admin ID's that the applications group uses to administer there applications from...&lt;BR /&gt;&lt;BR /&gt;They are allowed direct login to these ID's, and are forced to us sudo which issues the su for them to log into these accounts...&lt;BR /&gt;&lt;BR /&gt;The ID's do have ssh-keys generated for these Admin ID's so that they can communicate between other servers with these same ID's set up on them...&lt;BR /&gt;&lt;BR /&gt;We are required by our security group to have expiring passwords set on these ID's, even though there is no direct login to the ID's which brings up the issue we are having..&lt;BR /&gt;&lt;BR /&gt;Should the ID's password expire, the scripts that communicate with this ID between servers that is using the ssh-keys set up in the authorizedkeys file, also stops working..&lt;BR /&gt;As soon as the password is set to some new password it starts working again...&lt;BR /&gt;&lt;BR /&gt;Is there something that can be done, when the password expires, that will allow ID's with the ssh-keys defined to continue to function ??&lt;BR /&gt;</description>
      <pubDate>Fri, 08 Oct 2010 16:32:45 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/ssh-and-using-authorized-keys-file/m-p/5258282#M52599</guid>
      <dc:creator>MikeL_4</dc:creator>
      <dc:date>2010-10-08T16:32:45Z</dc:date>
    </item>
    <item>
      <title>Re: ssh and using Authorized Keys File ??</title>
      <link>https://community.hpe.com/t5/operating-system-linux/ssh-and-using-authorized-keys-file/m-p/5258283#M52600</link>
      <description>&lt;!--!*#--&gt;So, if I understand your description, the&lt;BR /&gt;actual problem here is that you can't use&lt;BR /&gt;SSH to log in as a user whose password has&lt;BR /&gt;expired.  (So, not really much to do with the&lt;BR /&gt;"authorized_keys" file, which isn't&lt;BR /&gt;changing.)  If that's correct, ...&lt;BR /&gt;&lt;BR /&gt;&amp;gt; They are allowed direct login to these&lt;BR /&gt;&amp;gt; ID's, [...]&lt;BR /&gt;&lt;BR /&gt;&amp;gt; [...] even though there is no direct login&lt;BR /&gt;&amp;gt; to the ID's [...]&lt;BR /&gt;&lt;BR /&gt;I'm confused.&lt;BR /&gt;&lt;BR /&gt;&amp;gt; We are required by our security group [...]&lt;BR /&gt;&lt;BR /&gt;Apparently, you need to pursue this problem&lt;BR /&gt;with them.  I know nothing, but I suspect&lt;BR /&gt;that any scheme which allows a user with an&lt;BR /&gt;expired password to log in would be a _real_&lt;BR /&gt;security problem.  (Which is different from&lt;BR /&gt;an intentional service disruption caused by&lt;BR /&gt;a lame policy decision made by "our security&lt;BR /&gt;group".)&lt;BR /&gt;&lt;BR /&gt;If no one actually uses a password to log in&lt;BR /&gt;as one of these Admin users -- passwordless&lt;BR /&gt;SSH connections only -- then I would think&lt;BR /&gt;that "our security group" could set&lt;BR /&gt;complex/random passwords for them, passwords&lt;BR /&gt;which are known to no one.  Then, who could&lt;BR /&gt;care if they ever expire?  And if long-life&lt;BR /&gt;passwords are still considered a problem,&lt;BR /&gt;even if no one actually uses (or even knows)&lt;BR /&gt;them, then let "our security group" change&lt;BR /&gt;them whenever it wants to, so long as it&lt;BR /&gt;doesn't ever let them expire.&lt;BR /&gt;&lt;BR /&gt;If "our security group" is not entirely&lt;BR /&gt;populated by morons, then it should be&lt;BR /&gt;possible to agree on a policy which satisfies&lt;BR /&gt;any rational security requirements while&lt;BR /&gt;allowing necessary work to get done.  In some&lt;BR /&gt;cases of nonsensical policies, there may be&lt;BR /&gt;no technical solution.  The real mystery here&lt;BR /&gt;is what "our security group" is expecting to&lt;BR /&gt;achieve by having these passwords expire.&lt;BR /&gt;Especially if no one is actually using them.&lt;BR /&gt;&lt;BR /&gt;Alternatively, one might be able to extract&lt;BR /&gt;the password expiration date from the&lt;BR /&gt;authorization data base, and run a "cron"&lt;BR /&gt;job which automatically sends increasingly&lt;BR /&gt;nasty e-mail messages to "our security group" &lt;BR /&gt;as password expiration dates grow nigh.&lt;BR /&gt;Sometimes a non-technical ("social&lt;BR /&gt;engineering") solution can substitute for a&lt;BR /&gt;technical solution.  (Or, ideally, educate&lt;BR /&gt;"our security group" regarding the benefits&lt;BR /&gt;of a more enlightened policy.)</description>
      <pubDate>Sat, 09 Oct 2010 00:14:14 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/ssh-and-using-authorized-keys-file/m-p/5258283#M52600</guid>
      <dc:creator>Steven Schweda</dc:creator>
      <dc:date>2010-10-09T00:14:14Z</dc:date>
    </item>
    <item>
      <title>Re: ssh and using Authorized Keys File ??</title>
      <link>https://community.hpe.com/t5/operating-system-linux/ssh-and-using-authorized-keys-file/m-p/5258284#M52601</link>
      <description>.</description>
      <pubDate>Thu, 14 Oct 2010 21:05:14 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/ssh-and-using-authorized-keys-file/m-p/5258284#M52601</guid>
      <dc:creator>MikeL_4</dc:creator>
      <dc:date>2010-10-14T21:05:14Z</dc:date>
    </item>
  </channel>
</rss>

