Mailing List Archive

sshd Failing New Inbound Connections
I managed to lock myself out of my firewall today.

I disabled inet6 resolution by removing it from the `family` option in
resolve.conf(5). After a while I noticed I couldn't make new inbound
connections using either ipv4 or ipv6. My client kept reporting:

"kex_exchange_identification: Connection closed by remote host"

On the server I found the following errors in /var/log/authlog:

"fatal: bad addr or host: ::1 (no address associated with name)"

Totally my fault for changing resolv.conf without enough thought, but
perhaps sshd could disable the listener in such cases.

Client Details:

MacOS 12.3
OpenSSH_8.6p1, LibreSSL 3.3.5


Server Details:

OpenBSD 7.0 GENERIC.MP#5 amd64
OpenSSH_8.8, LibreSSL 3.4.1

# cat sshd_config

AcceptEnv LC_CTYPE
AllowUsers <snip>
ClientAliveInterval 3
ClientAliveCountMax 30
ListenAddress ::1
ListenAddress 127.0.0.1
PasswordAuthentication no
PermitRootLogin forced-commands-only
TrustedUserCAKeys /etc/ssh/ca.pub

# relevant /etc/pf.conf

pass quick inet proto tcp from (em2:network) to { (em2) (egress) } \
port ssh divert-to lo0 port ssh

Cheers,

--Aaron
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: sshd Failing New Inbound Connections [ In reply to ]
On Thu, 17 Mar 2022, Aaron Poffenberger wrote:

> I managed to lock myself out of my firewall today.
>
> I disabled inet6 resolution by removing it from the `family` option in
> resolve.conf(5). After a while I noticed I couldn't make new inbound
> connections using either ipv4 or ipv6. My client kept reporting:
>
> "kex_exchange_identification: Connection closed by remote host"
>
> On the server I found the following errors in /var/log/authlog:
>
> "fatal: bad addr or host: ::1 (no address associated with name)"
>
> Totally my fault for changing resolv.conf without enough thought, but
> perhaps sshd could disable the listener in such cases.

Well, we can't catch every misconfiguration that could result in
sshd failing to accept connections, but I think we can fix this one :)

sshd doesn't need to actually resolve the listenaddress directives in
the reexec path, so skip it.

diff --git a/servconf.c b/servconf.c
index 63a7303..dd936f0 100644
--- a/servconf.c
+++ b/servconf.c
@@ -2459,7 +2459,7 @@ parse_server_match_config(ServerOptions *options,

initialize_server_options(&mo);
parse_server_config(&mo, "reprocess config", cfg, includes,
- connectinfo);
+ connectinfo, 0);
copy_set_server_options(options, &mo, 0);
}

@@ -2637,12 +2637,13 @@ parse_server_config_depth(ServerOptions *options, const char *filename,
void
parse_server_config(ServerOptions *options, const char *filename,
struct sshbuf *conf, struct include_list *includes,
- struct connection_info *connectinfo)
+ struct connection_info *connectinfo, int reexec)
{
int active = connectinfo ? 0 : 1;
parse_server_config_depth(options, filename, conf, includes,
connectinfo, (connectinfo ? SSHCFG_MATCH_ONLY : 0), &active, 0);
- process_queued_listen_addrs(options);
+ if (!reexec)
+ process_queued_listen_addrs(options);
}

static const char *
diff --git a/servconf.h b/servconf.h
index 1197c57..6f1f745 100644
--- a/servconf.h
+++ b/servconf.h
@@ -295,7 +295,7 @@ int process_server_config_line(ServerOptions *, char *, const char *, int,
void process_permitopen(struct ssh *ssh, ServerOptions *options);
void load_server_config(const char *, struct sshbuf *);
void parse_server_config(ServerOptions *, const char *, struct sshbuf *,
- struct include_list *includes, struct connection_info *);
+ struct include_list *includes, struct connection_info *, int);
void parse_server_match_config(ServerOptions *,
struct include_list *includes, struct connection_info *);
int parse_server_match_testspec(struct connection_info *, char *);
diff --git a/sshd.c b/sshd.c
index 6d8bc2a..72e9fe7 100644
--- a/sshd.c
+++ b/sshd.c
@@ -1638,7 +1638,7 @@ main(int ac, char **av)
load_server_config(config_file_name, cfg);

parse_server_config(&options, rexeced_flag ? "rexec" : config_file_name,
- cfg, &includes, NULL);
+ cfg, &includes, NULL, rexeced_flag);

#ifdef WITH_OPENSSL
if (options.moduli_file != NULL)
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: sshd Failing New Inbound Connections [ In reply to ]
> On Mar 17, 2022, at 22:52, Damien Miller <djm@mindrot.org> wrote:
>
> On Thu, 17 Mar 2022, Aaron Poffenberger wrote:
>
>> I managed to lock myself out of my firewall today.
>>
>> I disabled inet6 resolution by removing it from the `family` option in
>> resolve.conf(5). After a while I noticed I couldn't make new inbound
>> connections using either ipv4 or ipv6. My client kept reporting:
>>
>> "kex_exchange_identification: Connection closed by remote host"
>>
>> On the server I found the following errors in /var/log/authlog:
>>
>> "fatal: bad addr or host: ::1 (no address associated with name)"
>>
>> Totally my fault for changing resolv.conf without enough thought, but
>> perhaps sshd could disable the listener in such cases.
>
> Well, we can't catch every misconfiguration that could result in
> sshd failing to accept connections, but I think we can fix this one :)

:)

>
> sshd doesn't need to actually resolve the listenaddress directives in
> the reexec path, so skip it.

The fw is on -release. I'll setup a build environment this weekend and
test the patch.

Cheers!

--Aaron

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: sshd Failing New Inbound Connections [ In reply to ]
Damien Miller wrote:
> > "fatal: bad addr or host: ::1 (no address associated with name)"
>
> sshd doesn't need to actually resolve the listenaddress directives in
> the reexec path, so skip it.

Is a further improvement possible where addresses are recognized as
such without the resolver, eliminating the resolver as a source of
problems when it's actually not applicable?

I don't know how easy it is to accomplish very portably? :\

POSIX.1-2001 offers inet_pton() but that essentially requires trying
both AF_INET and AF_INET6 explicitly.

getaddrinfo() sometimes supports AI_NUMERICHOST which could perhaps
be tried once opportunistically, before trying again with it unset?

Would it be worthwhile to do something like that even if it only
works on some platforms? (Others would keep current behavior.)


//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: sshd Failing New Inbound Connections [ In reply to ]
Peter Stuge wrote in
<20220318230932.23632.qmail@stuge.se>:
|Damien Miller wrote:
|>> "fatal: bad addr or host: ::1 (no address associated with name)"
|>
|> sshd doesn't need to actually resolve the listenaddress directives in
|> the reexec path, so skip it.
|
|Is a further improvement possible where addresses are recognized as
|such without the resolver, eliminating the resolver as a source of
|problems when it's actually not applicable?
|
|I don't know how easy it is to accomplish very portably? :\
|
|POSIX.1-2001 offers inet_pton() but that essentially requires trying
|both AF_INET and AF_INET6 explicitly.

I wonder, don't you usually do

c_af = (su_cs_find_c(pgp->pg_ca, ':') != NIL) ? AF_INET6 : AF_INET;
if(inet_pton(c_af, pgp->pg_ca,
(c_af == AF_INET ? S(void*,&c_sip.v4)
: S(void*,&c_sip.v6))) != 1){

Problem (for me regarding inet_pton(3)) is more that this beast
fails for things like 127.000.000.001, it expects properly
formatted 127.0.0.1. (This at least GNU LibC, i personally see
this as a bug, even though POSIX says "standard text
interpretation" --- but that surely is decimal and then
"compression" (to use the term for IPv4) should be applicable or
not.)

|getaddrinfo() sometimes supports AI_NUMERICHOST which could perhaps
|be tried once opportunistically, before trying again with it unset?
|
|Would it be worthwhile to do something like that even if it only
|works on some platforms? (Others would keep current behavior.)

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: sshd Failing New Inbound Connections [ In reply to ]
Steffen Nurpmeso wrote in
<20220318235830.LtgtZ%steffen@sdaoden.eu>:
|Peter Stuge wrote in
| <20220318230932.23632.qmail@stuge.se>:
||Damien Miller wrote:
||>> "fatal: bad addr or host: ::1 (no address associated with name)"
...
||POSIX.1-2001 offers inet_pton() but that essentially requires trying
||both AF_INET and AF_INET6 explicitly.
|
|I wonder, don't you usually do
|
| c_af = (su_cs_find_c(pgp->pg_ca, ':') != NIL) ? AF_INET6 : AF_INET;
| if(inet_pton(c_af, pgp->pg_ca,
| (c_af == AF_INET ? S(void*,&c_sip.v4)
|: S(void*,&c_sip.v6))) != 1){
|
|Problem (for me regarding inet_pton(3)) is more that this beast
|fails for things like 127.000.000.001, it expects properly
|formatted 127.0.0.1. (This at least GNU LibC, i personally see
|this as a bug, even though POSIX says "standard text
|interpretation" --- but that surely is decimal and then
|"compression" (to use the term for IPv4) should be applicable or
|not.)

P.S. (and regardless that a commit seem to have happened: It is
actually even standardized that "octal numbers" are not supported
for IPv4, whereas leading zeroes for the hexadecimal ones in IPv6
addresses are. I do not like this, i have often seen
127.000.000.001 in form fields etc.

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: sshd Failing New Inbound Connections [ In reply to ]
On Sat, 19 Mar 2022, Steffen Nurpmeso wrote:

>> |getaddrinfo() sometimes supports AI_NUMERICHOST which could perhaps
>> |be tried once opportunistically, before trying again with it unset?

This sounds sensible. AIUI that one skips the resolver.

> actually even standardized that "octal numbers" are not supported

> 127.000.000.001 in form fields etc.

These are decimal, to add insult to injury, not octal.

Blame the Windows® 95 input fields…

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

****************************************************
/?\ The UTF-8 Ribbon
? ? Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
 ?  HTML eMail! Also, https://www.tarent.de/newsletter
? ? header encryption!
****************************************************
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: sshd Failing New Inbound Connections [ In reply to ]
Thorsten Glaser wrote in
<1f7ddbf7-b4da-10a2-62cc-4356ec12534@tarent.de>:
|On Sat, 19 Mar 2022, Steffen Nurpmeso wrote:
|>>|getaddrinfo() sometimes supports AI_NUMERICHOST which could perhaps
|>>|be tried once opportunistically, before trying again with it unset?
|
|This sounds sensible. AIUI that one skips the resolver.
|
|> actually even standardized that "octal numbers" are not supported

..inet_pton..

|> 127.000.000.001 in form fields etc.
|
|These are decimal, to add insult to injury, not octal.
|
|Blame the Windows® 95 input fields…

I do. But here we are and inet_pton was carefully designed to
require academics on the input side.

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: sshd Failing New Inbound Connections [ In reply to ]
On Mon, 21 Mar 2022, Steffen Nurpmeso wrote:

> |> actually even standardized that "octal numbers" are not supported
>
> ..inet_pton..

Huh. Not that but inet_aton on GNU, and other functions apparently.

This is idiotic, and I guess the same POSIX that insists on octals
for leading-zero numbers in shell, causing no small amount of bugs,
is responsible. Hmph.


| $ ./a.out 226.000.000.037 # Last byte is in octal

Given that these may be either decimal or octal, depending on where
they come from, it’s probably for the best to reject them.

(My RFC822-and-related-parser certainly does.)

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

****************************************************
/?\ The UTF-8 Ribbon
? ? Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
 ?  HTML eMail! Also, https://www.tarent.de/newsletter
? ? header encryption!
****************************************************
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: sshd Failing New Inbound Connections [ In reply to ]
On 3/21/22 15:08, Thorsten Glaser wrote:
> On Mon, 21 Mar 2022, Steffen Nurpmeso wrote:
>
>> |> actually even standardized that "octal numbers" are not supported
>>
>> ..inet_pton..
>
> Huh. Not that but inet_aton on GNU, and other functions apparently.
>
> This is idiotic, and I guess the same POSIX that insists on octals
> for leading-zero numbers in shell, causing no small amount of bugs,
> is responsible. Hmph.
>
>> |> 127.000.000.001 in form fields etc.
>
> | $ ./a.out 226.000.000.037 # Last byte is in octal
>
> Given that these may be either decimal or octal, depending on where
> they come from, it’s probably for the best to reject them.

Not only is it best practice to reject them, failing to do so has
caused security holes in the past. I believe both Go and Rust
reject them nowadays for that reason.

--
Sincerely,
Demi Marie Obenour (she/her/hers)
Re: sshd Failing New Inbound Connections [ In reply to ]
Hello Thorsten.

Thorsten Glaser wrote in
<cde1a8a-25b5-42d8-b4b-f1f595ea8bfc@tarent.de>:
|On Mon, 21 Mar 2022, Steffen Nurpmeso wrote:
|>|> actually even standardized that "octal numbers" are not supported
|>
|> ..inet_pton..
|
|Huh. Not that but inet_aton on GNU, and other functions apparently.

I did not know this one. But i want to go with standard ones,
otherwise i would have a parser myself, it is C++ but actually
that one is C. It requires "3 periods" for IPv4 though, and
always uses base 10.

|This is idiotic, and I guess the same POSIX that insists on octals
|for leading-zero numbers in shell, causing no small amount of bugs,
|is responsible. Hmph.
|
|>|> 127.000.000.001 in form fields etc.
|
|| $ ./a.out 226.000.000.037 # Last byte is in octal
|
|Given that these may be either decimal or octal, depending on where
|they come from, it’s probably for the best to reject them.
|
|(My RFC822-and-related-parser certainly does.)

Looking at the docu it seems even more strange, no end-user i know
would ever use octal or hexadecimal numbers in an IPv4 address,
let alone in a mixed fashion. I personally would only go for
"IPv4 dotted-decimal notation". Whatever.

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev