0

I know this question has been asked one million times - but all the input I found so far didn't help.

Long story short: I cannot SSH into my Raspi anymore.

Yesterday I've installed Raspberry Pi OS x64 as a clean installation from scratch (no upgrade installation). I spent all the day installing and configuring several things, e. g.:

  • Docker
  • ufw
  • fail2ban
  • nginx

I cannot count how many times I SSHed yesterday into my Raspi after installation - maybe three dozen times, without any issues.

This morning I wanted to continue my work, but ssh myRaspiUser@myRaspi gives Permission denied, please try again.. myRaspi has sudo rights.
The same happens for ssh pi@myRaspi. Both accounts are set up for password authentication.

There is another user raspiUserWithoutPassword which uses publickey authentication - and this one can still connect.

My client is a Windows 10 machine with all the latest updates. In all cases, I'm using the same windows account MyWindowsUser for connecting with pi, myRaspiUser or raspiUserWithoutPassword.

When connecting the Raspi via HDMI cable to my screen and log in via UI, I can still access all accounts without any issues.

Here are some things I already tried:

  • ping myRaspi
Pinging myRaspi.fritz.box [192.168.178.20] with 32 bytes of data:
Reply from 192.168.178.21: bytes=32 time=65ms TTL=64
Reply from 192.168.178.21: bytes=32 time=3ms TTL=64
Reply from 192.168.178.21: bytes=32 time=3ms TTL=64
Reply from 192.168.178.21: bytes=32 time=3ms TTL=64

Ping statistics for 192.168.178.21:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 3ms, Maximum = 65ms, Average = 18ms
  • ssh -v myRaspiUser@myRaspi
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
debug1: Connecting to myRaspi [192.168.178.21] port 22.
debug1: Connection established.
debug1: identity file C:\\Users\\MyWindowsUser/.ssh/id_rsa type 0
debug1: identity file C:\\Users\\MyWindowsUser/.ssh/id_rsa-cert type -1
debug1: identity file C:\\Users\\MyWindowsUser/.ssh/id_dsa type -1
debug1: identity file C:\\Users\\MyWindowsUser/.ssh/id_dsa-cert type -1
debug1: identity file C:\\Users\\MyWindowsUser/.ssh/id_ecdsa type -1
debug1: identity file C:\\Users\\MyWindowsUser/.ssh/id_ecdsa-cert type -1
debug1: identity file C:\\Users\\MyWindowsUser/.ssh/id_ed25519 type -1
debug1: identity file C:\\Users\\MyWindowsUser/.ssh/id_ed25519-cert type -1
debug1: identity file C:\\Users\\MyWindowsUser/.ssh/id_xmss type -1
debug1: identity file C:\\Users\\MyWindowsUser/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.4p1 Debian-5
debug1: match: OpenSSH_8.4p1 Debian-5 pat OpenSSH* compat 0x04000000
debug1: Authenticating to myRaspi:22 as 'myRaspiUser'
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:9Q0YBbDhnTvnJ/Jt4IEdTN29L6dFcdfR5iRjl9L8Qqk
debug1: Host 'myRaspi' is known and matches the ECDSA host key.
debug1: Found key in C:\\Users\\MyWindowsUser/.ssh/known_hosts:3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory
debug1: Will attempt key: C:\\Users\\MyWindowsUser/.ssh/id_rsa RSA SHA256:mX01zgqbmFoeRnLdwc04tX4ekPg0s/yH6Skh8aT+Mlw
debug1: Will attempt key: C:\\Users\\MyWindowsUser/.ssh/id_dsa
debug1: Will attempt key: C:\\Users\\MyWindowsUser/.ssh/id_ecdsa
debug1: Will attempt key: C:\\Users\\MyWindowsUser/.ssh/id_ed25519
debug1: Will attempt key: C:\\Users\\MyWindowsUser/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: C:\\Users\\MyWindowsUser/.ssh/id_rsa RSA SHA256:mX01zgqbmFoeRnLdwc04tX4ekPg0s/yH6Skh8aT+Mlw
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: C:\\Users\\MyWindowsUser/.ssh/id_dsa
debug1: Trying private key: C:\\Users\\MyWindowsUser/.ssh/id_ecdsa
debug1: Trying private key: C:\\Users\\MyWindowsUser/.ssh/id_ed25519
debug1: Trying private key: C:\\Users\\MyWindowsUser/.ssh/id_xmss
debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: No such file or directory
myRaspiUser@myRaspi's password:
Permission denied, please try again.
  • ls -la /dev/tty
crw-rw-rw- 1 root tty 5, 0 Jun  6 12:21 /dev/tty
  • sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere                  
Nginx Full                 ALLOW       Anywhere                  
22/tcp (v6)                ALLOW       Anywhere (v6)             
Nginx Full (v6)            ALLOW       Anywhere (v6)
  • Using IP address instead of host name → same errors
  • Using -o StrictHostKeyChecking=no → same errors
  • Calling ssh pi@127.0.0.1 when locally logged in as myRaspiUser (Raspi is attached via HDMI cable) → same errors
  • Simplified password (HelloWorld123) to avoid any typos → same errors
  • grep PasswordAuthentication /etc/ssh/sshd_config
#PasswordAuthentication yes
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication, then enable this but set PasswordAuthentication
  • ls -ld /run (as user myRaspi, no root/sudo)
drwr-xr-x 31 root root 920 Jun 6 18:23 /run
  • ls -ld /var/run (as user myRaspi, no root/sudo)
lrwxrwxrwx 1 root 4 Apr 4 16:25 /var/run -> /run
  • cat /usr/lib/tmpfiles.d/sshd.conf (as user myRaspi, no root/sudo)
cat: /usr/lib/tmpfiles.d/sshd.conf: No such file or directory

After several attempts, I'm receiving ssh_dispatch_run_fatal: Connection to 192.168.178.21 port 22: Connection timed out. I assume this is due to fail2ban and I can retry after a couple of minutes.

The question is pretty simple ^^ how can I SSH into my Raspi again using password authentication?

Thanks in advance

Improve this question
9
  • What does grep PasswordAuthentication /etc/ssh/sshd_config say?
    – Ljm Dullaart
    Jun 6, 2022 at 11:28
  • I've updated my question with the output - seems like only comments
    – mu88
    Jun 6, 2022 at 11:39
  • Remove the # before PasswordAuthentication yes and try again. Restart sshd after you've edited the file.
    – Ljm Dullaart
    Jun 6, 2022 at 12:01
  • Still fails with the same error
    – mu88
    Jun 6, 2022 at 12:11
  • You said that you can log-in from the console. Can you (from the console as root) stop sshd ; run /usr/sbin/sshd -d in the foreground ; next try to login from your Windows and see if that produces any usefull information?
    – Ljm Dullaart
    Jun 6, 2022 at 12:29

2 Answers 2

Reset to default
1

We're more or less debugging in the comments. Someone else who comes across this question won't want to go through all the comments, so these are the steps we took.

  1. Is password authentication allowed for ssh? Normally, it should be. That is why the line
# PasswordAuthentication yes

in /etc/ssh/sshd_config is commented out. If the line is set to no, this would be a reason why login with password would not work.

  1. To see what is going on, we launched the sshd on the host in the foreground with the debug option. Do this as root (or sudo'ed). This can produce usefull information.
sudo sshd -d
  1. Normally, the directory /run/sshd is created automatically. The creation should be specified in /usr/lib/tmpfiles.d/sshd.conf, which should contain
d /run/sshd 0755 root root

Manually creating /run/sshd with the owner and permissions above may result in a working password login on sshd. However, that will be gone after a reboot. So, for a test, create /run/sshd manually, for permanence, create the /usr/lib/tmpfiles.d/sshd.conf.

  1. Sshd now complains about not having host keys. Which is odd as it worked before. The host-keys should be available in /etc/ssh/; a simple ls should confirm whether they are there. If they are, sshd should be able to find them.

For good measure, you can delete them and re-create them:

rm /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server

Beware that all clients will give you a message that hostkeys have changed and that you might be victim of a man-in-the-middle attack. You're not; you did this yourself. Updating the known_hosts on the clients will solve this error message.

Improve this answer
10
  • Thank you! I will try in my lunch break. And what should be the content of the file /usr/lib/tmpfiles.d/sshd.conf? Empty? Or the same as /etc/ssh/sshd_config?
    – mu88
    Jun 7, 2022 at 6:11
  • 1
    d /run/sshd 0755 root root
    – Ljm Dullaart
    Jun 7, 2022 at 6:14
  • Still not working, now /usr/sbin/sshd -d returns three statements debug1: Unable to load host key: /etc/ssh/<<file>> and sshd: no hostkeys available -- exiting
    – mu88
    Jun 7, 2022 at 11:04
  • don't know what you did with ssh on your Pi, but you probably shouldn't do that again ;-). Next step added to the answer.
    – Ljm Dullaart
    Jun 7, 2022 at 15:56
  • I checked and /etc/ssh already contained six files ssh_host_*. When opening e. g. nano /etc/ssh/ssh_host_rsa_key, the file is empty. But when running sudo nano /etc/ssh/ssh_host_rsa_key, I see the RSA private key. The same after recreating the files and I still cannot login. Are some privileges missing? Thank you for your patience with me! It's so frustrating... I double-checked literally every single command which I executed on Sunday - not a single one is related to ssh - I have absolutely no clue what happened from Sunday to Monday
    – mu88
    Jun 7, 2022 at 17:35
0

I had to add the user to /etc/ssh/sshd_config like this:

AllowUsers myRaspiUser

But I have no clue why I have to do this on my own and why this was not necessary before 🤔

Improve this answer
2
  • 1
    AllowUsers specifies a list of local accounts that may accept SSH connections. The list is definitive: any account not listed cannot receive SSH connections. Although this might now work, this is not the solution. What is the uid of your myRaspiUser?
    – Ljm Dullaart
    Jun 8, 2022 at 12:25
  • Executing id returns uid=1001(myRaspiUser) gid=1001(myRaspiUser) groups=1001(myRaspiUser),4(adm),20(dialout),24(cdrom),27(sudo),29(audio),44(video),46(plugdev),60(games),100(users),104(input),108(netdev),995(docker),997(gpio),998(i2c),999(spi)
    – mu88
    Jun 8, 2022 at 15:11

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.