4

So I have been struggling with trying to authenticate without a password. Here is all my steps.

  1. On Source Host ssh-keygen and saved the file into the default directory with a blank key phrase (enter) drwx------ 2 root root 4096 Dec 11 18:08 .ssh is the file permissions.

  2. ssh-keyscan 192.168.117.131 > known_hosts

  3. ssh-copy-id user@192.168.117.131 and imputed "user's" password. After entering password, I got:

ssh-copy-id user@192.168.117.131
/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
user@192.168.117.131's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'user@192.168.117.131'"
and check to make sure that only the key(s) you wanted were added.
  1. ssh user@192.168.117.131 and it is still requiring a password.

On Remote Host

drwxr-xr-x  2 user user 4096 Dec 12 08:27 .ssh 

and

-rwxr-xr-x  1 user user  391 Dec 12 08:27 authorized_keys
  1. authorized_key file has the same key as id_rsa.pub on the SOURCE server.

My sshd_config file has the following settings:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
StrictModes no
#MaxAuthTries 6
#MaxSessions 10

PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
AuthorizedKeysFile      .ssh/authorized_keys .ssh/authorized_keys2
  1. /etc/init.d/ssh restart

  2. From source server, tried to SSH once again, and it is still asking for a password.

Here is my debug log as well:

root@kali:~/.ssh# ssh -v user@192.168.117.131
OpenSSH_7.4p1 Debian-10, OpenSSL 1.0.2k  26 Jan 2017
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.117.131 [192.168.117.131] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.5p1 Ubuntu-10
debug1: match: OpenSSH_7.5p1 Ubuntu-10 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.117.131:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:uGQe2r9lvKFm6w5p5jInX8Ywrg2PmICccUvC+q+Wc18
debug1: Host '192.168.117.131' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:3
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: Skipping ssh-rsa key /root/.ssh/id_rsa - not in PubkeyAcceptedKeyTypes
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Next authentication method: password
user@192.168.117.131's password: 

Please help, I have been trying to figure this out for the last 2 days.

Thanks!

4

From the debugging messages, it seems that your local ssh needs some configuration changes. You can see the local ssh, debug1:, skipping your RSA key:

debug1: Skipping ssh-rsa key /root/.ssh/id_rsa - not in PubkeyAcceptedKeyTypes

You can find out how to configure this option by checking out the man page for ssh_config:

 PubkeyAcceptedKeyTypes
         Specifies the key types that will be used for public key authentication as a comma-separated pattern list.  Alternately if the speci‐
         fied value begins with a ‘+’ character, then the key types after it will be appended to the default instead of replacing it.  If the
         specified value begins with a ‘-’ character, then the specified key types (including wildcards) will be removed from the default set
         instead of replacing them.  The default for this option is:

            ecdsa-sha2-nistp256-cert-v01@openssh.com,
            ecdsa-sha2-nistp384-cert-v01@openssh.com,
            ecdsa-sha2-nistp521-cert-v01@openssh.com,
            ssh-ed25519-cert-v01@openssh.com,
            ssh-rsa-cert-v01@openssh.com,
            ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
            ssh-ed25519,ssh-rsa

         The list of available key types may also be obtained using "ssh -Q key".

So, querying your ssh configuration:

ssh -Q key

Should yield all the accepted key types for the local ssh client.

It seems that your configuration is not the standard default configuration. This seems likely due to the specialized version of GNU/Linux you are running: "Kali"

2

On the host the ~/.ssh directory should not be readable by anyone but the user (drwx------) and the authorized_keys file should be the same (-rw-------).

If it is not so it is ignored by SSH.

  • 1
    This is probably the correct answer, as everything worked (ssh to it, transfer of key, etc) apart from using the key. chmod 600 ~/.ssh/* ; chmod 700 ~/.ssh – Olivier Dulac Dec 15 '17 at 9:20
0

Do you have an agent running, with a key loaded, and access set in your current environment? If you think of the ssh client as the key to a door, and the sshd server as the lock in that door, then having a key loaded in the agent can be thought of as the need to have the key with you and actually insert into the lock when you want to open the door.

You can check with ssh-add -l as:

$ ssh-add -l
2048 SHA256:Y0NxbfZjsvauyER2jjUqh5gysMyvawKKrYStcqWg6Ks user@Nhostname (RSA)
# An agent is running and accessible, and a key is loaded

The ssh-agent man page is a place to start with how use this, and there are plenty of answers here as well.

-1

Add a line in the sshd_config file:

RSAAuthentication yes

and restart the service.

  • I have added this to the sshd_config file: # Authentication: RSAAuthentication yes #LoginGraceTime 2m #PermitRootLogin prohibit-password StrictModes no #MaxAuthTries 6 #MaxSessions 10 PubkeyAuthentication yes # Expect .ssh/authorized_keys2 to be disregarded by default in future. AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 restarted service and it still requires a password. – Wraiith Dec 12 '17 at 17:23
  • Sorry the formatting is weird, but RSAAuthentication is not commented out, and is on it's separate line. – Wraiith Dec 12 '17 at 17:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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