1

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-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,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,curve25519-sha256@libssh.org,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-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa,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,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,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,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: ciphers stoc: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: MACs ctos: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
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?

Slack83
  • 21

1 Answers1

1

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.
Kamil Maciorowski
  • 81,893