Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

This question already has an answer here:

On ubuntu/mint, all I need to do for passwordless ssh login is:

ssh-keygen -t rsa # on both pc
ssh-copy-id targetpc
ssh targetpc # does not prompt from password anymore

and that's all..

I do the same on archlinux (or manjaro), it's not working on the third step, it still prompts for password..

debug1: Reading configuration data /home/blablabla/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 192.168.11.3 [192.168.11.3] port 22.
debug1: Connection established.
debug1: identity file /home/blablabla/.ssh/id_rsa type 1
debug1: identity file /home/blablabla/.ssh/id_rsa-cert type -1
debug1: identity file /home/blablabla/.ssh/id_dsa type 2
debug1: identity file /home/blablabla/.ssh/id_dsa-cert type -1
debug1: identity file /home/blablabla/.ssh/id_ecdsa type 3
debug1: identity file /home/blablabla/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.1
debug1: match: OpenSSH_6.1 pat OpenSSH*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client arcfour hmac-md5 zlib@openssh.com
debug1: kex: client->server arcfour hmac-md5 zlib@openssh.com
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 71:d2:05:dd:21:d1:ae:fc:a8:e5:f2:1c:2c:60:31:85
debug1: Host '192.168.11.3' is known and matches the ECDSA host key.
debug1: Found key in /home/blablabla/.ssh/known_hosts:11
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/blablabla/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Offering DSA public key: /home/blablabla/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password
debug1: Offering ECDSA public key: /home/blablabla/.ssh/id_ecdsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

and when using old home directory (from ubuntu), the ssh-copy-id shows some information that i've never seen before

/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

is there some steps missing that i should do on archlinux?

EDIT: the version of openssh is differ on both machine, one is 6.1p1-6, others was 6.2p1-1

share|improve this question

marked as duplicate by Gilles, vonbrand, jasonwryan, warl0ck, Mat Apr 7 '13 at 7:31

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

1  
Is Arch the client or the server? I guess the client. –  warl0ck Apr 6 '13 at 13:42
    
both are now using archlinux –  Kokizzu Apr 6 '13 at 13:42
1  
Then check if the server side actually have the key, and allowed to login, it's not root right? –  warl0ck Apr 6 '13 at 13:47
    
yup, it's not root, both have the key id_[r|d|ecd]sa and id_[r|d|ecd]sa.pub in .ssh folder with correct permisson –  Kokizzu Apr 6 '13 at 13:53
2  
typically it means your home directory or .ssh/ directories do not have correct permissions. check out the remote end's syslogs for errors from sshd. –  jsbillings Apr 6 '13 at 14:05
show 4 more comments

1 Answer 1

up vote 3 down vote accepted

Typically it means your home directory or .ssh/ directories do not have correct permissions. check out the remote end's syslogs for errors from sshd.

for example, a line containing:

sshd[pid]: Authentication refused: bad ownership or modes for directory /home/yourusername

on

/var/log/auth.log

means you must do

chmod 700 ~
share|improve this answer
add comment

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