[opensuse] ssh problem
Hello, all of a sudden I cannot ssh connect to my providers webserver anymore, either as user, as root nor in a virtualbox/winXP/putty... There are some "funny" things: - I can ssh to other servers of the same provider, but not to "mine" - I can ssh from my Computer in Basel/Sitzerland to "my" server, but not from here in Barcelona/Spain The ISP - of course - says, the problem is on my side, but I can't find out anything... Can you help? OpenSuse 10.3. I attach a working and non-working "report" of the console dialog with verbose option below. I renamed known_hosts both in /root and /my-user-home (there is no known_hosts is /etc/ssh). No change. Dosn't work. Thanks for any hints. Daniel the reports -------------- non-working session server-x001: ssh -vvv xxx@server-x001.hostpoint.ch OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to server-x001.hostpoint.ch [217.26.50.6] port 22. debug1: connect to address 217.26.50.6 port 22: Connection timed out ssh: connect to host server-x001.hostpoint.ch port 22: Connection timed out working session server-x002: ssh -vvv xxx@server-x002.hostpoint.ch OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to server-x002.hostpoint.ch [217.26.50.7] port 22. debug1: Connection established. debug1: identity file /home/daniel/.ssh/id_rsa type -1 debug1: identity file /home/daniel/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.5p1 FreeBSD-20061110 debug1: match: OpenSSH_4.5p1 FreeBSD-20061110 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.6 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 127/256 debug2: bits set: 497/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/daniel/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug3: check_host_in_hostfile: filename /home/daniel/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug3: check_host_in_hostfile: filename /home/daniel/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug2: no key of type 0 for host server-x002.hostpoint.ch debug3: check_host_in_hostfile: filename /home/daniel/.ssh/known_hosts2 debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts2 debug3: check_host_in_hostfile: filename /home/daniel/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug2: no key of type 1 for host server-x002.hostpoint.ch The authenticity of host 'server-x002.hostpoint.ch (217.26.50.7)' can't be established. DSA key fingerprint is 2b:76:60:60:64:82:f1:ac:c6:a3:fd:d6:11:89:15:c5. Are you sure you want to continue connecting (yes/no)? no Host key verification failed. -- Daniel Bauer photographer Basel Barcelona professional photography: http://www.daniel-bauer.com erotic art photos: http://www.bauer-nudes.com Madagascar special: http://www.fotograf-basel.ch/madagascar/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 31 March 2009 18:43:12 Daniel Bauer wrote:
non-working session server-x001:
ssh -vvv xxx@server-x001.hostpoint.ch OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to server-x001.hostpoint.ch [217.26.50.6] port 22. debug1: connect to address 217.26.50.6 port 22: Connection timed out ssh: connect to host server-x001.hostpoint.ch port 22: Connection timed out
This machine is either not running, or it's dropping all tcp packets from you. or possibly your local firewall is dropping all packets from the server including those that come in response to packets you have sent to it, but I find this a less likely possibility, since you would have had to set it up manually It can't be a problem with "known_hosts" or any other ssh config on your side, because you simply never get that far. The TCP connection is never established My guess is that it's simply not running. Note that it's not enough for the machine to be running and sshd to have died, you would not see this effect. In this case you would get a TCP reset (connection refused), not a timeout. In this case the remote machine is not responding to you at all. This requires either a dead box completely, or a firewall blocking access by dropping packets Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 31 March 2009 18:55:24, Anders Johansson wrote:
On Tuesday 31 March 2009 18:43:12 Daniel Bauer wrote:
non-working session server-x001:
ssh -vvv xxx@server-x001.hostpoint.ch OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to server-x001.hostpoint.ch [217.26.50.6] port 22. debug1: connect to address 217.26.50.6 port 22: Connection timed out ssh: connect to host server-x001.hostpoint.ch port 22: Connection timed out
This machine is either not running, or it's dropping all tcp packets from you.
It is running. I know, because my wife tried to connect via ssh at home in Switzerland and it worked. Also one of the supporters now weote me, he tried from home and additionally via another way and always could connect. So it seems it's dropping my packets. But then again: the supporter says he cannot see anything in the server logs ???
or possibly your local firewall is dropping all packets from the server including those that come in response to packets you have sent to it, but I find this a less likely possibility, since you would have had to set it up manually
I havn't changed anything here since long time. The problem first occured yesterday: I had an sftp session open with konqueror (which I always use for file management on my server), I deleted a bunch of directories and files on the server, and then wanted to upload new files. It took "for ever" and finally I stopped konq and tried to connect via console/ssh... Later I rebooted, but no change. Then I hoped I would better today, after rebooting this morning. But no.
It can't be a problem with "known_hosts" or any other ssh config on your side, because you simply never get that far. The TCP connection is never established
My guess is that it's simply not running.
Note that it's not enough for the machine to be running and sshd to have died, you would not see this effect. In this case you would get a TCP reset (connection refused), not a timeout. In this case the remote machine is not responding to you at all. This requires either a dead box completely, or a firewall blocking access by dropping packets
Is it possible that I have a "bad" IP-number at the moment? Would it eventually help if I shutdown my WLAN-router and restart it? Or any other ideas? I'm quite helpless, these things are far beyound my knowledge... thanks for help Daniel -- Daniel Bauer photographer Basel Barcelona professional photography: http://www.daniel-bauer.com erotic art photos: http://www.bauer-nudes.com Madagascar special: http://www.fotograf-basel.ch/madagascar/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 31 March 2009 20:53:22 Daniel Bauer wrote:
Is it possible that I have a "bad" IP-number at the moment? Would it eventually help if I shutdown my WLAN-router and restart it?
It could be. If the IP address has changed (you could confirm this by looking at the IP address your wife gets when she connects). That could have the same effect (assuming either that your old IP now points to something that is dropping packets or that something along the way is dropping ICMP packets) About restarting your router, well, is that your dns server? Compare the IP address you get with the one your wife gets.If they're different, then you can start restarting things Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 31 March 2009 21:17:35, Anders Johansson wrote:
On Tuesday 31 March 2009 20:53:22 Daniel Bauer wrote:
Is it possible that I have a "bad" IP-number at the moment? Would it eventually help if I shutdown my WLAN-router and restart it?
It could be. If the IP address has changed (you could confirm this by looking at the IP address your wife gets when she connects). That could have the same effect (assuming either that your old IP now points to something that is dropping packets or that something along the way is dropping ICMP packets)
About restarting your router, well, is that your dns server?
No, it's not the DNS server, but the dhcp server. However, when I disconnet and reconnect it I get a new IP address. I tried to ping the server by its name and it worked. It showed the same IP of the server as it showed from Switzerland. I could also not ssh using the IP-Number of the server.
Compare the IP address you get with the one your wife gets.If they're different, then you can start restarting things
Anders
I dis/reconnected the router, got a new IP address - and the ssh login works again... But I don't know, if it is because of this or just because some time has passed in between. The provider says, that the IP I had before was *not* blocked by the server and that they cannot see anything in their logs. Is it possible that my konqueror caused the problem somehow? The same problem already occured once in October last year, also during a konqueror sftp session - and it also solved itself magically after some days... If it was konqueror is there a place I could find hints (like log files, and if so, for what would I have to search there...)? Daniel -- Daniel Bauer photographer Basel Barcelona professional photography: http://www.daniel-bauer.com erotic art photos: http://www.bauer-nudes.com Madagascar special: http://www.fotograf-basel.ch/madagascar/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday 01 April 2009 13:17:49 Daniel Bauer wrote:
Is it possible that my konqueror caused the problem somehow?
The same problem already occured once in October last year, also during a konqueror sftp session - and it also solved itself magically after some days...
It could be, konqueror opens multiple ssh sessions with the server, and some servers have very silly anti-DoS rules that are far too aggressive in blocking. So yes, this could very well be the reason Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hi Anders, I forwarded your message to my provider - and now received the answer that they have "a 2nd firewall" of which the supporter wasn't aware and there he found my IP that was blocked. So it seems I had too many connections of konqueror (I remember I deleted a directory with many sub- and sub-sub-directories). However, thanks to your hint the problem could be solved now. regards Daniel On Wednesday 01 April 2009 13:22:55, Anders Johansson wrote:
On Wednesday 01 April 2009 13:17:49 Daniel Bauer wrote:
Is it possible that my konqueror caused the problem somehow?
The same problem already occured once in October last year, also during a konqueror sftp session - and it also solved itself magically after some days...
It could be, konqueror opens multiple ssh sessions with the server, and some servers have very silly anti-DoS rules that are far too aggressive in blocking. So yes, this could very well be the reason
Anders
-- Daniel Bauer photographer Basel Barcelona professional photography: http://www.daniel-bauer.com erotic art photos: http://www.bauer-nudes.com Madagascar special: http://www.fotograf-basel.ch/madagascar/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, Mar 31, 2009 at 12:43 PM, Daniel Bauer
Hello,
all of a sudden I cannot ssh connect to my providers webserver anymore, either as user, as root nor in a virtualbox/winXP/putty...
There are some "funny" things:
- I can ssh to other servers of the same provider, but not to "mine" - I can ssh from my Computer in Basel/Sitzerland to "my" server, but not from here in Barcelona/Spain
The ISP - of course - says, the problem is on my side, but I can't find out anything...
Can you help?
OpenSuse 10.3. I attach a working and non-working "report" of the console dialog with verbose option below.
I renamed known_hosts both in /root and /my-user-home (there is no known_hosts is /etc/ssh). No change. Dosn't work.
Thanks for any hints.
Daniel
the reports -------------- non-working session server-x001:
ssh -vvv xxx@server-x001.hostpoint.ch OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to server-x001.hostpoint.ch [217.26.50.6] port 22. debug1: connect to address 217.26.50.6 port 22: Connection timed out ssh: connect to host server-x001.hostpoint.ch port 22: Connection timed out
working session server-x002:
ssh -vvv xxx@server-x002.hostpoint.ch OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to server-x002.hostpoint.ch [217.26.50.7] port 22. debug1: Connection established. debug1: identity file /home/daniel/.ssh/id_rsa type -1 debug1: identity file /home/daniel/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.5p1 FreeBSD-20061110 debug1: match: OpenSSH_4.5p1 FreeBSD-20061110 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.6 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 127/256 debug2: bits set: 497/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/daniel/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug3: check_host_in_hostfile: filename /home/daniel/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug3: check_host_in_hostfile: filename /home/daniel/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug2: no key of type 0 for host server-x002.hostpoint.ch debug3: check_host_in_hostfile: filename /home/daniel/.ssh/known_hosts2 debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts2 debug3: check_host_in_hostfile: filename /home/daniel/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug2: no key of type 1 for host server-x002.hostpoint.ch The authenticity of host 'server-x002.hostpoint.ch (217.26.50.7)' can't be established. DSA key fingerprint is 2b:76:60:60:64:82:f1:ac:c6:a3:fd:d6:11:89:15:c5. Are you sure you want to continue connecting (yes/no)? no Host key verification failed.
I had something similar happen over the weekend. I have a package running that looks for failed ssh connections and adds the IPs to the /etc/hosts.deny file. Somehow my home IP got in there. I came into the box by another route and added my home IP to the /etc/hosts.allow file. All was good after that. Greg -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 31 March 2009 19:44:22 Greg Freemyer wrote:
On Tue, Mar 31, 2009 at 12:43 PM, Daniel Bauer
[...] debug1: Connecting to server-x001.hostpoint.ch [217.26.50.6] port 22. debug1: connect to address 217.26.50.6 port 22: Connection timed out ssh: connect to host server-x001.hostpoint.ch port 22: Connection timed out [...] I had something similar happen over the weekend.
I have a package running that looks for failed ssh connections and adds the IPs to the /etc/hosts.deny file.
hosts.deny won't cause a network timeout, it will cause the remote machine to terminate the connection with a tcp reset Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (3)
-
Anders Johansson
-
Daniel Bauer
-
Greg Freemyer