Solved

scp in public/private key mode not working

Posted on 2004-10-14
5
714 Views
Last Modified: 2010-04-22
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/remote_file localfile

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:
http://www.experts-exchange.com/Operating_Systems/Solaris/Q_20827914.html?query=automatic+scp&clearTAFilter=true










0
Comment
Question by:sandeep_th
5 Comments
 
LVL 6

Expert Comment

by:blkline
ID: 12310921
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.
0
 
LVL 51

Expert Comment

by:ahoffmann
ID: 12311794
>  echo "password" | scp  ...
does not work, except ther is no password expected ;-)

waiting for ssh -v output too ...
0
 
LVL 14

Accepted Solution

by:
chris_calabrese earned 125 total points
ID: 12311951
One thing to look at is file permissions.
The ssh client (server) won't let you use keys if the key file (authorized_keys file) is group/world writable, lives in a group/world writable directory, or if any of the other higher-level directories are world writable.
0
 

Author Comment

by:sandeep_th
ID: 12312887
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-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
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-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
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_REQUEST(1024<1024<8192) sent
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:1
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-interactive
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-interactive
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?

0
 
LVL 14

Expert Comment

by:chris_calabrese
ID: 12317987
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.
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

​Being a Managed Services Provider (MSP) has presented you  with challenges in the past— and by meeting those challenges you’ve reaped the rewards of success.  In 2014, challenges and rewards remain; but as the Internet and business environment evol…
BIND is the most widely used Name Server. A Name Server is the one that translates a site name to it's IP address. There is a new bug in BIND (https://kb.isc.org/article/AA-01272), affecting all versions of BIND 9 from BIND 9.1.0 (inclusive) thro…
Nobody understands Phishing better than an anti-spam company. That’s why we are providing Phishing Awareness Training to our customers. According to a report by Verizon, only 3% of targeted users report malicious emails to management. With compan…
Finding and deleting duplicate (picture) files can be a time consuming task. My wife and I, our three kids and their families all share one dilemma: Managing our pictures. Between desktops, laptops, phones, tablets, and cameras; over the last decade…

730 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question