You are not logged in.
Hello,
I have a problem with connections at work - it happens only at work, I tried on Arch and also Debian.
I haven't noticed it to affect 'web browsing' - it affects for sure ssh (incl. git) and sending email mesages.
What happens:
About 3/4 of times I try to send an email (google account from thunderbird), or log in to one of our servers with ssh (or pull/push some code from/to github) the connection 'hangs' and nothing happens. If I try ^C and 'redo' few times I finally manage to log in.
Log from ssh (unsuccessfull connection):
ssh bb5 -vvvv
OpenSSH_5.9p1, OpenSSL 1.0.0g 18 Jan 2012
debug1: Reading configuration data /home/kaczor/.ssh/config
debug1: /home/kaczor/.ssh/config line 18: Applying options for bb5
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to XXX.XXX.XXX.XXX [XXX.XXX.XXX.XXX] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/kaczor/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/kaczor/.ssh/id_rsa type 1
debug1: identity file /home/kaczor/.ssh/id_rsa-cert type -1
debug1: identity file /home/kaczor/.ssh/id_dsa type -1
debug1: identity file /home/kaczor/.ssh/id_dsa-cert type -1
debug1: identity file /home/kaczor/.ssh/id_ecdsa type -1
debug1: identity file /home/kaczor/.ssh/id_ecdsa-cert type -1
[-- and I can wait for ages on this --]
If the login is successfull the next lines are:
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze1
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug2: fd 3 setting O_NONBLOCK
...
My /etc/ssh/ssh_config on Arch is default (everything commented out)
~/.ssh/config has only few Host, User, entries
On Debian:
/etc/ssh/ssh_config
Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
Trying to ssh to server's IP doesn't change anything.
Any ideas how could I track where lies the problem? Or maybe I could at least make it 'retry' automatically?
Edit:
After setting timeout in ssh_config I get
Connection timed out during banner exchange
at the end of unsuccessfull connection.
Last edited by kaczor1984 (2012-04-24 15:15:17)
Offline
Can it be that your employer does not like encrypted traffic in his network? I could imagine an IPS system trying to decipher the connection... Try moving the server-side ssl service to a non-standard port if you can...
What happened to Arch's KISS? systemd sure is stupid but I must have missed the simple part ...
... and who is general Failure and why is he reading my harddisk?
Offline
Try connecting with the "-o ConnectTimeout=60" parameter. This will tell the ssh client to wait 60 seconds (or any number you want to try) before timing-out the banner exchange (and also applies to the normal tcp connection).
Seeing how you're seeing this behaviour on boxes other then your Arch, it's most likely caused by a delay in the network somewhere and will be difficult to troubleshoot. So the best we can try is to find a workaround for it.
Burninate!
Offline
Try downgrading openssl and openssh to the previous versions. I had issues similiar (but not exactly) to this. I think try openssl-1.0.0.h and openssh-5.9p1-5
Scott
Offline
Try downgrading openssl and openssh to the previous versions. I had issues similiar (but not exactly) to this. I think try openssl-1.0.0.h and openssh-5.9p1-5
Scott
On Debian the openssl is 0.9.8g-15 and openssh is 5.1p1-5
Try connecting with the "-o ConnectTimeout=60" parameter....
I've set it already in ssh_config file (see my edit). Is there any way to make ssh 'retry' few times because now it gives up after first failure.
I've set ConnectionAttempts 5 but i'm not sure if it works - I'll have to give it another try on tuesday.
Can it be that your employer does not like encrypted traffic in his network? I could imagine an IPS system trying to decipher the connection... Try moving the server-side ssl service to a non-standard port if you can...
It is possible - however I don't know exactly how is the network 'distributed'. Maybe I'll try to change it at least at one server and give it a try.
Anyway - what about emails for example - this uses port 25 (smtp on gmail) and is experiencing the same problems (message sending lasts until timeout 8 out of 10 times).
I don't know too much about networks - maybe there is some kind of service which doesn't work properly in my network at the office. Any clues what could it be?
Most important for me is to make 'git pull' work - because it's executed automatically on those Debian boxes and if it fails they are not updated.
So solution like 'make it retry 10 times per 5 seconds' will do the job for 90% cases I think.
Offline
...
Anyway - what about emails for example - this uses port 25 (smtp on gmail) and is experiencing the same problems (message sending lasts until timeout 8 out of 10 times).I don't know too much about networks - maybe there is some kind of service which doesn't work properly in my network at the office. Any clues what could it be?
.
This could support the traffic blockade theory as SMTP is usually the most blocked, or at least controlled protocol on many networks, not just corporate.
I'd suggest asking your network admin...
What happened to Arch's KISS? systemd sure is stupid but I must have missed the simple part ...
... and who is general Failure and why is he reading my harddisk?
Offline
I don't think you can use smtp (25) for gmail -- unless you have a special arrangement with google, the outgoing mail goes either to port 587 (submission) or 465. Both are encrypted with tls or ssl.
Arch Linux is more than just GNU/Linux -- it's an adventure
pkill -9 systemd
Offline
I don't think you can use smtp (25) for gmail -- unless you have a special arrangement with google, the outgoing mail goes either to port 587 (submission) or 465. Both are encrypted with tls or ssl.
You are right - my mistake - that isn't gmail, my second account is on gmail.
The problem seems to be solved - admin have replaced the modem and so far everything is working like a charm (seems like it was a hardware problem - recently everyone started complainig at 'not working email'). I'm keeping fingers crossed:)
Offline