1 |
----- Original Message ---- |
2 |
|
3 |
> From: "covici@××××××××××.com" <covici@××××××××××.com> |
4 |
> To: gentoo-user@l.g.o |
5 |
> Sent: Thu, October 7, 2010 6:21:15 PM |
6 |
> Subject: Re: [gentoo-user] Copying a file via ssh with no password, keeping the |
7 |
>system safe |
8 |
> |
9 |
> Momesso Andrea <momesso.andrea@×××××.com> wrote: |
10 |
> |
11 |
> > |
12 |
> > Quoting Andrea Conti <alyf@××××.net>: |
13 |
> > |
14 |
> > > On 07/10/2010 18:45, Momesso Andrea wrote: |
15 |
> > > |
16 |
> > >> Setting up a public key, would do the job, but then, all the connections |
17 |
> > >> between the servers would be passwordless, so if server A gets |
18 |
> > >> compromised, also server B is screwed. |
19 |
> > > |
20 |
> > > Well, not really... public key authentication works on a per-user basis, |
21 |
> > > so all you get is that some user with a specific key can log in as some |
22 |
> > > other user of B without typing a password. |
23 |
> > > |
24 |
> > > Of course, if you authorize a given key for logging in as root@B, then |
25 |
> > > what you said is true. But that is a problem with the specific setup. |
26 |
> > > |
27 |
> > >> Is there a way to allow only one single command from a single cronjob to |
28 |
> > >> operate passwordless, while keeping all the other connections secured by |
29 |
> > >> a password? |
30 |
> > > |
31 |
> > > You can't do that on a per-command basis. You'd be trying to control the |
32 |
> > > authentication method accepted by sshd on B according to which command |
33 |
> > > is run on A -- something sshd on B knows nothing about. |
34 |
> > > |
35 |
> > > I would try the following way: |
36 |
> > > |
37 |
> > > - Set up an unprivileged user on B -- let's call it foo -- which can |
38 |
> > > only write to its own home directory, /home/foo. |
39 |
> > > |
40 |
> > > - add the public key you will be using (*) to foo@B's authorized_keys |
41 |
> > > file. You should set the key's options to |
42 |
> > > 'pattern="<address_of_A>",no-pty,command="/usr/bin/scp -t -- /home/foo"' |
43 |
> > > (man sshd for details). |
44 |
> > > |
45 |
> > > - chattr +i /home/foo/.ssh/authorized_keys, so that the file can only be |
46 |
> > > changed by a superuser (you can't just chown the file to root as sshd is |
47 |
> > > quite anal about the permissions of the authorized_keys file) |
48 |
> > > |
49 |
> > > Now your cron job on A can do "scp <file> foo@B:/home/foo" without the |
50 |
> > > need for entering a password; you just have to set up another cron job |
51 |
> > > on B that picks up the file from /home/foo and puts it where it should |
52 |
> > > go with the correct permissions, possibly after doing a sanity check on |
53 |
> > > its contents. |
54 |
> > > |
55 |
> > > If you use something else than scp, (e.g. rsync) you should also adjust |
56 |
> > > the command option in the key options above. |
57 |
> > > Note that the option refers to what is run on B, not on A. Also, it is |
58 |
> > > *not* an authorization directive à la /etc/sudoers (i.e., it does not |
59 |
> > > specify what commands the user is allowed to run): it simply overwrites |
60 |
> > > whichever command is requested by the client side of the ssh connection, |
61 |
> > > so that, for example, the client cannot request a shell or do "cat |
62 |
> > > <somefile>". |
63 |
> > > |
64 |
> > > (*) You can either use the key of the user running the cron job on A, or |
65 |
> > > generate a separate key which is only used for the copy operation. In |
66 |
> > > this case, you will need to tell scp the location of the private key |
67 |
> > > file with the -i option. |
68 |
> > > |
69 |
> > > HTH, |
70 |
> > > andrea |
71 |
> > > |
72 |
> > > |
73 |
> > |
74 |
> > Thank you all for your fast replies, I think I'll use all of your |
75 |
>suggestions: |
76 |
> > |
77 |
> > -create an unprivilegied user with no shell access as Stroller and |
78 |
> > Andrea suggested |
79 |
> > |
80 |
> > -I'll setup a passwordless key for this user, only limited to a single |
81 |
> > command, as Willie |
82 |
> > suggested |
83 |
> > |
84 |
> > This sounds pretty sane to me. |
85 |
> I think for ssh to work the user needs a valid shell, not nologin, so |
86 |
> you can't do both of those suggestions.] |
87 |
|
88 |
Wouldn't a shell-less account per just provide the ability to use SFTP/SCP? |
89 |
Those don't require a shell to operate. |
90 |
|
91 |
You only need a shell if you are going to actually login as a user and do |
92 |
something other than a file transfer. |
93 |
|
94 |
Also, ssh can be run in multiple modes - some of which do not require a shell; |
95 |
for example: |
96 |
|
97 |
ssh someuser@××××××.com /bin/false |
98 |
|
99 |
will run the command "/bin/false" without initiating a shell. (man ssh for |
100 |
details). |
101 |
|
102 |
$0.02 |
103 |
|
104 |
Ben |