This discussion is archived
1 2 3 4 Previous Next 45 Replies Latest reply: May 8, 2013 8:31 AM by EdStevens RSS

logon issue with OL 6.3

EdStevens Guru
Currently Being Moderated
OL 6.3 x86-64 under VBox on Win7 Pro 64-bit.

I've got 5 OL 5.x machines under VBox, decided to give OL 6.3 a try. Once I get a new machine up, the first thing I do is get a putty connection to it. In this case it consistently takes 55 seconds from the time I enter the username (root) until it prompts me for the password. Once we get to that point everything seems to be fine, but 55 seconds of waiting to be prompted for the password "just ain't right". At first (before waiting that long) I thought perhaps it was a firewall issue. I did notice that with 5.x, on the first reboot after installation it comes up with a dialog to configure security. That's where I get the opportunity to turn off SELinux and configure (or turn off) the firewall. Didn't get that with 6.3, so I manually turned off the firewall, but now doubt that is the operative factor here.



Any of my 5.x vm's are subsecond response. Any ideas what might be going on?
  • 1. Re: logon issue with OL 6.3
    Avi Miller Guru
    Currently Being Moderated
    EdStevens wrote:
    Any ideas what might be going on?
    I'm guessing DNS isn't configured properly in the OL6 VM, which is causing sshd to timeout trying to resolve the incoming connection. Also, OL6 doesn't have any of the firstboot configuration tools in it's minimal/basic install like OL5 did.
  • 2. Re: logon issue with OL 6.3
    EdStevens Guru
    Currently Being Moderated
    Avi Miller wrote:
    EdStevens wrote:
    Any ideas what might be going on?
    I'm guessing DNS isn't configured properly in the OL6 VM, which is causing sshd to timeout trying to resolve the incoming connection. Also, OL6 doesn't have any of the firstboot configuration tools in it's minimal/basic install like OL5 did.
    That's possible. I did just now forge ahead to wget the yum repo file, and it took quite a while before telling me it couldn't resolve it. End of the day ... I'll take a look at it in the morning.
  • 3. Re: logon issue with OL 6.3
    Avi Miller Guru
    Currently Being Moderated
    EdStevens wrote:
    That's possible. I did just now forge ahead to wget the yum repo file, and it took quite a while before telling me it couldn't resolve it. End of the day ... I'll take a look at it in the morning.
    Note that 6.3 and 6.4 should have the public-yum-ol6.repo installed by default. I know 6.4 has it, and I believe 6.3 has it as well (though I can't remember exactly!)
  • 4. Re: logon issue with OL 6.3
    Dude! Guru
    Currently Being Moderated
    You might want to check if the delay is perhaps due to some security protocol failure and fallback.

    Here is a previous thread that might be useful:
    OEL 5.5 - access denied .... but not!
    OEL 5.5 - access denied .... but not!

    I suggest to logon using verbose mode to see where the ssh login hangs:

    ssh -vvv root@hostname

    I don't use PuTTY (I'm on Mac), but I think you have some options in the settings to enable verbose logging to a text file.

    So far I have not had any issues with SSH and reverse DNS lookups. From what understand, it's disabled in the default /etc/ssh/sshd_config file (#UseDNS yes).

    Edited by: Dude on May 4, 2013 6:28 AM
  • 5. Re: logon issue with OL 6.3
    EdStevens Guru
    Currently Being Moderated
    Dude wrote:
    You might want to check if the delay is perhaps due to some security protocol failure and fallback.

    Here is a previous thread that might be useful:
    OEL 5.5 - access denied .... but not!
    OEL 5.5 - access denied .... but not!

    I suggest to logon using verbose mode to see where the ssh login hangs:

    ssh -vvv root@hostname

    I don't use PuTTY (I'm on Mac), but I think you have some options in the settings to enable verbose logging to a text file.

    So far I have not had any issues with SSH and reverse DNS lookups. From what understand, it's disabled in the default /etc/ssh/sshd_config file (#UseDNS yes).
    Yeah, well we see the lamer that started THAT thread ... ;-)

    But based on that I did a series of tests. Increased my putty logging to include tcp packets, then connected both with and without GSSAPI enabled ... and repeated on one of my OL 5.x vm's.
    In all both cases (OL 6.3 vs. 5.6) with GSSAPI enabled, there was an extra set of packets exhanged .. one outgoing and one incoming ... before a packet exchange using the password.
    Logs were the same through this:
    Outgoing packet #0x4, type 5 / 0x05 (SSH2_MSG_SERVICE_REQUEST)
      00000000  00 00 00 0c 73 73 68 2d 75 73 65 72 61 75 74 68  ....ssh-userauth
    Incoming packet #0x4, type 6 / 0x06 (SSH2_MSG_SERVICE_ACCEPT)
      00000000  00 00 00 0c 73 73 68 2d 75 73 65 72 61 75 74 68  ....ssh-userauth
    Outgoing packet #0x5, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
      00000000  00 00 00 04 72 6f 6f 74 00 00 00 0e 73 73 68 2d  ....root....ssh-
      00000010  63 6f 6e 6e 65 63 74 69 6f 6e 00 00 00 04 6e 6f  connection....no
      00000020  6e 65                                            ne
    Incoming packet #0x5, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
      00000000  00 00 00 22 70 75 62 6c 69 63 6b 65 79 2c 67 73  ..."publickey,gs
      00000010  73 61 70 69 2d 77 69 74 68 2d 6d 69 63 2c 70 61  sapi-with-mic,pa
      00000020  73 73 77 6f 72 64 00                             ssword.
    {code}
    
    Then, with GSSAPI enabled, we get this
    {code}
    Event Log: Using SSPI from SECUR32.DLL
    Event Log: Attempting GSSAPI authentication
    Outgoing packet #0x6, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
      00000000  00 00 00 04 72 6f 6f 74 00 00 00 0e 73 73 68 2d  ....root....ssh-
      00000010  63 6f 6e 6e 65 63 74 69 6f 6e 00 00 00 0f 67 73  connection....gs
      00000020  73 61 70 69 2d 77 69 74 68 2d 6d 69 63 00 00 00  sapi-with-mic...
      00000030  01 00 00 00 0b 06 09 2a 86 48 86 f7 12 01 02 02  .......*.H......
    Incoming packet #0x6, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
      00000000  00 00 00 22 70 75 62 6c 69 63 6b 65 79 2c 67 73  ..."publickey,gs
      00000010  73 61 70 69 2d 77 69 74 68 2d 6d 69 63 2c 70 61  sapi-with-mic,pa
      00000020  73 73 77 6f 72 64 00                             ssword.
    Event Log: GSSAPI authentication request refused
    After which both configurations continue with
    Outgoing packet #0x7, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
      00000000  00 00 00 04 72 6f 6f 74 00 00 00 0e 73 73 68 2d  ....root....ssh-
      00000010  63 6f 6e 6e 65 63 74 69 6f 6e 00 00 00 08 70 61  connection....pa
      00000020  73 73 77 6f 72 64 00 XX XX XX XX XX XX XX XX XX  ssword.XXXXXXXXX
      00000030  XX XX XX                                         XXX
    Outgoing packet #0x8, type 2 / 0x02 (SSH2_MSG_IGNORE)
      00000000  00 00 00 b0 82 5d 4d ef a3 dc 88 4e 39 75 ac 11  .....]M....N9u..
      00000010  ca 60 26 f6 c0 31 35 10 03 0d 87 25 92 79 ec 43  .`&..15....%.y.C
      00000020  5e ee ff e7 c0 dc a2 9a 91 be 0b 07 6a 2f 8f 63  ^...........j/.c
      00000030  73 4f 07 e1 21 dd 80 0f 6b d4 84 53 8a 8b 83 0b  sO..!...k..S....
      00000040  35 2a c2 ee 9a 87 77 a4 99 92 99 1d a2 f5 27 a2  5*....w.......'.
      00000050  4e b3 d1 6d db 48 bd fe 90 57 60 46 54 96 d6 74  N..m.H...W`FT..t
      00000060  90 60 e4 b1 c1 68 2b 29 7b cc 42 a7 ed a9 c5 9b  .`...h+){.B.....
      00000070  4b e3 78 bf 74 e2 97 7d cd d0 d6 a2 3e 9d 53 ec  K.x.t..}....>.S.
      00000080  2a fa 14 99 11 25 ef f8 c0 74 e1 4c 77 ed 44 ab  *....%...t.Lw.D.
      00000090  6d 24 20 d8 c2 0e f0 35 7a 20 e8 05 84 ee a2 d6  m$ ....5z ......
      000000a0  be 09 21 1e 9a 7a 85 eb 1a ab 49 da d7 34 a1 26  ..!..z....I..4.&
      000000b0  ff ad e4 29                                      ...)
    Event Log: Sent password
    Incoming packet #0x7, type 52 / 0x34 (SSH2_MSG_USERAUTH_SUCCESS)
    Event Log: Access granted
    Both the OL 6.3 and the OL 5.6 exhibited the exact same sequence of packets. On OL 6.3, with GSSAPI enabled, it consistently takes 55+ seconds to get to the password prompt. Without GSSAPI it still takes about 30 seconds. On the OL 5.6, it is near instantaneous with or without GSSAPI.

    See my response to Avi Miller regarding follow up on DNS question.
  • 6. Re: logon issue with OL 6.3
    EdStevens Guru
    Currently Being Moderated
    Avi Miller wrote:
    EdStevens wrote:
    Any ideas what might be going on?
    I'm guessing DNS isn't configured properly in the OL6 VM, which is causing sshd to timeout trying to resolve the incoming connection. Also, OL6 doesn't have any of the firstboot configuration tools in it's minimal/basic install like OL5 did.
    As always, when we get into OS and networking, I know just enough to be dangerous, but here's what I've put together. I compared and contrasted the key net config files from the OL 5.6 system (which performs as expected) and the OL 6.3, which is the problem child. I'm not sure I understand ... no, I'm quite sure I don't understand -- the significance of the differences. In this listing, I go through the various files, top to bottom, with the ones from the OL 5.6 on the left and the 6.3 on the right.

    Keep in mind that these two vm's are on the same host OS under the same VBox setup. Except for IP address, server name, and domain name, everything is 'just shook it out of the box.'.


    ---------------------------------- /etc/sysconfig/network ---------------------------------- 
    
    -------- OL 5.6 --------                                           -------- OL 6.3 --------
    NETWORKINGyes                                                      NETWORKING=yes
    NETWORKING_IPV6=no                                                 HOSTNAME=vblnxsrv02.vbdomain
    HOSTNAME=vblnxsrv03.vbdomain
    
    
    ---------------------------------- ifcfg-eth0 ---------------------------------- 
    -------- OL 5.7 --------                                           -------- OL 6.3 --------
    # Intel Corporation 82540EM Gigabit Ethernet Controller            DEVICE="eth0"
    DEVICE=eth0                                                        BOOTPROTO="dhcp"
    BOOTPROTO=dhcp                                                     NM_CONTROLLED="yes"
    HWADDR=08:00:27:75:FB:5D                                           ONBOOT="yes"
    ONBOOT=yes                                                         TYPE="Ethernet"
    DHCP_HOSTNAME=vblnxsrv03.vbdomain                                  UUID="77f51d12-27a8-4574-b6e5-d2cd11e3bdc2"
                                                                       HWADDR=08:00:27:D8:F5:3F
                                                                       DEFROUTE=yes
                                                                       PEERDNS=yes
                                                                       IPV4_FAILURE_FATAL=yes
                                                                       IPV6INIT=no
                                                                       NAME="System eth0"
    
    
    ---------------------------------- ifcfg-eth1 ---------------------------------- 
    -------- OL 5.7 --------                                           -------- OL 6.3 --------
    # Intel Corporation 82540EM Gigabit Ethernet Controller            DEVICE="eth1"
    DEVICE=eth1                                                        BOOTPROTO="none"
    BOOTPROTO=static                                                   NM_CONTROLLED="yes"
    BROADCAST=192.168.56.255                                           ONBOOT="yes"
    HWADDR=08:00:27:94:37:86                                           TYPE="Ethernet"
    IPADDR=192.168.56.103                                              UUID="75a9f336-55c1-4947-b3ac-6e9e7450a84d"
    NETMASK=255.255.255.0                                              IPADDR=192.168.56.102
    NETWORK=192.168.56.0                                               PREFIX=24
    ONBOOT=yes                                                         GATEWAY=192.168.56.1
                                                                       DNS1=192.168.56.1
                                                                       DEFROUTE=yes
                                                                       IPV4_FAILURE_FATAL=yes
                                                                       IPV6INIT=no
                                                                       NAME="System eth1"
                                                                       HWADDR=08:00:27:60:45:8E
    In the above, on the 6.3 side, I find the "PREFIX=24" interesting. When I was going through the installation dialogs and configuring eth1, that was the value that popped into the net mask field before I over-rode it with 255.255.255.0.
    ---------------------------------- /etc/resolv.conf ---------------------------------- 
    -------- OL 5.7 --------                                           -------- OL 6.3 --------
    ; generated by /sbin/dhclient-script                               ; generated by /sbin/dhclient-script
    search <myorganization>.org                                        search <myorganization>.org vbdomain
    nameserver 172.nn.n1.3                                             nameserver 172.168.56.1
    nameserver 172.nn.n2.1                                             nameserver 172.nn.n2.1
    nameserver 172.nn.n1.9                                             nameserver 172.nn.n1.9
    As an aside, I just checked ifconfig on both boxes and noticed that the both have the same IP address on eth0 - the NT/dhcp nic. That seems rather odd.
  • 7. Re: logon issue with OL 6.3
    Dude! Guru
    Currently Being Moderated
    If you are using a default sshd server configuration there should be no issue with DNS. I can connect to several versions of Oracle Linux 6 and 5 under VirtualBox and have no login delays. Whether I have /etc/hosts configured and allow reverse DNS for the guest system does not make a difference. I also do not maintain any DNS for any virtual machine on the host system. However, I'm using Mac OS X and not PuTTy.

    I think the problem is related to your VirtualBox or TCP/IP setup. Perhaps you have a TCP/IP conflict or setup PORT forwarding on any VirtualBox NAT interface that is making some trouble. I think VirtualBox will not detect a TCP/IP or PORT forwarding conflict when you restore a machine from a snapshot or when a VM is in sleep mode.

    I have seen some connection delays in the past when using multiple virtual machines with NAT port forwarding, but I don't recall the details anymore. How does login work if you connect from one machine to another? How does it work if you have only one virtual guest system running. I cannot see how the netmask and ARP protocol can cause a connection delay in your setup.
  • 8. Re: logon issue with OL 6.3
    EdStevens Guru
    Currently Being Moderated
    Dude wrote:
    If you are using a default sshd server configuration there should be no issue with DNS. I can connect to several versions of Oracle Linux 6 and 5 under VirtualBox and have no login delays. Whether I have /etc/hosts configured and allow reverse DNS for the guest system does not make a difference. I also do not maintain any DNS for any virtual machine on the host system. However, I'm using Mac OS X and not PuTTy.

    I think the problem is related to your VirtualBox or TCP/IP setup. Perhaps you have a TCP/IP conflict or setup PORT forwarding on any VirtualBox NAT interface that is making some trouble. I think VirtualBox will not detect a TCP/IP or PORT forwarding conflict when you restore a machine from a snapshot or when a VM is in sleep mode.

    I think I have seen some connection delays when using multiple virtual machines with NAT port forwarding, but I don't recall the details anymore. How does login work if you connect from one machine to another? How does it work if you have only one virtual guest system running. I cannot see how the netmask and ARP protocol can cause a connection delay in your setup.

    Edited by: Dude on Apr 30, 2013 5:48 PM
    I hadn't tried connecting from another guest vm, but on your suggestion gave that a shot. No joy. ssh from a guest vm running OL 5.6 to my 6.3 guest gives about a 30 second delay. The same as putty from the host desktop without GSSAPI.
    Staring at the various config files some more, I found it odd that /etc/resolv.conf had references to my company's dns addresses. Even though my 5.6 vms have the same references, I tried commenting those out on the 6.3 and restarting the network. No change at all.

    Really at a loss here. When installing the vm, I made all the same choices as when building a 5.x machine. Any differences in the config files was imposed by the installer. To tie up any loose ends here ..
    1) the vbox net adapter is at 192.168.56.1
    2) All vms have two NICs. eth0 is configured NAT and dhcp. eth1 is configured host-only and an assigned ip address.
    3) The ip address assigned to eth1 is 192.168.56.1nn. For 'nn' I use the last two digits of the server name - vblnxsrv02 that is '02' so I assign an ip of 192.168.56.102.

    I just blew away and rebuilt vblnxsrv02, to clear away any vestiges of earlier adjustments. It is now absolutely clean, fresh out of the box. I've not done anything beyond the initial reboot. The key config files look like this: (obvious comments inserted)
    [root@vblnxsrv02 ~]# cat /etc/sysconfig/network
    NETWORKING=yes
    HOSTNAME=vblnxsrv02.vbdomain
    
    [root@vblnxsrv02 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
    DEVICE="eth0"
    BOOTPROTO="dhcp"
    NM_CONTROLLED="yes"                          <- does not exist in 5.6 config
    ONBOOT=yes
    TYPE="Ethernet"                              <- does not exist in 5.6 config
    UUID="d2e4a1d9-f50e-47f7-a8b7-0208dba938af"  <- does not exist in 5.6 config
    HWADDR=08:00:27:50:94:AB
    DEFROUTE=yes                                 <- does not exist in 5.6 config
    PEERDNS=yes                                  <- does not exist in 5.6 config
    PEERROUTES=yes                               <- does not exist in 5.6 config
    IPV4_FAILURE_FATAL=yes                       <- does not exist in 5.6 config
    IPV6INIT=no                                  <- does not exist in 5.6 config
    NAME="System eth0"                           <- does not exist in 5.6 config
    Also of note, in the eth0 config, the 5.6 server has the following, not found on 6.3

    DHCP_HOSTNAME=vblnxsrv01.vbdomain
    [root@vblnxsrv02 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1
    DEVICE="eth1"
    BOOTPROTO=none
    NM_CONTROLLED="yes"                         <- does not exist in 5.6 config
    ONBOOT=yes                                  <- does not exist in 5.6 config
    TYPE="Ethernet"                             <- does not exist in 5.6 config
    UUID="387da666-e13b-4431-9f13-2645754bf637" <- does not exist in 5.6 config
    HWADDR=08:00:27:A2:45:04
    IPADDR=192.168.56.102                       <- provided during OS installation
    PREFIX=24
    GATEWAY=192.168.56.1                        <- provided during OS installation, does not exist in 5.6 config
    DNS1=192.168.56.2                           <- provided during OS installation, does not exist in 5.6 config
    DOMAIN=vbdomain                             <- provided during OS installation, does not exist in 5.6 config
    DEFROUTE=yes
    IPV4_FAILURE_FATAL=yes                      <- does not exist in 5.6 config
    IPV6INIT=no                                 <- does not exist in 5.6 config
    NAME="System eth1"                          <- does not exist in 5.6 config
    Also of note, in the eth1 config, the 5.6 server has the following, not found on 6.3

    BROADCAST=192.168.56.255
    NETMASK=255.255.255.0
    NETWORK=192.168.56.0
    [root@vblnxsrv02 ~]# cat /etc/resolv.conf
    ; generated by /sbin/dhclient-script
    nameserver 192.168.56.2                     <- provided during OS installation
    nameserver 172.nn.n1.1
    nameserver 172.nn.n2.9
    search vbdomain
    [root@vblnxsrv02 ~]#
    Also of note in resolv.conf, on the 5.6 machine, the 3 'nameserver' entries all refer to my corporate addresses, none for the local vbox networ, and the 'search' parameter refers to my corporate domain.
  • 9. Re: logon issue with OL 6.3
    Dude! Guru
    Currently Being Moderated
    Perhaps you could try a different approach to diagnose the problem.

    A TCP dump is not really useful in this case. Unfortunately my experience with PuTTy logging or debugging is limited. But you could perhaps download the free version of MobaXterm from http://mobaxterm.mobatek.net. It is a single standalone application (15 MB), based on Cygwin, which includes a ssh client, terminal based on putty and a free X Window server, bash, etc.

    Then open mobaxterm and type "ssh -vvv root@remote_IP"

    You should see at which ssh debug step the login delay happens.
  • 10. Re: logon issue with OL 6.3
    EdStevens Guru
    Currently Being Moderated
    Dude wrote:
    Perhaps you could try a different approach to diagnose the problem.

    A TCP dump is not really useful in this case. Unfortunately my experience with PuTTy logging or debugging is limited. But you could perhaps download the free version of MobaXterm from http://mobaxterm.mobatek.net. It is a single standalone application (15 MB), based on Cygwin, which includes a ssh client, terminal based on putty and a free X Window server, bash, etc.

    Then open mobaxterm and type "ssh -vvv root@remote_IP"

    You should see at which ssh debug step the login delay happens.
    Here's the last several lines of that output
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug2: set_newkeys: mode 0
    debug1: SSH2_MSG_NEWKEYS received
    debug1: Roaming not allowed by server
    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.  Up to here it was as fast as the screen could scroll.  Paused at this point.  When it finally picked up, again it was as fast as the screen could scroll.
    
    
    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
    debug3: authmethod_lookup publickey
    debug3: remaining preferred: password,keyboard-interactive
    debug3: authmethod_is_enabled publickey
    debug1: Next authentication method: publickey
    debug1: Trying private key: /home/mobaxterm/.ssh/id_rsa
    debug3: no such identity: /home/mobaxterm/.ssh/id_rsa
    debug1: Trying private key: /home/mobaxterm/.ssh/id_dsa
    debug3: no such identity: /home/mobaxterm/.ssh/id_dsa
    debug1: Trying private key: /home/mobaxterm/.ssh/id_ecdsa
    debug3: no such identity: /home/mobaxterm/.ssh/id_ecdsa
    debug2: we did not send a packet, disable method
    debug3: authmethod_lookup password
    debug3: remaining preferred: keyboard-interactive
    debug3: authmethod_is_enabled password
    debug1: Next authentication method: password
    root@vblnxsrv02's password:   <<<< finally prompted for pswd
  • 11. Re: logon issue with OL 6.3
    Dude! Guru
    Currently Being Moderated
    Are there any clues in /var/log/secure?

    Can you check the result of the following on your server:
    # grep hosts /etc/nsswitch.conf
    And change it to "hosts: files dns" if necessary? Then logout and try again.
  • 12. Re: logon issue with OL 6.3
    EdStevens Guru
    Currently Being Moderated
    Dude wrote:
    Are there any clues in /var/log/secure?

    Can you check the result of the following on your server:
    # grep hosts /etc/nsswitch.conf
    And change it to "hosts: files dns" if necessary? Then logout and try again.
    Whaddya know! Actually, it was already set to 'files dns', so on a chance I just removed the 'dns'. Immediate problem solved, though I sure don't understand why that was necessary on the 6.3 server and not the 5.6 ones. Now you've done it -- just piled some more on my 'to research' list, to educate myself about nsswitch.conf ...
  • 13. Re: logon issue with OL 6.3
    Dude! Guru
    Currently Being Moderated
    I wouldn't feel comfortable with this solution. The /etc/nsswitch file determines how and in which order your system will obtain name-service information. You will need "dns" in order to browse the internet.

    Like I mentioned, non of my virtual machines can do a reverse lookup of my host IP address and I have no login delays. I also think that the ssh server does not attempt a reverse name lookup of the client, unless you configure useDNS in the sshd_config file. The problem might be something else. Can you check or post your /etc/hosts file?
  • 14. Re: logon issue with OL 6.3
    EdStevens Guru
    Currently Being Moderated
    Dude wrote:
    I wouldn't feel comfortable with this solution. The /etc/nsswitch file determines how and in which order your system will obtain name-service information. You will need "dns" in order to browse the internet.
    I don't feel comfortable with it either. Not because of any technical understanding (obviously something I lack in this area) but simply because it is so far outside of what has been my normal procedure.
    Like I mentioned, non of my virtual machines can do a reverse lookup of my host IP address and I have no login delays. I also think that the ssh server does not attempt a reverse name lookup of the client, unless you configure useDNS in the sshd_config file. The problem might be something else. Can you check or post your /etc/hosts file?
    Out of the box, the hosts file looks like this:
    [root@vblnxsrv02 ~]# cat /etc/hosts
    127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
    ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
    again, just on a flyer, I added the 'self reference', which I normally do pretty early in my setup, but a few steps beyond where I am on this one:
    192.168.56.102   vblnxsrv02 vblnxsrv02.vbdomain
    But that made no difference.

    By contrast, a 'straight out of the box' OL 5.6 looks like this
    [root@vblnxsrv03 ~]# cat /etc/hosts
    # Do not remove the following line, or various programs
    # that require network functionality will fail.
    127.0.0.1               vblnxsrv03.vbdomain vblnxsrv03 localhost.localdomain localhost
    ::1             localhost6.localdomain6 localhost6
    Quite a bit of difference in what it assocates with 127.0.0.1 -- especially in putting the actual server name there. In my normal setup, that's something I always change .. so that my final hosts file would look like this:
    # Do not remove the following line, or various programs
    # that require network functionality will fail.
    127.0.0.1               localhost.localdomain localhost
    ::1             localhost6.localdomain6 localhost6
    192.168.56.103   vblnxsrv03.vbdomain vblnxsrv03
1 2 3 4 Previous Next

Legend

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