[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#481939: marked as done (Anonymous authentication)



Your message dated Mon, 19 May 2008 22:47:48 +0100
with message-id <20080519214748.GK16645@riva.ucam.org>
and subject line Re: Bug#481939: Anonymous authentication
has caused the Debian Bug report #481939,
regarding Anonymous authentication
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 owner@bugs.debian.org
immediately.)


-- 
481939: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481939
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: openssh-server
Version: 1:4.3p2-9etch2
Severity: minor

No easy way to do anonymous authentication.
I had designated a key as anonnoymous and published it, and with the
recent blacklisting of keys, it got blacklisted. There should be a way
to allow logins to an account designated as anonymous with any
credentials. Arrg.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.22-3-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages openssh-server depends on:
ii  add 3.102                                Add and remove users and groups
ii  deb 1.5.11etch1                          Debian configuration management sy
ii  dpk 1.13.25                              package maintenance system for Deb
ii  lib 2.3.6.ds1-13etch5                    GNU C Library: Shared libraries
ii  lib 1.39+1.40-WIP-2006.11.14+dfsg-2etch1 common error description library
ii  lib 1.4.4-7etch5                         MIT Kerberos runtime libraries
ii  lib 0.79-5                               Pluggable Authentication Modules f
ii  lib 0.79-5                               Runtime support for the PAM librar
ii  lib 0.79-5                               Pluggable Authentication Modules l
ii  lib 1.32-3                               SELinux shared libraries
ii  lib 0.9.8c-4etch3                        SSL shared libraries
ii  lib 7.6.dbs-13                           Wietse Venema's TCP wrappers libra
ii  ope 0.1.1                                list of blacklisted OpenSSH RSA an
ii  ope 1:4.3p2-9etch2                       Secure shell client, an rlogin/rsh
ii  zli 1:1.2.3-13                           compression library - runtime

openssh-server recommends no packages.

-- debconf information:
  ssh/vulnerable_host_keys:
  ssh/new_config: true
* ssh/use_old_init_script: true
* ssh/disable_cr_auth: false
  ssh/encrypted_host_key_but_no_keygen:



--- End Message ---
--- Begin Message ---
On Mon, May 19, 2008 at 11:37:38AM -0600, Ben Hildred wrote:
> No easy way to do anonymous authentication.
> I had designated a key as anonnoymous and published it, and with the
> recent blacklisting of keys, it got blacklisted. There should be a way
> to allow logins to an account designated as anonymous with any
> credentials. Arrg.

This sounds like a misunderstanding. Your key was blacklisted not
because it was used for anonymous authentication, but because it was
generated with a vulnerable version of OpenSSL and thus anyone on the
Internet can come into possession of the corresponding private key with
little effort.

If you are sure that you wish to allow it anyway, set
'PermitBlacklistedKeys yes' in /etc/ssh/sshd_config. However, I would
strongly recommend that you simply regenerate the key! This is not
especially difficult (yes, I know, it's a bit of a pain, but much easier
than say GPG keys or SSL certificates would be), and I'm pretty
confident that this isn't going to be a problem again.

I do not intend to offer finer-grained control than this; these keys
need to die as soon as possible.

Regards,

-- 
Colin Watson                                       [cjwatson@debian.org]


--- End Message ---

Reply to: