Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #4945 > unrolled thread

Filtering incoming SSH connections

Back to article view | Back to comp.os.linux.networking

Contents

  Filtering incoming SSH connections Clark Smith <noaddress@nowhere.net> - 2021-09-07 23:01 +0000
    Re: Filtering incoming SSH connections Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-09-07 23:10 +0000
      Re: Filtering incoming SSH connections Grant Taylor <gtaylor@tnetconsulting.net> - 2021-09-07 19:28 -0600
        Re: Filtering incoming SSH connections Clark Smith <noaddress@nowhere.net> - 2021-09-08 14:41 +0000
          Re: Filtering incoming SSH connections Grant Taylor <gtaylor@tnetconsulting.net> - 2021-09-08 10:32 -0600
            Re: Filtering incoming SSH connections Clark Smith <noaddress@nowhere.net> - 2021-09-08 21:09 +0000
              Re: Filtering incoming SSH connections "Carlos E. R." <robin_listas@es.invalid> - 2021-09-08 23:50 +0200
              Re: Filtering incoming SSH connections Grant Taylor <gtaylor@tnetconsulting.net> - 2021-09-08 23:19 -0600
            Re: Filtering incoming SSH connections William Unruh <unruh@invalid.ca> - 2021-09-09 05:19 +0000
              Re: Filtering incoming SSH connections Grant Taylor <gtaylor@tnetconsulting.net> - 2021-09-09 12:09 -0600
                Re: Filtering incoming SSH connections William Unruh <unruh@invalid.ca> - 2021-09-11 01:16 +0000
                Re: Filtering incoming SSH connections William Unruh <unruh@invalid.ca> - 2021-09-11 01:21 +0000
                  Re: Filtering incoming SSH connections Aragorn <thorongil@telenet.be> - 2021-09-11 05:49 +0200
                    Re: Filtering incoming SSH connections William Unruh <unruh@invalid.ca> - 2021-09-11 19:26 +0000
                  Re: Filtering incoming SSH connections Grant Taylor <gtaylor@tnetconsulting.net> - 2021-09-10 23:55 -0600
                    Re: Filtering incoming SSH connections William Unruh <unruh@invalid.ca> - 2021-09-11 19:28 +0000
                      Re: Filtering incoming SSH connections Grant Taylor <gtaylor@tnetconsulting.net> - 2021-09-11 15:36 -0600
    Re: Filtering incoming SSH connections Grant Taylor <gtaylor@tnetconsulting.net> - 2021-09-07 19:22 -0600
    Re: Filtering incoming SSH connections Richard Kettlewell <invalid@invalid.invalid> - 2021-09-08 08:49 +0100
    Re: Filtering incoming SSH connections William Unruh <unruh@invalid.ca> - 2021-09-09 05:16 +0000

#4945 — Filtering incoming SSH connections

	I would like to be able to filter SSH connections on the basis of 
specific devices. That is, if the connection comes from a given device D 
then it is accepted, otherwise it is rejected.

	The thing is, what property of D can be used for this purpose? 
Not the IP address when D is a mobile device. Also not the MAC address, 
for this concept is not contemplated in cellular networks.

	What could one possibly use?

[toc] | [next] | [standalone]

#4946

On Tue, 07 Sep 2021 23:01:17 +0000, Clark Smith wrote:

> I would like to be able to filter SSH connections on the basis of 
> specific devices. That is, if the connection comes from a given device D 
> then it is accepted, otherwise it is rejected.
> 
> 	The thing is, what property of D can be used for this purpose? 
> Not the IP address when D is a mobile device. Also not the MAC address, 
> for this concept is not contemplated in cellular networks.
> 
> 	What could one possibly use?

Given that neither MAC nor IP address are acceptable filters for
you, the next step up from that is the encryption key used for the
SSH interaction. SSH can (and mostly does) use specific, shared keys
to govern the validity (authenticity and authority) of connections.

I suggest that you use the already in-place SSH key management as your filter
criteria.

-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#4948

On 9/7/21 5:10 PM, Lew Pitcher wrote:
> Given that neither MAC nor IP address are acceptable filters for you, 
> the next step up from that is the encryption key used for the SSH 
> interaction. SSH can (and mostly does) use specific, shared keys to 
> govern the validity (authenticity and authority) of connections.

