Re: proftpd and sshd delays
Ok, I've identified the problem, identd isn't the problem, reverse DNS
is. When I disabled reverse DNS on the proftpd system, the timeout
problem vanished, server now responds instantly. Solved the problem
with SSH as well, the VerifyReverseMapping setting has been
deprecated, and replaced with UseDNS... this has solved my problems.
Your hints on indentd were what eventually led me to solving this problem,
Thanks for your help'
--James Duff
On 8/5/05, James Duff <dingopuppy@gmail.com> wrote:
> Hi, thanks for the response.
>
> As far as I know I'm not using any ident system on the server, although I'll
> have to check. There are no packet filtering nor NAT systems between client
> and server. Server does not drop outgoing connections.
>
> I'm using passwd at the moment, but am trying to convert the system to LDAP
> with a win2003 domain controller currently (the problems existed before this
> attempt however).
>
> I'll check the server on Monday when I go back to work and check up on your
> suggestions.
>
> Thanks for your help.
>
> --James
>
> -----Original Message-----
> From: Mirko Parthey [mailto:mirko.parthey@informatik.tu-chemnitz.de]
> Sent: Friday, 5 August 2005 3:42 PM
> To: James Duff
> Cc: debian-user@lists.debian.org
> Subject: Re: proftpd and sshd delays
>
>
> On Fri, Aug 05, 2005 at 03:13:01PM +0800, James Duff wrote:
> > Both sshd, and proftpd are very slow to respond. I've noticed this in
> > sshd under debian on previous versions and machines also. Sshd asks
> > for a username almost immediately when I connect, but there is a
> > substantial time before it asks for a password.
> >
> > Proftpd also has a significant delay before responding to login
> > information.
>
> Is there a packet filtering firewall or a NAT device between your client
> machines and the server, or do your clients run a personal firewall software
> which drops incoming connections? Or does your server machine drop outgoing
> connections?
>
> Your FTP and SSH servers might be configured to ask the client machine which
> user issued the connection request. The "ident" protocol is used for this
> purpose (sometimes also called "auth", which is a bit misnamed). If your
> client machines ignore such connection attempts, instead of rejecting them,
> this will cause the delays you observed.
>
> You should be able to analyse this by running a packet sniffer such as
> ethereal on the server side.
>
> Another reason could be that the user lookup on the server itself takes too
> long. Which user directory are you using - passwd, NIS, LDAP or something
> else? If you don't know, please look in /etc/passwd for lines starting with
> "+" (which would indicate you are using NIS), and post your
> /etc/nsswitch.conf.
>
> The strace tool, attached to a server process, might help diagnosing this
> case.
>
> Mirko
>
>
--
--James
Reply to: