Debian Bug report logs - #193546
ssh: Strange authentication failure...

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Klaus Ethgen <Klaus@Ethgen.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: ssh: Strange authentication failure...

Date: Fri, 16 May 2003 14:06:39 +0200

Package: ssh
Version: 1:3.6.1p2-1
Severity: normal

Always I login with ssh to my server I get the following message:
May 16 xx:xx:xx xxxxx ssh(pam_unix)[16758]: authentication failure;
logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=xxxxxxxxxxxxxxxx.ch
user=xxxxx

This hapens independend if I realy sucess or not!

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux hathi 2.4.20-ptrace #1 Sun Mar 23 21:55:26 CET 2003 i686
Locale: LANG=de_DE, LC_CTYPE=de_DE (ignored: LC_ALL set)

Versions of packages ssh depends on:
ii  adduser                     3.50         Add and remove users and groups
ii  debconf                     1.2.35       Debian configuration management sy
ii  libc6                       2.3.1-16     GNU C Library: Shared libraries an
ii  libpam-modules              0.76-9       Pluggable Authentication Modules f
ii  libpam0g                    0.76-9       Pluggable Authentication Modules l
ii  libssl0.9.7                 0.9.7b-2     SSL shared libraries
ii  libwrap0                    7.6-ipv6.1-3 Wietse Venema's TCP wrappers libra
ii  zlib1g                      1:1.1.4-11   compression library - runtime

-- debconf information:
* ssh/ssh2_keys_merged: 
  ssh/insecure_rshd: 
* ssh/privsep_tell: 
  ssh/ancient_version: 
  ssh/protocol2_only: true
* ssh/protocol2_default: 
  ssh/insecure_telnetd: 
* ssh/user_environment_tell: 
* ssh/SUID_client: true
  ssh/privsep_ask: true
  ssh/new_config: true
* ssh/rootlogin_warning: 
* ssh/forward_warning: 
* ssh/run_sshd: true
  ssh/encrypted_host_key_but_no_keygen: 
* ssh/use_old_init_script: true
* ssh/upgrade_to_openssh: true

Message #10 received at 193546@bugs.debian.org (full text, mbox, reply):

From: Brian Thomas <cinnamon@pft.com>

To: Debian Bug Tracking System <193546@bugs.debian.org>

Subject: ssh: Incorrect (?) authentication failure for me, too.

Date: Fri, 16 May 2003 10:15:26 -0700

Package: ssh
Version: 1:3.6.1p2-1
Followup-For: Bug #193546

I am seeing the exact same problem, but only under certain
circumstances, when attempting to scp a file using publickey-based
authentication. Interactive logins do not seem to suffer this problem.
It occurs independently of the client used, the debug output below is
from SecureCRT's 'vcp' copy tool, but I also see the same behavior from
other OpenSSH 3.6.1p2-1 systems. I have not done exhaustive testing to
say for certain that it is limited to scp, only that I know interactive 
does not seem to suffer as far as I can tell whether using password or 
publickey.

It is difficult to correlate exactly, but the impression I get when
watching the syslog output vs. watching the debug output that the error
pops up before publickey authentication is attempted. As you can see
both 'none' and 'keyboard-interactive' fail before publickey is
attempted, but it's important to note I only see ONE failure in the
syslog output. 

Additional information available upon request.

