1

I am trying to set up a passwordless ssh login to a remote host. For that I generated a public key wich I copied to 

    /home/user/.ssh/authorized_keys

As mentioned in various posts I checked that the directories have the correct permissions:

Local:

    .ssh                     chmod 700 ~/.ssh
    .ssh/config              chmod 600 ~/.ssh/config
    .ssh/id_rsa.pub          chmod 600 ~/.ssh/id_rsa.pub

On the server:

    .ssh                     chmod 700 ~/.ssh
    .ssh/authorized_keys     chmod 600 ~/.ssh/authorized_keys

Unfortunately even though I checked the existence of the public key in the authorised_keys and the permission, I am still not able to login without being asked for a password. My ssh configuration looks as follows

Host <alias>
    HostName <hostname>
    Port 24
    User <user>
    IdentityFile  /Users/<user>/.ssh/id_rsa
    ForwardAgent yes

and the command ssh <alias> -vv produces the following output

OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/<user>/.ssh/config
debug1: /Users/<user>/.ssh/config line 33: Applying options for <alias>
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug1: Connecting to <hostname> port 24.
debug1: Connection established.
debug1: identity file /Users/<user>/.ssh/id_rsa type 0
debug1: identity file /Users/<user>/.ssh/id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000002
debug1: Authenticating to <hostname>:24 as '<user>'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: [email protected],[email protected],[email protected],rsa-sha2-512,rsa-sha2-256,ssh-rsa,[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,ssh-dss
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: MACs ctos: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: [email protected] compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: [email protected] compression: none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<3072<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 1529/3072
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-rsa SHA256:X8A9iSSMmTFCKdw8p1TDnazVonwcgBpo6hXA7krpHwU
debug1: Host '[<hostname>]:24' is known and matches the RSA host key.
debug1: Found key in /Users/<user>/.ssh/known_hosts:211
debug2: bits set: 1584/3072
debug2: set_newkeys: mode 1
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 4294967296 blocks
debug1: Will attempt key: /Users/<user>/.ssh/id_rsa RSA SHA256:3LIhc2rldQppUUeETqR863VdZHh+fluZCfWZnspaN+4 explicit
debug2: pubkey_prepare: done
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: password,keyboard-interactive
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:

Edit:

The /etc/ssh/ssh_config file looks as follows:

#   $OpenBSD: ssh_config,v 1.34 2019/02/04 02:39:42 dtucker Exp $

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

# Host *
#   ForwardAgent no
#   ForwardX11 no
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   IdentityFile ~/.ssh/id_ecdsa
#   IdentityFile ~/.ssh/id_ed25519
#   Port 22
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,[email protected]
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
#   RekeyLimit 1G 1h

Host *
    SendEnv LANG LC_*

Any ideas on what could be going on are greatly appreciated!

 Local OS: MacOS Catalina 10.15.4 
 Remote OS: Scientific Linux release 6.6 (Carbon)
Mark
  • 111
  • 3
  • Provide the configuration file located at */.ssh/config* and */etc/ssh/ssh_config* to confirm your configuration, is expected based on your expectations – Ramhound Apr 30 '20 at 21:44
  • @Ramhound The /.ssh/config just contains the snippet I posted on the question while the /etc/ssh/ssh_config contains the standard default values. – Mark Apr 30 '20 at 21:49
  • If the issue is difficult to find from the client side, the server-side logs (probably in /var/log/secure) would give additional informations. – A.B Apr 30 '20 at 21:50
  • @Mark - The standard default values are being imported. I want to see the contents of the two files, have not been provided, only the permissions. – Ramhound Apr 30 '20 at 21:52
  • @A.B Unfortunately I don't have access to those – Mark Apr 30 '20 at 21:53
  • @Ramhound Ok, will add it as and edit to the question! – Mark Apr 30 '20 at 21:53
  • "....Reading configuration data /Users//.ssh/config ... Applying options for " then it applies the configurations for all everything "Reading configuration data /etc/ssh/ssh_config .. Applying options for *" from the default configuration. – Ramhound Apr 30 '20 at 21:54

1 Answers1

1
debug1: Authentications that can continue: password,keyboard-interactive

The remote server isn't accepting public key authentication. It only accepts passwords (and "keyboard-interactive" which is usually another form of password authentication). If the server were accepting public keys, then the above line would also contain "publickey".

It appears from your comments that you don't have administrative rights on the remote server. You should talk to the administrators about using public key authentication.

Kenster
  • 7,483
  • 2
  • 32
  • 44
  • mhhh... Is there a way to explicitly check this on the remote without having root access? – Mark Apr 30 '20 at 22:21
  • The remote server claims to be OpenSSH 5.3, so its configuration file would probably be `/etc/sshd_config` or `/etc/ssh/sshd_config` or something like that. The option to look for is `PubkeyAuthentication`. – Kenster Apr 30 '20 at 22:24
  • Okay, as I do not have read access to these files there is no other way to find out? – Mark Apr 30 '20 at 22:35