Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm writing a Groovy script to do an SCP. Note that I haven't ran it yet, because the rest of it isn't finished. Now, if you're doing an scp for the first time, have to authenticate the fingerprint. Future times, you don't.

My current solution is, because I get 3 tries for the password, and I really only need 1 (it's not like the script will mistype the password... if it's wrong, it's wrong!) is to pipe in "yes" as the first password attempt. This way, it will accept the fingerprint if necessary, and use the correct password as the first attempt. If it didn't need it, it puts yes as the first attempt and the correct as the second.

However, I feel this is not a very robust solution, and I know if I were a customer I would not like seeing "incorrect password" in my output. Especially if it fails for another reason, it would be an incredibly annoying misnomer.

What follows is the appropriate section of the script in question. I am open to any tactics that involve using scp (or accomplishing the file transfer) in a different way. I just want to get the job done. I'm even open to shell scripting, although I'm not the best at it.

def command = []
command.add('scp')
command.add(srcusername + '@' + srcrepo + ':' + srcpath)
command.add(tarusername + '@' + tarrepo + ':' + tarpath)

def process = command.execute()
process.consumeOutput(out)
process << "yes" << LS << tarpassword << LS
process << "yes" << LS << srcpassword << LS
process.waitfor()

Thanks so much,

glowcoder

share|improve this question
    
Why can't you retrieve the server's key the first time the script runs (or better yet, distribute the public key with your app so you have some semblance of security)? see also man ssh-keyscan –  voretaq7 May 21 '10 at 19:27
    
I won't know in advance what servers it will need to access and whether or not those servers have their fingerprint on it. I'm simply automating a process for them - their usernames, their passwords, their servers. –  corsiKa May 21 '10 at 19:28
    
ah that makes things tougher - see woefully insecure answer below :) –  voretaq7 May 21 '10 at 19:32

3 Answers 3

up vote 1 down vote accepted
man ssh_config

"... StrictHostKeyChecking If this flag is set to yes'', ssh(1) will never automatically add host keys to the ~/.ssh/known_hosts file, and refuses to connect to hosts whose host key has changed. This provides maximum protection against trojan horse attacks, though it can be annoying when the /etc/ssh/ssh_known_hosts file is poorly main‐ tained or when connections to new hosts are frequently made. This option forces the user to manually add all new hosts. If this flag is set tono'', ssh will automatically add new host keys to the user known hosts files. If this flag is set to ask'', new host keys will be added to the user known host files only after the user has confirmed that is what they really want to do, and ssh will refuse to connect to hosts whose host key has changed. The host keys of known hosts will be verified automatically in all cases. The argument must beyes'', no'', orask''. The default is ``ask''. ..."

share|improve this answer

Woefully insecure answer: http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html

(Basically feed the ssh command options directives that make it look at /dev/null for host keys & ignore the fact that it's never seen the key before -- Fixes the problem, but throws away any security precautions & leaves you open to password or private key harvesting attacks)

share|improve this answer
1  
I'd add that if implementing this you should make it optional & instead suggest to your users that they run ssh-keyscan on their machines leave the strict host key checking enabled: An unexpected host key change or unknown key should be enough to make you stop whatever you're doing & think very hard about why you got that message. –  voretaq7 May 21 '10 at 19:37

Why not write a wrapper for ssh that basically performs a ssh-keyscan and then checks for the presence of the hostkey in ~/.ssh/known_hosts? If it's not in known_hosts, then expect the yes.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.