C:\Documents and Settings\me\Desktop>vcp -i "D:\My Documents\Keys\keyfile" -v file user@host.com:
[LOCAL DEBUG] : vcp(4.0.4 (build 413)) : Using SSH2Core v2.3.0.295
[LOCAL DEBUG] : State Change:
SSH_STATE_UNINITIALIZED->SSH_STATE_CONNECTING
[LOCAL DEBUG] : State Change:
SSH_STATE_CONNECTING->SSH_STATE_EXPECT_IDENTIFIER
[LOCAL DEBUG] : connected
[LOCAL DEBUG] : RECV : Remote Identifier = "SSH-1.99-OpenSSH_3.6.1p2
Debian 1:3.
6.1p2-1"
[LOCAL DEBUG] : CAP  : Remote can re-key
[LOCAL DEBUG] : CAP  : Remote sends language in password change requests
[LOCAL DEBUG] : CAP  : Remote sends algorithm name in PK_OK packets
[LOCAL DEBUG] : CAP  : Remote sends algorithm name in public key packets
[LOCAL DEBUG] : CAP  : Remote sends algorithm name in signatures
[LOCAL DEBUG] : CAP  : Remote sends error text in open failure packets
[LOCAL DEBUG] : CAP  : Remote sends name in service accept packets
[LOCAL DEBUG] : CAP  : Remote includes port number in x11 open packets
[LOCAL DEBUG] : CAP  : Remote uses 160 bit keys for SHA1 MAC
[LOCAL DEBUG] : CAP  : Remote supports new diffie-hellman group exchange messages
[LOCAL DEBUG] : CAP  : Remote correctly handles unknown SFTP extensions
[LOCAL DEBUG] : CAP  : Remote is IETF-DRAFT compliant
[LOCAL DEBUG] : SEND : KEXINIT
[LOCAL DEBUG] : State Change:
SSH_STATE_EXPECT_IDENTIFIER->SSH_STATE_INITIAL_KEY
EXCHANGE
[LOCAL DEBUG] : RECV : Read kexinit
[LOCAL DEBUG] : Kex Method = diffie-hellman-group1-sha1
[LOCAL DEBUG] : Host Key Algo = ssh-dss
[LOCAL DEBUG] : Send Cipher = aes128-cbc
[LOCAL DEBUG] : Recv Cipher = aes128-cbc
[LOCAL DEBUG] : Send Mac = hmac-md5
[LOCAL DEBUG] : Recv Mac = hmac-md5
[LOCAL DEBUG] : Compressor = none
[LOCAL DEBUG] : Decompressor = none
[LOCAL DEBUG] : SEND : KEXDH_INIT
[LOCAL DEBUG] : RECV : KEXDH_REPLY
[LOCAL DEBUG] : Hash Packet:
[LOCAL DEBUG] : SEND : NEWKEYS
[LOCAL DEBUG] : State Change:
SSH_STATE_INITIAL_KEYEXCHANGE->SSH_STATE_INITIAL_EXPECT_NEWKEYS
[LOCAL DEBUG] : RECV : NEWKEYS
[LOCAL DEBUG] : State Change:
SSH_STATE_INITIAL_EXPECT_NEWKEYS->SSH_STATE_USERAUTH
[LOCAL DEBUG] : SEND : SERVICE_REQUEST [userauth]
[LOCAL DEBUG] : RECV : SERVICE_ACCEPT
[LOCAL DEBUG] : SENT : USERAUTH_REQUEST [none]
[LOCAL DEBUG] : RECV : USERAUTH_FAILURE, continuations [publickey,password,keybo
ard-interactive]
[LOCAL DEBUG] : SENT : USERAUTH_REQUEST [keyboard-interactive]
[LOCAL DEBUG] : RECV : USERAUTH_FAILURE, continuations [publickey,password,keyboard-interactive]
[LOCAL DEBUG] : SENT : USERAUTH_REQUEST [publickey - unsigned, fingerprint: 07:88:5a:5e:f6:90:6c:93:d2:50:87:c2:8c:c2:22:1e]
[LOCAL DEBUG] : SENT : USERAUTH_REQUEST [publickey - signed,May 2000 Standard]
[LOCAL DEBUG] : RECV : AUTH_SUCCESS
[LOCAL DEBUG] : State Change: SSH_STATE_USERAUTH->SSH_STATE_CONNECTION
[LOCAL DEBUG] : RECV : Server Sftp Version: 3
[LOCAL DEBUG] : RECV : Status 8, Text: Operation unsupported
[LOCAL DEBUG] : SEND : Stat .
[LOCAL DEBUG] : RECV : Attrs, flags = 0000000f Copying: .\filename
[LOCAL DEBUG] : SEND : Open: ./filename, mode 0x1a
[LOCAL DEBUG] : RECV : File Handle[00329468]
[LOCAL DEBUG] : SEND : Close[00329468]
[LOCAL DEBUG] : RECV : Status 0, Text: Success
[LOCAL DEBUG] : State Change: SSH_STATE_CONNECTION->SSH_STATE_DISCONNECTING
[LOCAL DEBUG] : State Change: SSH_STATE_DISCONNECTING->SSH_STATE_CLOSING
[LOCAL DEBUG] : State Change: SSH_STATE_CLOSING->SSH_STATE_CLOSED
[LOCAL DEBUG] : Connected for 2 seconds, 5303 bytes sent, 2580 bytes received

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux malchus 2.4.19 #1 SMP Fri Oct 4 10:52:01 PDT 2002 i686
Locale: LANG=C, LC_CTYPE=C

Versions of packages ssh depends on:
ii  adduser                     3.50         Add and remove users and groups
ii  debconf                     1.2.35       Debian configuration management sy
ii  libc6                       2.3.1-16     GNU C Library: Shared libraries an
ii  libpam-modules              0.76-9       Pluggable Authentication Modules f
ii  libpam0g                    0.76-9       Pluggable Authentication Modules l
ii  libssl0.9.7                 0.9.7b-2     SSL shared libraries
ii  libwrap0                    7.6-ipv6.1-3 Wietse Venema's TCP wrappers libra
ii  zlib1g                      1:1.1.4-11   compression library - runtime

-- debconf information:
* ssh/ssh2_keys_merged: 
  ssh/new_config: true
* ssh/rootlogin_warning: 
  ssh/insecure_rshd: 
* ssh/privsep_tell: 
* ssh/forward_warning: 
  ssh/ancient_version: 
  ssh/protocol2_only: true
  ssh/insecure_telnetd: 
* ssh/user_environment_tell: 
* ssh/run_sshd: true
  ssh/encrypted_host_key_but_no_keygen: 
* ssh/use_old_init_script: true
* ssh/upgrade_to_openssh: true
* ssh/SUID_client: true
  ssh/privsep_ask: true

Message #15 received at 193546@bugs.debian.org (full text, mbox, reply):

From: Remco Blaakmeer <j.blaakmeer@chello.nl>

To: 193546@bugs.debian.org

Subject: I am having the same problem as bug#193546, debug output attached

Date: Fri, 16 May 2003 21:51:13 +0200 (CEST)

I'm having the same problem that is described in this bug. Every time I
login with ssh using public key authentication, a line like this is logged
to the syslog:

May 16 21:42:14 remco3 ssh(pam_unix)[24523]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=localhost  user=remco

Here's some output from sshd -d, I hope it helps :

