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"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.



--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 =

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.





--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.



--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)