Re: SSH Access Issue

[Philippe LeCavalier]

On Sun, Mar 26, 2017 at 6:04 PM Joshua Schaeffer 
wrote:

>
> On 03/26/2017 08:30 AM, Cindy-Sue Causey wrote:
>
>
> In the case I'm thinking, it's about manually adding multiple lines to
> a file that I'm not completely remembering just now. Gut is saying
> it's /etc/network/interfaces. Mine's almost empty so I don't have an
> example to confirm that.
>
> Typically user's put a second gateway option in the /etc/network/interface
> file (which you talk about in the next paragraph). This usually results in
> not understanding what the gateway does.
>
> What I encountered wasn't about declaring different values for
> gateway, either. For whatever reasons due to innate [functionality],
> it becomes a fail even if you declare the same gateway value for that
> line within each new, separate block of declarations. Success is found
> by declaring it once then omitting that line within any other new
> blocks added over time.
>
> While I've never put duplicate gateway information in
> /etc/network/interfaces I, at one point when learning about networking and
> setting it up in Debian, had put a gateway for each subnet in the
> interfaces file (which is incorrect and resulted in an error). A gateway,
> often called a "gateway of last resort" tells the system how to reach
> subnets that it is not attached to. That is the point of the gateway; it is
> the one place the system can send packets to when it doesn't know where to
> go. If you defined two gateways (meaning if this was allowed) you would be
> back to square one, the system wouldn't know which gateway to send the
> packet to. Defining two gateways could be an incorrect way of saying you
> are defining two routes (most likely static routes).
>
> Between my setup and cognition, I've never had anything stable enough
> to test if it matters which block that gateway is declared. I've
> wondered if it matters that it be in the first block, or if it just
> needs to show up somewhere in that file. I was consciously putting it
> in the first block because that seemed to be the *logical* thing to do
> k/t having touched on programming 20 years ago at a local tech school.
>
> I hadn't really thought about this myself. I've always defined the gateway
> under the interface that is attached to the subnet where the gateway
> resides. A.K.A. if I have two networks:
>
> auto eth0
> iface inet eth0 static
>   address 192.168.0.2/24
>
> auto eth1
> iface inet eth1 static
>   address 10.1.10.2/24
>
> And my gateway of last resort was on the 192.168.0 subnet then I would
> define the gateway under that interface
>
> auto eth0
> iface inet eth0 static
>   address 192.168.0.2/24
>   gateway 192.168.0.1
>
> It never occurred to me to see if it could be put anywhere in the file. My
> hunch is it can and I guess I could take the 60 seconds to test it, but
> I'll leave that to more adventurous people.
>
>
> Thanks,
> Joshua Schaeffer
>

I had simply done a route add so I reversed it with a route del.
-- 
Regards,
Phil

Re: SSH Access Issue

[Joshua Schaeffer]

On 03/26/2017 08:30 AM, Cindy-Sue Causey wrote:



In the case I'm thinking, it's about manually adding multiple lines to
a file that I'm not completely remembering just now. Gut is saying
it's /etc/network/interfaces. Mine's almost empty so I don't have an
example to confirm that.

Typically user's put a second gateway option in the /etc/network/interface file 
(which you talk about in the next paragraph). This usually results in not 
understanding what the gateway does.


What I encountered wasn't about declaring different values for
gateway, either. For whatever reasons due to innate [functionality],
it becomes a fail even if you declare the same gateway value for that
line within each new, separate block of declarations. Success is found
by declaring it once then omitting that line within any other new
blocks added over time.

While I've never put duplicate gateway information in /etc/network/interfaces I, at one 
point when learning about networking and setting it up in Debian, had put a gateway for 
each subnet in the interfaces file (which is incorrect and resulted in an error). A 
gateway, often called a "gateway of last resort" tells the system how to reach 
subnets that it is not attached to. That is the point of the gateway; it is the one place 
the system can send packets to when it doesn't know where to go. If you defined two 
gateways (meaning if this was allowed) you would be back to square one, the system 
wouldn't know which gateway to send the packet to. Defining two gateways could be an 
incorrect way of saying you are defining two routes (most likely static routes).


Between my setup and cognition, I've never had anything stable enough
to test if it matters which block that gateway is declared. I've
wondered if it matters that it be in the first block, or if it just
needs to show up somewhere in that file. I was consciously putting it
in the first block because that seemed to be the *logical* thing to do
k/t having touched on programming 20 years ago at a local tech school.

I hadn't really thought about this myself. I've always defined the gateway 
under the interface that is attached to the subnet where the gateway resides. 
A.K.A. if I have two networks:

auto eth0
iface inet eth0 static
  address 192.168.0.2/24

auto eth1
iface inet eth1 static
  address 10.1.10.2/24

And my gateway of last resort was on the 192.168.0 subnet then I would define 
the gateway under that interface

auto eth0
iface inet eth0 static
  address 192.168.0.2/24
  gateway 192.168.0.1

It never occurred to me to see if it could be put anywhere in the file. My 
hunch is it can and I guess I could take the 60 seconds to test it, but I'll 
leave that to more adventurous people.

Thanks,
Joshua Schaeffer

Re: SSH Access Issue

[David Christensen]

On 03/26/2017 05:21 AM, Philippe LeCavalier wrote:

Turns out the box had a second default gateway by mistake, mine of course.
I guess I forgot I manually added the default gateway when the box was in
my lab. As it turns out the clue was irrelevant but talking things out here
did somehow lead my the the right clue.


Years ago, I developed two habits that have proven very useful for 
troubleshooting:


1.  I keep a plain text system administration log file for every 
computer with personal notes, console sessions, contents of key files, 
e-mails, web pages, etc., etc..  I put this under version control.


2.  I put all manually-created and modified-default system configuration 
files under version control.



Lately, I have started keeping administration logs for individual drives 
and motherboards.



I have also tried putting the entire /etc tree under version control 
right after installation.  Because I use CVS, this gets messy when 
adding and removing packages.  Also, CVS has limited support for 
meta-data.  I supposed I could add automation and/or switch to a better 
version control system; but, then again, that is etckeeper:


http://joeyh.name/code/etckeeper/


David

Re: SSH Access Issue

[Cindy-Sue Causey]

On 3/26/17, Cindy-Sue Causey  wrote:
> On 3/26/17, Philippe LeCavalier  wrote:
>> On Sat, Mar 25, 2017, 17:52  wrote:
>>
>>> On Sat, Mar 25, 2017 at 06:56:03PM +, Philippe LeCavalier wrote:
>>>
>>> > Nevermind. I changed the forward to another box and can't get to it
>>> either
>>> > so it has to be something in the firewall capturing the connection
>>> despite
>>> > it showing a clean passthru.
>>>
>>> I see you found a clue to follow. One very helpful tool in those cases
>>> is the option -v (verbose) on the client:
>>>
>>>   ssh -v user@host.domain
>>>
>>> It shows you details of the handshake as it proceeds (try first on a
>>> working connection, to get an idea of what to expect). More "-v"
>>> increase the verbosity.
>>>
>>>
>> Turns out the box had a second default gateway by mistake, mine of
>> course.
>> I guess I forgot I manually added the default gateway when the box was in
>> my lab. As it turns out the clue was irrelevant but talking things out
>> here
>> did somehow lead my the the right clue.
>
>
> This sounds like it *might* be something that I've mentioned at least
> once, possibly twice, within seeming appropriate threads.
>
> In the case I'm thinking, it's about manually adding multiple lines to
> a file that I'm not completely remembering just now. Gut is saying
> it's /etc/network/interfaces. Mine's almost empty so I don't have an
> example to confirm that.
>
> What I encountered wasn't about declaring different values for
> gateway, either. For whatever reasons due to innate [functionality],
> it becomes a fail even if you declare the same gateway value for that
> line within each new, separate block of declarations. Success is found
> by declaring it once then omitting that line within any other new
> blocks added over time.
>
> Between my setup and cognition, I've never had anything stable enough
> to test if it matters which block that gateway is declared. I've
> wondered if it matters that it be in the first block, or if it just
> needs to show up somewhere in that file. I was consciously putting it
> in the first block because that seemed to be the *logical* thing to do
> k/t having touched on programming 20 years ago at a local tech school.