debug1: sshd version OpenSSH_3.6.1p2 Debian 1:3.6.1p2-1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
socket: Address family not supported by protocol
debug1: Bind to port 443 on 0.0.0.0.
Server listening on 0.0.0.0 port 443.
socket: Address family not supported by protocol
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Server will not fork when running in debugging mode.
Connection from 192.168.1.3 port 39408
debug1: Client protocol version 2.0; client software version OpenSSH_3.6.1p2 Debian 1:3.6.1p2-1
debug1: match: OpenSSH_3.6.1p2 Debian 1:3.6.1p2-1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2 Debian 1:3.6.1p2-1
debug1: permanently_set_uid: 102/65534
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user remco service ssh-connection method none
debug1: attempt 0 failures 0
debug1: Starting up PAM with username "remco"
debug1: PAM setting rhost to "remco3.remconet"
debug1: PAM password authentication failed for remco: Authentication failure
Failed none for remco from 192.168.1.3 port 39408 ssh2
Failed none for remco from 192.168.1.3 port 39408 ssh2
debug1: userauth-request for user remco service ssh-connection method publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 1000/1000 (e=0/0)
debug1: trying public key file /home/remco/.ssh/authorized_keys
debug1: matching key found: file /home/remco/.ssh/authorized_keys, line 7
Found matching RSA key: 5e:c0:90:e0:4e:35:f4:24:52:5a:99:2d:3c:79:80:5d
debug1: restore_uid: 0/0
Postponed publickey for remco from 192.168.1.3 port 39408 ssh2
debug1: userauth-request for user remco service ssh-connection method publickey
debug1: attempt 2 failures 1
debug1: temporarily_use_uid: 1000/1000 (e=0/0)
debug1: trying public key file /home/remco/.ssh/authorized_keys
debug1: matching key found: file /home/remco/.ssh/authorized_keys, line 7
Found matching RSA key: 5e:c0:90:e0:4e:35:f4:24:52:5a:99:2d:3c:79:80:5d
debug1: restore_uid: 0/0
debug1: ssh_rsa_verify: signature correct
Accepted publickey for remco from 192.168.1.3 port 39408 ssh2
Accepted publickey for remco from 192.168.1.3 port 39408 ssh2
debug1: monitor_child_preauth: remco has been authenticated by privileged process
debug1: PAM establishing creds
debug1: PAM setcred failed[6]: Permission denied
debug1: permanently_set_uid: 1000/1000
debug1: Entering interactive session for SSH2.
debug1: fd 4 setting O_NONBLOCK
debug1: fd 8 setting O_NONBLOCK
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 0 request pty-req reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_new: init
debug1: session_new: session 0
debug1: session_pty_req: session 0 alloc /dev/pts/5
debug1: server_input_channel_req: channel 0 request x11-req reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req x11-req
debug1: x11_create_display_inet: Socket family 10 not supported
debug1: bind port 6010: Address already in use
debug1: x11_create_display_inet: Socket family 10 not supported
debug1: bind port 6011: Address already in use
debug1: x11_create_display_inet: Socket family 10 not supported
debug1: bind port 6012: Address already in use
debug1: x11_create_display_inet: Socket family 10 not supported
debug1: fd 11 setting O_NONBLOCK
debug1: channel 1: new [X11 inet listener]
debug1: server_input_channel_req: channel 0 request auth-agent-req@openssh.com reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req auth-agent-req@openssh.com
debug1: temporarily_use_uid: 1000/1000 (e=1000/1000)
debug1: restore_uid: (unprivileged)
debug1: fd 12 setting O_NONBLOCK
debug1: channel 2: new [auth socket]
debug1: server_input_channel_req: channel 0 request shell reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug1: PAM setting tty to "/dev/pts/5"
debug1: PAM establishing creds
debug1: PAM setcred failed[6]: Permission denied
debug1: channel 0: rfd 10 isatty
debug1: fd 10 setting O_NONBLOCK
debug1: Setting controlling tty using TIOCSCTTY.

This looks like it first tries to use password authentication with an
empty password or something like that, before it tries to use public key
authentication.

It seems the authentication failure also causes an extra delay, as would
be normal after a failed password authentication.

Remco

Message #20 received at 193546@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: Klaus Ethgen <Klaus@Ethgen.de>, 193546@bugs.debian.org

Subject: Re: Bug#193546: ssh: Strange authentication failure...

Date: Mon, 19 May 2003 08:37:15 +0100

On Fri, May 16, 2003 at 02:06:39PM +0200, Klaus Ethgen wrote:
> Package: ssh
> Version: 1:3.6.1p2-1
> Severity: normal
> 
> Always I login with ssh to my server I get the following message:
> May 16 xx:xx:xx xxxxx ssh(pam_unix)[16758]: authentication failure;
> logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=xxxxxxxxxxxxxxxx.ch
> user=xxxxx
> 
> This hapens independend if I realy sucess or not!

Yes, this is related to #192207. Both bugs are caused by Solar
Designer's recent security patches; unfortunately, I can't go and hunt
for an upstream fix to backport, because the PAM code has been
completely ripped out and replaced since 3.6.1p2.

Work in progress ...

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]

Message #25 received at 193546@bugs.debian.org (full text, mbox, reply):

From: Darren Tucker <dtucker@zip.com.au>

To: Klaus Ethgen <Klaus@Ethgen.de>, "Theodore Y. Ts'o" <tytso@mit.edu>, oskar@osk.mine.nu

Cc: 193546@bugs.debian.org, 192207@bugs.debian.org, 99168@bugs.debian.org

