Bug#261771: ssh: breaks debian rules by hacking files in /etc/pam.d

["John D. Hendrickson" <jdh@hend.net>]

Package: ssh
Version: 1:3.4p1-1
Severity: normal



-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux link 2.4.20-mm #1 Tue Feb 24 17:47:00 EST 2004 i586
Locale: LANG=C, LC_CTYPE=C

Versions of packages ssh depends on:
ii  adduser                       3.47       Add and remove users and groups
ii  debconf                       1.0.32     Debian configuration management sy
ii  libc6                         2.2.5-11.2 GNU C Library: Shared libraries an
ii  libpam-modules                0.72-35    Pluggable Authentication Modules f
ii  libpam0g                      0.72-35    Pluggable Authentication Modules l
ii  libssl0.9.6                   0.9.6c-2   SSL shared libraries
ii  libwrap0                      7.6-9      Wietse Venema's TCP wrappers libra
ii  zlib1g                        1:1.1.4-1  compression library - runtime


I couldn't use rlogin / rsh after dist-upgrade becuase ssh had improperly
place himself in the /etc/pam.d/common-* files.

I did have ssh installed on all machines: it just didn't work where before
upgrade it had.

I don't like ssh.  Its a backward idea.  It has a bad usefullness record.

And some packager made RSYC depend on ssh and put it in as a default compile
option:
	--> WHICH CAUSED ALL MY RSYNC SCRIPTS TO FAIL
	--> WHICH IS MY DISK MIRRORING YOU )(*^&#)(&@*#$_

This is obviously NOT the rsync author's intention, as the manpage says you
must use "--rsh=ssh" to use ssh.  But now I have to use "--rsh=rsh" to NOT
use ssh.

It has in the past told users it was offering a secure shell when infact it 
did no such thing without hours of backwards configurations.  The most recent
version looks as if it has keys configured.  I'm not at all supprised to see
users are saying it is not using any security for logins.  Not at all.

It isn't compatible with telnet.  It breaks X - though it has found its way
into GNOME projects files anyway.

Its not transport compatible, not secure, hard to configure, pulls wool over
users eyes by calling itself a secure shell in its manpage.  It's hardly
an openvpn or kerberos.  It's practically inadvisable to install.

It has no place being "standard" or "base" at all - if you check the all too
lengthy bug logs.