Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I've got a Centos7 server setup in my Hyper-V. When i ssh into that machine it lags. After sshing into the machine, when i performs any type of action it lags. Even typing a simple cd it takes about a good minute for it show up on the screen let alone perform any type of action. This only happens when i ssh into that machine from anywhere. But when open up the machine from Hyper-v there is no lag or anything, it performs beautifully. Based on some reading online i have set the GSSAPIAuthentication no. Some forms suggest that it would clear up the issue but it hasn't. Please help.
I have RHEL7 guests on Hyper-V with no appreciable lag via ssh.
On looking at one just now in both /etc/ssh/ssh_config and /etc/ssh/sshd_config I see it set to yes:
GSSAPIAuthentication yes
Note that lines for GSSAPIAuthentication appears multiple times in the configs but is usually commented out (prepended by a pound sign [#]). It should only be uncommented once which is what I show above.
You may wish to be sure the line you're looking at is NOT commented out.
# GSSAPI options
GSSAPIAuthentication no
GSSAPICleanupCredentials no
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
#GSSAPIEnablek5users no
This is what i have in the /etc/ssh/sshd_config file. This whole file is the same as in the root account and the user account that has sudo privilages.
The only thing different is that in the root account this file has AllowUsers (username1) (username2). I am assuming that AllowUsers means that those users can ssh into the machine with their AD credentials. Thanks for your reply.
# GSSAPI options
GSSAPIAuthentication no
GSSAPICleanupCredentials no
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
#GSSAPIEnablek5users no
This is what i have in the /etc/ssh/sshd_config file. This whole file is the same as in the root account and the user account that has sudo privilages.
The only thing different is that in the root account this file has AllowUsers (username1) (username2). I am assuming that AllowUsers means that those users can ssh into the machine with their AD credentials. Thanks for your reply.
Just to clarify, you only have ONE /etc/ssh/ssh(d)config. You do not have one of these files for each user.
I apologize for the miscommunication. Yes, there is only one /etc/ssh/ssh(d). I have a user that is able to login with his AD credential and that user has sudo privilages, and then ofcoruse there is the root user. I just re-read your first comment about changing the "GSSAPIAuthentication no" in both the /etc/ssh/sshd_config and /etc/ssh/ssh_config. Originally i had changed it to "GSSAPIAuthentication no" in only the /etc/ssh/sshd_config file. I have made the changes in both places now, /etc/ssh/sshd_config and /etc/ssh/ssh_config. I just ssh'ed into that machine with a testuser and there didnt seem to be any lag. In my mind, i think that changing "GSSAPIAuthentication no" in both places may have fixed the issue. I just sent out an email to the privileged user to confirm that there is no more lag. Will get back to you on his reply.
I got a reply from the user and he states that he is still having lag on that machine while ssh'd into it. So it seems Changing the GSSAPI options in the ssh(d)_config file did not help. Anymore suggestion anyone?
I got a reply from the user and he states that he is still having lag on that machine while ssh'd into it. So it seems Changing the GSSAPI options in the ssh(d)_config file did not help. Anymore suggestion anyone?
If you're not having issues with a Linux users but he is with an AD user it suggests the issue may be with the AD access rather than the ssh access.
Also as noted in my earlier post we have GSSAPI option set to yes rather than no as you do. You might try reversing in both config files to see if it makes a difference.
From the Linux server can you connect to port 53 on XXX.XX.X.XX?
If you run "dig @XXX.XX.X.XX <workstation name>" does it give you the IP of the user's workstation from which he is doing his ssh to your Linux server?
If you run "dig @XXX.XX.X.XX <AD server name>" does it give you the IP of the AD server?
Do you have either of those name in /etc/hosts on the Linux server with different IPs than they have in DNS?
I hadn't noticed "myhostname" previously but see it is in my nsswitch.conf as well. On looking up its meaning I did find an article at RedHat saying it was causing issues if you didn't have package systemd-219-36.el7 or above. You might want to verify you do.
Article is at https://access.redhat.com/solutions/2766251 but requires a subscription to see.
From the Linux server can you connect to port 53 on XXX.XX.X.XX?
If you run "dig @XXX.XX.X.XX <workstation name>" does it give you the IP of the user's workstation from which he is doing his ssh to your Linux server?
If you run "dig @XXX.XX.X.XX <AD server name>" does it give you the IP of the AD server?
Do you have either of those name in /etc/hosts on the Linux server with different IPs than they have in DNS?
I hadn't noticed "myhostname" previously but see it is in my nsswitch.conf as well. On looking up its meaning I did find an article at RedHat saying it was causing issues if you didn't have package systemd-219-36.el7 or above. You might want to verify you do.
Article is at https://access.redhat.com/solutions/2766251 but requires a subscription to see.
output of #dig AD
; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.3 <<>> AD SERVER NAME HERE
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15075
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;AD SERVER NAME HERE. IN A
I did a #rpm -qa | grep systemd-219-36.el7
But got nothing in return. Which means i dont have the package at all in my system. I couldnt completely read the redhat article but i wonder, if you dont have the latest or the package at all what happens? you said it would cause an issue. what type of an issue?
If your responses ended with "IN A" after the host names it means they did NOT resolve so that may be your problem. Are your AD server and workstation in domain tang.com? If not did you type in the fully qualified domain name (FQDN) for each (i.e. servername.domainname)?
You're use of rpm command is slightly off.
rpm -qa will show ALL RPM packages - you can run "rpm -qa |grep systemd" to see all packages with systemd in the namme.
When you know the name of the package you can just specify that:
rpm -q systemd
You're not looking to see if you have exactly systemd-219-36.el7 but rather at least that version
So if for example you ran "rpm -q systemd" and it responded with systemd-219-19.el7_2.4.x86_64 that is version 219-19 which is earlier than 219-36 so you'd want to run "yum update systemd" to get the latest package.
On my test system doing that just now installed version 219-42. After the update "rpm -q systemd" now shows:
systemd-219-42.el7.x86_64
Since the link is restricted to RedHat subscribed users I can't put its contents here. It doesn't specifically talk about the issue you are having so may not be involved and the only reason I saw it was because I'd never noticed RHEL7 added that last item to hosts: line in nsswitch.conf before.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.