Hi,
Kenneth L. Owen wrote on 2008-12-03 13:19:30 -0500 [Re: [BackupPC-users] I
broke perfection ...]:
> [...]
> 1. Before I started setting up pass-phraseless keys for BackupPC, I had
> already created ssh keys that would allow me to log in remotely between the
> two Linux workstations as normal user 'ken'. Root logon is not allowed.
^^^^^^^^^^^^^^^^^^^^^^^^^^
> Once I logon, I can su to 'root', if needed.
true, but as you are trying to log in as root for your backups, that doesn't
work:
Kenneth L. Owen wrote on 2008-12-04 14:54:30 -0500 [Re: [BackupPC-users] I
broke perfection ...]:
> The problem is that when all is working properly, and I run the command
> -bash-3.2$ ssh -l root Winserver whoami
^^^^^^^^^^^^^^^^^^^^^
> (bash-3.2$ prompt since user 'backuppc' was setup on Fedora 8 'no-logon')
> WinServer should not ask for a password or pass-phrase, but only respond
> 'root'
You can keep root login disabled on 'archiver', but you need to enable it on
'winserver' (that's the setting "PermitRootLogin" in /etc/ssh/sshd_config, and
you need to restart sshd).
That is exactly what I get when I enable PasswordAuthentication, disable
PermitRootLogin and try to 'ssh -l root' to a machine: the
PubkeyAuthentication fails and I get a root password prompt (which will fail
even if I enter the correct password). If you give 'ssh' a '-v' option, it
will tell you much more about what is going on and what is failing, although
it can't tell you why your root password is rejected, because only the server
knows and it doesn't disclose that information for security reasons.
Kenneth L. Owen wrote on 2008-12-03 13:19:30 -0500 [Re: [BackupPC-users] I
broke perfection ...]:
> 3. I also have httpd setup for secure connections between the two Linux
> workstations (https:). I can log into BackupPC GUI as 'ken' on "Archiver",
> but cannot log in to BackupPC from "WinServer" as 'ken', nor could I do so
> before when every thing else was working. It may be that I am not doing it
> correctly. In both cases, I enter "https://Archiver/BackupPC/ <enter>' into
> my browser's url space.
Didn't you have a DNS problem before? Is 'Archiver' resolvable on WinServer,
i.e. does 'host Archiver' or 'dig Archiver' or something like that give you a
correct response (presuming those commands are installed)?
> 5. Your second comment "FYI, you do not need to conceal finger prints"
> is well taken. I was not trying to conceal so much as cut down on unneeded
> data and typing.
You shouldn't be typing ;-). You should cut&paste such information if at all
possible, because typos may easily distort the problem and lead us down wrong
paths.
Rob Owens wrote on 2008-12-04 07:38:27 -0500 [Re: [BackupPC-users] I broke
perfection ...]:
>
> There are 2 sets of keys in use here. One set is the server's keys.
> The system creates these keys when the ssh server is installed. These
> identify the server and this is what is referenced when you get the
> message "authenticity of host cannot be established...". That message
> provides you with the fingerprint of the public key for the server, and
> it is up to you to verify it. Note that each user who connects to that
> server for the first time will get that message.
(unless the system administrator has added the host's entry to
/etc/ssh/ssh_known_hosts, thereby accepting the key on behalf of all users).
FYI: on the *server*, 'ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub' will
list the fingerprint of the server RSA key (replace 'rsa' with 'dsa' for the
DSA key). This should match what the *client* displays:
The authenticity of host 'foobar (192.168.1.177)' can't be established.
RSA key fingerprint is ee:b3:3d:6e:fa:eb:1f:a9:20:54:d9:ca:e7:85:cf:1f.
Are you sure you want to continue connecting (yes/no)?
To be safe, I should only answer yes *after* having verified that
user@foobar: ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
(because it's "RSA key fingerprint ..." in the message) gives me
1024 ee:b3:3d:6e:fa:eb:1f:a9:20:54:d9:ca:e7:85:cf:1f
/etc/ssh/ssh_host_rsa_key.pub
For remote hosts, I should have noted the key beforehand and check it now.
For local hosts, I can walk over to the host in question, log in on the
console and check now. For a home network without internet connection, I can
just answer yes and not bother ;-). The reason you need to verify this
information is that a man-in-the-middle attack is possible, if the attacker
can fool you into believing a key he has generated is in fact the host key of
your target host. You then connect to his fake sshd which can decrypt and even
modify anything you send to the target host before sending it on (re-
encrypted). This needs some level of access to the network, but it can be
done, and it can be defeated by the simple fingerprint check.
> The other set of keys is the user's key pair. These are created with
> the ssh-keygen command,
... as is the host key, only that is usually done automatically. In fact, the
host key is also a passphrase-less key, because 'sshd' obviously can't type in
a passphrase on startup. That is why the private part of that key must be
readable only for root.
> and they are used for authentication purposes
> (in place of password authentication). If a user places his public key
> in the ~/.ssh/authorized_keys file on another machine, that gives him
> the ability to log into that other machine as that particular user
> (whichever user's home directory he put the keys in)
... provided he can prove that he is in posession of the corresponding private
key, which should usually be protected with a passphrase (for a normal user
key, that is). Provided this is the case, breaking into the account does *not*
give cascading access to the systems/accounts where the public key has been
placed (though breaking into the account may provide the opportunity to sniff
the passphrase at some later point).
> So I could put my public key in /home/rob/.ssh/authorized_keys and in
> /var/lib/backuppc/.ssh/authorized_keys and in /root/.ssh/authorized_keys
> and that would allow me to log in as "rob", "backuppc", and "root" on
> that server.
The benefits being:
1.) I need to remember one passphrase (mine) instead of three different
passwords (some of which other people may have selected).
2.) Authorization can later be revoked simply by removing my public key eg.
from /root/.ssh/authorized_keys. No need to change a password and notify
other people with access to the account.
3.) I'm less likely to give away my private key than to tell someone a
password (because I would, in fact, be giving them all passwords including
future ones).
Of course, if all of this is just my toy machine at home, these points are
pretty benign, but in the context of BackupPC, at least the revocability
aspect is something to keep in mind.
Hope the first part helps and the rest is not too boring.
Regards,
Holger
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
