Re: Eliminating password prompts from ssh & scp

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 10 Dec 2003, leam wrote:
> Allan Metts wrote:
> > 
> > I need to spawn a secure file transfer from within a C program.
....
> > Here's the silly part:  I can't find a way to prevent scp from prompting 
> > me for a password.  I've messed with sshd_config, established RSA1 keys, 
> > and done everything else I can think of.
....
> Copy the ~/.ssh/id_dsa.pub into the target ~/.ssh/authorized_keys

If the above one line hint and reading the man pages for ssh and 
sshd did not get you going... here is a more verbose hint:

First you must generate the keys for the user on the first
machine.  Too many bits and the transfers will be SLOW.  Too few
and your connection will be insecure.  IMO, 1024 bits is too many
for most of us but I like to stress my CPU.

	# as the user that will be making the ssh transfer.
	# check $HOME/.ssh/*key* for keys
	# if no keys do this once and recheck  $HOME/.ssh/*key*
	ssh-keygen -b1024 -t dsa
	ssh-keygen -b1024 -t rsa
	                     ^^^ other key types as needed.

Then copy the keys over to the target machine as the 
previous post indicated.

	scp $HOME/.ssh/*pub    remotebox:~

Then install the keys

	ssh remotebox
	# use >> not > because multiple machines and keys are possible.
	echo *pub 	# make sure the wild card  does not match an 
			# unexpected file  it should only 
			# expand to "id_dsa.pub" and "id_rsa.pub"
	cat *pub >> $HOME/.ssh/authorized_keys   
	rm *pub		# be tidy.

Next exit back to the first machine and make one new ssh
connection by hand to ensure the "known_hosts" file is filled in
etc. Then test your application.

N.B that sshd on the target machine might be configured to
disallow connections like this (no ~/.ssh stuff)  
See these comments in /etc/ssh/ssh_config
  # Change to yes if you don't trust ~/.ssh/known_hosts for
  # RhostsRSAAuthentication and HostbasedAuthentication
  #IgnoreUserKnownHosts no

Pay attention to /etc/ssh/sshd_config and /etc/ssh/ssh_config on
both machines.  It is possible for a sysadmin to make two
machines "equal" so the personal keys are not needed.  i.e.
/etc/ssh can hold keys for the system as well as ~/.ssh for
individuals.

It is necessary to protect the keys and key directory and
establish a protocol/ policy to generate new keys on a regular
basis.  Unlike data encryption there is little need to burn a
CDROM with keys for the vault (unless you use them for data).
Backup tools could expose these to prying eyes as well as NFS or
samba sharing..

Things can be _complicated_ in a DHCP world. Using authorized_keys 
for root is a MUCH bigger risk than for a single user.

The most convenient way to use RSA authentication may be with an
authentication agent.  See ssh-agent(1) for more information.

# Usage: ssh-keygen [options]
# Options:
#   -b bits     Number of bits in the key to create.
#   -c          Change comment in private and public key files.
#   -e          Convert OpenSSH to IETF SECSH key file.
#   -f filename Filename of the key file.
#   -i          Convert IETF SECSH to OpenSSH key file.
#   -l          Show fingerprint of key file.
#   -p          Change passphrase of private key file.
#   -q          Quiet.
#   -y          Read private key file and print public key.
#   -t type     Specify type of key to create.
#   -B          Show bubblebabble digest of key file.
#   -C comment  Provide new comment.
#   -N phrase   Provide new passphrase.
#   -P phrase   Provide old passphrase.
# You must specify a key type (-t).


-- 
	T o m  M i t c h e l l
	mitch48 -a*t- yahoo-dot-com




[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux