Enable keyboard-interactive authentication with password only

I have a ssh client and a ssh server. I want to enable keyboard interactive authentication on the server, so the client can only connect to the server with this authentication method. In /etc/ssh/sshd_config on the server I have the following:

KbdInteractiveAuthentication yes ChallengeResponseAuthentication yes PubkeyAuthentication no PasswordAuthentication no 

When I try to connect from the client to the server I receive the following error log:

julian: ssh -vvv 192.168.1.102 OpenSSH_8.1p1, LibreSSL 2.7.3 debug1: Reading configuration data /Users/client/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 47: Applying options for * debug2: resolve_canonicalize: hostname 192.168.1.102 is address debug2: ssh_connect_direct debug1: Connecting to 192.168.1.102 [192.168.1.102] port 22. debug1: Connection established. debug1: identity file /Users/julian/.ssh/id_rsa type 0 debug1: identity file /Users/julian/.ssh/id_rsa-cert type -1 debug1: identity file /Users/julian/.ssh/id_dsa type -1 debug1: identity file /Users/julian/.ssh/id_dsa-cert type -1 debug1: identity file /Users/julian/.ssh/id_ecdsa type -1 debug1: identity file /Users/julian/.ssh/id_ecdsa-cert type -1 debug1: identity file /Users/julian/.ssh/id_ed25519 type -1 debug1: identity file /Users/julian/.ssh/id_ed25519-cert type -1 debug1: identity file /Users/julian/.ssh/id_xmss type -1 debug1: identity file /Users/julian/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_8.1 debug1: Remote protocol version 1.99, remote software version OpenSSH_4.2 debug1: match: OpenSSH_4.2 pat OpenSSH_2*,OpenSSH_3*,OpenSSH_4* compat 0x00000002 debug2: fd 3 setting O_NONBLOCK debug1: Authenticating to 192.168.1.102:22 as 'julian' debug3: hostkeys_foreach: reading file "/Users/julian/.ssh/known_hosts" debug3: record_hostkey: found key type RSA in file /Users/julian/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys from 192.168.1.102 debug3: hostkeys_foreach: reading file "/etc/ssh/ssh_known_hosts" debug3: order_hostkeyalgs: prefer hostkeyalgs: ,,,rsa-sha2-512,rsa-sha2-256,ssh-rsa debug3: send packet: type 20 debug1: SSH2_MSG_KEXINIT sent debug3: receive packet: type 20 debug1: SSH2_MSG_KEXINIT received debug2: local client KEXINIT proposal debug2: KEX algorithms: curve25519-sha256,,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: ,,,rsa-sha2-512,rsa-sha2-256,ssh-rsa,,,,,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519 debug2: ciphers ctos: ,aes128-ctr,aes192-ctr,aes256-ctr,, debug2: ciphers stoc: ,aes128-ctr,aes192-ctr,aes256-ctr,, debug2: MACs ctos: ,,,,,,,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: ,,,,,,,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,,zlib debug2: compression stoc: none,,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-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: host key algorithms: ssh-rsa,ssh-dss debug2: ciphers ctos: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,,aes128-ctr,aes192-ctr,aes256-ctr debug2: ciphers stoc: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,,aes128-ctr,aes192-ctr,aes256-ctr debug2: MACs ctos: hmac-md5,hmac-sha1,hmac-ripemd160,,hmac-sha1-96,hmac-md5-96 debug2: MACs stoc: hmac-md5,hmac-sha1,hmac-ripemd160,,hmac-sha1-96,hmac-md5-96 debug2: compression ctos: none, debug2: compression stoc: none, debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug1: kex: algorithm: diffie-hellman-group14-sha1 debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha1 compression: none debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha1 compression: none debug2: bits set: 1032/2048 debug3: send packet: type 30 debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug3: receive packet: type 31 debug1: Server host key: ssh-rsa SHA256:OHArjVwFi3PAeZ1dpjvNmy1G5U4AY8drwTA+Dh/j4po debug3: hostkeys_foreach: reading file "/Users/julian/.ssh/known_hosts" debug3: record_hostkey: found key type RSA in file /Users/julian/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys from 192.168.1.102 debug3: hostkeys_foreach: reading file "/etc/ssh/ssh_known_hosts" debug1: Host '192.168.1.102' is known and matches the RSA host key. debug1: Found key in /Users/julian/.ssh/known_hosts:1 debug2: bits set: 1019/2048 debug3: send packet: type 21 debug2: set_newkeys: mode 1 debug1: rekey out after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug3: receive packet: type 21 debug1: SSH2_MSG_NEWKEYS received debug2: set_newkeys: mode 0 debug1: rekey in after 4294967296 blocks debug1: Will attempt key: /Users/julian/.ssh/id_rsa RSA SHA256:tpvej9coBUmf7otCvtTtRVxkfWGL2VVvD6v5GUdluT4 debug1: Will attempt key: /Users/julian/.ssh/id_dsa debug1: Will attempt key: /Users/julian/.ssh/id_ecdsa debug1: Will attempt key: /Users/julian/.ssh/id_ed25519 debug1: Will attempt key: /Users/julian/.ssh/id_xmss debug2: pubkey_prepare: done debug3: send packet: type 5 debug3: receive packet: type 6 debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug3: send packet: type 50 debug3: receive packet: type 51 debug1: Authentications that can continue: keyboard-interactive debug3: start over, passed a different list keyboard-interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug3: send packet: type 50 debug2: we sent a keyboard-interactive packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: keyboard-interactive debug3: userauth_kbdint: disable: no info_req_seen debug2: we did not send a packet, disable method debug1: No more authentication methods to try. julian@192.168.1.102: Permission denied (keyboard-interactive). 

Do I need to copy a key from the client to the server or make any changes in the /etc/ssh/ssh_config?

1 Answer

Do I need to copy a key from the client to the server?

No. Not only a key is not needed; the server is configured to disallow public key authentication (PubkeyAuthentication no), so copying any key is futile.

or make any changes in the /etc/ssh/ssh_config?

No. This file on the client matters for the client (ssh). Your client machine seems to be properly configured. The problem is on the server. A file /etc/ssh/ssh_config (if any) on the server doesn't matter for the SSH server (sshd).

From this point on, the answer is only about the server.

I assume you really want keyboard-interactive (as opposed to password). Then you need something that handles it, e.g. PAM.

I'm on Debian 10 and I can reproduce your problem by putting UsePAM no (along with the config you provided) in my sshd_config. I can fix it by changing to UsePAM yes.

I believe Slackware uses PAM too. Check man 5 sshd_config on the server and make sure UsePAM is supported by your sshd.

The fragment of sshd_config you published does not specify UsePAM. The default value is no, so if there's really no UsePAM at all, then it's like UsePAM no. If you're willing to use PAM then explicitly configure

UsePAM yes 

Notes:

• man 5 sshd_config says "for each keyword, the first obtained value will be used". While adding UsePAM yes, make sure there is no UsePAM no earlier in the file.
• After you change sshd_config, reload the SSH daemon (sshd). E.g. in my Debian 10 the right command is systemctl reload ssh.service. Reloading the service should not affect sshd processes that handle the already established connections, so it's safe to do it remotely.
• PAM requires its own configuration. Most likely the Linux distro your server uses provides sane /etc/pam.d/sshd and accompanying files. In such case PAM should work out of the box and without surprises after UsePAM yes kicks in.
• Misconfiguring PAM or starting using it when misconfigured may lock you out of the machine. It's highly advised to keep an elevated shell (sudo -i) running until you confirm that in the end (i.e. after all changes) you can independently log in anew and gain root access anew. In case of trouble use the elevated shell to revert.