That sounds like you're talking about the server's host key.  I say that 
because the client's key is used to authenticate the client to the 
server after the initial TCP connection is made and the SSH protocol 
negotiation has started.

I took the OP's comment to be in the spirit of wanting to avoid Internet 
Background Radiation noise of various things knocking on the SSH 
daemon's port, be it 22 or otherwise.

The /client/ key won't do much to avoid such IBR as it is used /after/ 
the TCP connection and SSH protocol starts.

> I suggest that you use the already in-place SSH key management as 
> your filter criteria.

I would also suggest looking at the already in-place SSH /certificates/ 
in addition to SSH /keys/.  If the server is configured to trust the 
SSH-Root-CA that signed the /certificate/ that the client is using, then 
the server can have extremely high confidence in the client.

Correspondingly, if the client is configured to trust the SSH-Root-CA 
that signed the /certificate/ that the server is using, then the client 
will not prompt with the typical Trust-On-First-Use stuff.

The SSH /certificates/ could make it such that any and all client's that 
don't have a certificate signed by the configured / trusted SSH-Root-CA 
are quite similar to water off of a duck's back.  --  Though they will 
still show up as TCP connections and SSH connection attempt failures in 
logs.  (I really suspect that's what the OP is wanting to reduce.)



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#4950

On Tue, 07 Sep 2021 19:28:34 -0600, Grant Taylor wrote:

> I took the OP's comment to be in the spirit of wanting to avoid Internet
> Background Radiation noise of various things knocking on the SSH
> daemon's port, be it 22 or otherwise.

	The goal is to make sure that a given physical device can ssh 
into the server no matter what network that device is trying to do so, 
bearing in mind that there may be iptables rules in place that put 
limitations on incoming ssh connections. 

	The obvious approach would be to use some non-standard port for 
ssh connections in the server, known to the server and the target client 
alone, but I wonder whether some feature intrinsic to the client could be 
used instead so that the standard port can be used.

[toc] | [prev] | [next] | [standalone]

#4951

On 9/8/21 8:41 AM, Clark Smith wrote:
> The goal is to make sure that a given physical device can ssh into 
> the server no matter what network that device is trying to do so, 
> bearing in mind that there may be iptables rules in place that put 
> limitations on incoming ssh connections.

Remember that you have no control over restrictions imposed by other 
networks.  You can only influence the things on the network(s) / 
system(s) that you control.  Meaning that there's between exceedingly 
little and nothing that you can do if some intermediate network filters 
the traffic.

> The obvious approach would be to use some non-standard port for ssh 
> connections in the server, known to the server and the target client 
> alone,

Using a different port will not prevent other clients from finding the 
SSH daemon and trying to log in.  There are 65,535 ports.  That's not a 
big number to search.  There are easy ~> automatable ways to search it.

Using a different, non-default, port will reduce the noise in logs.  But 
it won't stop the noise in logs.

> but I wonder whether some feature intrinsic to the client could be 
> used instead so that the standard port can be used.

You can't use the IP address of a road warrior machine, and MAC 
addresses are implicitly only available on the LAN.

Please clarify if you are trying to reduce log noise from IBR or if you 
are just trying to make sure that the client machine in question can 
authenticate and log in (presuming no intermediate filtering).



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#4952

On Wed, 08 Sep 2021 10:32:44 -0600, Grant Taylor wrote:

> You can't use the IP address of a road warrior machine, and MAC
> addresses are implicitly only available on the LAN.
> 
> Please clarify if you are trying to reduce log noise from IBR or if you
> are just trying to make sure that the client machine in question can
> authenticate and log in (presuming no intermediate filtering).

	A mix of both, I guess. In the extreme I case, I would like to 
guarantee that my roaming device can always ssh into my server, no matter 
where the former is attempting to do so from. In a more realistic 
setting, I am OK letting other people try, as long as they are not trying 
to brute-force their way into my system, in which case I would block them 
completely. This latter aspect is already covered - the sticking issue is 
to make sure that my roaming device can always make it.

	I am not inclined to use a non-standard port, pretty much for the 
reasons you mentioned. I am also not so keen on a VPN, for it is a bit 
painful to set up and manage. Plus, it is slower.

[toc] | [prev] | [next] | [standalone]

#4953

On 08/09/2021 23.09, Clark Smith wrote:
> On Wed, 08 Sep 2021 10:32:44 -0600, Grant Taylor wrote:
> 
>> You can't use the IP address of a road warrior machine, and MAC
>> addresses are implicitly only available on the LAN.
>>
>> Please clarify if you are trying to reduce log noise from IBR or if you
>> are just trying to make sure that the client machine in question can
>> authenticate and log in (presuming no intermediate filtering).
> 
> 	A mix of both, I guess. In the extreme I case, I would like to 
> guarantee that my roaming device can always ssh into my server, no matter 
> where the former is attempting to do so from. In a more realistic 
> setting, I am OK letting other people try, as long as they are not trying 
> to brute-force their way into my system, in which case I would block them 
> completely. This latter aspect is already covered - the sticking issue is 
> to make sure that my roaming device can always make it.

Then, as others have said, just use public key authentication.
You can _also_ change the port to reduce noise.
Possibly add certificates.

> 	I am not inclined to use a non-standard port, pretty much for the 
> reasons you mentioned. I am also not so keen on a VPN, for it is a bit 
> painful to set up and manage. Plus, it is slower.
> 


-- 
Cheers,
       Carlos E.R.

[toc] | [prev] | [next] | [standalone]

#4955

On 9/8/21 3:09 PM, Clark Smith wrote:
> A mix of both, I guess. In the extreme I case, I would like to 
> guarantee that my roaming device can always ssh into my server, 
> no matter where the former is attempting to do so from. In a more 
> realistic setting, I am OK letting other people try, as long as they 
> are not trying to brute-force their way into my system, in which case 
> I would block them completely. This latter aspect is already covered - 
> the sticking issue is to make sure that my roaming device can always 
> make it.

That's not a realistic expectation.

So what happens when you are trying to log in from a coffee shop where 
the person beside you is trying to brute force your server, and both of 
you are coming from the same NATed IP address?  Do you lock yourself out 
as part of the brute force protection?  Or do you allow them to continue 
to brute force their way so that you can always ssh into your server?

What do you do do when you are somewhere else that blocks ssh traffic?

> I am not inclined to use a non-standard port, pretty much for the 
> reasons you mentioned. I am also not so keen on a VPN, for it is a 
> bit painful to set up and manage. Plus, it is slower.

It seems to me that you are opting for / preferring convenience over 
security.



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#4956

On 2021-09-08, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> On 9/8/21 8:41 AM, Clark Smith wrote:
>> The goal is to make sure that a given physical device can ssh into 
>> the server no matter what network that device is trying to do so, 
>> bearing in mind that there may be iptables rules in place that put 
>> limitations on incoming ssh connections.
>
> Remember that you have no control over restrictions imposed by other 
> networks.  You can only influence the things on the network(s) / 
> system(s) that you control.  Meaning that there's between exceedingly 
> little and nothing that you can do if some intermediate network filters 
> the traffic.
>
>> The obvious approach would be to use some non-standard port for ssh 
>> connections in the server, known to the server and the target client 
>> alone,
>
> Using a different port will not prevent other clients from finding the 
> SSH daemon and trying to log in.  There are 65,535 ports.  That's not a 
> big number to search.  There are easy ~> automatable ways to search it.
>
> Using a different, non-default, port will reduce the noise in logs.  But 
> it won't stop the noise in logs.

Sue it will. If the "noise" goes from 100 a day to 1 per year, I would
say that is stopping the noise in the logs.  
>
>> but I wonder whether some feature intrinsic to the client could be 
>> used instead so that the standard port can be used.
>
> You can't use the IP address of a road warrior machine, and MAC 
> addresses are implicitly only available on the LAN.
>
> Please clarify if you are trying to reduce log noise from IBR or if you 
> are just trying to make sure that the client machine in question can 
> authenticate and log in (presuming no intermediate filtering).
>
>
>

[toc] | [prev] | [next] | [standalone]

#4957

On 9/8/21 11:19 PM, William Unruh wrote:
> Sue it will. If the "noise" goes from 100 a day to 1 per year, I would
> say that is stopping the noise in the logs.

A 100 to 1 /reduction/ is not the same as /stopping/ the noise.  100 to 
0 is stopping the noise.

There will still be /some/ noise, just at a much lower rate.

This is the difference between "could care less" (you do care some) and 
"couldn't care less" (you don't care any).



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#4958

On 2021-09-09, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> On 9/8/21 11:19 PM, William Unruh wrote:
>> Sue it will. If the "noise" goes from 100 a day to 1 per year, I would
>> say that is stopping the noise in the logs.
>
> A 100 to 1 /reduction/ is not the same as /stopping/ the noise.  100 to 
> 0 is stopping the noise.
>
> There will still be /some/ noise, just at a much lower rate.
>
> This is the difference between "could care less" (you do care some) and 
> "couldn't care less" (you don't care any).
>
>
>

[toc] | [prev] | [next] | [standalone]

#4959

On 2021-09-09, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> On 9/8/21 11:19 PM, William Unruh wrote:
>> Sue it will. If the "noise" goes from 100 a day to 1 per year, I would
>> say that is stopping the noise in the logs.
>
> A 100 to 1 /reduction/ is not the same as /stopping/ the noise.  100 to 
> 0 is stopping the noise.

It is a 36500 to 1 reduction. And there is ALWAYS noise of some sort. At
once year you will not even notice the noise. Once the noise falls below
some threshold, it is eliminated. 
>
> There will still be /some/ noise, just at a much lower rate.
>
> This is the difference between "could care less" (you do care some) and 
> "couldn't care less" (you don't care any).
>
Another person who rails against Englich idioms. 
>
>

[toc] | [prev] | [next] | [standalone]

#4960

On 11.09.2021 at 01:21, William Unruh scribbled:

> On 2021-09-09, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>
> > This is the difference between "could care less" (you do care some)
> > and "couldn't care less" (you don't care any).
>  
> Another person who rails against Englich idioms. 

There's a difference between an idiom and the misuse of language.  The
latter leads to many more problems in communication than the former,
and especially in a world where not everyone speaks English.  

One would therefore assume -- sadly, wrongfully so -- that those who
speak English natively would at the very least do so correctly. ;)

Or let me put it this way...: you wouldn't be so forgiving of
sloppiness in the mathematical equations of your students either. ;)


-- 
With respect,
= Aragorn =

[toc] | [prev] | [next] | [standalone]

#4962

On 2021-09-11, Aragorn <thorongil@telenet.be> wrote:
> On 11.09.2021 at 01:21, William Unruh scribbled:
>
>> On 2021-09-09, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>>
>> > This is the difference between "could care less" (you do care some)
>> > and "couldn't care less" (you don't care any).
>>  
>> Another person who rails against Englich idioms. 
>
> There's a difference between an idiom and the misuse of language.  The

Yes, and many things which started of as misuse became idioms. You may
rail even against "misuse" but if it gets popular enough, it is no
longer misuse, it becomes part of the language. Thus the "could/couldn't
care less"-- both have become part of the language meaning the same
thing. 

> latter leads to many more problems in communication than the former,
> and especially in a world where not everyone speaks English.  

Yes. And?

>
> One would therefore assume -- sadly, wrongfully so -- that those who
> speak English natively would at the very least do so correctly. ;)

Yes, of course just like all French speak French correctly, all Dutch
speak Dutch correctly, etc. And what is "correctly"?
>
> Or let me put it this way...: you wouldn't be so forgiving of
> sloppiness in the mathematical equations of your students either. ;)

Perhaps, perhaps not. It would depend on the sloppiness. But then
language is not mathematics. My lover's lips are drops of honey to my
tongue. Perfectly acceptable as part of language, not so as expressing a
mathematical identity. 
>
>

[toc] | [prev] | [next] | [standalone]

#4961

On 9/10/21 7:21 PM, William Unruh wrote:
> And there is ALWAYS noise of some sort.

There's not noise once you put the server behind port knocking / single 
packet authorization / VPN.  If the Internet at large can't get to the 
server, they can't cause noise in the logs.



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#4963

On 2021-09-11, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> On 9/10/21 7:21 PM, William Unruh wrote:
>> And there is ALWAYS noise of some sort.
>
> There's not noise once you put the server behind port knocking / single 
> packet authorization / VPN.  If the Internet at large can't get to the 
> server, they can't cause noise in the logs.

Sure it can. That port knocking/single packet authorization/VPN produce
lots of entries in the logs as well, entries whichwould not be there,
which are noise, if youdid not use them. 

>
>
>

[toc] | [prev] | [next] | [standalone]

#4964

On 9/11/21 1:28 PM, William Unruh wrote:
> Sure it can. That port knocking/single packet authorization/VPN 
> produce lots of entries in the logs as well,

The port knocking that I've done didn't produce any logs in and of 
themselves.

But the port knocking logs are different and independent of the ssh 
logs.  Frequently they go to different files.

> entries whichwould not be there, which are noise, if youdid not 
> use them.

My opinion is that the port knocking that you're talking about is 
inferior to the port knocking that I've done because of the new type of 
logging that you're talking about.



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#4947

On 9/7/21 5:01 PM, Clark Smith wrote:
> I would like to be able to filter SSH connections on the basis of 
> specific devices. That is, if the connection comes from a given device 
> D then it is accepted, otherwise it is rejected.

Are you wanting to only allow login from the specific device?  --  What 
does this mean about connections that aren't allowed to login from other 
devices?

Or are you wanting to prevent connections -- independent of if they can 
successfully log in -- from other devices period?  As in stop them at a 
TCP level before the SSH connection even starts?

> The thing is, what property of D can be used for this purpose? 
> Not the IP address when D is a mobile device. Also not the MAC address, 
> for this concept is not contemplated in cellular networks.
> 
> What could one possibly use?

Assuming that you're wanting to prevent the (TCP) connections before SSH 
even starts, I'd look at one or more of the following:

1)  Port Knocking
      - Multi-port
      - Single-port via Single Packet Authentication (a.k.a. SPA)
2)  VPN
      - I'd be inclined to use minimal (read: manual) IPsec for this.
      - WireGuard
      - OpenVPN
