[KLUG Members] ssh-keygen

[bert]

Thanks guys for all the explanations.

I want to use the ssh-keys to scp some files to an other server. Because process runs via the crontab, I can't provide a passfrase.
I use scp with the -i option to provide the key and -l to provide a non-root username.
The keys go into an root only accessable directory. (The cron runs as root.)
If there are better, more secure, ways to do this I would like to know about them.
My misunderstanding was that I thought that the passfrase could be used to bypass the ssh-key in some way, a sort of bypassfrase so to speak.

Kind regards,

Bert.


ps, Bill, you wrote your gpg key at the end of your message. I once created a gpg key (without a passfrase) and loaded that up to a keyserver. I guess it's better to use a passfrase on this too.





bill schreef:
> Hello,
> 
> On Mon, 2007-03-12 at 13:21, bert wrote:
>> Hi all,
>>
>> When generating a ssh key with ssh-keygen I always use -t DSA.
>> On the question to enter a passphrase, I always just press entre twice 
>> (no passfrase).
> 
> Sure.  Then you copy the public key to the remote system and when you
> log in to that system you won't need to use a passphrase.  
> 
> It's simpler than using a password and someone has to have the key (a
> special file) to log in.
> 
> Usually, you limit the SSH logins to only accept logins that use a key
> so name-and-password SSH logins aren't allowed.
> 
>> After reading the howto I am not sure anymore if this the most secure choise.
> 
> No, it is not the most secure choice.
> 
>> The howto explains that this passphrase will be used to encrypt the private 
>> part of this file using 3DES.
>> Is this good or bad? So should I enter a passfrase or better not?
> 
> SSH is a way to log in to another computer to do things there.  SSH
> means I can work on a remote computer as if I was at the keyboard over
> there.  I'm typing on the Client computer, my commands are run on the
> Server computer.
> 
> SSH Session:
> 
>   (I'm typing on the) Client ---> (my typing is acting on the) Server
> 
> We used to log in to other computers with Telnet, giving our name and
> password.  But, Telnet transmitted our name and password to the Server
> in the clear, making them vulnerable to someone "listening in."
> 
> SSH encrypts the transmissions so people can't steal information by
> "listening in."  But, there are other ways to steal passwords (like
> reading the post-it note on the underside of the keyboard!).
> 
> There are three general ways to do SSH: name & pw, passwordless keys,
> and keys with passwords.  You are talking about the last two.
> 
> There are other ways to do SSH, but they don't apply to your question.
> 
> --------------------
> 
> The first way is the most basic: Name and password.  I run SSH, calling
> up the remote computer and it asks for my name and password.  If I give
> correct answers, I get to log in as that user and away I go.
> 
> First, have an account on the Server
> Client runs SSH and calls Server
> 	Server says "What is your name and password"
> 	I give the name and password.  
> 	If correct, I'm logged in and begin my SSH session.
> 
> The second way is more advanced, but simpler: passwordless keys.  I run
> SSH, calling up the remote computer and giving my name.  The Server
> looks up my account and sees my public key.  The server asks for the
> matching private key, which is on the client.  The client automatically
> provides it, and if the keys correspond, I get to log in as that user
> and away I go.
> 
> First, have an account on the Server with your public key installed
> Client runs SSH and calls Server, giving name
> 	Server looks up account, 
> 		sees public key, asks Client for private key
> 	Client provides private key (happens automatically)
> 	If the keys correspond, I'm logged in and begin my SSH session.
> 
> 
> --------------------
> 
> The third way is more secure: keys with password.  I run SSH, calling up
> the remote computer and giving my name.  The Server looks up my account
> and sees my public key.  The server asks for the matching private key,
> which is on the client.  The client DOESN'T AUTOMATICALLY PROVIDE THE
> PRIVATE KEY, BUT ASKS ME FOR THE PASSWORD TO USE IT.  IF THE KEY
> PASSWORD IS CORRECT IT FORWARDS THE KEY TO THE SERVER, if the keys
> correspond, I get to log in as that user and away I go.
> 	
> First, have an account on the Server with your public key installed
> Client runs SSH and calls Server, giving name
> 	Server looks up account, 
> 		sees public key, asks Client for private key
> 	Client finds private key
> 		Asks me for password to use it
> 		If password is correct, forwards key to Server
> 	If the keys correspond, I'm logged in and begin my SSH session
> 
> --------------------
> 
> So there are three increasing levels of security here.
> 
> I can log in by using a name and password.
> 	But, what if someone steals my name & password?  		They can log in as
> me!
> 
> I can log in by using a passwordless key.
> 	But, what if someone steals my private key?  
> 		They can log in as me!
> 
> I can by using a key with a password.
> 	But what if someone steals my key and my password for that key?  		They
> can log in as me!
> 
> So, you can see that the three levels give increasing security by making
> it more difficult for someone to steal your identity and log in as you.
> 
> kind regards,
> 
> bill
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Members mailing list
> Members at kalamazoolinux.org
>