Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here. |
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.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
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.
|
|
06-21-2006, 04:34 PM
|
#1
|
LQ Newbie
Registered: Aug 2004
Location: Southern IL
Distribution: OpenSuSE 10.1
Posts: 24
Rep:
|
SSH: One moment, I can log in, next I can't!!
Running OpenSSH_3.8.1p1, Debian-8.sarge.4, 2.4.27-2-386.
I'm having major issues with ssh. I authenticate via an rsa key. Sometimes, I can log in without any incident. Other times, though, I get this:
Code:
[root@client ~]# ssh -v user@remote_server
OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to remote_server [192.168.1.6] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host
I'll try it again immediately, probably get the same results. But after 5-6 tries, BAM, I'm back in, no problem.
I know for a fact this isn't a client issue. I've checked my hosts.deny (which is blank) and my hosts.allow (SSH: ALL\nSSHD: ALL\nALL: ALL).
It worked for MONTHS, a couple of hundred of automatic logins a day without any incident, and then it started happening.
I can't find a log that has the failed ssh attempts. /var/www/auth.log only has successes recorded.
Any ideas?
|
|
|
06-23-2006, 12:01 AM
|
#2
|
Senior Member
Registered: Sep 2003
Posts: 3,171
Rep:
|
communications link problem?
|
|
|
06-23-2006, 12:18 AM
|
#3
|
Member
Registered: Oct 2005
Location: Australia
Distribution: slackware 12.1
Posts: 753
Rep:
|
Quote:
communications link problem?
|
most probably. also check for packet loss.
|
|
|
06-23-2006, 11:39 PM
|
#4
|
Member
Registered: Mar 2004
Posts: 135
Rep:
|
maybe the cable is loose.
|
|
|
06-24-2006, 08:00 PM
|
#5
|
LQ Newbie
Registered: Aug 2004
Location: Southern IL
Distribution: OpenSuSE 10.1
Posts: 24
Original Poster
Rep:
|
Code:
11734 packets transmitted, 11734 received, 0% packet loss, time 11733437ms
rtt min/avg/max/mdev = 0.167/0.340/0.804/0.093 ms
0% packet loss. Any other ideas?
|
|
|
06-24-2006, 09:52 PM
|
#6
|
Member
Registered: Mar 2005
Location: Right behind you.
Distribution: NBG, then randomed.
Posts: 480
Rep:
|
Looks like simple instability on the remote host to me. If you want to know more about what's going on, run `tcpdump -l -v -n port 22` on it in a screen session or something while you're connecting to it. What sshd writes to the syslog isn't going to be entirely useful in debugging why a connection is dumped if sshd is coredumping before it can decide whether to drop or accept the connection.
|
|
|
06-25-2006, 04:09 PM
|
#7
|
HCL Maintainer
Registered: Jan 2006
Distribution: (H)LFS, Gentoo
Posts: 2,450
Rep:
|
In addition to the suggestions above, why don't you look at the most detailed debug logs (debug3) on both sides (if you have that kind of control).
Also, why are you logging in as root?
|
|
|
06-26-2006, 09:27 AM
|
#8
|
LQ Newbie
Registered: Aug 2004
Location: Southern IL
Distribution: OpenSuSE 10.1
Posts: 24
Original Poster
Rep:
|
Why am I logging in as root? The prompt above is a fake. Would it even matter if I was logged in as root (for the sake of troubleshooting), or were you going to just give the advice that I shouldn't be logged in as root?
Why don't I post the debug logs? Because they haven't had anything appended to them in the last 20 days. Considering that this error happens hundreds of times a day, logic would suggest that this error is not producing output to my debug log. Is there something I'm not understanding?
|
|
|
06-26-2006, 09:40 AM
|
#9
|
LQ Newbie
Registered: Aug 2004
Location: Southern IL
Distribution: OpenSuSE 10.1
Posts: 24
Original Poster
Rep:
|
Ok, apparently I'm getting a build-up of hanging ssh connections/processes. When I reach my cap, I get that error.
Thanks for your help!
|
|
|
06-26-2006, 12:04 PM
|
#10
|
Member
Registered: Oct 2005
Location: Australia
Distribution: slackware 12.1
Posts: 753
Rep:
|
how do we generate an idea when we could not regenerate the problem? haven't seen whats its like. right now its only bits of suggesstions (check this, check that) i am afraid and i have run out of that too.
|
|
|
06-28-2006, 09:37 PM
|
#11
|
Member
Registered: Mar 2005
Location: Right behind you.
Distribution: NBG, then randomed.
Posts: 480
Rep:
|
Well, for one thing, I'm saying use tcpdump to look at the traffic (on both ends) to be sure that you're actually talking to the machine you're talking to. Someone might be trying to perform a MITM attack for all we know of your network topology.
|
|
|
06-29-2006, 02:22 AM
|
#12
|
Member
Registered: Mar 2006
Distribution: RedHat, Slackware, Experimenting with FreeBSD
Posts: 222
Rep:
|
Try regenerating your RSA key:
ssh-keygen -t rsa
reinsert the RSA key into the .ssh/authorized-keys on the server side.
When you try to login from the client, specify the identity key explicitly with the -i option:
ssh -i .ssh/id_rsa.pub remote_server
I am not sure whether the steps are identical on Debian Sarge but it should be similar.
Not sure that it will help but its worth a try.
*EDIT*
seems you've solved the problem. sorry for the repost
Last edited by SlackDaemon; 06-29-2006 at 02:25 AM.
|
|
|
All times are GMT -5. The time now is 12:33 PM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|