3)  HTTP(S) (reverse) proxy the SSH connection
      - Leverage HTTP's "CONNECT" verb
      - Leverage /client/ TLS certificates to authenticate the connection
      - This works well if you've already got a web server exposed.
4)  SOCKS proxy the SSH connection
      - Leverage the SOCKS protocol's authentication
      - This is probably less likely to exist than #3.
5)  Use sslh to hide the SSH daemon behind another port that something 
else is listening on.  }:-)

There are some options.  It really depends what you're trying to do.



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#4949

Clark Smith <noaddress@nowhere.net> writes:
> I would like to be able to filter SSH connections on the basis of
> specific devices. That is, if the connection comes from a given device
> D then it is accepted, otherwise it is rejected.
>
> The thing is, what property of D can be used for this purpose?  Not
> the IP address when D is a mobile device. Also not the MAC address,
> for this concept is not contemplated in cellular networks.
>
> What could one possibly use?

That’s what public key authentication is for. Add D’s key to the
authorized_keys file, don’t add any other keys.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#4954

On 2021-09-07, Clark Smith <noaddress@nowhere.net> wrote:
> 	I would like to be able to filter SSH connections on the basis of 
> specific devices. That is, if the connection comes from a given device D 
> then it is accepted, otherwise it is rejected.
>
> 	The thing is, what property of D can be used for this purpose? 
> Not the IP address when D is a mobile device. Also not the MAC address, 
> for this concept is not contemplated in cellular networks.

I am afraid the IP address is the only information that is available to
your machine to use to decide what to do with. The MAC is available only
if the machine is on the same local network as your machine. 

However, there are a couple of other things you can do. One is to put
ssh onto a different port than the normal one. -- eg port 17224 just to
pick a random number out of the air. The chances of a random attacker
knowing that is verysmall. You can also make it even more difficult
byport knocking. Ie, you set up D so that when it wants to connect, it
sfirst tries on port 1554 and then on port 12443. Neither of those have
sshd listening for a connection but a little script is listening, and
when it gets connection attempts on those two ports it raises a flag for
say 20 sec, and only if the third attempt comes on port 37554 AND the
flag is raised is the connection to ssh allowed. You can cleary make
that as complicated as you want. 

>
> 	What could one possibly use?

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web