I added the public ssh key to the authorized_keys file. ssh localhost
should log me in without asking for the password.
I did that and tried typing ssh localhost
, but it still asks me to type in the password. Is there any other setting that I have to go through to make it work?
I have followed instruction for changing permissions:
Below is the result if I do ssh -v localhost
debug1: Reading configuration data /home/john/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/john/.ssh/identity type 1
debug1: identity file /home/john/.ssh/id_rsa type -1
debug1: identity file /home/john/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu3
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
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
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/john/.ssh/known_hosts:12
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
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 public key: /home/john/.ssh/identity
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Then it asks for passphase after the above log. Why isn't it logging me in without a password?
In my case it's because the user's group is not set in AllowGroups of config file /etc/ssh/sshd_config. After adding it everything works fine.
you need to verify the properties of the files. to assign the required property use:
setting ssh authorized_keys seem to be simple but hides some traps I'm trying to figure
-- SERVER --
in /etc/ssh/sshd_config set
passwordAuthentication yes
to let server temporary accept password authentication-- CLIENT --
1. generate private and public keys (client side)
# ssh-keygen
here pressing just ENTER you get DEFAULT 2 files "id_rsa" and "id_rsa.pub" in ~/.ssh/ but if you give a name_for_the_key the generated files are saved in your pwd
2. place the your_key.pub to target machine
ssh-copy-id user_name@host_name
if you didn't create default key this is the first step to go wrong ... you should use
ssh-copy-id -i path/to/key_name.pub user_name@host_name
3. logging
ssh user_name@host_name
will work only for default id_rsa so here is 2nd trap for you need tossh -i path/to/key_name user@host
(use ssh -v ... option to see what is happening)
If server still asks for password then you gave smth. to Enter passphrase: when you've created keys ( so it's normal)
if ssh is not listening default port 22 must use
ssh -p port_nr
-- SERVER -----
4. modify /etc/ssh/sshd_config to have
(uncoment if case)
This tells ssh to accept authorized_keys and look in user home directory for key_name sting written in .ssh/authorized_keys file
5 set permissions in target machine
Also turn off pass auth
passwordAuthentication no
to close the gate to all ssh root/admin/....@your_domain attempts
6 ensure ownership and group ownership of all non-root home directories are appropriate.
===============================================
7. consider the excelent http://www.fail2ban.org
8. extra ssh TUNNEL to access a MySQL (bind = 127.0.0.1) sever
Beware that SELinux can trigger this error as well, even if all permissions seem to be OK. Disabling it did the trick for me (insert usual disclaimers about disabling it).
Just look on /var/log/auth.log on the server. Setting additional verbosity with -vv on the client side won't help, because the server is unlikely to offer too much information to a possible attacker.
You need to verify the permissions of the
authorized_keys
file and the folder / parent folders in which it is located.For more information see this page.
You may also need to change/verify the permissions of your home directory to remove write access for the group and others.