7:14 p.m.
I'm trying to set up amanda using the amaddclient command. That
requires that user amandabackup be able to log into the client machine
using ssh keys.
I've generated the keys on the server machine, copied the public key to
the client machine in /var/lib/amanda/.ssh/authorized_keys
(/var/lib/amanda is amandabackup's home directory). I believe all file
protections are set correctly--they mirror the ones for a regular user.
But ssh fails to use the keys and prompts for a password.
ssh with keys by a normal user works fine. No error messages to be
found in /var/log/secure on the client or with ssh -v on the server.
Any suggestions as to what the difference is and how to fix this would
be welcome.
TIA.
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
8:45 a.m.
New subject: ssh by user amandabackup [SOLVED]
On Sun, 2011-01-02 at 00:14 -0800, Gordon Messmer wrote:
On 01/01/2011 05:14 PM, Matthew Saltzman wrote:
>
> ssh with keys by a normal user works fine. No error messages to be
> found in /var/log/secure on the client or with ssh -v on the server.
Does the output from "ssh -v" indicate that the correct key file is
being offered?
Yes. The relevant lines from ssh -v are
debug1: Next authentication method: publickey
debug1: Offering public key: /var/lib/amanda/.ssh/id_rsa
debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /var/lib/amanda/.ssh/id_dsa
debug1: Next authentication method: password
amandabackup@client's password:
So the key is being offered, but there is no acknowledgment from the
client and no indication of any problem in the client's /var/log/secure.
Aha! In /var/log/messages, on the other hand, this happens:
Jan 2 09:40:36 yankee setroubleshoot: SELinux is preventing /usr/sbin/sshd from
search access on the directory /var/lib/amanda. For complete SELinux messages. run sealert
-l d477003b-6568-4441-95d8-60bda5a6c0e5
Jan 2 09:40:36 yankee setroubleshoot: SELinux is preventing /usr/sbin/sshd from
search access on the directory /var/lib/amanda. For complete SELinux messages. run sealert
-l d477003b-6568-4441-95d8-60bda5a6c0e5
The full SELinux message is
$ sudo sealert -l d477003b-6568-4441-95d8-60bda5a6c0e5
SELinux is preventing /usr/sbin/sshd from search access on the directory
/var/lib/amanda.
***** Plugin catchall (100. confidence) suggests ***************************
If you believe that sshd should be allowed search access on the amanda directory
by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do allow this access for now by executing:
# grep /usr/sbin/sshd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
So I will file the bug.
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
10:36 a.m.
New subject: ssh by user amandabackup [SOLVED]
On Sun, 2011-01-02 at 09:45 -0500, Matthew Saltzman wrote:
On Sun, 2011-01-02 at 00:14 -0800, Gordon Messmer wrote:
> On 01/01/2011 05:14 PM, Matthew Saltzman wrote:
> >
> > ssh with keys by a normal user works fine. No error messages to be
> > found in /var/log/secure on the client or with ssh -v on the server.
>
> Does the output from "ssh -v" indicate that the correct key file is
> being offered?
>
Yes. The relevant lines from ssh -v are
debug1: Next authentication method: publickey
debug1: Offering public key: /var/lib/amanda/.ssh/id_rsa
debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /var/lib/amanda/.ssh/id_dsa
debug1: Next authentication method: password
amandabackup@client's password:
So the key is being offered, but there is no acknowledgment from the
client and no indication of any problem in the client's /var/log/secure.
Aha! In /var/log/messages, on the other hand, this happens:
Jan 2 09:40:36 yankee setroubleshoot: SELinux is preventing /usr/sbin/sshd from
search access on the directory /var/lib/amanda. For complete SELinux messages. run sealert
-l d477003b-6568-4441-95d8-60bda5a6c0e5
Jan 2 09:40:36 yankee setroubleshoot: SELinux is preventing /usr/sbin/sshd from
search access on the directory /var/lib/amanda. For complete SELinux messages. run sealert
-l d477003b-6568-4441-95d8-60bda5a6c0e5
The full SELinux message is
$ sudo sealert -l d477003b-6568-4441-95d8-60bda5a6c0e5
SELinux is preventing /usr/sbin/sshd from search access on the directory
/var/lib/amanda.
***** Plugin catchall (100. confidence) suggests ***************************
If you believe that sshd should be allowed search access on the amanda directory
by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do allow this access for now by executing:
# grep /usr/sbin/sshd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
So I will file the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=666722
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
3:08 a.m.
New subject: ssh by user amandabackup [SOLVED]
On 01/02/2011 06:45 AM, Matthew Saltzman wrote:
Aha! In /var/log/messages, on the other hand, this happens:
Jan 2 09:40:36 yankee setroubleshoot: SELinux is preventing /usr/sbin/sshd from
search access on the directory /var/lib/amanda. For complete SELinux messages. run sealert
-l d477003b-6568-4441-95d8-60bda5a6c0e5
Jan 2 09:40:36 yankee setroubleshoot: SELinux is preventing /usr/sbin/sshd from
search access on the directory /var/lib/amanda. For complete SELinux messages. run sealert
-l d477003b-6568-4441-95d8-60bda5a6c0e5
...
So I will file the bug.
I believe you'll need to fix that like so:
# semanage fcontext -a -t user_home_dir_t /var/lib/amanda
# semanage fcontext -a -t user_home_t "/var/lib/amanda/.*"
# restorecon -r /var/lib/amanda
8:11 a.m.
New subject: ssh by user amandabackup [SOLVED]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/04/2011 04:08 AM, Gordon Messmer wrote:
On 01/02/2011 06:45 AM, Matthew Saltzman wrote:
> Aha! In /var/log/messages, on the other hand, this happens:
>
> Jan 2 09:40:36 yankee setroubleshoot: SELinux is preventing /usr/sbin/sshd
from search access on the directory /var/lib/amanda. For complete SELinux messages. run
sealert -l d477003b-6568-4441-95d8-60bda5a6c0e5
> Jan 2 09:40:36 yankee setroubleshoot: SELinux is preventing /usr/sbin/sshd
from search access on the directory /var/lib/amanda. For complete SELinux messages. run
sealert -l d477003b-6568-4441-95d8-60bda5a6c0e5
...
> So I will file the bug.
I believe you'll need to fix that like so:
# semanage fcontext -a -t user_home_dir_t /var/lib/amanda
# semanage fcontext -a -t user_home_t "/var/lib/amanda/.*"
# restorecon -r /var/lib/amanda
No This would probably cause amanda to break then.
Does labeling .ssh as
ssh_home_t solve the problem?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk0jKqgACgkQrlYvE4MpobMi5ACgs8iR07cwraZoqn97BeioWyFQ
cXoAmweXApHTqeZ5SFcOEf7poTnyMBXV
=pn02
-----END PGP SIGNATURE-----
10:22 a.m.
New subject: ssh by user amandabackup [SOLVED]
On 01/04/2011 06:11 AM, Daniel J Walsh wrote:
On 01/04/2011 04:08 AM, Gordon Messmer wrote:
> # semanage fcontext -a -t user_home_dir_t /var/lib/amanda
> # semanage fcontext -a -t user_home_t "/var/lib/amanda/.*"
> # restorecon -r /var/lib/amanda
No This would probably cause amanda to break then. Does labeling .ssh as
ssh_home_t solve the problem?
That seems unlikely, since the selinux denial was on /var/lib/amanda.
If amanda is restricted, I believe the only option (until the policy is
fixed) is to create a new module:
# setenforce permissive
# tail -n 0 -f /var/log/audit/audit.log > /var/tmp/sshdAmanda.avc
-- Run an amanda backup --
-- Ctrl+c to kill "tail" when the backup is complete --
# audit2allow -M sshdAmanda < /var/tmp/sshdAmanda.avc
# semodule -i sshdAmanda.pp
10:33 a.m.
New subject: ssh by user amandabackup [SOLVED]
On Tue, 2011-01-04 at 09:11 -0500, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/04/2011 04:08 AM, Gordon Messmer wrote:
> On 01/02/2011 06:45 AM, Matthew Saltzman wrote:
>> Aha! In /var/log/messages, on the other hand, this happens:
>>
>> Jan 2 09:40:36 yankee setroubleshoot: SELinux is preventing
/usr/sbin/sshd from search access on the directory /var/lib/amanda. For complete SELinux
messages. run sealert -l d477003b-6568-4441-95d8-60bda5a6c0e5
>> Jan 2 09:40:36 yankee setroubleshoot: SELinux is preventing
/usr/sbin/sshd from search access on the directory /var/lib/amanda. For complete SELinux
messages. run sealert -l d477003b-6568-4441-95d8-60bda5a6c0e5
> ...
>> So I will file the bug.
>
> I believe you'll need to fix that like so:
>
> # semanage fcontext -a -t user_home_dir_t /var/lib/amanda
> # semanage fcontext -a -t user_home_t "/var/lib/amanda/.*"
> # restorecon -r /var/lib/amanda
No This would probably cause amanda to break then. Does labeling .ssh as
ssh_home_t solve the problem?
Now that you mention it, no. (Sorry, I sang your praises a bit too soon
8^).
The messages on the client side (before and after the relabeling):
Jan 4 11:10:06 yankee setroubleshoot: SELinux is
preventing /usr/sbin/sshd from search access on the
directory /var/lib/amanda. For complete SELinux messages. run
sealert -l 90efb757-498d-4a01-bc5a-b117d159ee2d
Jan 4 11:10:06 yankee setroubleshoot: SELinux is
preventing /usr/sbin/sshd from search access on the
directory /var/lib/amanda. For complete SELinux messages. run
sealert -l 90efb757-498d-4a01-bc5a-b117d159ee2d
And the full sealert:
SELinux is preventing /usr/sbin/sshd from search access on the
directory /var/lib/amanda.
***** Plugin catchall (100. confidence) suggests
***************************
If you believe that sshd should be allowed search access on the
amanda directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep /usr/sbin/sshd /var/log/audit/audit.log | audit2allow -M
mypol
# semodule -i mypol.pp
So it looks like /var/lib/amanda is the problem, not the .ssh
subdirectory. /var/lib/amanda's label is:
drwxr-xr-x. amandabackup disk
system_u:object_r:amanda_var_lib_t:s0 /var/lib/amanda/
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
10:45 a.m.
New subject: ssh by user amandabackup [SOLVED]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/04/2011 11:33 AM, Matthew Saltzman wrote:
On Tue, 2011-01-04 at 09:11 -0500, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/04/2011 04:08 AM, Gordon Messmer wrote:
>> On 01/02/2011 06:45 AM, Matthew Saltzman wrote:
>>> Aha! In /var/log/messages, on the other hand, this happens:
>>>
>>> Jan 2 09:40:36 yankee setroubleshoot: SELinux is preventing
/usr/sbin/sshd from search access on the directory /var/lib/amanda. For complete SELinux
messages. run sealert -l d477003b-6568-4441-95d8-60bda5a6c0e5
>>> Jan 2 09:40:36 yankee setroubleshoot: SELinux is preventing
/usr/sbin/sshd from search access on the directory /var/lib/amanda. For complete SELinux
messages. run sealert -l d477003b-6568-4441-95d8-60bda5a6c0e5
>> ...
>>> So I will file the bug.
>>
>> I believe you'll need to fix that like so:
>>
>> # semanage fcontext -a -t user_home_dir_t /var/lib/amanda
>> # semanage fcontext -a -t user_home_t "/var/lib/amanda/.*"
>> # restorecon -r /var/lib/amanda
> No This would probably cause amanda to break then. Does labeling .ssh as
> ssh_home_t solve the problem?
Now that you mention it, no. (Sorry, I sang your praises a bit too soon
8^).
The messages on the client side (before and after the relabeling):
Jan 4 11:10:06 yankee setroubleshoot: SELinux is
preventing /usr/sbin/sshd from search access on the
directory /var/lib/amanda. For complete SELinux messages. run
sealert -l 90efb757-498d-4a01-bc5a-b117d159ee2d
Jan 4 11:10:06 yankee setroubleshoot: SELinux is
preventing /usr/sbin/sshd from search access on the
directory /var/lib/amanda. For complete SELinux messages. run
sealert -l 90efb757-498d-4a01-bc5a-b117d159ee2d
And the full sealert:
SELinux is preventing /usr/sbin/sshd from search access on the
directory /var/lib/amanda.
***** Plugin catchall (100. confidence) suggests
***************************
If you believe that sshd should be allowed search access on the
amanda directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep /usr/sbin/sshd /var/log/audit/audit.log | audit2allow -M
mypol
# semodule -i mypol.pp
So it looks like /var/lib/amanda is the problem, not the .ssh
subdirectory. /var/lib/amanda's label is:
drwxr-xr-x. amandabackup disk
system_u:object_r:amanda_var_lib_t:s0 /var/lib/amanda/
You would need the combination of relabeling the homedir and searching
/var/lib/amanda.
WHich is what we will be adding to policy.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk0jTrgACgkQrlYvE4MpobPRIgCeMQnY139E2M4Ehwt0oeNb9kbH
adMAnjN5W96sF3VGiI3XXZLJi5o+nS+c
=pLpV
-----END PGP SIGNATURE-----
10:54 a.m.
New subject: ssh by user amandabackup [SOLVED]
On Tue, 2011-01-04 at 11:45 -0500, Daniel J Walsh wrote:
You would need the combination of relabeling the homedir and
searching
/var/lib/amanda.
WHich is what we will be adding to policy.
Ah, I don't think that was in your earlier message. If the policy is
published someplace, I'd be happy to test.
One question: How does a regular user's .ssh directory get relabeled?
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
2:19 p.m.
New subject: ssh by user amandabackup [SOLVED]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/04/2011 11:54 AM, Matthew Saltzman wrote:
On Tue, 2011-01-04 at 11:45 -0500, Daniel J Walsh wrote:
> You would need the combination of relabeling the homedir and searching
> /var/lib/amanda.
>
> WHich is what we will be adding to policy.
Ah, I don't think that was in your earlier message. If the policy is
published someplace, I'd be happy to test.
One question: How does a regular user's .ssh directory get relabeled?
Restorecon. Or by transition.
If you use ssh-copy-id, selinux/sshd will created the files with the
correct labeling.
If a user logged into the console via X does mkdir ~/.ssh, restorecond
will watch for the creation of the directory and label it correctly. If
the user does it via ssh/mkdir .ssh, it will be mislabeled, until they
run restorecon on it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk0jgNAACgkQrlYvE4MpobMskQCggIMPvtF5gRVEbEYWaAaAiC70
ZfsAnRkoOoJksZ1tN6cSUdJEnZPjqh0l
=uvqc
-----END PGP SIGNATURE-----
3 p.m.
New subject: ssh by user amandabackup [SOLVED]
On Tue, 2011-01-04 at 15:19 -0500, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/04/2011 11:54 AM, Matthew Saltzman wrote:
> On Tue, 2011-01-04 at 11:45 -0500, Daniel J Walsh wrote:
>> You would need the combination of relabeling the homedir and searching
>> /var/lib/amanda.
>>
>> WHich is what we will be adding to policy.
>
> Ah, I don't think that was in your earlier message. If the policy is
> published someplace, I'd be happy to test.
>
> One question: How does a regular user's .ssh directory get relabeled?
>
Restorecon. Or by transition.
If you use ssh-copy-id, selinux/sshd will created the files with the
correct labeling.
If a user logged into the console via X does mkdir ~/.ssh, restorecond
will watch for the creation of the directory and label it correctly. If
the user does it via ssh/mkdir .ssh, it will be mislabeled, until they
run restorecon on it.
OK Thanks. That provides some insight I didn't have.
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
8:30 a.m.
New subject: ssh by user amandabackup [SOLVED]
On Tue, 2011-01-04 at 01:08 -0800, Gordon Messmer wrote:
On 01/02/2011 06:45 AM, Matthew Saltzman wrote: > Aha! In
/var/log/messages, on the other hand, this happens: > > Jan 2
09:40:36 yankee setroubleshoot: SELinux is preventing /usr/sbin/sshd
from search access on the directory /var/lib/amanda. For complete
SELinux messages. run sealert -l d477003b-6568-4441-95d8-60bda5a6c0e5
> Jan 2 09:40:36 yankee setroubleshoot: SELinux is preventing
/usr/sbin/sshd from search access on the directory /var/lib/amanda. For
complete SELinux messages. run sealert -l
d477003b-6568-4441-95d8-60bda5a6c0e5 ... > So I will file the bug.
I believe you'll need to fix that like so:
# semanage fcontext -a -t user_home_dir_t /var/lib/amanda # semanage
fcontext -a -t user_home_t "/var/lib/amanda/.*" # restorecon -r
/var/lib/amanda
Dan Walsh's suggestion was
chcon -Rt ssh_home_t /var/lib/amanda/.ssh
Should fix the problem.
I haven't tested it yet, but that's the patch he proposed in response
to the bug. He seems to know what he's doing with SELinux 8^).
(Although it isn't transparent--has to be done when the directory is
created.)
Thanks, tho.
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
3:09 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 02/01/2011 02:14, Matthew Saltzman a écrit :
I'm trying to set up amanda using the amaddclient command. That
requires that user amandabackup be able to log into the client machine
using ssh keys.
I've generated the keys on the server machine, copied the public key to
the client machine in /var/lib/amanda/.ssh/authorized_keys
(/var/lib/amanda is amandabackup's home directory). I believe all file
protections are set correctly--they mirror the ones for a regular user.
But ssh fails to use the keys and prompts for a password.
Did you give some permission to selinux?
- --
François Patte
UFR de mathématiques et informatique
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)1 4286 2145
http://www.math-info.univ-paris5.fr/~patte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk0gQNIACgkQdE6C2dhV2JWoXgCaA0qp1ObJDme7QXRTy0FxyaHJ
AkUAnjQWDDCjiJ9LbkOBv7sfJwuJNO61
=/0fS
-----END PGP SIGNATURE-----
10:43 a.m.
On Sun, 2011-01-02 at 10:09 +0100, François Patte wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 02/01/2011 02:14, Matthew Saltzman a crit :
> I'm trying to set up amanda using the amaddclient command. That
> requires that user amandabackup be able to log into the client machine
> using ssh keys.
>
> I've generated the keys on the server machine, copied the public key to
> the client machine in /var/lib/amanda/.ssh/authorized_keys
> (/var/lib/amanda is amandabackup's home directory). I believe all file
> protections are set correctly--they mirror the ones for a regular user.
> But ssh fails to use the keys and prompts for a password.
Did you give some permission to selinux?
No, that turned out to be the problem. (Didn't see the violation in
setroubleshoot because I was doing things remotely.) I think it's a
bug: amandabackup is a normal user with home directory /var/lib/amanda/.
Logging in via ssh should "Just Work (tm)".
- --
Franois Patte
UFR de mathmatiques et informatique
Universit Paris Descartes
45, rue des Saints Pres
F-75270 Paris Cedex 06
Tl. +33 (0)1 4286 2145
http://www.math-info.univ-paris5.fr/~patte
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk0gQNIACgkQdE6C2dhV2JWoXgCaA0qp1ObJDme7QXRTy0FxyaHJ
AkUAnjQWDDCjiJ9LbkOBv7sfJwuJNO61
=/0fS
-----END PGP SIGNATURE-----
4:33 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/02/2011 11:43 AM, Matthew Saltzman wrote:
On Sun, 2011-01-02 at 10:09 +0100, François Patte wrote:
Le 02/01/2011 02:14, Matthew Saltzman a crit :
>>> I'm trying to set up amanda using the amaddclient command. That
>>> requires that user amandabackup be able to log into the client machine
>>> using ssh keys.
>>>
>>> I've generated the keys on the server machine, copied the public key to
>>> the client machine in /var/lib/amanda/.ssh/authorized_keys
>>> (/var/lib/amanda is amandabackup's home directory). I believe all file
>>> protections are set correctly--they mirror the ones for a regular user.
>>> But ssh fails to use the keys and prompts for a password.
Did you give some permission to selinux?
> No, that turned out to be the problem. (Didn't see the violation in
> setroubleshoot because I was doing things remotely.) I think it's a
> bug: amandabackup is a normal user with home directory /var/lib/amanda/.
> Logging in via ssh should "Just Work (tm)".
>
chcon -Rt ssh_home_t /var/lib/amanda/.ssh
Should fix the problem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk0iTr4ACgkQrlYvE4MpobP+4wCfZg098r3tzKUbmORHuWPuqdtS
+n4Anii4B0mKqnbK7bC6Rl4y+lklGI58
=WI2T
-----END PGP SIGNATURE-----
4885
days inactive
4887
days old
15 comments
4 participants
participants (4)
-
Daniel J Walsh -
François Patte -
Gordon Messmer -
Matthew Saltzman