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
