Re: authorized_keys and security(8)

[Tyler]

On 4/24/2012 12:54 PM, Stefan Johnson wrote:



On Tue, Apr 24, 2012 at 2:24 PM, Tyler mailto:disc...@gmail.com>> wrote:

Hi,

Is there a way to create logins that are only accessed via
authorized_keys so that security(8) doesn't complain about them
every day?

The general goal is to disable remote root login via SSH and allow
an unprivileged "admin" user access via key files and pass phrases
(and then sudo or su).

My problem is security(8) complains about this every day:

"Login admin is off but still has a valid shell and alternate access
files in home directory are still readable."

Which, taking a look at the newly rewritten /usr/libexec/security
script, is a result of the .ssh files existing and being readable by
anyone:

  or check_access_file "$home/.$_", $name
foreach qw(ssh rhosts shosts klogin);

and:

  nag $mode & (S_IRUSR | S_IRGRP | S_IROTH) && ! -O $filename,

It seems to me I need to learn how to make these types of logins in
such a way that security(8) doesn't whine about them; or, if that is
not possible, I will write a patch for /usr/libexec/security that
works the way I want it to and post it.

Thanks all,
Tyler


The recommended permissions of the .ssh directory for each user is 700.
What are the permissions you are using?  It sounds like it might be
something like 755 (which means world and group readable, not just user
readable.)  The directory has to be at least read and execute capable
for the user that owns it in order to use the files within it, and the
write bit should be set for accepting keys when logging on to a new
system.  This is why the '7' is recommended.


The .ssh directory is 700. I even locked down the .ssh directory files 
from 644 to 640 (ie: known_hosts and id_rsa.pub) in hopes of silencing 
the message.


The check in the security(8) script in based on the current user running 
it, which looks like root when ran via cron.daily, who would have 
S_IRUSR no matter what I did to the perms.


/home/pfcopy as 755 is default as far as I know.

root@border2-bellevue:/home# ls -laR admin/
total 40
drwxr-xr-x  3 admin  admin  512 Mar 14 17:42 .
drwxr-xr-x  3 rootwheel   512 Aug 17  2011 ..
-rw-r--r--  1 admin  admin   22 Mar 14 17:25 .Xdefaults
-rw-r--r--  1 admin  admin  773 Mar 14 17:25 .cshrc
-rw-r--r--  1 admin  admin   21 Mar 14 17:40 .forward
-rw-r--r--  1 admin  admin  398 Mar 14 17:25 .login
-rw-r--r--  1 admin  admin  113 Mar 14 17:25 .mailrc
-rw-r--r--  1 admin  admin  218 Mar 14 17:25 .profile
drwx--  2 admin  admin  512 Mar 14 17:26 .ssh
-rwxr-xr-x  1 rootwheel   335 Mar 14 17:39 admin.sh

admin/.ssh:
total 24
drwx--  2 admin  admin   512 Mar 14 17:26 .
drwxr-xr-x  3 admin  admin   512 Mar 14 17:42 ..
-rw---  1 admin  admin   415 Mar 14 17:27 authorized_keys
-rw---  1 admin  admin  1651 Mar 14 17:25 id_rsa
-rw-r-  1 admin  admin   415 Mar 14 17:25 id_rsa.pub
-rw-r-  1 admin  admin   192 Mar 14 17:26 known_hosts
root@border2-bellevue:/home# ls -lad admin/
drwxr-xr-x  3 admin  admin  512 Mar 14 17:42 admin/

root@border2-bellevue:/home# uname -a
OpenBSD border2-bellevue.tradetech.net 5.0 GENERIC.MP#63 amd64

Re: authorized_keys and security(8)

[Stuart Henderson]

On 2012-04-24, Tyler  wrote:
> Hi,
>
> Is there a way to create logins that are only accessed via 
> authorized_keys so that security(8) doesn't complain about them every day?
>
> The general goal is to disable remote root login via SSH and allow an 
> unprivileged "admin" user access via key files and pass phrases (and 
> then sudo or su).
>
> My problem is security(8) complains about this every day:
>
> "Login admin is off but still has a valid shell and alternate access 
> files in home directory are still readable."

vipw and set the crypted password to 13 *'s. pretty sure the old
/etc/security script did the same thing in this respect.

Re: authorized_keys and security(8)

[Tyler Morgan]

On 4/25/2012 5:11 PM, Stuart Henderson wrote:

On 2012-04-24, Tyler  wrote:

Hi,

Is there a way to create logins that are only accessed via
authorized_keys so that security(8) doesn't complain about them every day?

The general goal is to disable remote root login via SSH and allow an
unprivileged "admin" user access via key files and pass phrases (and
then sudo or su).

My problem is security(8) complains about this every day:

"Login admin is off but still has a valid shell and alternate access
files in home directory are still readable."

vipw and set the crypted password to 13 *'s. pretty sure the old
/etc/security script did the same thing in this respect.



Thanks for the help.

This worked -- security is no longer whining about the accounts -- and I 
found the proper documentation in passwd(5).


--

Re: authorized_keys and security(8)

[Mike Erdely]

On Thu, May 3, 2012 at 2:16 PM, Tyler Morgan  wrote:
> On 4/25/2012 5:11 PM, Stuart Henderson wrote:
>> On 2012-04-24, Tyler  wrote:
>>> My problem is security(8) complains about this every day:
>>> "Login admin is off but still has a valid shell and alternate access
>>> files in home directory are still readable."
>>
>> vipw and set the crypted password to 13 *'s. pretty sure the old
>> /etc/security script did the same thing in this respect.
>
> Thanks for the help.
>
> This worked -- security is no longer whining about the accounts -- and I
> found the proper documentation in passwd(5).

FYI: For a test, I added "foo" with useradd(8) and "bar" with adduser(8):
# grep -E "(foo|bar)" /etc/master.passwd
foo:*:1002:1002::0:0::/home/foo:/bin/ksh
bar:*:1003:1003::0:0:bar:/home/bar:/bin/ksh

Looks like useradd does the right thing and adduser does not.

-ME

Re: authorized_keys and security(8)

[Mike Erdely]

On Thu, May 03, 2012 at 02:48:14PM -0400, Mike Erdely wrote:
> FYI: For a test, I added "foo" with useradd(8) and "bar" with adduser(8):
> # grep -E "(foo|bar)" /etc/master.passwd
> foo:*:1002:1002::0:0::/home/foo:/bin/ksh
> bar:*:1003:1003::0:0:bar:/home/bar:/bin/ksh
> 
> Looks like useradd does the right thing and adduser does not.

With the diff below I added baz:
foo:*:1002:1002::0:0::/home/foo:/bin/ksh
bar:*:1003:1003::0:0:bar:/home/bar:/bin/ksh
baz:*:1004:1004::0:0:baz:/home/baz:/bin/ksh

ok?

