Bug#955725: marked as done (openssh-server: working passwordless authentication with ssh-keygen key suddently fails)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Bug#955725: marked as done (openssh-server: working passwordless authentication with ssh-keygen key suddently fails)

Debian Bug Tracking System
Your message dated Sat, 4 Apr 2020 11:58:05 +0100
with message-id <[hidden email]>
and subject line Re: Bug#955725: The bug is due to someone changing the permission of /root
has caused the Debian Bug report #955725,
regarding openssh-server: working passwordless authentication with ssh-keygen key suddently fails
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [hidden email]

955725: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955725
Debian Bug Tracking System
Contact [hidden email] with problems

Package: openssh-server
Version: 1:8.2p1-4
Severity: important

I had setup rsync backup without passord that was perfectly working. Suddently it was
stuck by asking remote passwd for each rsync command. ssh passwordless for root user
was indeed borken.

Even regenerating the key in case of lengh and algorythm change did not fix the
problem. Did something change in the config?

It started April 2.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.30 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openssh-server depends on:
ii  adduser                3.118
ii  debconf [debconf-2.0]  1.5.73
ii  dpkg                   1.20.0
ii  libaudit1              1:2.8.5-3
ii  libc6                  2.31-0experimental0
ii  libcom-err2            1.46~WIP.2019.10.03-1
ii  libcrypt1              1:4.4.15-1
ii  libgssapi-krb5-2       1.17-7
ii  libkrb5-3              1.17-7
ii  libpam-modules         1.3.1-5
ii  libpam-runtime         1.3.1-5
ii  libpam0g               1.3.1-5
ii  libselinux1            3.0-1+b2
ii  libssl1.1              1.1.1f-1
ii  libsystemd0            245.4-1
ii  libwrap0               7.6.q-30
ii  lsb-base               11.1.0
ii  openssh-client         1:8.2p1-4
ii  openssh-sftp-server    1:8.2p1-4
ii  procps                 2:3.3.16-4
ii  runit-helper           2.8.15
ii  ucf                    3.0038+nmu1
ii  zlib1g                 1:1.2.11.dfsg-2

Versions of packages openssh-server recommends:
ii  libpam-systemd [logind]  245.4-1
ii  ncurses-term             6.2-1
ii  xauth                    1:1.0.10-1

Versions of packages openssh-server suggests:
ii  ksshaskpass [ssh-askpass]  4:5.17.5-2
pn  molly-guard                <none>
pn  monkeysphere               <none>
pn  ufw                        <none>

-- debconf information:
  openssh-server/password-authentication: true
* ssh/use_old_init_script: true
* openssh-server/permit-root-login: false
  ssh/disable_cr_auth: false

On Sat, Apr 04, 2020 at 11:48:52AM +0200, Eric Valette wrote:
> Enabling the authentication debug on both server, I discovered that the
> ownership of the /root directory had been changed to my regular machine user
> instead of root.root on the TWO MACHINES.
> I did not issue a chmod on the machines as far as I know, especially on one
> of the two machines that seldom log in.
> Dunno what has been causing that but I suspect a wrong install script.

OK.  This certainly isn't something that the openssh packaging does, so
closing this bug.

Colin Watson                                       [[hidden email]]