sandeep_th
asked on
scp in public/private key mode not working
Hi,
I have 3 suse linux boxes at my disposal currently and wanted to configure the 3 in such a way that scp commands from and to either of these 3 boxes would work without manual intervention.
Box 1 : SuSE Linux 9 ssh -V : OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7b 10 Apr 2003
Box 2 : SuSE Linux 9 ssh -V : OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7b 10 Apr 2003
Box 3 : SuSE Linux Enterprise Server 9 ssh -V : OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004
I managed to get the automatic scp(without passwords) working between Box1-> Box2 quite easily...both ways. From Box 2 -> Box 3 it also works fine. But when I try the same from Box3->Box2....THIS doesn't work. Unfortunately this is the one I need the most!!!
I followed the regular procedure....generated the keys using:
ssh-keygen -t rsa
on the machine I want to send FROM
and appended the resultant public key(id_rsa.pub) to the ~/.ssh/authorized_keys file on the machine to be sent TO.
Works like a charm in all scenarios EXCEPT the one specified above(Box3->Box2).
Also, in one of the umpteen discussions I found on the subject(in EE) someone had suggested the following for running scp commands in a script:
echo "password" | scp user@machine:/home/user/re
Although I wouldn't go for this method....since it is very insecure.....I was prepared to try it as an interim arrangement...till I found what exactly was wrong. But this doesn't work either....it still asks for a password!! I wonder how the solution was "accepted"?!! Here it is:
https://www.experts-exchange.com/questions/20827914/Wanna-secure-copy-a-file-from-one-machine-to-another-using-a-script.html?query=automatic+scp&clearTAFilter=true
I have 3 suse linux boxes at my disposal currently and wanted to configure the 3 in such a way that scp commands from and to either of these 3 boxes would work without manual intervention.
Box 1 : SuSE Linux 9 ssh -V : OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7b 10 Apr 2003
Box 2 : SuSE Linux 9 ssh -V : OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7b 10 Apr 2003
Box 3 : SuSE Linux Enterprise Server 9 ssh -V : OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004
I managed to get the automatic scp(without passwords) working between Box1-> Box2 quite easily...both ways. From Box 2 -> Box 3 it also works fine. But when I try the same from Box3->Box2....THIS doesn't work. Unfortunately this is the one I need the most!!!
I followed the regular procedure....generated the keys using:
ssh-keygen -t rsa
on the machine I want to send FROM
and appended the resultant public key(id_rsa.pub) to the ~/.ssh/authorized_keys file on the machine to be sent TO.
Works like a charm in all scenarios EXCEPT the one specified above(Box3->Box2).
Also, in one of the umpteen discussions I found on the subject(in EE) someone had suggested the following for running scp commands in a script:
echo "password" | scp user@machine:/home/user/re
Although I wouldn't go for this method....since it is very insecure.....I was prepared to try it as an interim arrangement...till I found what exactly was wrong. But this doesn't work either....it still asks for a password!! I wonder how the solution was "accepted"?!! Here it is:
https://www.experts-exchange.com/questions/20827914/Wanna-secure-copy-a-file-from-one-machine-to-another-using-a-script.html?query=automatic+scp&clearTAFilter=true
Try ssh -vv box2 while logged on to box 3. You'll be able to see what is transpiring and it may give you some clue as to why your scp session isn't working.
> echo "password" | scp ...
does not work, except ther is no password expected ;-)
waiting for ssh -v output too ...
does not work, except ther is no password expected ;-)
waiting for ssh -v output too ...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
You got a winner there Chris!!!!! THAT was indeed the problem. The authorized_keys file was ok....but one of the higher-level directories was world writable. Incidentally the ssh -vv output wasn't giving a clue about this.
Is this some kind of restriction laid down by ssh or something?
Just copying out the "ssh -vv box2" output anyway......could anyone tell me how I was supposed to pinpoint this problem from this output:-
OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to box2 [box2] port 22.
debug1: Connection established.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/foo/.ssh/id_rsa type 1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.7.1p2
debug1: match: OpenSSH_3.7.1p2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-excha
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfi
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfi
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ri
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ri
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-excha
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfi
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfi
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ri
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ri
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUES
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 117/256
debug2: bits set: 513/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'box2' is known and matches the RSA host key.
debug1: Found key in /home/foo/.ssh/known_hosts
debug2: bits set: 514/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/foo/.ssh/id_rsa (0x808a640)
debug1: Authentications that can continue: publickey,keyboard-interac
debug1: Next authentication method: publickey
debug1: Offering public key: /home/foo/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,keyboard-interac
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
password:
This is where it used to ask for the password. Now how is one ought to know it is the file permissions problem?
Is this some kind of restriction laid down by ssh or something?
Just copying out the "ssh -vv box2" output anyway......could anyone tell me how I was supposed to pinpoint this problem from this output:-
OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to box2 [box2] port 22.
debug1: Connection established.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/foo/.ssh/id_rsa type 1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.7.1p2
debug1: match: OpenSSH_3.7.1p2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-excha
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfi
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfi
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ri
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ri
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-excha
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfi
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfi
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ri
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ri
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUES
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 117/256
debug2: bits set: 513/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'box2' is known and matches the RSA host key.
debug1: Found key in /home/foo/.ssh/known_hosts
debug2: bits set: 514/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/foo/.ssh/id_rsa (0x808a640)
debug1: Authentications that can continue: publickey,keyboard-interac
debug1: Next authentication method: publickey
debug1: Offering public key: /home/foo/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,keyboard-interac
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
password:
This is where it used to ask for the password. Now how is one ought to know it is the file permissions problem?
Yeah, I've seen this many times before. The restriction is in there to ensure that the key files and authorized_keys file couldn't have been created by an attacker. Don't know why nobody's ever thought to put in better error messages about it, though.