Index: adduser.perl
===
RCS file: /cvs/src/usr.sbin/adduser/adduser.perl,v
retrieving revision 1.58
diff -u -p -r1.58 adduser.perl
--- adduser.perl22 Sep 2011 10:59:23 -  1.58
+++ adduser.perl3 May 2012 19:00:17 -
@@ -800,7 +800,7 @@ sub new_users {
if (&new_users_ok) {
$new_users_ok = 1;
 
-   $cryptpwd = "*";# Locked by default
+   $cryptpwd = "*";# Locked by default
$cryptpwd = encrypt($password, &salt) if ($password ne "");
$log_cl = "" if ($log_cl eq "default");

Re: authorized_keys and security(8)

[Alexander Hall]

On 05/03/12 21:05, Mike Erdely wrote:

On Thu, May 03, 2012 at 02:48:14PM -0400, Mike Erdely wrote:

FYI: For a test, I added "foo" with useradd(8) and "bar" with adduser(8):
# grep -E "(foo|bar)" /etc/master.passwd
foo:*:1002:1002::0:0::/home/foo:/bin/ksh
bar:*:1003:1003::0:0:bar:/home/bar:/bin/ksh

Looks like useradd does the right thing and adduser does not.


With the diff below I added baz:
foo:*:1002:1002::0:0::/home/foo:/bin/ksh
bar:*:1003:1003::0:0:bar:/home/bar:/bin/ksh
baz:*:1004:1004::0:0:baz:/home/baz:/bin/ksh

ok?


I'm not sure about this. The check in security is there for a reason. If 
you want to bypass it, it might be better to have to do it manually.


The inconsistancy is annoying though, as is the "*"-trick, 
which I believe is merely a way to make it seem like a password while it 
is not.


/Alexander

Re: authorized_keys and security(8)

[Mike Erdely]

On Thu, May 3, 2012 at 5:43 PM, Alexander Hall  wrote:
> I'm not sure about this. The check in security is there for a reason. If you
> want to bypass it, it might be better to have to do it manually.
>
> The inconsistancy is annoying though, as is the "*"-trick, which
> I believe is merely a way to make it seem like a password while it is not.

I see two separate issues.
1. The two ways to add users are inconsistent.
2. The security script may not be doing what it's supposed to if the
password is "*".

So, I think either my diff should go in or we should change useradd.
And/or maybe the security script should bitch if your password is
"*".

-ME

Re: authorized_keys and security(8)

[Alexander Hall]

On 05/04/12 00:06, Mike Erdely wrote:

On Thu, May 3, 2012 at 5:43 PM, Alexander Hall  wrote:

I'm not sure about this. The check in security is there for a reason. If you
want to bypass it, it might be better to have to do it manually.

The inconsistancy is annoying though, as is the "*"-trick, which
I believe is merely a way to make it seem like a password while it is not.


I see two separate issues.
1. The two ways to add users are inconsistent.
2. The security script may not be doing what it's supposed to if the
password is "*".

So, I think either my diff should go in or we should change useradd.


I bet there are more inconsistencies, and I don't know which one is 
right, if anyone.



And/or maybe the security script should bitch if your password is
"*".


A few years ago diffs (or at least discussions) allowing

"*" word "*"

(e.g. "*SSH*" or "*NOPASSWORD*"), as a more controlled '*'. 
In the end I don't think it went anywhere, but I'd rather see that.


/Alexander

Re: authorized_keys and security(8)

[Alexander Hall]

Alexander Hall  wrote:

>On 05/04/12 00:06, Mike Erdely wrote:
>> On Thu, May 3, 2012 at 5:43 PM, Alexander Hall 
>wrote:
>>> I'm not sure about this. The check in security is there for a
>reason. If you
>>> want to bypass it, it might be better to have to do it manually.
>>>
>>> The inconsistancy is annoying though, as is the
>"*"-trick, which
>>> I believe is merely a way to make it seem like a password while it
>is not.
>>
>> I see two separate issues.
>> 1. The two ways to add users are inconsistent.
>> 2. The security script may not be doing what it's supposed to if the
>> password is "*".
>>
>> So, I think either my diff should go in or we should change useradd.
>
>I bet there are more inconsistencies, and I don't know which one is 
>right, if anyone.
>
>> And/or maybe the security script should bitch if your password is
>> "*".
>
>A few years ago diffs (or at least discussions) allowing
>
>   "*" word "*"
>
>(e.g. "*SSH*" or "*NOPASSWORD*"), as a more controlled '*'.

...were discussed.

>
>In the end I don't think it went anywhere, but I'd rather see that.

i.e. that security accepted /^\*.*\*$/ as a password for accounts with a valid 
shell.

We probably don't want to rule out *.

>
>/Alexander

Re: authorized_keys and security(8)

[Chris Cappuccio]

Mike Erdely [m...@erdelynet.com] wrote:
> 
> FYI: For a test, I added "foo" with useradd(8) and "bar" with adduser(8):
> # grep -E "(foo|bar)" /etc/master.passwd
> foo:*:1002:1002::0:0::/home/foo:/bin/ksh
> bar:*:1003:1003::0:0:bar:/home/bar:/bin/ksh
> 
> Looks like useradd does the right thing and adduser does not.

Maybe I missed the memo. When did thirteen asterisks start to mean anything 
different than the single traditional asterisk? sshd/login tries to hash 
against it but not * ?

Re: authorized_keys and security(8)

[Tyler Morgan]

On 5/3/2012 9:31 PM, Chris Cappuccio wrote:

Mike Erdely [m...@erdelynet.com] wrote:

FYI: For a test, I added "foo" with useradd(8) and "bar" with adduser(8):
# grep -E "(foo|bar)" /etc/master.passwd
foo:*:1002:1002::0:0::/home/foo:/bin/ksh
bar:*:1003:1003::0:0:bar:/home/bar:/bin/ksh

Looks like useradd does the right thing and adduser does not.

Maybe I missed the memo. When did thirteen asterisks start to mean anything 
different than the single traditional asterisk? sshd/login tries to hash 
against it but not * ?



For my specific case, it means something different to 
/usr/libexec/security's daily run, and Mike Erdely pointed out adduser 
and useradd have inconsistent behavior regarding the passwd file, which 
was probably the root of my original confusion.


"Note that
 there is nothing special about `*', it is just one of many characters
 that cannot occur in a valid encrypted password (see crypt(3)).
 Similarly, login accounts not allowing password authentication but
 allowing other authentication methods, for example public key
 authentication, conventionally have 13 asterisks in the password 
field."


http://www.openbsd.org/cgi-bin/man.cgi?query=passwd&apropos=0&sektion=5&manpath=OpenBSD+Current&arch=i386&format=html 



--

Re: authorized_keys and security(8)

[Ingo Schwarze]

Hi Chris,

Chris Cappuccio wrote on Thu, May 03, 2012 at 09:31:55PM -0700:
> Mike Erdely [m...@erdelynet.com] wrote:

>> FYI: For a test, I added "foo" with useradd(8) and "bar" with adduser(8):
>> # grep -E "(foo|bar)" /etc/master.passwd
>> foo:*:1002:1002::0:0::/home/foo:/bin/ksh
>> bar:*:1003:1003::0:0:bar:/home/bar:/bin/ksh
>> 
>> Looks like useradd does the right thing and adduser does not.

> When did thirteen asterisks start to mean anything different
> than the single traditional asterisk?

On March 31, 1992, when Keith Bostic first implemented
counting the characters in the password hash field in 
in etc/security SCCS diff 5.14.

Here is Keith's original implementation:

  echo "Checking for turned-off accounts with valid shells:"
  awk -F: "length(\$2) != 13 && \$10 ~ /.*sh$/ \
  { print \"user \" \$1 \" account turned off with valid shell.\" }" \
  /etc/master.passwd

Yours,
  Ingo