sshd -i startup time
Joseph Shraibman
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
Darren Tucker
> 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.
Nico Kadel-Garcia
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.
Joseph Shraibman
away, so that isn't it.
Michael Heiming
> 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 zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 432: Borg nanites have infested the server
Darren Tucker
> 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).
Richard E. Silverman
DT> On 2006-02-17, Joseph Shraibman <j...@iname.com> 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
r...@qoxp.net
Joseph Shraibman
> In comp.security.ssh Joseph Shraibman <j...@iname.com>:
>
> Why would you want to run sshd from (x)inetd?
>
This is a secondary sshd, the primary runs as a daemon.
Joseph Shraibman
>>>>>>"DT" == Darren Tucker <dtu...@gate.dtucker.net> 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.
Joseph Shraibman
>>
>
> I did, and it appears that xinetd is waiting 30 seconds to spin of sshd
Michael Heiming
> Michael Heiming wrote:
>> In comp.security.ssh Joseph Shraibman <j...@iname.com>:
>>
>> 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
<portnumber>' 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
Per Hedeland
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
p...@hedeland.org
Darren Tucker
> 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
Some xinetd options cause an ident lookup too (eg log_on_failure = USERID).
Joseph Shraibman
> On 2006-02-23, Per Hedeland <p...@hedeland.org> 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).
>
needs a way to be configured to have a lower timeout.