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.
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.
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-60bda5a6c0e5The 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.ppSo I will file the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=666722
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
-----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?
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
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/
-----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-b117d159ee2dAnd 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.ppSo 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.
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?
-----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.
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.
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.
-----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
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 -----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-----
-----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.
-
Daniel J Walsh -
François Patte -
Gordon Messmer -
Matthew Saltzman