setting up ssh keys to copy between desktop to freenas

[Andy Botterill]

I am currently using an external usb drive as my backup.
I want to use a nasbox instead of the external usb drive.
I bought a proliant microserver and put freenas on it.
I have copied the desktop directories to the nasbox using rsync.

I want to run the rsync without typing in a password.
The answer is (I believe) using an ssh key.

On my desktop I usually run the rsync commands as root.
The freenas software has a root login but it has a read-only filesystem.
So I cannot copy the ssh keys to the .ssh directory.

I have a general (unprivileged) user andy on the freenas system.
andy (my) personal directory is writeable.

Can ssh allow an unprivileged user andy to become root on another system?

If so how do I do this.

Thanks for your help. Andy

[Chris Davies]

Andy Botterill <an...@plymouth2.demon.co.uk> wrote:
> I bought a proliant microserver and put freenas on it.

> I want to run the rsync without typing in a password.
> The answer is (I believe) using an ssh key.

That's the usual option, but you could use the (unencrypted) rsync
protocol itself.

> On my desktop I usually run the rsync commands as root.
> The freenas software has a root login but it has a read-only filesystem.
> So I cannot copy the ssh keys to the .ssh directory.

> If so how do I do this.

The first half-dozen or so hits on google for "freenas ssh rsync" seem
to address the kind of issues you're trying to resolve. Have you looked
at any of these?

Chris

[Andy Botterill]

On 07/08/2012 02:05 PM, Chris Davies wrote:
> Andy Botterill <an...@plymouth2.demon.co.uk> wrote:
>> I bought a proliant microserver and put freenas on it.
>
>> I want to run the rsync without typing in a password.
>> The answer is (I believe) using an ssh key.
>
> That's the usual option, but you could use the (unencrypted) rsync
> protocol itself.

I didn't know that exists.

>
>
>> On my desktop I usually run the rsync commands as root.
>> The freenas software has a root login but it has a read-only filesystem.
>> So I cannot copy the ssh keys to the .ssh directory.
>
>> If so how do I do this.
>
> The first half-dozen or so hits on google for "freenas ssh rsync" seem
> to address the kind of issues you're trying to resolve. Have you looked
> at any of these?

I tried 2 and I got problems.

For example:-http://www.rsync.net/resources/howto/freenas_integration.html
Says to run the ssh-keygen -q -t rsa -f /root/.ssh/id_rsa-N ""
command on the console. The root login area is read only.

So can I use a non-privileged account (that has a writable login
directory) to create an ssh key? Do I then copy that key to the same
account on my desktop or to /root?

Do ssh keys go from root->root or root->somebody else?


>
> Chris
>

[J G Miller]

On Sunday, July 8th, 2012, at 14:51:30h +0100, Andy Botterill declared:

> The root login area is read only.

To non-root users.

So login as root and generate the keys as root.

And is it not better (more secure) to use dsa keys?

ssh-keygen -t dsa

[Andy Botterill]

Using the console plugged into the nasbox (assuming that that is root) I
cannot write to the local directory.

I wrote the key to /tmp/.ssh/ directory.
I then copied the key into the key place for the root login in the
freenas gui.

After that I get the /root/.ssh/ directory. The known_hosts file is
different to my desktop. What is it supposed to contain?

I then copied the key to my desktop in the file /root/.ssh/authorized_key

So both the nasbox and the desktop have the same key. Is this the right
way of doing it?

At the moment I get no more complaints (about RSA key fingerprint) when
using ssh. I still have to type in a password.

Once I have automated backups I'm willing to look at extra security. All
of my network is using LAN cable.

I think that I have the same key for the desktop and the nasbox. What do
I need to next?

The key ends with ro...@freenas.local. My hosts file has it as nasbox.
Should the hosts file use freenas.local?

I don't really understand this process. Thanks for your help.
>
>
>

[Richard Kettlewell]

J G Miller <mil...@yoyo.ORG> writes:
> Andy Botterill declared:

>> The root login area is read only.
>
> To non-root users.
>
> So login as root and generate the keys as root.
>
> And is it not better (more secure) to use dsa keys?
>
> ssh-keygen -t dsa

Is it? NIST suggest (in SP800-57) that RSA and DSA keys of comparable
size provide comparable security.

This assumes correct implementation, of course, which isn't a given; for
example DSA and ECDSA have both seen relatively recent high profile
implementation errors that allowed private keys to be recovered from
signatures.

--
http://www.greenend.org.uk/rjk/

[J G Miller]

On Sunday, July 8th, 2012, at 19:04:26 +0100, Richard Kettlewell asked:

> Is it?

That is why I asked.

According to one source the choice of DSA versus RSA on the client
side makes little difference, but

QUOTE

On the server, a DSA key is preferred, because then the key exchange
will use a transient Diffie-Hellman key, which opens the road for
"Perfect Forward Secrecy" (i.e. if a bad guy steals the server
private key, he still cannot decrypt past connections that he
would have recorded).

UNQUOTE

Is that incorrect?

There is of course the issue that the only size of DSA
in the ssh implementation is 1024 where RSA keys of size
larger than 1024 can be used.

ssh-keygen -b 2048 -t dsa
DSA keys must be 1024 bits

ssh-keygen -b 4096 -t rsa
Generating public/private rsa key pair.

[Richard Kettlewell]

J G Miller <mil...@yoyo.ORG> writes:

> That is why I asked.
>
> According to one source the choice of DSA versus RSA on the client
> side makes little difference, but
>
> QUOTE
>
> On the server, a DSA key is preferred, because then the key exchange
> will use a transient Diffie-Hellman key, which opens the road for
> "Perfect Forward Secrecy" (i.e. if a bad guy steals the server
> private key, he still cannot decrypt past connections that he
> would have recorded).
>
> UNQUOTE
>
> Is that incorrect?

I suspect it's talking about SSH v1, though without context it's hard to
be sure.

The base SSH RFC only offers DH key exchange mechanisms, and there's
nothing inherent to RSA that stops them from being used. (How could
it?) If you prefer empiricism, 'ssh -v' reveals that indeed it uses DH
kx even when both client and host key are RSA.

--
http://www.greenend.org.uk/rjk/

[Chris Davies]

Andy Botterill <an...@plymouth2.demon.co.uk> wrote:
> For example:-http://www.rsync.net/resources/howto/freenas_integration.html
> Says to run the ssh-keygen -q -t rsa -f /root/.ssh/id_rsa-N ""
> command on the console. The root login area is read only.

This is what puzzled me. I saw in your first post that your root login
is on a read-only filesystem, yet the docs for FreeNAS suggest it should
be otherwise.

Can you create a new administrative user account but with UID 0?

Chris

[Nigel Wade]

On 08/07/12 17:08, Andy Botterill wrote:
> On 07/08/2012 04:30 PM, J G Miller wrote:
>> On Sunday, July 8th, 2012, at 14:51:30h +0100, Andy Botterill declared:
>>
>>> The root login area is read only.
>>
>> To non-root users.
>>
>> So login as root and generate the keys as root.
>>
>> And is it not better (more secure) to use dsa keys?
>>
>> ssh-keygen -t dsa
>
> Using the console plugged into the nasbox (assuming that that is root) I
> cannot write to the local directory.

Which way are you performing the ssh/rsync? That's very important.

In public/private key authentication, the private key is kept by the
client (the end initiating the ssh connection). The public key resides
on the recipient "server". The private key should normally be in the
.ssh directory. The .ssh directory, and the key, must be
readable/writeable only by the owner of the key.

>
> I wrote the key to /tmp/.ssh/ directory.
> I then copied the key into the key place for the root login in the
> freenas gui.
>

Which key did you copy (public/private), and where did you put it?

> After that I get the /root/.ssh/ directory. The known_hosts file is
> different to my desktop. What is it supposed to contain?

A list of known hosts, and their respective keys (not the user ssh keys,
the host keys). ssh requires that the host be identified by a key to
avoid spoofing of host/user. Normally, when you first connect to a
machine ssh, and ssh receives a key it does not have stored, it will
prompt you as to whether you want to accept the key as valid. If you
accept it ssh will store the key in known_hosts. There is also a system
wide file, probably in /etc/ssh/ssh_known_hosts where host keys can be
stored so every user doesn't have to accept keys for well known hosts.

>
> I then copied the key to my desktop in the file /root/.ssh/authorized_key

There should be an "s" on the end of that file. What version of ssh is
FreeNAS using? There's also an authorized_keys2 file which openssh uses
for SSH v2.

>
> So both the nasbox and the desktop have the same key. Is this the right
> way of doing it?

No, the initiating end ("client") should have the private key (and
normally the public key as well). The receiving end ("server") should
ONLY have the public key. The private key on the server would be the
private key of the user on that machine, not the private key of the user
on the client machine. You never, ever, send your private key to any
other machine.

So, which file goes where depends on whether you want to initiate the
rsync on the NAS or the desktop, and what user accounts you want to use
at either end.

The normal ssh public/private key setup is as follows.

On the client (the end which initiates the connection, and requires
authentication on the server) run ssh-keygen to create a public/private
key pair. Don't enter a password when prompted, or you'll have to enter
this password to decrypt the private key when you use it (unless you
setup some kind of key escrow agent such as ssh-agent). The keys will
be, by default, written in the user's .ssh directory unless you specify
an alternate output file on the ssh-keygen command.

The account which is used to initiate the connection requires the
private key (id_rsa or id_dsa) in its .ssh directory. The account which
is accepting the connection on the remote end requires the public key in
its .ssh/authorized_keys file. On both sides the .ssh directory, and the
files within it, must only be readable or writeable by the account
holder. Copy the PRIVATE key to the .ssh folder of the account which
will initiate the remote connection. If you created the keys as that
user, with the default output, then it will already be there.

Copy the PUBLIC key to the remote user account, preferably to some
location other than .ssh (you can delete this file when it's been added
to the authorized keys file). Append the contents of the public key to
the .ssh authorized keys file. Depending on the type/version of ssh on
the server this file is variously known as authorirized_keys (SSH-1,
OpenSSH), authorized_keys2 (OpenSSH using SSH v2) or in the unlikely
event that the server is using SSH2 then .ssh2/authorization. The same
permission restriction applies to this file/folder as on the server. The
.ssh/ssh2 directory and authorized keys file must be owned by, and only
readable/writeable, by the owner.

If you want to perform an authenticated rsync, as root, from the NAS box
to your desktop, then the root account on the NAS box requires the
private key file in root's .ssh directory. FreeNAS uses a ram disk, so
you can't just put files in root's home directory or they won't be there
next time you re-boot. That's why you have to add the key using the GUI.
The remote account on your desktop requires the public key in its
.ssh/authorized_keys file.

--
Nigel Wade

[Geoff Clements]

ssh-copy-id is useful for automating this step, see:
http://www.debian-administration.org/articles/152

--
Geoff

[Geoff Clements]

On Sunday, July 8, 2012 10:07:24 AM UTC+1, Andy Botterill wrote:
> I want to run the rsync without typing in a password.
> The answer is (I believe) using an ssh key.

If you don't mind the rsync session being unencrypted and you are scripting the commands rather than running from an interactive session then you can get the client rsync to use a password by doing something like:

RSYNC_PASSWORD=<password> rsync ...

or

export RSYNC_PASSWORD=<password>
rsync ...

--
Geoff

[Andy Botterill]

It's a bit late for me now. I'll give this (and all the others) another
try tomorrow. Thanking you all andy

[Nigel Wade]

That's useful to know. The O'Reilly "snail" book I use for ssh doesn't
mention that particular tool.

[Nix]

On 9 Jul 2012, Nigel Wade verbalised:

> On 08/07/12 17:08, Andy Botterill wrote:
>> So both the nasbox and the desktop have the same key. Is this the right
>> way of doing it?
>
> No, the initiating end ("client") should have the private key (and
> normally the public key as well). The receiving end ("server") should
> ONLY have the public key. The private key on the server would be the
> private key of the user on that machine, not the private key of the
> user on the client machine. You never, ever, send your private key to
> any other machine.

Well, the server will *work* if it has both keys. It just doesn't need
the private key. It's fine to provide the private key to machines within
the same security domain -- e.g. the major machines on my local net
share their home directories over NFS, and these all naturally have
access to both public and private SSH keys, because if you have access
to one of them you have access to all anyway.

You can figure out which key belongs on the server from the first
principles quite easily. The public key is not a secret: it can be
written on a postcard or published in a newspaper without a secuity
risk. If it was the key at the client end, this would be horrible
because anyone who grabbed that key could pretend to be you and log in
to any systems you could log in to with that key. Thus, it must be the
other way around: anyone who grabs that key can do nothing with it
except let *you* into their systems.

(I can never remember which way around it goes, so I have to run through
this reasoning quite frequently!)

>The .ssh/ssh2 directory and authorized keys file must be owned by, and
>only readable/writeable, by the owner.

Further, no parent directories may be group-writable, right up to the
root. This is to stop other members of the same group mv'ing directories
out of the way and introducing their own .ssh directory. (Annoyingly, if
you get this wrong there is no diagnostic about it on either the server
or the client end. The connection is just refused.)

--
NULL && (void)

[Andy Botterill]

On 07/09/2012 01:13 PM, Nigel Wade wrote:
> On 08/07/12 17:08, Andy Botterill wrote:
>> On 07/08/2012 04:30 PM, J G Miller wrote:
>>> On Sunday, July 8th, 2012, at 14:51:30h +0100, Andy Botterill declared:
>>>
>>>> The root login area is read only.
>>>
>>> To non-root users.
>>>
>>> So login as root and generate the keys as root.
>>>
>>> And is it not better (more secure) to use dsa keys?
>>>
>>> ssh-keygen -t dsa
>>
>> Using the console plugged into the nasbox (assuming that that is root) I
>> cannot write to the local directory.
>
> Which way are you performing the ssh/rsync? That's very important.
>
> In public/private key authentication, the private key is kept by the
> client (the end initiating the ssh connection). The public key resides
> on the recipient "server". The private key should normally be in the

> ..ssh directory. The .ssh directory, and the key, must be

> readable/writeable only by the owner of the key.
>
>>
>> I wrote the key to /tmp/.ssh/ directory.
>> I then copied the key into the key place for the root login in the
>> freenas gui.
>>
>
> Which key did you copy (public/private), and where did you put it?

I had another search around and found a website that gave me a more
obvious way of doing things. Once I followed this it just works.

Using root on orac3.
ssh-keygen -t rsa
cat ~/.ssh/id_rsa.pub | ssh root@nasbox 'cat >> ~/.ssh/authorized_keys'

Using root on nasbox.
ssh-keygen -t rsa
cat ~/.ssh/id_rsa.pub | ssh root@orac3 'cat >> ~/.ssh/authorized_keys'
ssh orac3

ssh is working in both directions. Yeehah.

I also did not use the web gui thing to update the root key. Command
line is so much easier.

Thanks gents I was pulling my hair out. Andy