Subject: Debian bugs 99168, 192207, 193546: fixed in upstream (+patch).

Date: Wed, 06 Aug 2003 16:44:05 +1000

[Message part 1 (text/plain, inline)]

Hi.
	Regarding the following Debian OpenSSH bugs:
#99168: identifying root's password by measuring password-failure delays
#192207: ssh 3.6.1p2-1 introduces a 2-3 second delay when logging in
#193546: ssh: Strange authentication failure... 

	I've been looking at these.  They're interrelated, hence the multiple
update.

	They have all been fixed in the current development tree as part of a
cleanup of auth-passwd.c (rev 1.57, but the diff is large) and new PAM
code (auth-pam.c rev 1.58 + associated changes).

	Attached is a small patch against 3.6.1p2 which should solve all three. 
I would review it very carefully before using it, though, I may have
overlooked something.

	Basically, the issue arises because in the SSH2 protocol, the "none"
authentication method does double duty as "let me log in now if you don't
require authentication" and "otherwise tell me what authentications you
require".

	The client starts an authentication by asking the server for "none"
authentication, and the server must either allow the login at that point
(if the user has no passsword and empty passwords are permitted) or reply
with a list of allowed methods.  To determine if the "none" login should
be allowed, auth_password is called with a password of "", and if that
fails it proceeds with the rest of the authentication protocol.

	Previously, auth_password would return as soon as any of its tests
failed, so as long as the server was configured with "PermitEmptyPasswords
no" the attempt to authenticate with the empty password would fail
immediately (before asking PAM).  Unfortunately this leaked information
(eg about the state of PermitRootLogin).

	The "owl-always-auth" patch added for 3.6.1p2 changed the way
auth_password worked.  Instead of failing immediately, it set a flag on
failure but tried all the tests anyway.  Unfortunately this meant the
"none" authentication tries a PAM authentication without a password, which
fails and adds the delay and log message.  It also meant that regardless
of the PermitRootLogin setting, a PAM authentication was always attempted
for root, which returns much faster when the password is correct and thus
leaks information (ie #99168 re-occurred).

	The attached patch:
a) returns immediately for empty passwords if PermitEmptyPasswords=no.
b) makes an invalid call to auth_pam_password if PermitRootLogin=no which
will always fail.

	Note that a) will leak the PermitEmptyPasswords setting; I don't see any
way around that without imposing a delay on *all* logins.  This is
behaviour is consistent with the current development tree.

	Also note that b) will leak info on whether or not root actually has a
password.  I suspect that could be determined easily in other ways :-)

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

[openssh-debian_login.patch (text/plain, inline)]

Index: auth-passwd.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth-passwd.c,v
retrieving revision 1.51.4.1
diff -u -r1.51.4.1 auth-passwd.c
--- auth-passwd.c	29 Apr 2003 09:12:08 -0000	1.51.4.1
+++ auth-passwd.c	6 Aug 2003 06:16:36 -0000
@@ -117,14 +117,22 @@
 	/* deny if no user. */
 	if (pw == NULL)
 		ok = 0;
+	if (*password == '\0' && options.permit_empty_passwd == 0)
+		return 0;
 #ifndef HAVE_CYGWIN
 	if (pw && pw->pw_uid == 0 && options.permit_root_login != PERMIT_YES)
 		ok = 0;
 #endif
-	if (*password == '\0' && options.permit_empty_passwd == 0)
-		ok = 0;
 
 #if defined(USE_PAM)
+	/*
+	 * If the user logging in is root and RootLogin=no, always attempt
+	 * an invalid root login to prevent leaking timing information
+	 */
+	if (pw && pw->pw_uid == 0 && options.permit_root_login != PERMIT_YES) {
+		auth_pam_password(authctxt, "");
+		return 0;
+	}
 	return auth_pam_password(authctxt, password) && ok;
 #elif defined(HAVE_OSF_SIA)
 	if (!ok)

Message #32 received at 193546-quiet@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: Darren Tucker <dtucker@zip.com.au>, 192207@bugs.debian.org

Cc: 99168-quiet@bugs.debian.org, 193546-quiet@bugs.debian.org, control@bugs.debian.org

Subject: Re: Bug#192207: Updated patch

Date: Wed, 3 Sep 2003 01:30:59 +0100

tags 99168 pending
tags 192207 pending
tags 193546 pending
thanks

On Sat, Aug 09, 2003 at 03:47:24PM +1000, Darren Tucker wrote:
> 	Attached is an updated patch that should address a couple of issues with
> the previous one:
> 
> a) The short-cut for permitemptypassword=no is in the authentication
> negotiation.  This means that if the user actually supplies a null
> password, it will be logged.
> 
> b) In the case of permitrootlogin=no, attempt an auth with a totally bogus
> password (idea from openwall linux).
> 
> 	Again, review carefully before using it, I may have overlooked something.

I've thought about this carefully and tested all the interesting
combinations I can think of, and it seems fine. I'll upload to Debian
unstable shortly, at which point no doubt it'll break for half a dozen
people with strange setups, but that's life. ;)

Thanks!

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]

Message #37 received at 193546-close@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: 193546-close@bugs.debian.org

Subject: Bug#193546: fixed in openssh 1:3.6.1p2-6

Date: Wed, 03 Sep 2003 16:26:05 -0400

Source: openssh
Source-Version: 1:3.6.1p2-6

We believe that the bug you reported is fixed in the latest version of
openssh, which is due to be installed in the Debian FTP archive:

openssh_3.6.1p2-6.diff.gz
  to pool/main/o/openssh/openssh_3.6.1p2-6.diff.gz
openssh_3.6.1p2-6.dsc
  to pool/main/o/openssh/openssh_3.6.1p2-6.dsc
ssh-askpass-gnome_3.6.1p2-6_i386.deb
  to pool/main/o/openssh/ssh-askpass-gnome_3.6.1p2-6_i386.deb
ssh_3.6.1p2-6_i386.deb
  to pool/main/o/openssh/ssh_3.6.1p2-6_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 193546@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Colin Watson <cjwatson@debian.org> (supplier of updated openssh package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Wed,  3 Sep 2003 19:14:02 +0100
Source: openssh
Binary: ssh-askpass-gnome ssh
Architecture: source i386
Version: 1:3.6.1p2-6
Distribution: unstable
Urgency: medium
Maintainer: Matthew Vernon <matthew@debian.org>
Changed-By: Colin Watson <cjwatson@debian.org>
Description: 
 ssh        - Secure rlogin/rsh/rcp replacement (OpenSSH)
 ssh-askpass-gnome - under X, asks user for a passphrase for ssh-add
Closes: 99168 192207 193546 197576 208036
Changes: 
 openssh (1:3.6.1p2-6) unstable; urgency=medium
 .
   * Use a more CVS-friendly means of setting SSH_VERSION.
   * Update Brazilian Portuguese debconf template translation (thanks, Andre
     Luis Lopes; closes: #208036).
   * Don't run 'sshd -t' in init script if the server isn't to be run
     (closes: #197576).
   * Fix login delay, spurious auth.log entry, and PermitRootLogin
     information leakage due to PAM issues with upstream's recent security
     update (thanks, Darren Tucker; closes: #99168, #192207, #193546).
   * Policy version 3.6.1: recode this changelog to UTF-8.
Files: 
 79a152667d63253e2086fa31f78425f1 847 net standard openssh_3.6.1p2-6.dsc
 0ed10571bcc3518bd5c10fd8f6418438 80668 net standard openssh_3.6.1p2-6.diff.gz
 5ae4629042fc19ef0f5b422ddc5bd6e2 645280 net standard ssh_3.6.1p2-6_i386.deb
 9a738e3aa3c8bd9512e5166772b4b65e 42648 gnome optional ssh-askpass-gnome_3.6.1p2-6_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Colin Watson <cjwatson@debian.org> -- Debian developer

iD8DBQE/VjhV9t0zAhD6TNERAnPdAJwJY8w0hKP7YjqCIXX88LtblA9sggCeMSar
uMuo5E2Omu+KC+f0zFA50xc=
=Lwmi
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.