SSH hangs whilst on VPN
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgO9GURib1T8z7lCwjOGLQaGtrueEthgQ8LO42ZX8cOfTqDK4jvDDpKkLFwf2J49kYCMNW7d4ABih_XCb_2UXdq5fPJDkoyg7-8g_YfRUot-XnaXkNYycsNp7lA5_TW9td0FFpLQ2APzKcZ/s1600/1.jpg)
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYQ0N5W1qAOxLP7t7iOM6O6AzbZnkXUy16s7P_CWfOb5UbTQY_aDsc727chyphenhyphen5W4IppVNernMMQeaUFTB_rFzAd95_CDt-tnwN-nBx6JyUp2duGjPaL5-VgNO41AVsA_vu30EJcipdDG409/s400/Clash+Royale+CLAN+TAG%2523URR8PPP.png)
up vote
0
down vote
favorite
I connect to a University shared computer facility by connecting to the University VPN and using SSH to log in. This is fine on my Windows installation using Cygwin. However, on my Ubuntu installation the SSH hangs.
Originally the VPN was not getting any internet access whatsoever, but I fixed this by removing dns=dnsmasq
from /etc/NetworkManager/NetworkManager.conf, but this did not fix the SSH error.
Also prior warning that I'm new to Ubuntu.
networking ssh vpn
add a comment |Â
up vote
0
down vote
favorite
I connect to a University shared computer facility by connecting to the University VPN and using SSH to log in. This is fine on my Windows installation using Cygwin. However, on my Ubuntu installation the SSH hangs.
Originally the VPN was not getting any internet access whatsoever, but I fixed this by removing dns=dnsmasq
from /etc/NetworkManager/NetworkManager.conf, but this did not fix the SSH error.
Also prior warning that I'm new to Ubuntu.
networking ssh vpn
Can you be more specific on the exact SSH error? Have you tried SSHing to the IP directly to see if that's the problem?
â Thomas Wardâ¦
Feb 8 at 15:23
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I connect to a University shared computer facility by connecting to the University VPN and using SSH to log in. This is fine on my Windows installation using Cygwin. However, on my Ubuntu installation the SSH hangs.
Originally the VPN was not getting any internet access whatsoever, but I fixed this by removing dns=dnsmasq
from /etc/NetworkManager/NetworkManager.conf, but this did not fix the SSH error.
Also prior warning that I'm new to Ubuntu.
networking ssh vpn
I connect to a University shared computer facility by connecting to the University VPN and using SSH to log in. This is fine on my Windows installation using Cygwin. However, on my Ubuntu installation the SSH hangs.
Originally the VPN was not getting any internet access whatsoever, but I fixed this by removing dns=dnsmasq
from /etc/NetworkManager/NetworkManager.conf, but this did not fix the SSH error.
Also prior warning that I'm new to Ubuntu.
networking ssh vpn
networking ssh vpn
asked Feb 2 at 19:21
![](https://i.stack.imgur.com/q5pC6.jpg?s=32&g=1)
![](https://i.stack.imgur.com/q5pC6.jpg?s=32&g=1)
obackhouse
1264
1264
Can you be more specific on the exact SSH error? Have you tried SSHing to the IP directly to see if that's the problem?
â Thomas Wardâ¦
Feb 8 at 15:23
add a comment |Â
Can you be more specific on the exact SSH error? Have you tried SSHing to the IP directly to see if that's the problem?
â Thomas Wardâ¦
Feb 8 at 15:23
Can you be more specific on the exact SSH error? Have you tried SSHing to the IP directly to see if that's the problem?
â Thomas Wardâ¦
Feb 8 at 15:23
Can you be more specific on the exact SSH error? Have you tried SSHing to the IP directly to see if that's the problem?
â Thomas Wardâ¦
Feb 8 at 15:23
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
0
down vote
This sounds like a problem with DNS, and more specifically DNS when using dnsmasq
with a VPN. There is a known issue when using dnsmasq
and NetworkManager with a VPN which will break DNS resolution within dnsmasq
. Upstream has acknowledged but also done nothing towards fixing it. This has been an issue since 16.04, and doesn't seem to be on their radar to fix any time soon. My guess is that they have no idea where it's actually breaking. (LP Bug #1588018, among many other bugs on the same problem)
The solution is to not use dnsmasq
at all, and instead use a different DNS system or set of DNS servers by default, usually by forcibly overriding the resolvconf
service settings.
However, this is a major, nontrivial change, and can cause other problems.
Therefore, there's no real workaround currently to this issue.
WARNING: This is my workaround to this problem, and is a non-standard, nontrivial solution to the DNS issue. Use only at your own risk.
My workaround was a painful, non-trivial one. I installed and configured bind9
to be a forwarding DNS resolver, so that it forwards all DNS queries off to Google DNS (8.8.8.8
and 8.8.4.4
), and then once that was working I went and edited my /etc/resolvconf/resolv.conf.d/head
file to query the local DNS. Note that I had to add a local DNS binding for 127.0.2.1
and in order for that to work I have to roll custom IP ranges in my lo
adapter by adding these lines to my /etc/network/interfaces
file (I included the default lo
auto/loopback declarations for context):
auto lo
iface lo inet loopback
up ip -4 addr add 127.0.2.1/8 dev lo
down ip -4 addr del 127.0.2.1/8 dev lo
... and by setting bind9
in the /etc/bind/named.conf.options
folder so that this is now in the options configuration block:
listen-on 127.0.2.1; ;
Once I rebooted the system after making those changes, the system began defaulting to using my local bind9
resolver.
However, this prevents VPNs which have Intranets and internal DNS resolutions and internal domains from properly resolving; this introduced other issues, but nothing I couldn't work around (as a power user and system administrator).
add a comment |Â
up vote
-2
down vote
To provide a meaningful answer, we'll need some more information. I'm assuming the VPN is a Cisco Openconnect VPN. Is that right? Without any more information, I'm guessing that your problem is in the setup of the VPN.
If so, there is a proprietary client from Cisco that works very well, but it's not necessary. Your university should provide a link to download and directions to install that client.
If you prefer open source solutions, there is a program called openconnect. Directions for its use are here.
Try 1 of these options. If you don't care about open source, honestly the Cisco client will work most easily. If you do care, then try openconnect.
Best of luck!
There is no reason to believe this is a VPN problem.
â Thomas Wardâ¦
Feb 8 at 15:11
I would say there is. I've used these VPNs with my university, and the routing is often touchy. Also, the fact that poster specifically mentions there was a routing problem requiring a change in NetworkManager implies something is fishy with the VPN.
â Noah
Feb 8 at 15:15
it's actually not a VPN problem, it's a NetworkManager / dnsmasq problem, and has had bugs about it since 2016 on the radar (see my answer which links to the bug). I'll bet if OP goes and usesping 8.8.8.8
or usesssh ip.add.re.ss
instead of trying to use a domain itself, it'll properly work. It's ultimately still not a VPN-specific issue, it's the Network Manager anddnsmasq
components being buggy and unfixed by upstream. And it's not just OpenConnect specific - it also affects OpenVPN andvpnc
traditional IPSec VPNs. Basically, all VPNs, not client or protocol specific.
â Thomas Wardâ¦
Feb 8 at 15:21
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
This sounds like a problem with DNS, and more specifically DNS when using dnsmasq
with a VPN. There is a known issue when using dnsmasq
and NetworkManager with a VPN which will break DNS resolution within dnsmasq
. Upstream has acknowledged but also done nothing towards fixing it. This has been an issue since 16.04, and doesn't seem to be on their radar to fix any time soon. My guess is that they have no idea where it's actually breaking. (LP Bug #1588018, among many other bugs on the same problem)
The solution is to not use dnsmasq
at all, and instead use a different DNS system or set of DNS servers by default, usually by forcibly overriding the resolvconf
service settings.
However, this is a major, nontrivial change, and can cause other problems.
Therefore, there's no real workaround currently to this issue.
WARNING: This is my workaround to this problem, and is a non-standard, nontrivial solution to the DNS issue. Use only at your own risk.
My workaround was a painful, non-trivial one. I installed and configured bind9
to be a forwarding DNS resolver, so that it forwards all DNS queries off to Google DNS (8.8.8.8
and 8.8.4.4
), and then once that was working I went and edited my /etc/resolvconf/resolv.conf.d/head
file to query the local DNS. Note that I had to add a local DNS binding for 127.0.2.1
and in order for that to work I have to roll custom IP ranges in my lo
adapter by adding these lines to my /etc/network/interfaces
file (I included the default lo
auto/loopback declarations for context):
auto lo
iface lo inet loopback
up ip -4 addr add 127.0.2.1/8 dev lo
down ip -4 addr del 127.0.2.1/8 dev lo
... and by setting bind9
in the /etc/bind/named.conf.options
folder so that this is now in the options configuration block:
listen-on 127.0.2.1; ;
Once I rebooted the system after making those changes, the system began defaulting to using my local bind9
resolver.
However, this prevents VPNs which have Intranets and internal DNS resolutions and internal domains from properly resolving; this introduced other issues, but nothing I couldn't work around (as a power user and system administrator).
add a comment |Â
up vote
0
down vote
This sounds like a problem with DNS, and more specifically DNS when using dnsmasq
with a VPN. There is a known issue when using dnsmasq
and NetworkManager with a VPN which will break DNS resolution within dnsmasq
. Upstream has acknowledged but also done nothing towards fixing it. This has been an issue since 16.04, and doesn't seem to be on their radar to fix any time soon. My guess is that they have no idea where it's actually breaking. (LP Bug #1588018, among many other bugs on the same problem)
The solution is to not use dnsmasq
at all, and instead use a different DNS system or set of DNS servers by default, usually by forcibly overriding the resolvconf
service settings.
However, this is a major, nontrivial change, and can cause other problems.
Therefore, there's no real workaround currently to this issue.
WARNING: This is my workaround to this problem, and is a non-standard, nontrivial solution to the DNS issue. Use only at your own risk.
My workaround was a painful, non-trivial one. I installed and configured bind9
to be a forwarding DNS resolver, so that it forwards all DNS queries off to Google DNS (8.8.8.8
and 8.8.4.4
), and then once that was working I went and edited my /etc/resolvconf/resolv.conf.d/head
file to query the local DNS. Note that I had to add a local DNS binding for 127.0.2.1
and in order for that to work I have to roll custom IP ranges in my lo
adapter by adding these lines to my /etc/network/interfaces
file (I included the default lo
auto/loopback declarations for context):
auto lo
iface lo inet loopback
up ip -4 addr add 127.0.2.1/8 dev lo
down ip -4 addr del 127.0.2.1/8 dev lo
... and by setting bind9
in the /etc/bind/named.conf.options
folder so that this is now in the options configuration block:
listen-on 127.0.2.1; ;
Once I rebooted the system after making those changes, the system began defaulting to using my local bind9
resolver.
However, this prevents VPNs which have Intranets and internal DNS resolutions and internal domains from properly resolving; this introduced other issues, but nothing I couldn't work around (as a power user and system administrator).
add a comment |Â
up vote
0
down vote
up vote
0
down vote
This sounds like a problem with DNS, and more specifically DNS when using dnsmasq
with a VPN. There is a known issue when using dnsmasq
and NetworkManager with a VPN which will break DNS resolution within dnsmasq
. Upstream has acknowledged but also done nothing towards fixing it. This has been an issue since 16.04, and doesn't seem to be on their radar to fix any time soon. My guess is that they have no idea where it's actually breaking. (LP Bug #1588018, among many other bugs on the same problem)
The solution is to not use dnsmasq
at all, and instead use a different DNS system or set of DNS servers by default, usually by forcibly overriding the resolvconf
service settings.
However, this is a major, nontrivial change, and can cause other problems.
Therefore, there's no real workaround currently to this issue.
WARNING: This is my workaround to this problem, and is a non-standard, nontrivial solution to the DNS issue. Use only at your own risk.
My workaround was a painful, non-trivial one. I installed and configured bind9
to be a forwarding DNS resolver, so that it forwards all DNS queries off to Google DNS (8.8.8.8
and 8.8.4.4
), and then once that was working I went and edited my /etc/resolvconf/resolv.conf.d/head
file to query the local DNS. Note that I had to add a local DNS binding for 127.0.2.1
and in order for that to work I have to roll custom IP ranges in my lo
adapter by adding these lines to my /etc/network/interfaces
file (I included the default lo
auto/loopback declarations for context):
auto lo
iface lo inet loopback
up ip -4 addr add 127.0.2.1/8 dev lo
down ip -4 addr del 127.0.2.1/8 dev lo
... and by setting bind9
in the /etc/bind/named.conf.options
folder so that this is now in the options configuration block:
listen-on 127.0.2.1; ;
Once I rebooted the system after making those changes, the system began defaulting to using my local bind9
resolver.
However, this prevents VPNs which have Intranets and internal DNS resolutions and internal domains from properly resolving; this introduced other issues, but nothing I couldn't work around (as a power user and system administrator).
This sounds like a problem with DNS, and more specifically DNS when using dnsmasq
with a VPN. There is a known issue when using dnsmasq
and NetworkManager with a VPN which will break DNS resolution within dnsmasq
. Upstream has acknowledged but also done nothing towards fixing it. This has been an issue since 16.04, and doesn't seem to be on their radar to fix any time soon. My guess is that they have no idea where it's actually breaking. (LP Bug #1588018, among many other bugs on the same problem)
The solution is to not use dnsmasq
at all, and instead use a different DNS system or set of DNS servers by default, usually by forcibly overriding the resolvconf
service settings.
However, this is a major, nontrivial change, and can cause other problems.
Therefore, there's no real workaround currently to this issue.
WARNING: This is my workaround to this problem, and is a non-standard, nontrivial solution to the DNS issue. Use only at your own risk.
My workaround was a painful, non-trivial one. I installed and configured bind9
to be a forwarding DNS resolver, so that it forwards all DNS queries off to Google DNS (8.8.8.8
and 8.8.4.4
), and then once that was working I went and edited my /etc/resolvconf/resolv.conf.d/head
file to query the local DNS. Note that I had to add a local DNS binding for 127.0.2.1
and in order for that to work I have to roll custom IP ranges in my lo
adapter by adding these lines to my /etc/network/interfaces
file (I included the default lo
auto/loopback declarations for context):
auto lo
iface lo inet loopback
up ip -4 addr add 127.0.2.1/8 dev lo
down ip -4 addr del 127.0.2.1/8 dev lo
... and by setting bind9
in the /etc/bind/named.conf.options
folder so that this is now in the options configuration block:
listen-on 127.0.2.1; ;
Once I rebooted the system after making those changes, the system began defaulting to using my local bind9
resolver.
However, this prevents VPNs which have Intranets and internal DNS resolutions and internal domains from properly resolving; this introduced other issues, but nothing I couldn't work around (as a power user and system administrator).
answered Feb 8 at 15:20
![](https://i.stack.imgur.com/jLgkr.jpg?s=32&g=1)
![](https://i.stack.imgur.com/jLgkr.jpg?s=32&g=1)
Thomas Wardâ¦
42k23117167
42k23117167
add a comment |Â
add a comment |Â
up vote
-2
down vote
To provide a meaningful answer, we'll need some more information. I'm assuming the VPN is a Cisco Openconnect VPN. Is that right? Without any more information, I'm guessing that your problem is in the setup of the VPN.
If so, there is a proprietary client from Cisco that works very well, but it's not necessary. Your university should provide a link to download and directions to install that client.
If you prefer open source solutions, there is a program called openconnect. Directions for its use are here.
Try 1 of these options. If you don't care about open source, honestly the Cisco client will work most easily. If you do care, then try openconnect.
Best of luck!
There is no reason to believe this is a VPN problem.
â Thomas Wardâ¦
Feb 8 at 15:11
I would say there is. I've used these VPNs with my university, and the routing is often touchy. Also, the fact that poster specifically mentions there was a routing problem requiring a change in NetworkManager implies something is fishy with the VPN.
â Noah
Feb 8 at 15:15
it's actually not a VPN problem, it's a NetworkManager / dnsmasq problem, and has had bugs about it since 2016 on the radar (see my answer which links to the bug). I'll bet if OP goes and usesping 8.8.8.8
or usesssh ip.add.re.ss
instead of trying to use a domain itself, it'll properly work. It's ultimately still not a VPN-specific issue, it's the Network Manager anddnsmasq
components being buggy and unfixed by upstream. And it's not just OpenConnect specific - it also affects OpenVPN andvpnc
traditional IPSec VPNs. Basically, all VPNs, not client or protocol specific.
â Thomas Wardâ¦
Feb 8 at 15:21
add a comment |Â
up vote
-2
down vote
To provide a meaningful answer, we'll need some more information. I'm assuming the VPN is a Cisco Openconnect VPN. Is that right? Without any more information, I'm guessing that your problem is in the setup of the VPN.
If so, there is a proprietary client from Cisco that works very well, but it's not necessary. Your university should provide a link to download and directions to install that client.
If you prefer open source solutions, there is a program called openconnect. Directions for its use are here.
Try 1 of these options. If you don't care about open source, honestly the Cisco client will work most easily. If you do care, then try openconnect.
Best of luck!
There is no reason to believe this is a VPN problem.
â Thomas Wardâ¦
Feb 8 at 15:11
I would say there is. I've used these VPNs with my university, and the routing is often touchy. Also, the fact that poster specifically mentions there was a routing problem requiring a change in NetworkManager implies something is fishy with the VPN.
â Noah
Feb 8 at 15:15
it's actually not a VPN problem, it's a NetworkManager / dnsmasq problem, and has had bugs about it since 2016 on the radar (see my answer which links to the bug). I'll bet if OP goes and usesping 8.8.8.8
or usesssh ip.add.re.ss
instead of trying to use a domain itself, it'll properly work. It's ultimately still not a VPN-specific issue, it's the Network Manager anddnsmasq
components being buggy and unfixed by upstream. And it's not just OpenConnect specific - it also affects OpenVPN andvpnc
traditional IPSec VPNs. Basically, all VPNs, not client or protocol specific.
â Thomas Wardâ¦
Feb 8 at 15:21
add a comment |Â
up vote
-2
down vote
up vote
-2
down vote
To provide a meaningful answer, we'll need some more information. I'm assuming the VPN is a Cisco Openconnect VPN. Is that right? Without any more information, I'm guessing that your problem is in the setup of the VPN.
If so, there is a proprietary client from Cisco that works very well, but it's not necessary. Your university should provide a link to download and directions to install that client.
If you prefer open source solutions, there is a program called openconnect. Directions for its use are here.
Try 1 of these options. If you don't care about open source, honestly the Cisco client will work most easily. If you do care, then try openconnect.
Best of luck!
To provide a meaningful answer, we'll need some more information. I'm assuming the VPN is a Cisco Openconnect VPN. Is that right? Without any more information, I'm guessing that your problem is in the setup of the VPN.
If so, there is a proprietary client from Cisco that works very well, but it's not necessary. Your university should provide a link to download and directions to install that client.
If you prefer open source solutions, there is a program called openconnect. Directions for its use are here.
Try 1 of these options. If you don't care about open source, honestly the Cisco client will work most easily. If you do care, then try openconnect.
Best of luck!
answered Feb 8 at 15:09
Noah
21
21
There is no reason to believe this is a VPN problem.
â Thomas Wardâ¦
Feb 8 at 15:11
I would say there is. I've used these VPNs with my university, and the routing is often touchy. Also, the fact that poster specifically mentions there was a routing problem requiring a change in NetworkManager implies something is fishy with the VPN.
â Noah
Feb 8 at 15:15
it's actually not a VPN problem, it's a NetworkManager / dnsmasq problem, and has had bugs about it since 2016 on the radar (see my answer which links to the bug). I'll bet if OP goes and usesping 8.8.8.8
or usesssh ip.add.re.ss
instead of trying to use a domain itself, it'll properly work. It's ultimately still not a VPN-specific issue, it's the Network Manager anddnsmasq
components being buggy and unfixed by upstream. And it's not just OpenConnect specific - it also affects OpenVPN andvpnc
traditional IPSec VPNs. Basically, all VPNs, not client or protocol specific.
â Thomas Wardâ¦
Feb 8 at 15:21
add a comment |Â
There is no reason to believe this is a VPN problem.
â Thomas Wardâ¦
Feb 8 at 15:11
I would say there is. I've used these VPNs with my university, and the routing is often touchy. Also, the fact that poster specifically mentions there was a routing problem requiring a change in NetworkManager implies something is fishy with the VPN.
â Noah
Feb 8 at 15:15
it's actually not a VPN problem, it's a NetworkManager / dnsmasq problem, and has had bugs about it since 2016 on the radar (see my answer which links to the bug). I'll bet if OP goes and usesping 8.8.8.8
or usesssh ip.add.re.ss
instead of trying to use a domain itself, it'll properly work. It's ultimately still not a VPN-specific issue, it's the Network Manager anddnsmasq
components being buggy and unfixed by upstream. And it's not just OpenConnect specific - it also affects OpenVPN andvpnc
traditional IPSec VPNs. Basically, all VPNs, not client or protocol specific.
â Thomas Wardâ¦
Feb 8 at 15:21
There is no reason to believe this is a VPN problem.
â Thomas Wardâ¦
Feb 8 at 15:11
There is no reason to believe this is a VPN problem.
â Thomas Wardâ¦
Feb 8 at 15:11
I would say there is. I've used these VPNs with my university, and the routing is often touchy. Also, the fact that poster specifically mentions there was a routing problem requiring a change in NetworkManager implies something is fishy with the VPN.
â Noah
Feb 8 at 15:15
I would say there is. I've used these VPNs with my university, and the routing is often touchy. Also, the fact that poster specifically mentions there was a routing problem requiring a change in NetworkManager implies something is fishy with the VPN.
â Noah
Feb 8 at 15:15
it's actually not a VPN problem, it's a NetworkManager / dnsmasq problem, and has had bugs about it since 2016 on the radar (see my answer which links to the bug). I'll bet if OP goes and uses
ping 8.8.8.8
or uses ssh ip.add.re.ss
instead of trying to use a domain itself, it'll properly work. It's ultimately still not a VPN-specific issue, it's the Network Manager and dnsmasq
components being buggy and unfixed by upstream. And it's not just OpenConnect specific - it also affects OpenVPN and vpnc
traditional IPSec VPNs. Basically, all VPNs, not client or protocol specific.â Thomas Wardâ¦
Feb 8 at 15:21
it's actually not a VPN problem, it's a NetworkManager / dnsmasq problem, and has had bugs about it since 2016 on the radar (see my answer which links to the bug). I'll bet if OP goes and uses
ping 8.8.8.8
or uses ssh ip.add.re.ss
instead of trying to use a domain itself, it'll properly work. It's ultimately still not a VPN-specific issue, it's the Network Manager and dnsmasq
components being buggy and unfixed by upstream. And it's not just OpenConnect specific - it also affects OpenVPN and vpnc
traditional IPSec VPNs. Basically, all VPNs, not client or protocol specific.â Thomas Wardâ¦
Feb 8 at 15:21
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1002453%2fssh-hangs-whilst-on-vpn%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Can you be more specific on the exact SSH error? Have you tried SSHing to the IP directly to see if that's the problem?
â Thomas Wardâ¦
Feb 8 at 15:23