On Tue, Jul 1, 2008 at 2:01 AM, Bruce Korb wrote:
> The build bug: DESTDIR=$SOMEDIR does not work:
>
> mkdir ${HOME}/tools/openssh/openssh-5.0p1/_i/usr/local/etc
> ${HOME}/tools/openssh/openssh-5.0p1/_i/usr/local/sbin/sshd -t -f
> ${HOME}/tools/openssh/openssh-5.0p1/_i/usr/local/etc/sshd_config
> Could not load host key: /usr/local/etc/ssh_host_rsa_key
> Could not load host key: /usr/local/etc/ssh_host_dsa_key
> Disabling protocol version 2. Could not load host key
> sshd: no hostkeys available -- exiting.
> make: [check-config] Error 1 (ignored)


That looks like the install worked but the "sshd -t" test failed
because sshd did not have permission to read the keys that it's
configured to use (via --prefix or --sysconfdir as Ben mentioned).
Try "make install-nokeys DESTDIR=foo" instead.

[...]
> It works with my client side daemon running 0.9.8c and 0.9.8e
> (as reported by "ssh", not "sshd"), but not with 0.9.8g.


Those are versions of the OpenSSL library that OpenSSH uses. What are
the versions of ssh and sshd?

> On the server side, I invoke:
>
> /usr/bin/ssh -v -q -g -R ${PORT}:localhost:22 -n \
> -o BatchMode=yes -o StrictHostKeyChecking=no


The output of this command would be interesting (particularly with
"-vvv") to see if the remote forwarding request was actually accepted
by the server. You could also add "-o ExitOnForwardFailure=yes" to
make sure that the tunnel is established.

> The only user allowed to ssh in has a shell that does nothing except
> keep the connection open.

[...]

My guess is that the server (ie the thing running sshd) has
"AllowTcpForwarding no" in its sshd_config.

--
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-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/li...enssh-unix-dev