On Wed, 11 Oct 2000, Marco wrote:

time we use ssh with a useraccount which has no password. sounds unsecure eh ? :) i know that it is possible for everyone on the machine "a" to connect to machine "b" when he knows 1) the non-password useracc and 2) the ip where the ssh-key with no-password is stored.

I don't know very sure whether this sollution is better, but you could allow a specified account (say xxyyz) on machine A to connect to a (you could name the same account) on machine B without password but by using the .rhost file of xxyyz@B (containing a line with "A xxyyz") which when ssh is (im?)properly defined (ssh documentation points it out as a lesser secure way), allows user xxyyz to connect to machine B as user xxyyz originating from machine A only, without having to enter a password. When on both machines password is DISABLED (not unset, but set to a value that can never be generated so no one (except for root) can login (or su) to that user xxyyz (on both systems A and B)), this should solve your problem. ******* Groetjes vanwege ***** Greetings From ******* Dieter Demerre - http://www.angelfire.com/de/ddemerre ddemerre@acm.org - ext.dieter.demerre@siemens.be Although this private and confidential e-mail has been sent to you through a personal Siemens account, it does NOT represent any official opinion of Siemens. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox.

* Marco wrote on Wed, Oct 11, 2000 at 22:19 +0000:

hi all,

is there a way to copy/move a file (backup) secure over the network ? at this time we use ssh with a useraccount which has no password. sounds unsecure eh ? :)

I think you mean a null password? If an account has no passwort, that means no password authentication is possible, this is ok of course. But you should never ever have null passwords somewhere!

i know that it is possible for everyone on the machine "a" to connect to machine "b" when he knows 1) the non-password useracc and 2) the ip where the ssh-key with no-password is stored.

Did you used a ssh key and the authorized_keys mechanism with a non-password account? Then the attacker need the secret key to make a login. Knowing the IP doesn't mean that the attacker could steal the key. At least, if you haven't configured very bad things ;)

what happens if the ssh-key with the non-passwd is stolen or may be used by an attacker to get more accounts or root ?

_if_ you need to use ssh keys for automatic connects, you won't use passphrases to encrypt the keys. So it's enough to steal the secret key file. By this, you know you should never grant root access for such keys. Use a good passphrase and the possibility to connect to a root account, but satisfy both conditions or none.

i don´t know how this could help him, but i think its not the best way to transfer the files with this method. any ideas ?

Well, doing backups requires root permissions often. First, you may use a wrapper script in authorized_keys to allow only the file transfer. But this still allows an attacker to steal all your files you backup. I had the same problem and did the following: - Each system has a backup user. This user had no special privileges, it's like the nobody account. - The backupserver connects to that user with a ssh key to back up all world-readble files (which are a lot usually ;)). It may be possible to make a root cronjob that copies some root files to a directory below the home of backup, so only the backup user is able to read that files. But here you shouldn't copy secret files either (like /etc/shadow). - From time to time a more complete backup is done useing a root connect. The key for that is only stored on floppy disks. If the backup (i.e. once a week) is about to begin, the key disk has to be inserted. Then the key is loaded and used. After that the disk is removed from floppy. So it's a little bit more difficult to steal the key (since most of the time the disk is not inserted into drive), but still _not_ secure. - To make it more secure, use either one-time passwords (or maybe one-time passphrases, i.e. deleteing the key disk after use or whatever), or require manual input of the passphrase before backing up. In that case before backup an agent (ssh-agent) would be loaded. The key is decrypted once, and removed from memory when backup is finished. This requires an operator starting the backup which does not differ too much from inserting a disk. Well, so do both: encrypted key on dedicated disk. I would like to hear what others do in that case. I would like a short discussion. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.