I literally HATE when this happens. Forgot something then remembered
as the first email was blipping off the screen. I also wanted to
wonder out loud if it's possible to teach programs that touch on that
to complain specifically about that duplication being the cause of
failure.

That error would save users a lot of hair pulling. I only ever
stumbled on that tidbit completely by accident because I had hit up a
BUNCH of different website help lists while trying to get my setup to
function here. My guess is that I would/will not likely recall that
being a potential check point during potential future moments of
failure, too. It only ever comes to mind now when someone writes the
right keywords that trigger the memory of that tip. :)

Cindy :)

-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

Re: SSH Access Issue

[Cindy-Sue Causey]

On 3/26/17, Philippe LeCavalier  wrote:
> On Sat, Mar 25, 2017, 17:52  wrote:
>
>> On Sat, Mar 25, 2017 at 06:56:03PM +, Philippe LeCavalier wrote:
>>
>> > Nevermind. I changed the forward to another box and can't get to it
>> either
>> > so it has to be something in the firewall capturing the connection
>> despite
>> > it showing a clean passthru.
>>
>> I see you found a clue to follow. One very helpful tool in those cases
>> is the option -v (verbose) on the client:
>>
>>   ssh -v user@host.domain
>>
>> It shows you details of the handshake as it proceeds (try first on a
>> working connection, to get an idea of what to expect). More "-v"
>> increase the verbosity.
>>
>>
> Turns out the box had a second default gateway by mistake, mine of course.
> I guess I forgot I manually added the default gateway when the box was in
> my lab. As it turns out the clue was irrelevant but talking things out here
> did somehow lead my the the right clue.


This sounds like it *might* be something that I've mentioned at least
once, possibly twice, within seeming appropriate threads.

In the case I'm thinking, it's about manually adding multiple lines to
a file that I'm not completely remembering just now. Gut is saying
it's /etc/network/interfaces. Mine's almost empty so I don't have an
example to confirm that.

What I encountered wasn't about declaring different values for
gateway, either. For whatever reasons due to innate [functionality],
it becomes a fail even if you declare the same gateway value for that
line within each new, separate block of declarations. Success is found
by declaring it once then omitting that line within any other new
blocks added over time.

Between my setup and cognition, I've never had anything stable enough
to test if it matters which block that gateway is declared. I've
wondered if it matters that it be in the first block, or if it just
needs to show up somewhere in that file. I was consciously putting it
in the first block because that seemed to be the *logical* thing to do
k/t having touched on programming 20 years ago at a local tech school.
:)

Just thinking out loud...

Cindy :)

-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

Re: SSH Access Issue

[Philippe LeCavalier]

On Sat, Mar 25, 2017, 17:52  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sat, Mar 25, 2017 at 06:56:03PM +, Philippe LeCavalier wrote:
>
> [...]
>
> > Nevermind. I changed the forward to another box and can't get to it
> either
> > so it has to be something in the firewall capturing the connection
> despite
> > it showing a clean passthru.
>
> I see you found a clue to follow. One very helpful tool in those cases
> is the option -v (verbose) on the client:
>
>   ssh -v user@host.domain
>
> It shows you details of the handshake as it proceeds (try first on a
> working connection, to get an idea of what to expect). More "-v"
> increase the verbosity.
>
> Regards
> - -- tomás
>
Turns out the box had a second default gateway by mistake, mine of course.
I guess I forgot I manually added the default gateway when the box was in
my lab. As it turns out the clue was irrelevant but talking things out here
did somehow lead my the the right clue.

> --
Regards,
Phil

Re: SSH Access Issue

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Mar 25, 2017 at 06:56:03PM +, Philippe LeCavalier wrote:

[...]

> Nevermind. I changed the forward to another box and can't get to it either
> so it has to be something in the firewall capturing the connection despite
> it showing a clean passthru.

I see you found a clue to follow. One very helpful tool in those cases
is the option -v (verbose) on the client:

  ssh -v user@host.domain

It shows you details of the handshake as it proceeds (try first on a
working connection, to get an idea of what to expect). More "-v"
increase the verbosity.

Regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAljW5pEACgkQBcgs9XrR2kYFKwCfTNESxVUczgMv1DXNGC/nZw8h
JD8An2OLvM+yEBACQibKclFscsiFb7wz
=JFEt
-END PGP SIGNATURE-

Re: SSH Access Issue

[Philippe LeCavalier]

On Sat, Mar 25, 2017 at 2:49 PM Philippe LeCavalier 
wrote:

> On Sat, Mar 25, 2017 at 2:08 PM Nate Bargmann  wrote:
>
> * On 2017 25 Mar 12:36 -0500, Philippe LeCavalier wrote:
>
> > One obvious aspect is firewalling. Rest assured I have opened TCP 22 and
> > ofrwarded to the correct host(the debian box). I can access all the other
> > forwarded services I've configured without issues but not SSH on the Deb
> > box. I can see the connection go through the firewall in the live feed
> but
> > the box doesn't answer.
>
> Is there a firewall running on the server that is blocking port 22?
>
> > sshd_config is stock and daemon is running yet I get nothing in the logs.
> > Not even attempts with DEBUG enabled.
>
> Usually if there is a firewall running on the box, entries will be found
> in syslog, but your logs are quiet.
>
> A default sshd_config has ListenAddress set to 0.0.0.0, if it were set
> to anything other than the network IP address, that would cause an issue
>
> It's 0.0.0.0
>
>
> Otherwise, I'd make sure the router is actually forwarding port 22 to
> the right box.
>
> As I mentioned, I can see the firewall forwarding the connection to the
> server.
>
>
> I've found some ISPs block port 22 to their customers.  In that case, a
> port above 1024 can be used and the router can then forward that
> connection to the server on port 22.
>
> I changed it to  and still get the same issue. As with 22, after I
> change the port to  I can successfully ssh to the box from within the
> LAN.
>
>
> - Nate
>
> --
>
> "The optimist proclaims that we live in the best of all
> possible worlds.  The pessimist fears this is true."
>
> Ham radio, Linux, bikes, and more: http://www.n0nb.us
>
> --
> Regards,
> Phil
>

Nevermind. I changed the forward to another box and can't get to it either
so it has to be something in the firewall capturing the connection despite
it showing a clean passthru.

Thank you for your help guys! Sorry for the false alarm.
-- 
Regards,
Phil

Re: SSH Access Issue

[Philippe LeCavalier]

On Sat, Mar 25, 2017 at 2:08 PM Nate Bargmann  wrote:

> * On 2017 25 Mar 12:36 -0500, Philippe LeCavalier wrote:
>
> > One obvious aspect is firewalling. Rest assured I have opened TCP 22 and
> > ofrwarded to the correct host(the debian box). I can access all the other
> > forwarded services I've configured without issues but not SSH on the Deb
> > box. I can see the connection go through the firewall in the live feed
> but
> > the box doesn't answer.
>
> Is there a firewall running on the server that is blocking port 22?
>
> > sshd_config is stock and daemon is running yet I get nothing in the logs.
> > Not even attempts with DEBUG enabled.
>
> Usually if there is a firewall running on the box, entries will be found
> in syslog, but your logs are quiet.
>
> A default sshd_config has ListenAddress set to 0.0.0.0, if it were set
> to anything other than the network IP address, that would cause an issue
>
It's 0.0.0.0

>
> Otherwise, I'd make sure the router is actually forwarding port 22 to
> the right box.
>
As I mentioned, I can see the firewall forwarding the connection to the
server.

>
> I've found some ISPs block port 22 to their customers.  In that case, a
> port above 1024 can be used and the router can then forward that
> connection to the server on port 22.
>
I changed it to  and still get the same issue. As with 22, after I
change the port to  I can successfully ssh to the box from within the
LAN.

>
> - Nate
>
> --
>
> "The optimist proclaims that we live in the best of all
> possible worlds.  The pessimist fears this is true."
>
> Ham radio, Linux, bikes, and more: http://www.n0nb.us
>
-- 
Regards,
Phil

Re: SSH Access Issue

[David Christensen]

On 03/25/2017 10:35 AM, Philippe LeCavalier wrote:

I've recently installed a new server for a client, using Deb 8.5 net
install.


2017-03-25 11:05:42 dpchrist@jesse ~
$ cat /etc/debian_version
8.7


Your Debian is stale.  Please 'apt-get update' and 'apt-get upgrade'.



Linux localhost(masked for privacy reasons) 3.16.0-4-amd64 #1 SMP Debian
3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux


2017-03-25 11:06:17 dpchrist@jesse ~
$ uname -a
Linux jesse 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) 
x86_64 GNU/Linux



Your kernel is stale.  Please 'apt-get update' and 'apt-get upgrade'.



The server is used as an SAMBA AD DC for a small network of users.
While in my lab, I could SSH to the box as expected but some some odd
reason, once deployed on site I can no longer SSH from the outside.


I assume you mean that you cannot connect to the server using SSH from 
the Internet via the client's LAN-Internet router.



Can you ping the server from the LAN?


Can you connect to the server using SSH from the LAN?


If you reconfigure the router to send incoming Internet SSH connections 
to another LAN host with known good sshd, can you connect to that host 
using SSH from the Internet?



David

Re: SSH Access Issue

[Nate Bargmann]

* On 2017 25 Mar 12:36 -0500, Philippe LeCavalier wrote:

> One obvious aspect is firewalling. Rest assured I have opened TCP 22 and
> ofrwarded to the correct host(the debian box). I can access all the other
> forwarded services I've configured without issues but not SSH on the Deb
> box. I can see the connection go through the firewall in the live feed but
> the box doesn't answer.

Is there a firewall running on the server that is blocking port 22?

> sshd_config is stock and daemon is running yet I get nothing in the logs.
> Not even attempts with DEBUG enabled.

Usually if there is a firewall running on the box, entries will be found
in syslog, but your logs are quiet.

A default sshd_config has ListenAddress set to 0.0.0.0, if it were set
to anything other than the network IP address, that would cause an issue

Otherwise, I'd make sure the router is actually forwarding port 22 to
the right box.

I've found some ISPs block port 22 to their customers.  In that case, a
port above 1024 can be used and the router can then forward that
connection to the server on port 22.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us


signature.asc
Description: Digital signature

SSH Access Issue

[Philippe LeCavalier]

Hi All,

Long time linux/debian/ssh user here. I've never seen this particular
problem I'm experiencing which has left me scratching my head for answers.
At this point I'm still trying to eliminate sources so please bare with
me...

I've recently installed a new server for a client, using Deb 8.5 net
install. The server is used as an SAMBA AD DC for a small network of users.
While in my lab, I could SSH to the box as expected but some some odd
reason, once deployed on site I can no longer SSH from the outside.

One obvious aspect is firewalling. Rest assured I have opened TCP 22 and
ofrwarded to the correct host(the debian box). I can access all the other
forwarded services I've configured without issues but not SSH on the Deb
box. I can see the connection go through the firewall in the live feed but
the box doesn't answer.

So my first question as a long time Deb user, has anything changed in the
most recent releases of Stable that would cause such a thing that I could
look at to eliminate?

If not, what else can possibly be preventing these connection to complete?

I realise this is a very "open ended" issue but any advice or suggestions
would be greatly appreciated.

Linux localhost(masked for privacy reasons) 3.16.0-4-amd64 #1 SMP Debian
3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux

sshd_config is stock and daemon is running yet I get nothing in the logs.
Not even attempts with DEBUG enabled.

-- 
Regards,
Phil