Results 1 to 21 of 21
  1. #1
    Join Date
    Apr 2001
    Location
    Palm Beach, FL
    Posts
    1,095

    OpenSSH 3.4 + djbdns ?

    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?
    Alex Llera
    Professional Server Management
    FreeBSD|Linux|HSphere|Cpanel|Plesk

  2. #2
    It might also be a problem with Ident. Do a search and you should be able to figure out how to turn this off.
    *AlphaOmegaHosting.Com* - Hosting since 1998
    Managed Dedicated Servers and VPS
    Hosted Exchange 2010 Email Service

  3. #3
    Try copying /etc/resolv.conf to /var/empty/etc/resolv.conf (assuming that /var/empty/ is where the privsep code is jailing itself).
    Dr. Colin Percival, FreeBSD Security Officer
    Online backups for the truly paranoid: http://www.tarsnap.com/

  4. #4
    Join Date
    Apr 2001
    Location
    Palm Beach, FL
    Posts
    1,095
    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.

    [edit]
    Yep, the second djbdns server is delaying as well... I'll post a dump of sshd to see if it helps.
    [/edit]
    Last edited by allera; 06-28-2002 at 10:24 PM.
    Alex Llera
    Professional Server Management
    FreeBSD|Linux|HSphere|Cpanel|Plesk

  5. #5
    Join Date
    Apr 2001
    Location
    Palm Beach, FL
    Posts
    1,095
    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.
    Alex Llera
    Professional Server Management
    FreeBSD|Linux|HSphere|Cpanel|Plesk

  6. #6
    Join Date
    Apr 2001
    Location
    Palm Beach, FL
    Posts
    1,095
    # /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
    Alex Llera
    Professional Server Management
    FreeBSD|Linux|HSphere|Cpanel|Plesk

  7. #7
    It may be the line below the one in bold that might be the problem.......
    *AlphaOmegaHosting.Com* - Hosting since 1998
    Managed Dedicated Servers and VPS
    Hosted Exchange 2010 Email Service

  8. #8
    Join Date
    Nov 2001
    Location
    Canada
    Posts
    1,963
    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

  9. #9
    Join Date
    Apr 2001
    Location
    Palm Beach, FL
    Posts
    1,095
    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.

  10. #10
    Join Date
    Apr 2001
    Location
    Palm Beach, FL
    Posts
    1,095
    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.
    Alex Llera
    Professional Server Management
    FreeBSD|Linux|HSphere|Cpanel|Plesk

  11. #11
    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.
    *AlphaOmegaHosting.Com* - Hosting since 1998
    Managed Dedicated Servers and VPS
    Hosted Exchange 2010 Email Service

  12. #12
    Join Date
    Apr 2001
    Location
    Palm Beach, FL
    Posts
    1,095
    If you're referring to

    VerifyReverseMapping no

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

  13. #13
    Join Date
    Dec 2001
    Location
    Detroit, MI
    Posts
    1,067
    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.
    <!-- boo! -->

  14. #14
    Join Date
    Apr 2001
    Location
    Palm Beach, FL
    Posts
    1,095
    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.

  15. #15
    Join Date
    Dec 2001
    Location
    Detroit, MI
    Posts
    1,067
    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?
    <!-- boo! -->

  16. #16
    Join Date
    Apr 2001
    Location
    Palm Beach, FL
    Posts
    1,095
    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.
    Alex Llera
    Professional Server Management
    FreeBSD|Linux|HSphere|Cpanel|Plesk

  17. #17
    Join Date
    Dec 2001
    Location
    Detroit, MI
    Posts
    1,067
    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.
    <!-- boo! -->

  18. #18
    Join Date
    Apr 2001
    Location
    Palm Beach, FL
    Posts
    1,095
    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.
    Alex Llera
    Professional Server Management
    FreeBSD|Linux|HSphere|Cpanel|Plesk

  19. #19
    Join Date
    Nov 2001
    Location
    Canada
    Posts
    1,963
    damn *nix

  20. #20
    Join Date
    Sep 2001
    Location
    Madras
    Posts
    738
    Originally posted by clocker1996
    damn *nix
    Damn all webhosting!
    Offering Managed Servers - for an exclusive clientèle who value uptime, caring support and superior technology.

  21. #21
    Join Date
    Oct 2001
    Location
    The Netherlands, Europe
    Posts
    153
    Same thing happened to me using OpenSSH 3.3 w/ privsep turned on. And djbdns was running on that box too

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •