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

Groups > comp.os.linux.misc > #36405 > unrolled thread

Guaranteeing SSH access to specific clients

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

Contents

  Guaranteeing SSH access to specific clients Harold Johanssen <noemail@please.net> - 2022-12-08 19:47 +0000
    Re: Guaranteeing SSH access to specific clients "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2022-12-08 16:31 -0500
      Re: Guaranteeing SSH access to specific clients Harold Johanssen <noemail@please.net> - 2022-12-09 01:20 +0000
        Re: Guaranteeing SSH access to specific clients "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2022-12-08 21:43 -0500
        Re: Guaranteeing SSH access to specific clients Robert Heller <heller@deepsoft.com> - 2022-12-09 03:34 +0000
        Re: Guaranteeing SSH access to specific clients stepore <stepore@be.here.now> - 2022-12-08 19:34 -0800
        Re: Guaranteeing SSH access to specific clients "Carlos E.R." <robin_listas@es.invalid> - 2022-12-09 04:42 +0100
          Re: Guaranteeing SSH access to specific clients "26C.Z969" <26C.Z969@noaada.net> - 2022-12-09 01:53 -0500
        Re: Guaranteeing SSH access to specific clients Henning Hucke <h_hucke+spam.news@newsmail.aeon.icebear.org> - 2022-12-09 06:43 +0000
        Re: Guaranteeing SSH access to specific clients The Natural Philosopher <tnp@invalid.invalid> - 2022-12-09 13:29 +0000
        Re: Guaranteeing SSH access to specific clients Allodoxaphobia <trepidation@example.net> - 2022-12-09 13:55 +0000
          Re: Guaranteeing SSH access to specific clients Pancho <Pancho.Jones@proton.me> - 2022-12-09 14:08 +0000
      Re: Guaranteeing SSH access to specific clients Robert Heller <heller@deepsoft.com> - 2022-12-09 03:34 +0000
        Re: Guaranteeing SSH access to specific clients Andreas Kohlbach <ank@spamfence.net> - 2022-12-09 12:44 -0500
          Re: Guaranteeing SSH access to specific clients The Natural Philosopher <tnp@invalid.invalid> - 2022-12-09 17:52 +0000
    Re: Guaranteeing SSH access to specific clients Andreas Kohlbach <ank@spamfence.net> - 2022-12-08 22:31 -0500
    Re: Guaranteeing SSH access to specific clients Richard Kettlewell <invalid@invalid.invalid> - 2022-12-09 12:36 +0000
    Re: Guaranteeing SSH access to specific clients The Natural Philosopher <tnp@invalid.invalid> - 2022-12-09 13:27 +0000
    Re: Guaranteeing SSH access to specific clients Harold Johanssen <noemail@please.net> - 2022-12-09 14:48 +0000
      Re: Guaranteeing SSH access to specific clients Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2022-12-09 17:42 +0200
        Re: Guaranteeing SSH access to specific clients The Natural Philosopher <tnp@invalid.invalid> - 2022-12-09 17:36 +0000
          Re: Guaranteeing SSH access to specific clients Robert Heller <heller@deepsoft.com> - 2022-12-09 19:35 +0000
            Re: Guaranteeing SSH access to specific clients The Natural Philosopher <tnp@invalid.invalid> - 2022-12-10 09:53 +0000
              Re: Guaranteeing SSH access to specific clients Robert Heller <heller@deepsoft.com> - 2022-12-10 13:58 +0000
              Re: Guaranteeing SSH access to specific clients Pancho <Pancho.Jones@proton.me> - 2022-12-10 14:08 +0000
                Re: Guaranteeing SSH access to specific clients Pancho <Pancho.Jones@proton.me> - 2022-12-10 14:15 +0000
              Re: Guaranteeing SSH access to specific clients Andreas Kohlbach <ank@spamfence.net> - 2022-12-10 19:25 -0500
                Re: Guaranteeing SSH access to specific clients Robert Heller <heller@deepsoft.com> - 2022-12-11 00:53 +0000
                  Re: Guaranteeing SSH access to specific clients "Carlos E.R." <robin_listas@es.invalid> - 2022-12-11 10:37 +0100
                    Re: Guaranteeing SSH access to specific clients Robert Heller <heller@deepsoft.com> - 2022-12-11 12:50 +0000
                      Re: Guaranteeing SSH access to specific clients "Carlos E.R." <robin_listas@es.invalid> - 2022-12-11 20:55 +0100
                        Re: Guaranteeing SSH access to specific clients Pancho <Pancho.Jones@proton.me> - 2022-12-12 09:35 +0000
                        Re: Guaranteeing SSH access to specific clients Richard Kettlewell <invalid@invalid.invalid> - 2022-12-13 08:36 +0000
                          Re: Guaranteeing SSH access to specific clients "Carlos E. R." <robin_listas@es.invalid> - 2022-12-15 18:09 +0100
        Re: Guaranteeing SSH access to specific clients Harold Johanssen <noemail@please.net> - 2022-12-09 22:03 +0000
          Re: Guaranteeing SSH access to specific clients The Natural Philosopher <tnp@invalid.invalid> - 2022-12-10 09:56 +0000
            Re: Guaranteeing SSH access to specific clients Ted Heise <theise@panix.com> - 2022-12-16 18:40 +0000

Page 1 of 2  [1] 2  Next page →

#36405 — Guaranteeing SSH access to specific clients

	I don't know whether this is reasonable possible, but I thought 
I'd ask anyway, just in case:

	Is it possible to guarantee SSH to a specific client, to the 
exclusion of all other clients? In effect, all other connection would be 
immediately rejected, even before the SSH protocol exchange gets going. 
The following requirements must be met:

	- The SSH server must be listening on port 22.
	- The target client may connect from different, arbitrary IP 
addresses.

	This would be easily possible with tweaked SSH servers and 
clients, but I am not sure it can be done with off-the-shelf ones.

[toc] | [next] | [standalone]

#36406

On Thu, 08 Dec 2022 14:47:14 -0500, Harold Johanssen <noemail@please.net> wrote:

> 	I don't know whether this is reasonable possible, but I thought
> I'd ask anyway, just in case:
>
> 	Is it possible to guarantee SSH to a specific client, to the
> exclusion of all other clients? In effect, all other connection would be
> immediately rejected, even before the SSH protocol exchange gets going.
> The following requirements must be met:
>
> 	- The SSH server must be listening on port 22.
> 	- The target client may connect from different, arbitrary IP
> addresses.
>
> 	This would be easily possible with tweaked SSH servers and
> clients, but I am not sure it can be done with off-the-shelf ones.

Excluding all other clients would go against the fact that linux is a multi-user
system, so it's not a standard feature.

killing the sshd server does not kill the working ssh connection(s), so you could
have a script run on login via ssh that kills the sshd server, but you'd have
to also figure out how to restart it after that connection ends (intentionally
or not).

Why do you want to do this? There's probably a better way to lock things when
needed.

Regards, Dave Hodgins

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

#36407

On Thu, 08 Dec 2022 16:31:45 -0500, David W. Hodgins wrote:

> On Thu, 08 Dec 2022 14:47:14 -0500, Harold Johanssen
> <noemail@please.net> wrote:
> 
>> 	I don't know whether this is reasonable possible, but I thought
>> I'd ask anyway, just in case:
>>
>> 	Is it possible to guarantee SSH to a specific client, to the
>> exclusion of all other clients? In effect, all other connection would
>> be immediately rejected, even before the SSH protocol exchange gets
>> going. The following requirements must be met:
>>
>> 	- The SSH server must be listening on port 22.
>> 	- The target client may connect from different, arbitrary IP
>> addresses.
>>
>> 	This would be easily possible with tweaked SSH servers and
>> clients, but I am not sure it can be done with off-the-shelf ones.
> 
> Excluding all other clients would go against the fact that linux is a
> multi-user system, so it's not a standard feature.
> 
> killing the sshd server does not kill the working ssh connection(s), so
> you could have a script run on login via ssh that kills the sshd server,
> but you'd have to also figure out how to restart it after that
> connection ends (intentionally or not).
> 
> Why do you want to do this? There's probably a better way to lock things
> when needed.
> 
> Regards, Dave Hodgins

	You misunderstood what I wrote. What I meant is the following:

	I want to ssh into a specific system that I control, from 
wherever I am in the Internet. Any ssh connections from anybody else into 
that system, wherever they are coming from in the Internet, are 
automatically rejected - it is not that they are rejected when the wrong 
username and password are supplied; rather, their connection requests are 
rejected before the ssh protocol gets started. Can this be done, with the 
constraints that I specified?

	This would be networking-related question: in a nutshell, if the 
TCP connection on port 22 is coming from me then it is forwarded to the 
ssh daemon; otherwise, it is dropped immediately. The problem is, how 
would the TCP code in my server know that the connection is coming me 
from me, as opposed to anybody else?

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

#36408

On Thu, 08 Dec 2022 20:20:58 -0500, Harold Johanssen <noemail@please.net> wrote:
> 	I want to ssh into a specific system that I control, from
> wherever I am in the Internet. Any ssh connections from anybody else into
> that system, wherever they are coming from in the Internet, are
> automatically rejected - it is not that they are rejected when the wrong
> username and password are supplied; rather, their connection requests are
> rejected before the ssh protocol gets started. Can this be done, with the
> constraints that I specified?
>
> 	This would be networking-related question: in a nutshell, if the
> TCP connection on port 22 is coming from me then it is forwarded to the
> ssh daemon; otherwise, it is dropped immediately. The problem is, how
> would the TCP code in my server know that the connection is coming me
> from me, as opposed to anybody else?

See https://linuxhandbook.com/ssh-disable-password-authentication/
(keep the ssh key on a usb stick for your use), and also add
https://www.howtogeek.com/442733/how-to-use-port-knocking-on-linux-and-why-you-shouldnt/

Never rely on just port knocking.

The only other way I can see it being done is if you know in advance what ip
addresses you'll be connecting from, then add rules to allow it when needed.

Regards, Dave Hodgins

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

#36412

At Fri, 9 Dec 2022 01:20:58 -0000 (UTC) Harold Johanssen <noemail@please.net> wrote:

> 
> On Thu, 08 Dec 2022 16:31:45 -0500, David W. Hodgins wrote:
> 
> > On Thu, 08 Dec 2022 14:47:14 -0500, Harold Johanssen
> > <noemail@please.net> wrote:
> > 
> >> 	I don't know whether this is reasonable possible, but I thought
> >> I'd ask anyway, just in case:
> >>
> >> 	Is it possible to guarantee SSH to a specific client, to the
> >> exclusion of all other clients? In effect, all other connection would
> >> be immediately rejected, even before the SSH protocol exchange gets
> >> going. The following requirements must be met:
> >>
> >> 	- The SSH server must be listening on port 22.
> >> 	- The target client may connect from different, arbitrary IP
> >> addresses.
> >>
> >> 	This would be easily possible with tweaked SSH servers and
> >> clients, but I am not sure it can be done with off-the-shelf ones.
> > 
> > Excluding all other clients would go against the fact that linux is a
> > multi-user system, so it's not a standard feature.
> > 
> > killing the sshd server does not kill the working ssh connection(s), so
> > you could have a script run on login via ssh that kills the sshd server,
> > but you'd have to also figure out how to restart it after that
> > connection ends (intentionally or not).
> > 
> > Why do you want to do this? There's probably a better way to lock things
> > when needed.
> > 
> > Regards, Dave Hodgins
> 
> 	You misunderstood what I wrote. What I meant is the following:
> 
> 	I want to ssh into a specific system that I control, from 
> wherever I am in the Internet. Any ssh connections from anybody else into 
> that system, wherever they are coming from in the Internet, are 
> automatically rejected - it is not that they are rejected when the wrong 
> username and password are supplied; rather, their connection requests are 
> rejected before the ssh protocol gets started. Can this be done, with the 
> constraints that I specified?
> 
> 	This would be networking-related question: in a nutshell, if the 
> TCP connection on port 22 is coming from me then it is forwarded to the 
> ssh daemon; otherwise, it is dropped immediately. The problem is, how 
> would the TCP code in my server know that the connection is coming me 
> from me, as opposed to anybody else?

Only the SSH server can know it is from you. You could disable password
authenific ation and force RSA public/private key authentification -- this
will kill brute-force password attacks (or actually make them ineffective and
avoid wasting time hashing "guessed" passwords). That is the best you can do.
The only check possible IS the SSH authentification process. Since you might
be connecting from "anywhere", IP-level firewalling won't work. At the initial
connection level there is no "knowledge" as to who is connecting. The sshd
process uses its authentification exchange process to determing "who" is
connecting and if they are really who they say they are (eg username [who] and
password/keys/etc. authentificate the connection).

> 
>                
> 

-- 
Robert Heller             -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                                          

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

#36413

On 12/8/22 17:20, Harold Johanssen wrote:

> 	This would be networking-related question: in a nutshell, if the
> TCP connection on port 22 is coming from me then it is forwarded to the
> ssh daemon; otherwise, it is dropped immediately. The problem is, how
> would the TCP code in my server know that the connection is coming me
> from me, as opposed to anybody else?


This has nothing at all to do with ssh.

It's possible with iptables but you'd had to know your IP in advance.

Can also be done with TCPwrappers.
/etc/hosts.allow
/etc/hosts.deny

<https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/sect-security_guide-tcp_wrappers_and_xinetd-tcp_wrappers_configuration_files>

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

#36414

On 2022-12-09 02:20, Harold Johanssen wrote:
> On Thu, 08 Dec 2022 16:31:45 -0500, David W. Hodgins wrote:
> 
>> On Thu, 08 Dec 2022 14:47:14 -0500, Harold Johanssen
>> <noemail@please.net> wrote:

...

> 	You misunderstood what I wrote. What I meant is the following:
> 
> 	I want to ssh into a specific system that I control, from
> wherever I am in the Internet. Any ssh connections from anybody else into
> that system, wherever they are coming from in the Internet, are
> automatically rejected - it is not that they are rejected when the wrong
> username and password are supplied; rather, their connection requests are
> rejected before the ssh protocol gets started. Can this be done, with the
> constraints that I specified?

No, unless you know how the server is going to know that it is you 
calling before hearing your name...

You first answer this, and then we find how the program does that.


Like for example, you know in advance what IP the client is going to have.

Or the client triggers some events before hand. Say, knocking on some 
port sequence.


In the end, people do two things:

  - make the server listen to a high port instead
  - make the server not respond to login/password, but to a public key 
challenge.


You may add other things.




-- 
Cheers, Carlos.

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

#36419

On 12/8/22 10:42 PM, Carlos E.R. wrote:
> On 2022-12-09 02:20, Harold Johanssen wrote:
>> On Thu, 08 Dec 2022 16:31:45 -0500, David W. Hodgins wrote:
>>
>>> On Thu, 08 Dec 2022 14:47:14 -0500, Harold Johanssen
>>> <noemail@please.net> wrote:
> 
> ...
> 
>>     You misunderstood what I wrote. What I meant is the following:
>>
>>     I want to ssh into a specific system that I control, from
>> wherever I am in the Internet. Any ssh connections from anybody else into
>> that system, wherever they are coming from in the Internet, are
>> automatically rejected - it is not that they are rejected when the wrong
>> username and password are supplied; rather, their connection requests are
>> rejected before the ssh protocol gets started. Can this be done, with the
>> constraints that I specified?
> 
> No, unless you know how the server is going to know that it is you 
> calling before hearing your name...

   Agreed. SSH - or any other connection system - starts
   assuming that all users are equal.

   Now there IS the olde-tyme trick called "port knocking"
   and there's software to implement that. Those who do not
   "knock" correctly don't get in. It's a bit cludgy, but
   it IS very secure.

   Frankly, decent passwords combined with low tolerance
   for brute-force methods like trying 999 times a second
   from the same IP address are often Good Enough.

   Alas for a big commercial/govt system ... you just can't
   DO that. THEY have to bias towards high-volume traffic and
   idiot users and thus lose a lot of options when it comes
   to rejecting Bad Actors.

   Ain't nothin' "perfect" ....

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

#36420

Harold Johanssen <noemail@please.net> wrote:

Hello Harold,

> [...]
>         This would be networking-related question: in a nutshell, if the 
> TCP connection on port 22 is coming from me then it is forwarded to the 
> ssh daemon; otherwise, it is dropped immediately. The problem is, how 
> would the TCP code in my server know that the connection is coming me 
> from me, as opposed to anybody else?

strange thinking: Don't communicate ("before the SSH protocol is
started") but recognise me from whichever IP address I might come...

For the case that you still didn't get over to us what you really want
to accomplish you might look into the "tcp wrapper" which is still
linked into the ssh daemon.
But from what I understand about your concern I would recommend a port
knocking mechanism. Hint: Don't use "knockd" for diverse reasons as long
as the system(s) in question already has netfilter tables since this
firewall code is able to implement port knocking totally and very
flexible as a ruleset system.

Best regards,
    Henning
-- 
Honesty is for the most part less profitable than dishonesty.
                -- Plato

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

#36425

On 09/12/2022 01:20, Harold Johanssen wrote:
> On Thu, 08 Dec 2022 16:31:45 -0500, David W. Hodgins wrote:
> 
>> On Thu, 08 Dec 2022 14:47:14 -0500, Harold Johanssen
>> <noemail@please.net> wrote:
>>
>>> 	I don't know whether this is reasonable possible, but I thought
>>> I'd ask anyway, just in case:
>>>
>>> 	Is it possible to guarantee SSH to a specific client, to the
>>> exclusion of all other clients? In effect, all other connection would
>>> be immediately rejected, even before the SSH protocol exchange gets
>>> going. The following requirements must be met:
>>>
>>> 	- The SSH server must be listening on port 22.
>>> 	- The target client may connect from different, arbitrary IP
>>> addresses.
>>>
>>> 	This would be easily possible with tweaked SSH servers and
>>> clients, but I am not sure it can be done with off-the-shelf ones.
>>
>> Excluding all other clients would go against the fact that linux is a
>> multi-user system, so it's not a standard feature.
>>
>> killing the sshd server does not kill the working ssh connection(s), so
>> you could have a script run on login via ssh that kills the sshd server,
>> but you'd have to also figure out how to restart it after that
>> connection ends (intentionally or not).
>>
>> Why do you want to do this? There's probably a better way to lock things
>> when needed.
>>
>> Regards, Dave Hodgins
> 
> 	You misunderstood what I wrote. What I meant is the following:
> 
> 	I want to ssh into a specific system that I control, from
> wherever I am in the Internet. Any ssh connections from anybody else into
> that system, wherever they are coming from in the Internet, are
> automatically rejected - it is not that they are rejected when the wrong
> username and password are supplied; rather, their connection requests are
> rejected before the ssh protocol gets started. Can this be done, with the
> constraints that I specified?

I use a random sshd high port for this.
Ok if someone port scans they might find it.  But script kiddies are not 
so good as that.


> 
> 	This would be networking-related question: in a nutshell, if the
> TCP connection on port 22 is coming from me then it is forwarded to the
> ssh daemon; otherwise, it is dropped immediately. The problem is, how
> would the TCP code in my server know that the connection is coming me
> from me, as opposed to anybody else?
> 
As I said, either because it isn't on 22 at all, or because you ate 
using an identifiable source port


-- 
"The most difficult subjects can be explained to the most slow witted 
man if he has not formed any idea of them already; but the simplest 
thing cannot be made clear to the most intelligent man if he is firmly 
persuaded that he knows already, without a shadow of doubt, what is laid 
before him."

    - Leo Tolstoy

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

#36426

On Fri, 9 Dec 2022 01:20:58 -0000 (UTC), Harold Johanssen wrote:
> On Thu, 08 Dec 2022 16:31:45 -0500, David W. Hodgins wrote:
>> On Thu, 08 Dec 2022 14:47:14 -0500, Harold Johanssen
>> <noemail@please.net> wrote:
>> 
>>> 	I don't know whether this is reasonable possible, but I thought
>>> I'd ask anyway, just in case:
>>>
>>> 	Is it possible to guarantee SSH to a specific client, to the
>>> exclusion of all other clients? In effect, all other connection would
>>> be immediately rejected, even before the SSH protocol exchange gets
>>> going. The following requirements must be met:
>>>
>>> 	- The SSH server must be listening on port 22.
>>> 	- The target client may connect from different, arbitrary IP
>>> addresses.
>>>
>>> 	This would be easily possible with tweaked SSH servers and
>>> clients, but I am not sure it can be done with off-the-shelf ones.
>> 
>> Excluding all other clients would go against the fact that linux is a
>> multi-user system, so it's not a standard feature.
>> 
>> killing the sshd server does not kill the working ssh connection(s), so
>> you could have a script run on login via ssh that kills the sshd server,
>> but you'd have to also figure out how to restart it after that
>> connection ends (intentionally or not).
>> 
>> Why do you want to do this? There's probably a better way to lock things
>> when needed.
>> 
>> Regards, Dave Hodgins
>
> 	You misunderstood what I wrote. What I meant is the following:
>
> 	I want to ssh into a specific system that I control, from 
> wherever I am in the Internet. Any ssh connections from anybody else into 
> that system, wherever they are coming from in the Internet, are 
> automatically rejected - it is not that they are rejected when the wrong 
> username and password are supplied; rather, their connection requests are 
> rejected before the ssh protocol gets started. Can this be done, with the 
> constraints that I specified?

For crying out loud!  
Simply use public-private keys _only_ 
between the one client (you) and the ssh server.

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

#36427

On 09/12/2022 13:55, Allodoxaphobia wrote:

>> 	I want to ssh into a specific system that I control, from
>> wherever I am in the Internet. Any ssh connections from anybody else into
>> that system, wherever they are coming from in the Internet, are
>> automatically rejected - it is not that they are rejected when the wrong
>> username and password are supplied; rather, their connection requests are
>> rejected before the ssh protocol gets started. Can this be done, with the
>> constraints that I specified?
> 
> For crying out loud!
> Simply use public-private keys _only_
> between the one client (you) and the ssh server.

Yeah, I don't think I understand the question, because I just use 
.ssh/authorised_keys. It seemed registering the specific client public 
key in .ssh/authorised_keys and turning off ssh password authentication 
would do the trick.

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

#36411

If the accepted clients have specific, known IP addresses, then if the server 
has a firewall (eg iptables, firewalld, etc.), then firewall rules could be 
set up to "reject" (or drop) port 22 packets from non-accepted IP addresses.  
No changes to sshd or special settings in /etc/ssh/*config would be needed.  

At Thu, 08 Dec 2022 16:31:45 -0500 "David W. Hodgins" <dwhodgins@nomail.afraid.org> wrote:

> 
> On Thu, 08 Dec 2022 14:47:14 -0500, Harold Johanssen <noemail@please.net> wrote:
> 
> > 	I don't know whether this is reasonable possible, but I thought
> > I'd ask anyway, just in case:
> >
> > 	Is it possible to guarantee SSH to a specific client, to the
> > exclusion of all other clients? In effect, all other connection would be
> > immediately rejected, even before the SSH protocol exchange gets going.
> > The following requirements must be met:
> >
> > 	- The SSH server must be listening on port 22.
> > 	- The target client may connect from different, arbitrary IP
> > addresses.
> >
> > 	This would be easily possible with tweaked SSH servers and
> > clients, but I am not sure it can be done with off-the-shelf ones.
> 
> Excluding all other clients would go against the fact that linux is a multi-user
> system, so it's not a standard feature.
> 
> killing the sshd server does not kill the working ssh connection(s), so you could
> have a script run on login via ssh that kills the sshd server, but you'd have
> to also figure out how to restart it after that connection ends (intentionally
> or not).
> 
> Why do you want to do this? There's probably a better way to lock things when
> needed.
> 
> Regards, Dave Hodgins
>                                                         
> 

-- 
Robert Heller             -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                    

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

#36432

On Fri, 09 Dec 2022 03:34:32 +0000, Robert Heller wrote:
>
> If the accepted clients have specific, known IP addresses, then if the server 
> has a firewall (eg iptables, firewalld, etc.), then firewall rules could be 
> set up to "reject" (or drop) port 22 packets from non-accepted IP addresses.  
> No changes to sshd or special settings in /etc/ssh/*config would be needed.  

SSH has options itself to deal with traffic.

As long as a server can deal with these things I refrained from using a
package filter.

Example SMB. I set up

bind interfaces only = Yes

and

interfaces = 127.0.0.0/8 eth0

to only allow localhost and what comes over Ethernet (my other computer).
-- 
Andreas

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

#36433

On 09/12/2022 17:44, Andreas Kohlbach wrote:
> On Fri, 09 Dec 2022 03:34:32 +0000, Robert Heller wrote:
>>
>> If the accepted clients have specific, known IP addresses, then if the server
>> has a firewall (eg iptables, firewalld, etc.), then firewall rules could be
>> set up to "reject" (or drop) port 22 packets from non-accepted IP addresses.
>> No changes to sshd or special settings in /etc/ssh/*config would be needed.
> 
> SSH has options itself to deal with traffic.
> 
> As long as a server can deal with these things I refrained from using a
> package filter.
> 
> Example SMB. I set up
> 
> bind interfaces only = Yes
> 
> and
> 
> interfaces = 127.0.0.0/8 eth0
> 
> to only allow localhost and what comes over Ethernet (my other computer).

Won't solve OPs problem since the IP address of the source is neither 
constant nor known in advance.


-- 
Socialism is the philosophy of failure, the creed of ignorance and the 
gospel of envy.

Its inherent virtue is the equal sharing of misery.

Winston Churchill

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

#36410

On Thu, 8 Dec 2022 19:47:14 -0000 (UTC), Harold Johanssen wrote:
>
> 	I don't know whether this is reasonable possible, but I thought 
> I'd ask anyway, just in case:
>
> 	Is it possible to guarantee SSH to a specific client, to the 
> exclusion of all other clients? In effect, all other connection would be 
> immediately rejected, even before the SSH protocol exchange gets going. 
> The following requirements must be met:
>
> 	- The SSH server must be listening on port 22.
> 	- The target client may connect from different, arbitrary IP 
> addresses.
>
> 	This would be easily possible with tweaked SSH servers and 
> clients, but I am not sure it can be done with off-the-shelf ones.

I can think of several ways.

The sshd_config (probably in /etc/ssh/sshd_config) knows

AllowUsers user1

If this entry exists, only user1 can login.

Then there is

ListenAddress

so SSH will only listen to the IP following.

There is also the good old /etc/hosts.allow and /etc/hosts.deny

In the deny you could add

sshd: ALL

and in the allow only those IP(s) to grant access.

Personally I only use AllowUsers in the /etc/ssh/sshd_config which
works. Thus other users I have on the system cannot access via SSH, even
if provided the correct password.

After altering the config you need to restart the SSH-Server.

Alternatively (or use all of the options if paranoid) there are "host
keys". Users identify with their unique "host key" and don't need to
provide a password. One could even deactivate password auth. Then no user
can log in, even if provided the correct password. Their host key(s) must
match instead.
-- 
Andreas

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

#36423

Harold Johanssen <noemail@please.net> writes:
> 	I don't know whether this is reasonable possible, but I thought 
> I'd ask anyway, just in case:
>
> 	Is it possible to guarantee SSH to a specific client, to the 
> exclusion of all other clients? In effect, all other connection would be 
> immediately rejected, even before the SSH protocol exchange gets going. 
> The following requirements must be met:
>
> 	- The SSH server must be listening on port 22.
> 	- The target client may connect from different, arbitrary IP 
> addresses.
>
> 	This would be easily possible with tweaked SSH servers and 
> clients, but I am not sure it can be done with off-the-shelf ones.

AIUI you want to avoid exposing the SSH session setup implementation to
anything but your chosen clients, for some reason that you’ve not
stated. (Perhaps explaining the motivation would help.)

To do that you need a reasonably secure way to identify your chosen
clients. A VPN could do the job, but now you’re exposing the VPN’s
session setup code to the entire Internet instead of the SSH equivalent.

Unless you have a reason to believe that the VPN is better than SSH, in
whatever way it is you care about, you’ve not gained anything - you’ve
just added complexity to your system.

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

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

#36424

On 08/12/2022 19:47, Harold Johanssen wrote:
> 	I don't know whether this is reasonable possible, but I thought
> I'd ask anyway, just in case:
> 
> 	Is it possible to guarantee SSH to a specific client, to the
> exclusion of all other clients? In effect, all other connection would be
> immediately rejected, even before the SSH protocol exchange gets going.
> The following requirements must be met:
> 
> 	- The SSH server must be listening on port 22.
> 	- The target client may connect from different, arbitrary IP
> addresses.
> 
> 	This would be easily possible with tweaked SSH servers and
> clients, but I am not sure it can be done with off-the-shelf ones.
think about this for a moment.
To connect, a packet with source port and IP musts connect to 
destination port 22 at IP address of server.

In order for this all to work at all, the only variable you can use to 
identify 'legal' traffic at the TCP level is the source port.

At that level a simple firewall rule that rejected all connections other 
than those from a specific source port would do what you want.

How to ensure your application only used that port is somewhat trickier, 
especially if its behind NAṪ

So its possible, but non trivial







-- 
“Puritanism: The haunting fear that someone, somewhere, may be happy.”

H.L. Mencken, A Mencken Chrestomathy

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

#36429

On Thu, 8 Dec 2022 19:47:14 -0000 (UTC), Harold Johanssen wrote:

> I don't know whether this is reasonable possible, but I thought I'd ask
> anyway, just in case:
> 
> 	Is it possible to guarantee SSH to a specific client, to the
> exclusion of all other clients? In effect, all other connection would be
> immediately rejected, even before the SSH protocol exchange gets going.
> The following requirements must be met:
> 
> 	- The SSH server must be listening on port 22.
> 	- The target client may connect from different, arbitrary IP
> addresses.
> 
> 	This would be easily possible with tweaked SSH servers and
> clients, but I am not sure it can be done with off-the-shelf ones.

	Thank everybody for your suggestion. Here's what I am going to do:

	Since I am talking about a particular Linux SSH server that I 
fully control, and a particular Linux SSH client that I also fully 
control, I am going to make use of the SSH identification string. Since 
this string contemplates an optional field where one can put anything 
(with the constraints mentioned in the relevant RFC) I will use the 
contents of that string to filter out incoming connections.

	Initially I will use some arbitrary, fixed string - the changes 
to the SSH client and server codes to support this are trivial. Later on 
I could use a OTP-like scheme, which would not be much more difficult to 
pull off. Either way, my server will reject pests before the SSH protocol 
exchange gets going (which is elaborate and computationally intensive) 
and my client will still work with standard SSH servers. I'll have to 
maintain that code, but that will be a nice entertainment.

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

#36430

On 9.12.2022 16.48, Harold Johanssen wrote:
> On Thu, 8 Dec 2022 19:47:14 -0000 (UTC), Harold Johanssen wrote:
> 
>> I don't know whether this is reasonable possible, but I thought I'd ask
>> anyway, just in case:
>>
>> 	Is it possible to guarantee SSH to a specific client, to the
>> exclusion of all other clients? In effect, all other connection would be
>> immediately rejected, even before the SSH protocol exchange gets going.
>> The following requirements must be met:
>>
>> 	- The SSH server must be listening on port 22.
>> 	- The target client may connect from different, arbitrary IP
>> addresses.
>>
>> 	This would be easily possible with tweaked SSH servers and
>> clients, but I am not sure it can be done with off-the-shelf ones.
> 
> 	Thank everybody for your suggestion. Here's what I am going to do:
> 
> 	Since I am talking about a particular Linux SSH server that I
> fully control, and a particular Linux SSH client that I also fully
> control, I am going to make use of the SSH identification string. Since
> this string contemplates an optional field where one can put anything
> (with the constraints mentioned in the relevant RFC) I will use the
> contents of that string to filter out incoming connections.
> 
> 	Initially I will use some arbitrary, fixed string - the changes
> to the SSH client and server codes to support this are trivial. Later on
> I could use a OTP-like scheme, which would not be much more difficult to
> pull off. Either way, my server will reject pests before the SSH protocol
> exchange gets going (which is elaborate and computationally intensive)
> and my client will still work with standard SSH servers. I'll have to
> maintain that code, but that will be a nice entertainment.

There is a such mechanism already in SSH. Google for
'passswordless ssh login'. The generated cryptographic
keys are far more secure than an invented string.

-- 

-TV

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web