This discussion is archived
1 2 3 4 Previous Next 45 Replies Latest reply: May 8, 2013 8:31 AM by EdStevens Go to original post RSS
  • 30. Re: logon issue with OL 6.3
    Dude! Guru
    Currently Being Moderated
    The /etc/nsswitch.conf file defines the order in which names are resolved. Normally this means first try /etc/hosts than use DNS. If the client IP address can be resolved using the /etc/hosts file on the SSH server, than DNS (/etc/resolve.conf) is not used. This is however usually not the case and the reverse client IP to name mapping will have to be resolved using DNS.

    A DNS server provides 3 types of responses.
    a) IP or name
    b) does not exist
    c) no response

    A and B do not delay the SSH login. C does because the SSH server is waiting for response. During my tests, the timeout is 10 seconds for each DNS that does not respond.
  • 31. Re: logon issue with OL 6.3
    AmitShil Newbie
    Currently Being Moderated
    Thanks, but how you do simulate a no response? would a entry in the file be enough which if pinged gives a timeout (as there's no internal to external connectivity via the VM)?

    Are you suggesting as the VM finds out the DNS servers in my case are non reachable instantly that's why my SSH is working fast?

    [root@Gateway ~]# cat /etc/resolv.conf
    ; generated by /sbin/dhclient-script
    nameserver 103.8.46.5
    nameserver 121.242.190.210
    [root@Gateway ~]# ping 103.8.46.5
    connect: Network is unreachable
    [root@Gateway ~]# ping 121.242.190.210
    connect: Network is unreachable


    Regards Amit
  • 32. Re: logon issue with OL 6.3
    Dude! Guru
    Currently Being Moderated
    No, if the DNS servers are not reachable and your client IP is not in /etc/ hosts then there is a delay, provided /etc/nsswitch and useDNS in ssh are configured as default.

    Please see the last paragraph of my previous response.
  • 33. Re: logon issue with OL 6.3
    BillyVerreynne Oracle ACE
    Currently Being Moderated
    Ed, the sshd daemon is using GSSAPIAuthentication by default - which causes the problem.

    Edit +/etc/ssh/sshd_config+ and set the option to no. Then restart the sshd daemon.
  • 34. Re: logon issue with OL 6.3
    EdStevens Guru
    Currently Being Moderated
    Billy  Verreynne  wrote:
    Ed, the sshd daemon is using GSSAPIAuthentication by default - which causes the problem.

    Edit +/etc/ssh/sshd_config+ and set the option to no. Then restart the sshd daemon.
    No joy.
    [root@vblnxsrv02 ssh]# grep GSSAPI /etc/ssh/sshd_config
    # GSSAPI options
    GSSAPIAuthentication no
    #GSSAPIAuthentication yes
    #GSSAPICleanupCredentials yes
    GSSAPICleanupCredentials yes
    #GSSAPIStrictAcceptorCheck yes
    #GSSAPIKeyExchange no
    [root@vblnxsrv02 ssh]#
    Reboot. Same result.
    FWIW, all of my several OL 5.6 systems also have "GSSAPIAuthentication yes" and none exhibit this behavior. I have also disables GSSAPI from my putty connection profiles.
  • 35. Re: logon issue with OL 6.3
    BillyVerreynne Oracle ACE
    Currently Being Moderated
    Weird... Have had the exact same symptoms as you describe - ssh connections to RHEL/OL6 systems being very slow during handshaking, before making the eventual connection.

    In my case, it was due to GSSAPI authentication. I was pretty sure your problem was a match. +<wry grin>+

    Suggest that you isolate potential issues. It could be a ssh client or ssh server induced issue. It could be a network issue. Etc.

    What happens if you run ssh on the host, and ssh in as root@localhost? Turn debug tracing on if slow (and please post the results). If not slow, then it is not the server - and potentially either the network, or the client.

     
    PS. I'm using Kitty at home, with MPutty (Multi Tab Interface for Putty/Kitty). Exact same problem too connecting to a VM in the office, that went away when I disabled GSSAPI in the sshd in the VM.
  • 36. Re: logon issue with OL 6.3
    Dude! Guru
    Currently Being Moderated
    If I remember correctly, the problem with GSSAPI authentication also prints a "access denied" error during the login phase. Putty version 0.61 had this issue.

    Regarding this thread, I thought the problem was identified as a DNS issue, and the solution that worked so far was to set useDNS=no in the /etc/ssh/sshd_config file.

    Btw, the following is from man resolv.conf
    the default timeout is RES_TIMEOUT (currently 5 seconds).
    the default number of tries is RES_DFLRETRY (currently 2).
    which means a 10 second delay for each unresponsive DNS server in /etc/resolv.conf

    I have no idea what happens if the name servers are responding, but not providing a reasonable or ill-formed response. Like I mentioned earlier, maybe using .vboxdomain as the host domain name is not a good idea and it was better to use any of the reserved domain names for private use.

    I have not noticed any different behavior between Oracle Linux 5 and 6. Since this is a VirtualBox VM, there could be other issues too. Are there any Firewalls installed on Windows or DNS server side?
  • 37. Re: logon issue with OL 6.3
    BillyVerreynne Oracle ACE
    Currently Being Moderated
    Dude wrote:
    If I remember correctly, the problem with GSSAPI authentication also prints a "access denied" error during the login phase. Putty version 0.61 had this issue.
    Never saw that myself.. but then I do not use Putty and only very seldom use Kitty on Win7 from home. 99% of the time it is Linux OpenSSH clients,
    Regarding this thread, I thought the problem was identified as a DNS issue, and the solution that worked so far was to set useDNS=no in the /etc/ssh/sshd_config file.
    What struck me is the following that Ed posted:
    debug1: SSH2_MSG_SERVICE_REQUEST sent
    debug2: service_accept: ssh-userauth
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug2: key: /home/mobaxterm/.ssh/id_rsa (0x0)
    debug2: key: /home/mobaxterm/.ssh/id_dsa (0x0)
    debug2: key: /home/mobaxterm/.ssh/id_ecdsa (0x0)
     
    This was where the delay occurred...
     
    debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
    debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
    debug3: preferred hostbased,publickey,password,keyboard-interactive
    Which means to me that there were some "discussion" between the client and server when handshaking and deciding which authentication issues to use.

    Thus my thoughts that it was GSSAPI (as in my case, with all OL6 servers I recently installed).

    But it could also be an issue from the client side, with the client going to an enumerated list of auth types it prefers?

    Offhand, I do not see why a network resolution issue during this stage would cause an issue - unless both parties agreed on using a 3rd party (e.g. Kerberos server) to authenticate via?
    I have no idea what happens if the name servers are responding, but not providing a reasonable or ill-formed response. Like I mentioned earlier, maybe using .vboxdomain as the host domain name is not a good idea and it was better to use any of the reserved domain names for private use.
    Never even thought about that as I'm always particular about FQDN and not using defaults. :-)
    I have not noticed any different behavior between Oracle Linux 5 and 6. Since this is a VirtualBox VM, there could be other issues too. Are there any Firewalls installed on Windows or DNS server side?
    With all the OL5 installations I have done, I have never had a ssh client taking up to 30s to establish a connection and prompt for the password (or using the local rsa public key for authorised hosts auth). The very 1st OL6 server installed (default base install, standard stuff), I ran into ssh delays. And every OL6 server installed since (including a VM installed by colleagues in our labs, which I had to access via the Internet from home using Kitty). In all cases, disabling GSSAPI and bouncing the sshd daemon, worked for me and the delay on connection was no more. Which is why I thought Ed ran into the same issue.

    If a ssh root@localhost shows the same delay issues, I would run it in full debug mode - and if that fails to uncover where the delay is, perhaps use strace and dump that to file for investigation.
  • 38. Re: logon issue with OL 6.3
    Dude! Guru
    Currently Being Moderated
    I have too never experienced such a login delay and had my doubts that DNS could be the issue. You may have seen the beginning of this thread where I was providing a link to a previous thread that resolved as a GSSAPI authentication issue.

    However, if the authentication process was the culprit, why would disabling DNS on the server side eliminate the delay?

    Perhaps the following might finally shed some light on the root cause of the issue:

    Don't forget to reset the noDNS parameter in the sshd_config file and /etc/nsswitch.conf to the default

    Open a root terminal:
    # service sshd stop
    # /usr/sbin/sshd -d -d -d
    Then login from the client in another session and watch the server screen for any clues.

    If this does not reveal the issue, how about strace:
    # yum install strace
    # service sshd stop
    # strace /usr/sbin/sshd
    To get out of the above mode, simply restart the server or hit Ctr-c followed by service sshd restart

    Test:

    <pre>
    I modified /etc/resolv.conf containing unreachable IP addresses:

    # cat /etc/resolv.conf
    nameserver 10.0.0.50
    nameserver 10.0.0.100

    service network restart
    service sshd stop
    /usr/sbin/sshd -d -d -d

    You may see a similar output:

    debug2: input_userauth_request: try method publickey
    debug1: test whether pkalg/pkblob are acceptable
    debug3: mm_key_allowed entering
    debug3: mm_request_send entering: type 38
    debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED
    debug3: mm_request_receive_expect entering: type 39
    debug3: mm_request_receive entering
    debug3: Trying to reverse map address 10.0.0.1.

    Delay of 20 seconds
    </pre>
  • 39. Re: logon issue with OL 6.3
    BillyVerreynne Oracle ACE
    Currently Being Moderated
    Will run some tests when I get a change - pretty busy at the moment.

    Remember that SVR4 IPC message queue issue I posted about a while back (and wondering whether Posix IPC message queue would work better)? Reached a point where I had to revisit that code (for running on OL6.4) - and it seems the basic problem have been solved (no more messages dropping). But I ran into a really magnificent error that seems to partially corrupts the code segment when using msgctl(). But except for that, everything else is working fine... Got to love working with kernel APIs. Never know just what to expect. ;-)
  • 40. Re: logon issue with OL 6.3
    EdStevens Guru
    Currently Being Moderated
    Dude wrote:
    I have too never experienced such a login delay and had my doubts that DNS could be the issue. You may have seen the beginning of this thread where I was providing a link to a previous thread that resolved as a GSSAPI authentication issue.

    However, if the authentication process was the culprit, why would disabling DNS on the server side eliminate the delay?

    Perhaps the following might finally shed some light on the root cause of the issue:

    Don't forget to reset the noDNS parameter in the sshd_config file and /etc/nsswitch.conf to the default

    Open a root terminal:
    # service sshd stop
    # /usr/sbin/sshd -d -d -d
    Then login from the client in another session and watch the server screen for any clues.
    <snip>
    trace begins with first message emitted when second session sent connection request
    debug1: userauth-request for user root service ssh-connection method none
    debug1: attempt 0 failures 0
    debug3: mm_getpwnamallow entering
    debug3: mm_request_send entering: type 7
    debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM
    debug3: mm_request_receive_expect entering: type 8
    debug3: mm_request_receive entering
    debug3: monitor_read: checking request 7
    debug3: mm_answer_pwnamallow
    debug3: Trying to reverse map address 192.168.56.1.
    
    
    ------ delay ---------
    ------ the address it is trying to reverse map is that of the gateway - the VBox host-only adapter
    
    debug2: parse_server_config: config reprocess config len 563
    debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
    debug3: mm_request_send entering: type 8
    debug2: monitor_read: 7 used once, disabling now
    debug3: mm_request_receive entering
    debug2: input_userauth_request: setting up authctxt for root
    debug3: mm_start_pam entering
    debug3: mm_request_send entering: type 50
    debug3: mm_inform_authserv entering
    debug3: mm_request_send entering: type 3
    debug3: mm_inform_authrole entering
    debug3: mm_request_send entering: type 4
    debug2: input_userauth_request: try method none
    debug3: Wrote 84 bytes for a total of 2581
    debug3: monitor_read: checking request 50
    debug1: PAM: initializing for "root"
    debug1: PAM: setting PAM_RHOST to "192.168.56.1"
    debug1: PAM: setting PAM_TTY to "ssh"
    debug2: monitor_read: 50 used once, disabling now
    debug3: mm_request_receive entering
    debug3: monitor_read: checking request 3
    debug3: mm_answer_authserv: service=ssh-connection, style=
    debug2: monitor_read: 3 used once, disabling now
    debug3: mm_request_receive entering
    debug3: monitor_read: checking request 4
    debug3: mm_answer_authrole: role=
    debug2: monitor_read: 4 used once, disabling now
    debug3: mm_request_receive entering
    
    -------  waiting for password ------
  • 41. Re: logon issue with OL 6.3
    EdStevens Guru
    Currently Being Moderated
    Dude wrote:
    .... there is a single host-only net adapter listed, it is at 192.168.56.1, and DHCP server is NOT enabled for it. All that is default. I've never touched it.
    I always thought it was enabled by default. I just installed VirtualBox in Windows Guest machine to check. It is indeed enabled by default:

    Server: 192.168.56.100
    lower bound: 192.168.56.101
    upper bound: 192.168.56.254

    If you have it disabled than no problem with your IP address range, otherwise you may run into a problem when configuring a static IP and have any other machine trying to use the same address as a DHCP address.
    Interesting. I was working on my personal laptop last night (all work on this thread has been from my office desktop) and checked that .. exact same version of VBox, and it was as you said. Exact same version of Vbox. I surely don't remember changing that on my office machine, and as little as I monkey with network settings, I'd think I'd remember it. But maybe I'm having another 'senior moment'. ;-)
  • 42. Re: logon issue with OL 6.3
    EdStevens Guru
    Currently Being Moderated
    OK, let's recap and pull together information from several different messages.

    Host machine: Win 7 Pro, 64bit
    Virtual Box 4.2.10
    VBox net adapter:
    Ethernet adapter VirtualBox Host-Only Network:
    
       Connection-specific DNS Suffix  . :
       Link-local IPv6 Address . . . . . : fe80::b4f9:a17a:f469:25a4%16
       IPv4 Address. . . . . . . . . . . : 192.168.56.1
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Default Gateway . . . . . . . . . :
    Two virtual machines:
    - vblnxsrv56, running OL 5.6 64-bit - normal behavior
    - vblnxsrv63, running OL 6.3 64-bit - logon delay of 56 seconds before password prompt

    Both vm's configured with two nics:
    - nic 1 is NAT
    - nic 2 is host-only
    Both vm's created with all default values except:
    - eth0, mapped to nic 1, configured DHCP
    - eth1, mapped to nic 2, fixed IP of 192.168.56.1nn, where 'nn' matches the last two characters of the server name, and also matches the release of OL. (just for ease of keeping track of "who's on first")

    Following are contrasting various items of configuration. The value of the shell prompt indicates which server the item is from. I will always list the 5.6 first.

    ifconfig - 5.6
    [root@vblnxsrv56 ~]# ifconfig
    eth0      Link encap:Ethernet  HWaddr 08:00:27:BD:62:42  
              inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:16 errors:0 dropped:0 overruns:0 frame:0
              TX packets:30 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:2194 (2.1 KiB)  TX bytes:3696 (3.6 KiB)
    
    eth1      Link encap:Ethernet  HWaddr 08:00:27:C6:D9:6D  
              inet addr:192.168.56.156  Bcast:192.168.56.255  Mask:255.255.255.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:1060 errors:0 dropped:0 overruns:0 frame:0
              TX packets:911 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:108054 (105.5 KiB)  TX bytes:147447 (143.9 KiB)
    
    lo        Link encap:Local Loopback  
              inet addr:127.0.0.1  Mask:255.0.0.0
              UP LOOPBACK RUNNING  MTU:16436  Metric:1
              RX packets:34 errors:0 dropped:0 overruns:0 frame:0
              TX packets:34 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:0 
              RX bytes:3352 (3.2 KiB)  TX bytes:3352 (3.2 KiB)
    ifconfig - 6.3
    [root@vblnxsrv63 ~]# ifconfig
    eth0      Link encap:Ethernet  HWaddr 08:00:27:F8:B7:54  
              inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
              inet6 addr: fe80::a00:27ff:fef8:b754/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:1 errors:0 dropped:0 overruns:0 frame:0
              TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:590 (590.0 b)  TX bytes:1074 (1.0 KiB)
    
    eth1      Link encap:Ethernet  HWaddr 08:00:27:A0:25:6F  
              inet addr:192.168.56.163  Bcast:192.168.56.255  Mask:255.255.255.0
              inet6 addr: fe80::a00:27ff:fea0:256f/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:641 errors:0 dropped:0 overruns:0 frame:0
              TX packets:1022 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:55066 (53.7 KiB)  TX bytes:128717 (125.7 KiB)
    
    lo        Link encap:Local Loopback  
              inet addr:127.0.0.1  Mask:255.0.0.0
              inet6 addr: ::1/128 Scope:Host
              UP LOOPBACK RUNNING  MTU:16436  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0 frame:0
              TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:0 
              RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
    network-scripts/ifcfg-eth0 - 5.6
    [root@vblnxsrv56 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
    # Intel Corporation 82540EM Gigabit Ethernet Controller
    DEVICE=eth0
    BOOTPROTO=dhcp
    HWADDR=08:00:27:BD:62:42
    ONBOOT=yes
    DHCP_HOSTNAME=vblnxsrv56.vbdomain
    network-scripts/ifcfg-eth0 - 6.3
    [root@vblnxsrv63 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
    DEVICE="eth0"
    BOOTPROTO="dhcp"
    NM_CONTROLLED="yes"
    ONBOOT=yes
    TYPE="Ethernet"
    UUID="3760d917-8121-429a-a16e-7ec1c7d9b60e"
    HWADDR=08:00:27:F8:B7:54
    DEFROUTE=yes
    PEERDNS=yes
    PEERROUTES=yes
    IPV4_FAILURE_FATAL=yes
    IPV6INIT=no
    NAME="System eth0"
    network-scripts/ifcfg-eth1 - 5.6
    [root@vblnxsrv56 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1
    # Intel Corporation 82540EM Gigabit Ethernet Controller
    DEVICE=eth1
    BOOTPROTO=static
    BROADCAST=192.168.56.255
    HWADDR=08:00:27:C6:D9:6D
    IPADDR=192.168.56.156
    NETMASK=255.255.255.0
    NETWORK=192.168.56.0
    ONBOOT=yes
    network-scripts/ifcfg-eth1 - 6.3
    [root@vblnxsrv63 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1
    DEVICE="eth1"
    BOOTPROTO=none
    NM_CONTROLLED="yes"
    ONBOOT=yes
    TYPE="Ethernet"
    UUID="787482d6-a888-47d2-a899-0a49379bff25"
    HWADDR=08:00:27:A0:25:6F
    IPADDR=192.168.56.163
    PREFIX=24
    GATEWAY=192.168.56.1
    DEFROUTE=yes
    IPV4_FAILURE_FATAL=yes
    IPV6INIT=no
    NAME="System eth1"
    /etc/sysconfig/network - 5.6
    [root@vblnxsrv56 ~]# cat /etc/sysconfig/network
    NETWORKING=yes
    NETWORKING_IPV6=no
    HOSTNAME=vblnxsrv56.vbdomain
    /etc/sysconfig/network - 6.3
    [root@vblnxsrv63 ~]# cat /etc/sysconfig/network
    NETWORKING=yes
    HOSTNAME=vblnxsrv63.vbdomain
    /etc/hosts - 5.6
    [root@vblnxsrv56 ~]# cat /etc/hosts
    # Do not remove the following line, or various programs
    # that require network functionality will fail.
    127.0.0.1vblnxsrv56.vbdomain vblnxsrv56 localhost.localdomain localhost
    ::1localhost6.localdomain6 localhost6
    /etc/hosts - 6.3
    [root@vblnxsrv63 ~]# cat /etc/hosts
    127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
    ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
    /etc/resolv.conf - 5.6
    note: 'acmewidgets.org' and the asterisks mask company identifiable values. I was surprised they even showed up on the vm.
    notice that the 5.6 version has only the reference to the company domain, while the 6.3 adds the reference to my vb 'vbdomain'.
    [root@vblnxsrv56 ~]# cat /etc/resolv.conf
    ; generated by /sbin/dhclient-script
    search acmewidgets.org
    nameserver ***.***.***.3
    nameserver ***.***.***.1
    nameserver ***.***.***.9
    /etc/resolv.conf - 6.3
    [root@vblnxsrv63 ~]# cat /etc/resolv.conf
    ; generated by /sbin/dhclient-script
    search acmewidgets.org vbdomain
    nameserver ***.***.***.3
    nameserver ***.***.***.1
    nameserver ***.***.***.9
    routing table - 5.6
    [root@vblnxsrv56 ~]# route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
    192.168.56.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
    169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
    0.0.0.0         10.0.2.2        0.0.0.0         UG    0      0        0 eth0
    routing table - 6.3
    Note the duplication of 169.254.0.0 across both nics
    [root@vblnxsrv63 ~]# route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    0.0.0.0         192.168.56.1    0.0.0.0         UG    0      0        0 eth1
    10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
    169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
    169.254.0.0     0.0.0.0         255.255.0.0     U     1003   0        0 eth1
    192.168.56.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
    /etc/ssh/sshd_config - 5.6
    [root@vblnxsrv56 ~]# grep DNS /etc/ssh/sshd_config
    #UseDNS yes
    /etc/ssh/sshd_config - 6.3
    [root@vblnxsrv63 ~]# grep DNS /etc/ssh/sshd_config
    #UseDNS yes
    /etc/nsswitch.conf - 5.6
    [root@vblnxsrv56 ~]# grep hosts /etc/nsswitch.conf
    #hosts:     db files nisplus nis dns
    hosts:      files dns
    /etc/nsswitch.conf - 6.3
    [root@vblnxsrv63 ~]# grep hosts /etc/nsswitch.conf
    #hosts:     db files nisplus nis dns
    hosts:      files dns
    timing of domain resolution - 5.6
    [root@vblnxsrv56 ~]# date;dnsdomainname ;date
    Tue May  7 15:40:49 CDT 2013
    vbdomain
    Tue May  7 15:40:49 CDT 2013
    timing of domain resolution - 6.3
    [root@vblnxsrv63 ~]# date;dnsdomainname ;date
    Tue May  7 15:40:47 CDT 2013
    dnsdomainname: Host name lookup failure
    Tue May  7 15:41:43 CDT 2013
    timing of hostname resolution - 5.6
    [root@vblnxsrv56 ~]# date;hostname -v;date
    Tue May  7 15:41:52 CDT 2013
    gethostname()=`vblnxsrv56.vbdomain'
    vblnxsrv56.vbdomain
    Tue May  7 15:41:52 CDT 2013
    timing of hostname resolution - 6.3
    [root@vblnxsrv63 ~]# date;hostname -v;date
    Tue May  7 15:41:49 CDT 2013
    gethostname()=`vblnxsrv63.vbdomain'
    vblnxsrv63.vbdomain
    Tue May  7 15:41:49 CDT 2013
    And as discovered, the "fix" seems to be to modify /etc/ssh/sshd_config, to enable "UseDNS no". So I guess the question comes down to why would that be necessary on OL 6.3 (at least on my OL 6.3) and not on my several OL 5.x vm's?

    Edited by: EdStevens on May 8, 2013 8:59 AM
  • 43. Re: logon issue with OL 6.3
    Dude! Guru
    Currently Being Moderated
    debug3: Trying to reverse map address 192.168.56.1.
    This is actually normal since the VirtualBox host-only adapter acts on behalf of the client connection. Similarly, with the NAT adapter, the host adapter acts on behalf of the virtual machine.

    One thing to remember is that the host-only interface is no good for outgoing connections. Traffic should go out on your VirtualBox NAT interface.

    Looking at your previous output:
    and on the ill-behaved OL 6.3

    [root@vblnxsrv02 ~]# route -n
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use Iface
    0.0.0.0 192.168.56.1 0.0.0.0 UG 0 0 0 eth1
    I see that you have set 192.168.56.1 as the TCP/IP gateway. This is apparently not the case on your OL 5.6 machine.

    So I'm wondering, did you perhaps specify 192.168.56.1 as default gateway in the TCP/IP settings of your OL 6.3 virtual machine? You should not specify any gateway on that 192.168.56.102/103 interface. Just leave it blank. Compare it with the setting of your OL 5.6 machine.

    At least this would explain why your OL 6.3 machine cannot reach any DNS name server. It is not going to resolve 192.168.56.1 anyway, but at least it won't delay because it cannot connect to any DNS server.

    And btw, 192.168.56.100 - 254 are usually reserved for host-only DHCP. You could try to enable the DHCP server on the host-only adapter in your TCP/IP settings on the VM and enable the DCHP server on the host-only adapter of VirtualBox preferences. You will also see it does not set a gateway.
  • 44. Re: logon issue with OL 6.3
    AmitShil Newbie
    Currently Being Moderated
    guess it would be worth seeing the routing table of the host machine as well, 192.168.56.0 is on the link local for the host so there should be no need to enter any gateway entry on the guest (either of the machines) .

    what about the duplicate entries of 169 network on the 6.3 machine, why the duplicacy - any comments on that? surely Ed wouldn't have touched those entries ..

    As there's no such n/w present, it should be better to cleanse the routing table and remove this altogether

    Regards Amit

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points