RE: [suse-security] automatic backups over ssh/scp
That depends on the situation. The private keys are on the SSH client machine, so if that is more secure than the SSH server, the setup is more secure than with passwords being on the server.
I don't think so. In my opinion i doesn't matter if you store a plaintext password or a ssh-key, which is not secured by an password.
It depends on the security of the system that either one is stored on. In SSH, they are different, the passwords are stored on the SSH server, the private keys are stored on the client. So, if your client is more secure than the server, the public key file is more difficult to get than the password file. And vice versa, of course.
Once Mr. X get's access to the file, he get's instantly access to the account which is guarded by them.
Exactly, but the difficulty in getting the file can be different, because we're talking about two different machines. I.e. one machine could be a public web server, while the other one is a heavily firewalled and IDS's and whetever'd machine in a room with several feet of concrete and steel all around it. I'd place a critical file on the second machine. Note that you need clear text stuff in some situations if you want to automate them and automation is necessary in quite a few situations. If that means an empty passphrase on an SSH private key, OK, but I make sure the machine the file is on is safe.
The use of public key authentication is definitely a lot safer against
No, I strongly disagree. By just using public key authentication you gain *no* benefit for security and aren't instantly safer.
Read the rest of the sentence. Public key authentication is safer than password authentication most of the time because only very few passwords have the entropy of a pair of public and private keys. Passphrases to private keys have to be protected, as do passwords. Private key files without a passphrase have to be protected in the same way. The difference is that passwords are usually stored on a central machine, while private keys are on the clients. However, the distinction between client and server is not a distinction in security per se. I believe there are quite a few web clients that are more secure than many web servers, for example.
If you use public-key-mechanisms in a wrong way things get much worse! Especially ssh can be abused in many ways to undermine any security barriers.
Of course any scheme can be abused. There's no difference between public key mechanisms and passwords here. But how does this relate to the issue at hand? Cya Tobias
Hi Again, On Wed, 1 Aug 2001, Reckhard, Tobias wrote:
I don't think so. In my opinion i doesn't matter if you store a plaintext password or a ssh-key, which is not secured by an password. It depends on the security of the system that either one is stored on.
You are comparing apples with pears [old German saying ;) ] I did talk about storing unsecured credentials (password or private key) on the client not on the server! On the server you don't store credentials! You store something, like hashes or public-keys, which you can use to prove that the contestant has the correct credential.
.., but the difficulty in getting the file can be different, because we're talking about two different machines. I.e. one machine could be a public web server,...
Than you'd better use a dedicated password, which is valid for and only for this one web-server. So if this machine gets compromised and our Mr. X manages to get your password, he only gets the password for the machine/user he just got access to (value: approx. zero). :)
The use of public key authentication is definitely a lot safer against No, I strongly disagree. Read the rest of the sentence.
I read the whole sentence twice and am still disagreeing. :) First: In most setups password authentication is in place anyway and it's not likely you can simply turn it off. Second: Users are not allowed to read /etc/shadow by definition. If you worry about an imposter, who can get access to /etc/shadow, you are worrying about someone who gets root. In the underlying scenario from the beginning of this thread, you lost, because the sensitive data is revealed. Third: I know users [I'm not responsible for!], who have a .ssh on one client, with identity, identity.pub and authorized_keys set up, and then are setting up multilateral public-key-authentication by copying the whole .ssh to any [trusted?] host [e.g. not well administered shared web-server], they gain access to. [Seen in real life more than once.] Worse: For more comfort users like to do this with no passphrase on "identity" or with agent-forwarding turned on. Hey, these nasty users are successfully using public-key authentication without knowing about the risks on each of the mutually trusted account. Recall: "The use of public key authentication is definitely a lot safer against [weak passwords]" -- Sorry, I strongly disagree! Though: If we add something like "correct" or "accurate" before "use of of public-key authentication" to your sentence and delete the ugly "definitely" from it, I might agree for a specific scenario. ;-)
If you use public-key-mechanisms in a wrong way things get much worse! Of course any scheme can be abused. <...> But how does this relate to the issue at hand?
It should be just a reminder to use SSH in the "right" way. Like telling someone, he should pay attention to bang the hammer onto the nail instead of hurting his fingers. ;-) Regards, Holger ----------------------------------------------------------------------- Holger van Lengerich paderLinx - Neue Informationsmedien GmbH Diplom-Informatiker Cheruskerstraße 2b, 33102 Paderborn mailto:hvl@paderlinx.de Fon: +49 5251 8994 - 16 Fax: -20 -----------------------------------------------------------------------
participants (2)
-
Holger van Lengerich -
Reckhard, Tobias