sshd -i startup time - SSH

This is a discussion on sshd -i startup time - SSH ; When I run sshd from xinetd, it takes 30 seconds for the password prompt to appear. sshd is not using up cpu in this time. What is is doing? Running sshd -i -d -d -d give me: Feb 14 16:58:12 ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: sshd -i startup time

  1. sshd -i startup time

    When I run sshd from xinetd, it takes 30 seconds for the password prompt
    to appear. sshd is not using up cpu in this time. What is is doing?


    Running sshd -i -d -d -d give me:

    Feb 14 16:58:12 d1 xinetd[725]: START: sshd pid=4888 from=66.166.198.124

    Feb 14 16:58:42 d1 sshd[4888]: debug1: inetd sockets after dupping: 5, 6
    ....

    This is OpenSSH_3.5p1

  2. Re: sshd -i startup time

    On 2006-02-15, Joseph Shraibman wrote:
    > When I run sshd from xinetd, it takes 30 seconds for the password prompt
    > to appear. sshd is not using up cpu in this time. What is is doing?


    Reverse resolving the source IP of the connection, most likely.

    > This is OpenSSH_3.5p1


    On which platform?

    --
    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.

  3. Re: sshd -i startup time

    Joseph Shraibman wrote:
    > When I run sshd from xinetd, it takes 30 seconds for the password
    > prompt to appear. sshd is not using up cpu in this time. What is is
    > doing?
    >
    > Running sshd -i -d -d -d give me:
    >
    > Feb 14 16:58:12 d1 xinetd[725]: START: sshd pid=4888
    > from=66.166.198.124
    > Feb 14 16:58:42 d1 sshd[4888]: debug1: inetd sockets after dupping:
    > 5, 6 ...
    >
    > This is OpenSSH_3.5p1


    That's pretty seriously out of date. Try doing it twice in a row: if it
    doesn't happen the second time, the server is reverse-resolving the IP
    address of the connecting client, and your client doesn't have reverse DNS
    set up. This is preventable on the server by using the "sshd -u0", which
    prevents it from trying to log that reverse DNS name.



  4. Re: sshd -i startup time

    Nico Kadel-Garcia wrote:
    > Joseph Shraibman wrote:
    >
    >>When I run sshd from xinetd, it takes 30 seconds for the password
    >>prompt to appear. sshd is not using up cpu in this time. What is is
    >>doing?
    >>
    >>Running sshd -i -d -d -d give me:
    >>
    >>Feb 14 16:58:12 d1 xinetd[725]: START: sshd pid=4888
    >>from=66.166.198.124
    >>Feb 14 16:58:42 d1 sshd[4888]: debug1: inetd sockets after dupping:
    >>5, 6 ...
    >>
    >>This is OpenSSH_3.5p1

    >
    >
    > That's pretty seriously out of date. Try doing it twice in a row: if it
    > doesn't happen the second time, the server is reverse-resolving the IP
    > address of the connecting client, and your client doesn't have reverse DNS
    > set up. This is preventable on the server by using the "sshd -u0", which
    > prevents it from trying to log that reverse DNS name.
    >
    >

    Nope, that doesn't help. And "host 66.166.198.124" comes back right
    away, so that isn't it.

  5. Re: sshd -i startup time

    In comp.security.ssh Joseph Shraibman :
    > When I run sshd from xinetd, it takes 30 seconds for the password prompt
    > to appear. sshd is not using up cpu in this time. What is is doing?



    > Running sshd -i -d -d -d give me:


    > Feb 14 16:58:12 d1 xinetd[725]: START: sshd pid=4888 from=66.166.198.124


    > Feb 14 16:58:42 d1 sshd[4888]: debug1: inetd sockets after dupping: 5, 6
    > ...


    > This is OpenSSH_3.5p1


    Why would you want to run sshd from (x)inetd?

    --
    Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
    mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
    #bofh excuse 432: Borg nanites have infested the server

  6. Re: sshd -i startup time

    On 2006-02-17, Joseph Shraibman wrote:
    > Nico Kadel-Garcia wrote:

    [...]
    >> This is preventable on the server by using the "sshd -u0", which
    >> prevents it from trying to log that reverse DNS name.
    >>

    > Nope, that doesn't help. And "host 66.166.198.124" comes back right
    > away, so that isn't it.


    I missed the start of this thread, but does forcing Protocol 2 only
    (ie "Protocol 2" in sshd_config) make a difference?

    If so, this is because the SSHv1 protocol requires an "ephemeral host
    key" which changes frequently and in OpenSSH is generated on process
    startup (and regenerated periodically when running as a standalone
    daemon).

    --
    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.

  7. Re: sshd -i startup time

    >>>>> "DT" == Darren Tucker writes:

    DT> On 2006-02-17, Joseph Shraibman wrote:
    >> Nico Kadel-Garcia wrote:

    DT> [...]
    >>> This is preventable on the server by using the "sshd -u0", which
    >>> prevents it from trying to log that reverse DNS name.
    >>>

    >> Nope, that doesn't help. And "host 66.166.198.124" comes back
    >> right away, so that isn't it.


    DT> I missed the start of this thread, but does forcing Protocol 2
    DT> only (ie "Protocol 2" in sshd_config) make a difference?

    DT> If so, this is because the SSHv1 protocol requires an "ephemeral
    DT> host key" which changes frequently and in OpenSSH is generated on
    DT> process startup (and regenerated periodically when running as a
    DT> standalone daemon).

    I didn't mention this because the OP said, "When I run sshd from xinetd,
    it takes 30 seconds for the password prompt to appear. sshd is not using
    up cpu in this time. What is is doing?"

    Anyway, I would simply run sshd under strace and find out what it's doing.

    --
    Richard Silverman
    res@qoxp.net


  8. Re: sshd -i startup time

    Michael Heiming wrote:
    > In comp.security.ssh Joseph Shraibman :


    >
    > Why would you want to run sshd from (x)inetd?
    >

    This is a secondary sshd, the primary runs as a daemon.

  9. Re: sshd -i startup time

    Richard E. Silverman wrote:
    >>>>>>"DT" == Darren Tucker writes:


    > Anyway, I would simply run sshd under strace and find out what it's doing.
    >


    I did, and it appears that xinetd is waiting 30 seconds to spin of sshd
    in the first place, but I can't figure out why.

  10. Re: sshd -i startup time

    Joseph Shraibman wrote:
    >>

    >
    > I did, and it appears that xinetd is waiting 30 seconds to spin of sshd

    of = off


  11. Re: sshd -i startup time

    In comp.security.ssh Joseph Shraibman :
    > Michael Heiming wrote:
    >> In comp.security.ssh Joseph Shraibman :


    >>
    >> Why would you want to run sshd from (x)inetd?
    >>

    > This is a secondary sshd, the primary runs as a daemon.


    Now that sounds easy. Just fire up a second 'sshd -p
    ' from console or last startup script, it should
    detach from tty if starting from console and pickup the originals
    config despite the port unless you tell it to use another file.

    Good luck

    --
    Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
    mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'

  12. Re: sshd -i startup time

    In article <1ZOdnex6RrkxE2HeRVn-tQ@britsys.net> Joseph Shraibman
    writes:
    >Richard E. Silverman wrote:
    >>>>>>>"DT" == Darren Tucker writes:

    >
    >> Anyway, I would simply run sshd under strace and find out what it's doing.
    >>

    >
    >I did, and it appears that xinetd is waiting 30 seconds to spin of sshd
    >in the first place, but I can't figure out why.


    Do some packet tracing too - my guess would be that xinetd initiates an
    ident lookup (goes to port 113 on the client box), indirectly via the
    builtin libwrap calls and based on whatever you have in
    /etc/hosts.{allow,deny}, and that this is dropped by the client or an
    intermediate firewall rather than rejected with RST (or allowed to
    complete). It should supposedly be possible to turn off the libwrap call
    with the NOLIBWRAP flag, see the xinetd documentation - could be useful
    for verification at least.

    --Per Hedeland
    per@hedeland.org

  13. Re: sshd -i startup time

    On 2006-02-23, Per Hedeland wrote:
    > Do some packet tracing too - my guess would be that xinetd initiates an
    > ident lookup (goes to port 113 on the client box), indirectly via the
    > builtin libwrap calls [...]


    Some xinetd options cause an ident lookup too (eg log_on_failure = USERID).

    --
    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.

  14. Re: sshd -i startup time

    Darren Tucker wrote:
    > On 2006-02-23, Per Hedeland wrote:
    >
    >>Do some packet tracing too - my guess would be that xinetd initiates an
    >>ident lookup (goes to port 113 on the client box), indirectly via the
    >>builtin libwrap calls [...]

    >
    >
    > Some xinetd options cause an ident lookup too (eg log_on_failure = USERID).
    >

    Yup, commented that out and everything is working fine now. xinetd
    needs a way to be configured to have a lower timeout.

+ Reply to Thread