Can't disable password login ssh

[notbob11]

I read about this in an ancient post (2014) but did not see a resolution.

I have both Leap 15.6 and Tumbleweed 20250417 installed on an HP laptop.

The Leap has a file /etc/ssh/sshd_config and I have set PasswordAuthentication no. My ~/.ssh folder has permissions set correctly, and contains an id_rsa file. When I connect with ssh, I am asked for a password, which is my regular user password. It allows me to connect.

My understanding is that the login should fail in this case.

When I ask for verbosity while connecting, there are no messages indicating failures that I can tell.

The Tumbleweed does not even have a sshd_config file, at least not in the /etc/ssh folder. When I connect with ssh, I am asked for the id_rsa password, which is what I want.

Is there an easy fix for this? Is it a bug?

[mhurron]

No one can help you without logs.

[knurpht]

Do: cat /etc/ssh/sshd_config | susepaste and post the returned paste.opensuse.org link here.

It is not clear to me from where you are trying to reconnect to what. Please elaborate. My feeling is that you are barking up the wrong tree.

[hendersj]

@notbob11

The Tumbleweed does not even have a sshd_config file, at least not in the /etc/ssh folder. When I connect with ssh, I am asked for the id_rsa password, which is what I want.

Tumbleweed uses a defaults setting that puts configuration files in /usr/etc/, and overrides go in /etc. So what you can do to set the configuration system-wide is copy the /usr/etc/ssh/sshd_config file to /etc/ssh/sshd_config and change the configuration there.

[arvidjaar]

@notbob11

When I connect with ssh

You connect with ssh from where to where?

@notbob11

My understanding is that the login should fail in this case.

In which case? I really do not understand what you are asking. There are a lot of different settings on a client and a server affecting login and you did not describe them.

Anyway, sshd can request password using either PasswordAuthentication or KbdInteractiveAuthentication (alias ChallengeResponseAuthentication) which are two different login methods in SSH protocol. So, any use of “password login” is highly ambiguous.

[nrickert]

@notbob11

Is there an easy fix for this? Is it a bug?

Yes, there is an easy “fix”. No it is not a bug.

You can copy “/usr/etc/ssh/sshd_config” to “/etc/ssh/sshd_config” and then modify that copy. But it is better to use the preferred method. Just create a drop-in file in “/etc/ssh/sshd_config.d/” and put your changes there. My drop in file for this is “/etc/ssh/sshd_config.d/01-auth.conf”

[arvidjaar]

@nrickert

Just create a drop-in file in “/etc/ssh/sshd_config.d/”

E-h-h … to the extent I could understand OP the Tumbleweed does what OP wants. It is Leap which seemingly behaves “incorrectly”. But we do not even know whether Leap and/or Tumbleweed are a client or a server.

[nrickert]

@arvidjaar

It is Leap which seemingly behaves “incorrectly”.

The OP does not say which version of Leap he is referring to, though he does mention 15.6. Drop in files work fine with Leap 15.6, but I don’t think they were supported in Leap 15.5 or earlier.

[hendersj]

However, something I think we both missed is that OP’s issue isn’t on the TW system, but on the Leap system. He’s trying to set it up so it doesn’t accept passwords, but it does.

Setting PasswordAuthentication no in sshd_config should be sufficient on the server end. There’s nothing on the client end that will override this (indeed, that would make things less secure)

@notbob11 - seeing what’s in /etc/ssh/sshd_config will help us understand what’s going on. Knupht’s susepaste command is the best option to help us see how the system in question is configured.

[arvidjaar]

@hendersj

Setting PasswordAuthentication no in sshd_config should be sufficient on the server end.

Sufficient for what?

[hendersj]

Disabling password logins. He wants to use public key authentication only.

[arvidjaar]

@hendersj

Disabling password logins.

No, it is not. Read my earlier reply.

[hendersj]

@arvidjaar

No, it is not. Read my earlier reply.

Somehow I missed that as well. Time for my morning caffeine, I guess.

I was literally just looking at that on a test system to see if that might be the issue.

And, indeed, it is. @notbob11 - if you execute ssh with -v, you’ll see something like this at the end of the messages if it is using kbdInteractive authentication:

debug1: Next authentication method: keyboard-interactive
(jhenderson@172.16.42.184) Password: 

Disabling that method, per arvidjaar’s comment, will resolve that.

[notbob11]

@hendersj

Setting PasswordAuthentication no in sshd_config should be sufficient on the server end.

Precisely. I should not be able to log into the Leap system from any other machine without the id_rsa file installed, and should not be asked for any other type of password.
At first I only changed two setting in the default sshd_conf file
PasswordAuthentication no
PermitRootLogin no

I could connect with ssh using my regular password from, any other machine until I changed
KbdInteractiveAuthentication no

and logins are denied entirely.

Here is a connection attempt.

