SlackwareThis Forum is for the discussion of Slackware Linux.
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.
Since a few days all things concerning logging IN (ssh, su, sudo, hell even console) take ages. For as far I know I didn't change anything. I hoped it would disappear, but it is getting very annoying by now.
I didn't notice anything in my dmesg, nor in my other logs. I don't think it has to do with my uptime either, it is quite low since I had to reboot 3 weeks ago..
And for the record, I did check the reverse-dns 'nslookup <IP>' to check if SSH might be having that problem, but it errored out immediately as it should on my LAN.
Did anyone ever have this before? And more importantly, figure out a way to fix it?
hmm, only thing I can think of is maybe your disk is failing, but usually that would log errors...
You could run some tests with smartctl. What kernel is this?
Is it partition-specific (is /var on it's own partition)?
If this box is remote, does it respond to pings quickly?
When reading your answer I suddenly noticed that I somehow forgot a word in my first sentence (which is in the title however). It should have read: ...all things concerning logging IN ....
I do not have any problems with harddisks (for as far I know). I apologise if I confused everyone with my mistake
However, in case you did understand me, I will run some tests with smartctl later. Currently downloading something which I prefer to have finished as it is rather urgent
The box is semi-remote: I usually access it through putty from the main family computer, but if necessary I can also use the console. The login-delay is there in either case.
The following is the output of df -lh: (yes, /var is on its own partition, hda5).
I did some googling, and a remedy for a slow ssh login would be to add the ip address of the other computer into each /etc/hosts file. But if you're also having the same problem after you've logged in w/ su & sudo, those wouldn't be affected by this. I'm not convinced that's the fix for your problem. Could you post the /etc/ssh/sshd_config for the box you're trying to get to.
Yup I tried those but those didn't work. Also didn't seem to be my problem as it worked fine before, hell, I hadn't even rebooted when this behavior began
Code:
worstje@coresausage ssh $ cat sshd_config
# $OpenBSD: sshd_config,v 1.65 2003/08/28 12:54:34 markus Exp $
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.
#Port 22
#Protocol 2,1
#ListenAddress 0.0.0.0
#ListenAddress ::
# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768
# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCreds yes
# Set this to 'yes' to enable PAM authentication (via challenge-response)
# and session processing. Depending on your PAM configuration, this may
# bypass the setting of 'PasswordAuthentication'
#UsePAM yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#KeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
# no default banner path
#Banner /etc/issue
# override default of no subsystems
Subsystem sftp /usr/libexec/sftp-server
I haven't made any progress myself, but I thought it might be useful for any people who are interested to see my /etc/passwd and /etc/shadow (modified a bit naturally )
I am unfamiliar with the syntax of /etc/shadow, and the repeating 99999 number is a bit worrying since I am not sure whether it belongs there (never looked in /etc/shadow before )
Edit: I just found out that in the opposite of what my first message says, INITIAL console logins do NOT delay at all. But using anything else that wants your password from that point on (sudo, su) IS delayed.
On suse lists I found this post: su login delay
It shed some light on the problem. I looked at the other posts too and try the things they mentioned, for as far applicaple on a slackware system
'bash --login' works instantly.
adding 'set -x' to /etc/profile .. shows (like the guy in the thread) a huge delay and suddenly lots of output from bash.
/etc/pam.d/ ? Cannot do, don't have it
In the end this person disabled LDAP. So I googled for it, but it doesnt seem like its part of slackware or manually installed, but I do see that samba and sudo have some kind of support for it (in the packagebrowser wildcard search).
Is there anyway to see what is happening between 'login' and 'shell'? And once again, I don't think it's specific to ssh, su or sudo since its happening in each of them given certain circumstances (not being inital login on console to name something).
Back I am.
Well this must be something to do with the 'windows'-network it's linked to: rebooting the box fixed everything . Wish I had the possibility to have tried that 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.