Web Hosting Talk







View Full Version : OpenSSH 3.4 + djbdns ?


allera
06-28-2002, 08:53 PM
I tried compiling and installing OpenSSH 3.4 onto a machine with djbdns installed. It compiles, installs, and executes just fine. However, whenever I try to connect, it takes a very long time to pop up the password prompt. I ran sshd with the -d option and it is getting suck on my reverse lookup. I reversed my connecting IP from the server and it reverses fine, yet sshd doesn't want to reverse it.

I then did it all on a machine without djbdns running (no DNS server). It installed and connected without a hitch. It may not be djbdns, but I've talked to another person with the same delay problem and he's running djbdns as well.

Oh yea, on the djbdns server, if I set 'UsePrivilegeSeparation no' it works fine...

Any ideas?

dandanfirema
06-28-2002, 09:13 PM
It might also be a problem with Ident. Do a search and you should be able to figure out how to turn this off.

cperciva
06-28-2002, 10:09 PM
Try copying /etc/resolv.conf to /var/empty/etc/resolv.conf (assuming that /var/empty/ is where the privsep code is jailing itself).

allera
06-28-2002, 10:16 PM
Well, I tried copying resolv.conf for kicks, but it didn't work.

3.4 works fine with other servers. I'm going to try it on another djbdns server and see if it has the delay there too.


Yep, the second djbdns server is delaying as well... I'll post a dump of sshd to see if it helps.

allera
06-28-2002, 10:23 PM
Originally posted by dandanfirema
It might also be a problem with Ident.
Problem with Ident how? The machine isn't running identd, if that's what you mean.

allera
06-28-2002, 10:31 PM
# /usr/local/sbin/sshd -d
debug1: sshd version OpenSSH_3.4
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
Generating 768 bit RSA key.
RSA key generation complete.
debug1: Server will not fork when running in debugging mode.
Connection from x.x.x.x port 64766
debug1: Client protocol version 1.5; client software version 1.0
debug1: no match: 1.0
debug1: Local version string SSH-1.99-OpenSSH_3.4
debug1: Sent 768 bit server key and 1024 bit host key.
debug1: Encryption type: 3des
debug1: cipher_init: set keylen (16 -> 32)
debug1: cipher_init: set keylen (16 -> 32)
debug1: Received session key; encryption turned on.
debug1: Installing crc compensation attack detector.
Could not reverse map address x.x.x.x.
debug1: Attempting authentication for xxx.
Failed none for xxx from x.x.x.x port 64766
Accepted password for xxx from x.x.x.x port 64766
Accepted password for xxx from x.x.x.x port 64766
debug1: monitor_child_preauth: xxx has been authenticated by privileged process
debug1: cipher_init: set keylen (16 -> 32)
debug1: cipher_init: set keylen (16 -> 32)
debug1: session_new: init
debug1: session_new: session 0
debug1: Installing crc compensation attack detector.
debug1: packet_set_maxsize: setting to 4096
debug1: Allocating pty.
debug1: session_pty_req: session 0 alloc /dev/ttyp3
debug1: Ignoring unsupported tty mode opcode 37 (0x25)
debug1: Ignoring unsupported tty mode opcode 52 (0x34)
debug1: Ignoring unsupported tty mode opcode 71 (0x47)
debug1: fd 5 setting TCP_NODELAY
debug1: Entering interactive session.
debug1: Setting controlling tty using TIOCSCTTY.
debug1: fd 3 setting O_NONBLOCK
debug1: fd 9 setting O_NONBLOCK
debug1: fd 10 setting O_NONBLOCK
debug1: server_init_dispatch_13
debug1: server_init_dispatch_15

I could turn on debug2 and debug3 if anyone thinks it's necessary, but it's huge...

It gets stuck on the bold line. After a while, I get a password prompt, and the debug continues on with the rest of the junk

dandanfirema
06-28-2002, 10:36 PM
It may be the line below the one in bold that might be the problem.......

clocker1996
06-28-2002, 10:43 PM
try putting your ip (The ip youare coming from) in /etc/hosts

like

[10:35] *** Looking up d226-66-182.home.cgocable.net
-
[10:35] *** Resolved d226-66-182.home.cgocable.net to 24.226.66.182

so

ecoo "24.226.66.182 home" >> /etc/hosts

allera
06-28-2002, 10:43 PM
Well, this is from a working machine:

# /usr/local/sbin/sshd -d
debug1: sshd version OpenSSH_3.4
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
Generating 768 bit RSA key.
RSA key generation complete.
debug1: Server will not fork when running in debugging mode.
Connection from x.x.x.x port 65412
debug1: Client protocol version 1.5; client software version 1.0
debug1: no match: 1.0
debug1: Local version string SSH-1.99-OpenSSH_3.4
debug1: Sent 768 bit server key and 1024 bit host key.
debug1: Encryption type: 3des
debug1: cipher_init: set keylen (16 -> 32)
debug1: cipher_init: set keylen (16 -> 32)
debug1: Received session key; encryption turned on.
debug1: Installing crc compensation attack detector.
Could not reverse map address x.x.x.x.
debug1: Attempting authentication for xxx.
Failed none for xxx from x.x.x.x port 65412
Accepted password for xxx from x.x.x.x port 65412
debug1: monitor_child_preauth: xxx has been authenticated by privileged process
Accepted password for xxx from x.x.x.x port 65412
debug1: cipher_init: set keylen (16 -> 32)
debug1: cipher_init: set keylen (16 -> 32)
debug1: session_new: init
debug1: session_new: session 0
debug1: Installing crc compensation attack detector.
debug1: packet_set_maxsize: setting to 4096
debug1: Allocating pty.
debug1: session_new: init
debug1: session_new: session 0
debug1: session_pty_req: session 0 alloc /dev/ttyp2
debug1: Ignoring unsupported tty mode opcode 37 (0x25)
debug1: Ignoring unsupported tty mode opcode 52 (0x34)
debug1: Ignoring unsupported tty mode opcode 71 (0x47)
debug1: fd 5 setting TCP_NODELAY
debug1: Entering interactive session.
debug1: Setting controlling tty using TIOCSCTTY.
debug1: fd 4 setting O_NONBLOCK
debug1: fd 10 setting O_NONBLOCK
debug1: fd 11 setting O_NONBLOCK
debug1: server_init_dispatch_13
debug1: server_init_dispatch_15

This server has no delay -- zips me right into the shell.

I only bolded to signify where the process was delayed at. The bolded line was the last line shown while I was sitting here waiting for the password prompt.

I'm sure it's something really stupid; it always is.

allera
06-28-2002, 10:46 PM
Originally posted by clocker1996
try putting your ip (The ip youare coming from) in /etc/hosts
No go. Besides, I wouldn't be a happy camper if I had to do that. :)

dandanfirema
06-28-2002, 10:49 PM
Just for grins and giggles, look in /etc/ssh/sshd_config and turn off reverse mapping. I don't have the version you are looking for but it should be at the bottom of the file and mentions reverse mapping.

allera
06-28-2002, 10:55 PM
If you're referring to

VerifyReverseMapping no

I already tried that one. Seemed to make sense to me, too. :)

ScottD
06-28-2002, 11:00 PM
Did you also try:

ReverseMappingCheck no

?

Obviously even if this works it doesn't resolve the problem. In fact it just validates what you already know since the debug info showed it pausing that the reverse dns lookup.

allera
06-28-2002, 11:11 PM
Nada... I also had /etc/resolv.conf point to outside nameservers that the other non-djbdns servers use and still didn't fly.

Maybe I need to read more on this privsep thing.

ScottD
06-28-2002, 11:26 PM
I thought not, VerifyReverseMapping really just takes the results of the reverse lookup, requeries for the IP, and verifies that it resolves the same way forward. So it is still going to perform the reverse lookup.

I can't begin to imagine where djbdns is playing into this, strange. You are running this on FreeBSD correct? Is your privsep using /var/empty, or is it possibly chrooting somewhere else?

allera
06-28-2002, 11:35 PM
Yes, FreeBSD, and yes, /var/empty (and it exists).

I can't think of where djbdns plays in either, but it's the only common thing I can find. Although, I did also find someone who is having the problem and not running djbdns...

There also seems to be a thread over at the OpenSSH mailing lists about someone having a similar problem. We'll see how that thread turns out.

ScottD
06-28-2002, 11:39 PM
Okay, stupid question...

When you created /var/empty/etc, it was world read / execute right? And /var/empty/resolv.conf is world readable?

And the computer is plugged in? :) Hopefully you'll get an answer from the mailing list. I had the same slow-down without djbdns, but copying resolv.conf resolved it.

allera
06-29-2002, 03:39 AM
cperciva and DizixCom, you had the right ideas.

The FreeBSD port uses /usr/local/empty as the home dir for user sshd by default. For some reason, the box that I tried cperciva's suggestion on had sshd's home dir set to /var/empty (I think the port was broken before or something...). I tried it again on the other delaying box (put resolv.conf into /usr/local/empty/etc) and bam, it worked. I changed the first box's sshd home dir to /usr/local/empty, created the ~/etc/resolv.conf file, bam it worked.

Thanks for the help guys. :) Stupid oversight on my part...

Although I'm not sure why it didn't happen with the other servers, but oh well, I'm done with this.

clocker1996
06-29-2002, 04:57 AM
damn *nix

MotleyFool
07-02-2002, 02:57 AM
Originally posted by clocker1996
damn *nix

Damn all webhosting!;)

T_E_O
07-02-2002, 03:51 AM
Same thing happened to me using OpenSSH 3.3 w/ privsep turned on. And djbdns was running on that box too :eek:

But after upgrading to 3.4 the problem just vanished without me having to place any resolve.conf file anywhere :) Maybe the port was indeed broken and they fixed it somewhere between your upgrade to 3.4 and mine :)