Blockquote
me@stars-end:~$ ssh saturn -vvv
OpenSSH_7.9p1 Debian-10+deb10u4, OpenSSL 1.1.1n 15 Mar 2022
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving “saturn” port 22
debug2: ssh_connect_direct
debug1: Connecting to saturn [192.168.0.50] port 22.
debug1: Connection established.
debug1: identity file /home/me/.ssh/id_rsa type 0
debug1: identity file /home/me/.ssh/id_rsa-cert type -1
debug1: identity file /home/me/.ssh/id_dsa type -1
debug1: identity file /home/me/.ssh/id_dsa-cert type -1
debug1: identity file /home/me/.ssh/id_ecdsa type -1
debug1: identity file /home/me/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/me/.ssh/id_ed25519 type -1
debug1: identity file /home/me/.ssh/id_ed25519-cert type -1
debug1: identity file /home/me/.ssh/id_xmss type -1
debug1: identity file /home/me/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u4
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.6
debug1: match: OpenSSH_9.6 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to saturn:22 as ‘me’
debug3: hostkeys_foreach: reading file “/home/me/.ssh/known_hosts”
debug3: record_hostkey: found key type ECDSA in file /home/me/.ssh/known_hosts:9
debug3: load_hostkeys: loaded 1 keys from saturn
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
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,kex-strict-c-v00@openssh.com
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
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: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,ext-info-s,kex-strict-s-v00@openssh.com
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr
debug2: ciphers stoc: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr
debug2: MACs ctos: hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512
debug2: MACs stoc: hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512
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
debug3: will use strict KEX ordering
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:7Vq/eL1N3Ekx0v8y+yiX41yaAL4Xw2/2tCj+thWdPT0
debug3: hostkeys_foreach: reading file “/home/me/.ssh/known_hosts”
debug3: record_hostkey: found key type ECDSA in file /home/me/.ssh/known_hosts:9
debug3: load_hostkeys: loaded 1 keys from saturn
debug3: hostkeys_foreach: reading file “/home/me/.ssh/known_hosts”
debug3: record_hostkey: found key type ECDSA in file /home/me/.ssh/known_hosts:10
debug3: load_hostkeys: loaded 1 keys from 192.168.0.50
debug1: Host ‘saturn’ is known and matches the ECDSA host key.
debug1: Found key in /home/me/.ssh/known_hosts:9
debug3: send packet: type 21
debug1: ssh_packet_send2_wrapped: resetting send seqnr 3
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: ssh_packet_read_poll2: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: Will attempt key: /home/me/.ssh/id_rsa RSA SHA256:pJ1sekqTnItYx1KNxQulcp+8KLJFk+KhcL1pNPCXhlw
debug1: Will attempt key: /home/me/.ssh/id_dsa
debug1: Will attempt key: /home/me/.ssh/id_ecdsa
debug1: Will attempt key: /home/me/.ssh/id_ed25519
debug1: Will attempt key: /home/me/.ssh/id_xmss
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ecdsa-sha2-nistp256,sk-ecdsa-sha2-nistp256@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,sk-ssh-ed25519@openssh.com,rsa-sha2-256,rsa-sha2-512>
debug1: kex_input_ext_info: publickey-hostbound@openssh.com (unrecognised)
debug1: kex_input_ext_info: ping@openssh.com (unrecognised)
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: publickey
debug3: start over, passed a different list publickey
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/me/.ssh/id_rsa RSA SHA256:pJ1sekqTnItYx1KNxQulcp+8KLJFk+KhcL1pNPCXhlw
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/me/.ssh/id_dsa
debug3: no such identity: /home/me/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/me/.ssh/id_ecdsa
debug3: no such identity: /home/me/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/me/.ssh/id_ed25519
debug3: no such identity: /home/me/.ssh/id_ed25519: No such file or directory
debug1: Trying private key: /home/me/.ssh/id_xmss
debug3: no such identity: /home/me/.ssh/id_xmss: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
me@saturn: Permission denied (publickey).

[knurpht]

@hendersj

So what you can do to set the configuration system-wide is copy the /usr/etc/ssh/sshd_config file to /etc/ssh/sshd_config and change the configuration there.

You can, but should better do it by creating a .conf file in /etc/ssh/sshd_config.d/

[nrickert]

@notbob11

debug1: Offering public key: /home/me/.ssh/id_rsa RSA

It seems that you want to use an RSA key.

Recent versions of openssh have deprecated RSA keys that are too short. I’m using a 3072 bit key, which works. You might need to create a newer key.

[hendersj]

@notbob11

Precisely. I should not be able to log into the Leap system from any other machine without the id_rsa file installed, and should not be asked for any other type of password.
At first I only changed two setting in the default sshd_conf file
PasswordAuthentication no
PermitRootLogin no

I could connect with ssh using my regular password from, any other machine until I changed
KbdInteractiveAuthentication no

As noted later in the discusison, though, the KbdInteractiveAuthentication setting is also needed, because entering a password is a “keyboard interactive authentication” method.

That’s as intended. See man sshd_config and look at that setting’s description.

You need both settings to disable password-based authentication.

[karlmistelberger]

@notbob11

Is there an easy fix for this?

You may always want to query what is available and disable everything in /etc/ssh/ but the method you want to use:

i4130:~ # sshd -T|grep authentication
hostbasedauthentication no
pubkeyauthentication yes
kerberosauthentication no
gssapiauthentication no
passwordauthentication no
kbdinteractiveauthentication no
authenticationmethods publickey
i4130:~ # 

Local settings are:

i4130:~ # cat /etc/ssh/sshd_config
PermitRootLogin yes
AuthenticationMethods publickey
PasswordAuthentication no
KbdInteractiveAuthentication no
i4130:~ #