[Techtalk] SSHD default config questions

[Almut Behrens]

On Wed, Sep 05, 2001 at 12:08:12PM -0500, Nicoya Helm wrote:
>
> I just installed ssh2 on a rh7.1 box.  I compiled it with tcp-wrapper
> support enabled because, well, because I thought it'd be cool to just
> be able to edit my main hosts.allow list.  Now that it's installed,
> I'm running into two problems.
> 
> 1.  Having not made any config changes, just starting up the ssh2
> daemon fresh after install, it is allowing 3 password attempts - but
> does not disconnect after the 3rd attempt.  It just hangs.  I have
> not been able to figure out where this default is coming from,
> because right now my sshd2_config file, including the PasswordGuesses
> line, is commented out.

the "3 attempts" is the hardcoded default (in apps/ssh/sshconfig.c),
not sure, though, why it hangs after that.  Maybe the next step it's
trying to do (logging, switching to another authentication method,
etc.) fails for some reason or is waiting on a timeout.  Attaching
'strace' to the process (see below) might provide some more info...

> 
> 2.  When I compiled, tcp-wrappers did appear to be enabled at the
> end.  However, I edited my /etc/hosts.allow with this line:
> 
> sshd2: 196.178.20.0/255.255.255.0.

just in case you started the new sshd2 via some (sym)link with a
different name, e.g. /usr/sbin/sshd, you'd have to specify that name
("sshd") in hosts.allow. Don't know whether you've tried that already;
could be the reason why the line is ignored. If unsure, simply specify
both:

sshd2 sshd: ...


> Someone suggested to me to do an ldd on my sshd2 and ssh2 to make
> sure it was referencing the libwrap.a library.  I've done this and do
> not see any evidence of libwrap being referenced.

ldd would not help much in this case, as libwrap.a is not a shared
library, but just a normal archive (.a), being linked in statically.

Basically, you could give the -d debug option (or verbose, -v) to
sshd2 to get a detailed log of what it's doing.  However, the tcp
wrapper code unfortunately wouldn't produce any useful output here.

So, you'll have to resort to some more generic debugging facility like
strace. In this particular case, it's probably best to attach strace to
the already running daemon process:

  strace -f -e trace=file -o /tmp/sshd.strace -p <PID of sshd>

  [ -f : also trace forked off processes
    -e : what to trace
    -o : save output to file (instead of stdout)
    -p : which process to trace / attach to  ]

In order to debug the tcp wrapper stuff, you'd have to attach strace
to the master sshd process (as most daemons, sshd forks off a new
process for every connection attempt). Otherwise you wouldn't get hold
of the most interesting part, i.e. the libwrap routines, which should
be executed immediately after having forked... OTOH, to find out why it
does hang after 3 incorrect passwords, you could also attach strace to
the sshd child process that's handling the connection request
(attaching after you got the "password:" prompt would be sufficient).

To find the right PIDs, preferably do a "ps axf", which should give
something like

(...)
  264 ?        S      0:21 /usr/sbin/sshd
30459 ?        S      0:33  \_ /usr/sbin/sshd
30460 pts/2    S      0:00  |   \_ -bash
30811 ?        S      0:10  \_ /usr/sbin/sshd
30812 pts/4    S      0:00  |   \_ -bash
30844 ?        S      0:00  \_ /usr/sbin/sshd
(...)

In the example, the first sshd (PID 264) is the master daemon process,
the second and third (PIDs 30549 and 30811) are two established
interactive logins (note the bash subprocesses), and the last (PID
30844) is a new connection request in the authentication phase (showing
the "password:" prompt on the client side).
To attach to the master you'd specify "-p 264" to strace, and to
attach to the child handling the new connection, you'd specify
"-p 30844" -- I guess you get the idea :)
(to detach again from the master daemon, simply press Ctrl-C in the
terminal where you started strace)

Now, what's all this for?  In the strace log you should see something
resembling

264   open("/dev/urandom", O_RDONLY)    = 6
32400 open("/etc/hosts.allow", O_RDONLY) = 4
32400 open("/etc/hosts.deny", O_RDONLY) = 4
(...)

if the libwrap routines are properly doing their job (first column is
the PID, btw.).  For the password issue I can't tell what you might
get ;) -- just try to make some sense of it... (might also drop the
option "-e trace=file" for more details...)

Good luck,

- Almut