Re: ssh and IPv6 addresses in brackes with proxy command
On Thu, 3 Nov 2022, Mikolaj Kucharski wrote: > On Thu, Nov 03, 2022 at 07:06:48AM +, Mikolaj Kucharski wrote: > > Hi, > > > > I'm using below type of config for few years now. Today I've upgraded to: > > > > > > OpenBSD 7.2-current (GENERIC.MP) #823: Wed Nov 2 11:56:37 MDT 2022 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > > and see following problem: > > > > > > $ ssh -vv pce-0035 > > OpenSSH_9.1, LibreSSL 3.6.0 > > debug1: Reading configuration data /home/mk1/.ssh/config > > debug1: /home/mk1/.ssh/config line 127: Applying options for pce-0035 > > debug1: /home/mk1/.ssh/config line 1527: Applying options for * > > debug1: Reading configuration data /etc/ssh/ssh_config > > debug2: resolve_addr: could not resolve name [fde4:f456:48c2:13c0::cc35] as > > address: name or service is not known > > debug1: resolve_canonicalize: hostname [fde4:f456:48c2:13c0::cc35] is an > > unrecognised address > > debug1: Executing proxy command: exec ssh -q -W > > [fde4:f456:48c2:13c0::cc35]:22 ks2 > > ... > > debug1: load_hostkeys: fopen /home/mk1/.ssh/known_hosts2: No such file or > > directory > > debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or > > directory > > debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or > > directory > > debug1: check_host_key: invalid hostname "[fde4:f456:48c2:13c0::cc35]"; > > will not record: domain name "[fde4:f456:48c2:13c0::cc35]" starts with > > invalid character > > Host key verification failed. > > $ _ > > > > > > # ~/.ssh/config > > Host pce-0035 > > User root > > HostName [fde4:f456:48c2:13c0::cc35] > > ProxyCommand ssh -q -W %h:%p ks2 > > Host ks2 > > User root > > HostName ks2.example.com > > Host * > > AddressFamily any > > Protocol 2 > > ServerAliveInterval 120 > > ConnectionAttempts 3 > > ConnectTimeout 30 > > ForwardAgent no > > > > Reverting below helps with above: > > > commit 64416e996841f6651db1721672edf837c235712c > Author: djm > Date: Mon Oct 24 22:43:36 2022 + > > Be more paranoid with host/domain names coming from the resolver: > don't follow CNAMEs with invalid characters when canonicalising > and never write a name with bad characters to a known_hosts file. > > reported by David Leadbeater, ok deraadt@ I just committed something to relax this overly-strict check, but it still won't fix your config. This is because HostName [fde4:f456:48c2:13c0::cc35] doesn't actually work. E.g. $ ssh -oHostname=[::1] x ssh: Could not resolve hostname [::1]: no address associated with name It only worked in the context of your configuration because it was treated as a literal string and not an address. Changing your config to avoid this should be backwards-compatible: Host pce-0035 User root HostName fde4:f456:48c2:13c0::cc35 ProxyCommand ssh -q -W [%h]:%p ks2 or you could use ProxyJump -d
Re: ssh anoncvs regression: Connection closed
On Mon, 27 Dec 2021, Damien Miller wrote: > The specific problem was that I was relying on authmethod_lookup() in > userauth_finish() to get the canonical authentication method name, but > this lookup function implicitly checks whether the authentication method > is enabled, and I didn't realise that userauth_none() disables itself > after being called once. > > The solution is to split the lookup and enable tests into separate > functions. This has been committed, and you should be able to resolve your problem by updating to CVS head and rebuilding sshd. Thanks again for the report! -d
Re: ssh anoncvs regression: Connection closed
On Mon, 27 Dec 2021, Damien Miller wrote:
> On Sun, 26 Dec 2021, Nam Nguyen wrote:
>
> > >Synopsis: ssh anoncvs regression: Connection closed
> > >Category: user
> > >Environment:
> > System : OpenBSD 7.0
> > Details : OpenBSD 7.0-current (GENERIC) #198: Sat Dec 25 16:22:02
> > MST 2021
> >
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> >
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> > >Description:
> > I have an anoncvs instance that stopped working upon upgrading to
> > -current. This looks like a regression with openssh, which closes the
> > connection.
> >
> > $ cvs -d anon...@namtsui.com:/cvs checkout -P nvi/
> > Connection closed by 45.77.165.128 port 22
> > cvs [checkout aborted]: end of file from server (consult above messages if
> > any)
>
> Thanks for the report. Do you control the server too? If so, are you able to
> capture a debug trace from sshd there? An easy way to do this is to run
> sshd on a separate port in non-forking mode and connect to that, e.g.
> "/usr/bin/sshd -dddp" and "ssh -p user@host".
Never mind, I have reproduced the problem locally. I broke "none"
authentication in the process of merging the agent restriction changes.
Unfortunately we don't have good coverage of this authentication method in
the regress tests.
The specific problem was that I was relying on authmethod_lookup() in
userauth_finish() to get the canonical authentication method name, but
this lookup function implicitly checks whether the authentication method
is enabled, and I didn't realise that userauth_none() disables itself
after being called once.
The solution is to split the lookup and enable tests into separate
functions.
This should fix it:
diff --git a/auth2.c b/auth2.c
index d6cc3d7..e68952a 100644
--- a/auth2.c
+++ b/auth2.c
@@ -89,6 +89,7 @@ static int input_service_request(int, u_int32_t, struct ssh
*);
static int input_userauth_request(int, u_int32_t, struct ssh *);
/* helper */
+static Authmethod *authmethod_byname(const char *);
static Authmethod *authmethod_lookup(Authctxt *, const char *);
static char *authmethods_get(Authctxt *authctxt);
@@ -345,9 +346,10 @@ userauth_finish(struct ssh *ssh, int authenticated, const
char *packet_method,
}
if (authctxt->postponed)
fatal("INTERNAL ERROR: authenticated and postponed");
- if ((m = authmethod_lookup(authctxt, method)) == NULL)
+ /* prefer primary authmethod name to possible synonym */
+ if ((m = authmethod_byname(method)) == NULL)
fatal("INTERNAL ERROR: bad method %s", method);
- method = m->name; /* prefer primary name to possible synonym */
+ method = m->name;
}
/* Special handling for root */
@@ -457,25 +459,42 @@ authmethods_get(Authctxt *authctxt)
}
static Authmethod *
-authmethod_lookup(Authctxt *authctxt, const char *name)
+authmethod_byname(const char *name)
{
int i;
- if (name != NULL)
- for (i = 0; authmethods[i] != NULL; i++)
- if (authmethods[i]->enabled != NULL &&
- *(authmethods[i]->enabled) != 0 &&
- (strcmp(name, authmethods[i]->name) == 0 ||
- (authmethods[i]->synonym != NULL &&
- strcmp(name, authmethods[i]->synonym) == 0)) &&
- auth2_method_allowed(authctxt,
- authmethods[i]->name, NULL))
- return authmethods[i];
- debug2("Unrecognized authentication method name: %s",
- name ? name : "NULL");
+ if (name == NULL)
+ fatal_f("NULL authentication method name");
+ for (i = 0; authmethods[i] != NULL; i++) {
+ if (strcmp(name, authmethods[i]->name) == 0 ||
+ (authmethods[i]->synonym != NULL &&
+ strcmp(name, authmethods[i]->synonym) == 0))
+ return authmethods[i];
+ }
+ debug_f("unrecognized authentication method name: %s", name);
return NULL;
}
+static Authmethod *
+authmethod_lookup(Authctxt *authctxt, const char *name)
+{
+ Authmethod *method;
+
+ if ((method = authmethod_byname(name)) == NULL)
+ return NULL;
+
+ if (method->enabled == NULL || *(method->enabled) == 0) {
+ debug3_f("method %s not enabled", name);
+ return NULL;
+ }
+ if (!auth2_method_allowed(authctxt, method->name, NULL)) {
+ debug3_f("method %s not allowed "
+ "by AuthenticationMethods", name);
+ return NULL;
+ }
+ return method;
+}
+
/*
* Check a comma-separated list of methods for validity. Is need_enable is
* non-zero, then also require that the methods are enabled.
Re: ssh anoncvs regression: Connection closed
On Sun, 26 Dec 2021, Nam Nguyen wrote: > >Synopsis:ssh anoncvs regression: Connection closed > >Category:user > >Environment: > System : OpenBSD 7.0 > Details : OpenBSD 7.0-current (GENERIC) #198: Sat Dec 25 16:22:02 > MST 2021 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > I have an anoncvs instance that stopped working upon upgrading to > -current. This looks like a regression with openssh, which closes the > connection. > > $ cvs -d anon...@namtsui.com:/cvs checkout -P nvi/ > Connection closed by 45.77.165.128 port 22 > cvs [checkout aborted]: end of file from server (consult above messages if > any) Thanks for the report. Do you control the server too? If so, are you able to capture a debug trace from sshd there? An easy way to do this is to run sshd on a separate port in non-forking mode and connect to that, e.g. "/usr/bin/sshd -dddp" and "ssh -p user@host". -d
Re: OpenSSH parsing list regression
Thanks - I just committed a fix. Will look at adding a regress test to catch similar cases. On Tue, 8 Jun 2021, Lucas wrote: > Hi bugs@, Damien, > > I updated to a really recent snapshot > > oolong$ sysctl kern.version > > kern.version=OpenBSD 6.9-current (GENERIC.MP) #58: Tue Jun 8 10:24:26 MDT > 2021 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > still there, the previously working > > -o UserKnownHostsFile='a b' > > does not work anymore. This is interpreted as checking the file 'a' and > then the file 'b' in 6.9, but it only checks file 'a' in that snapshot. > > An easy way to test it is using `-o UserKnownHostsFile=/dev/null > ~/.ssh/known_hosts', which check both files on 6.9 but ask to approve > the fingerprint in -current. In particular, `reposync` uses this > construction[1], quite probably responsable for the failures reported > by danj earlier on. > > [1]: > https://github.com/sthen/reposync/blob/30a2ee87fa7e8fba071737ba065827011d6d41b3/reposync#L73 >
Re: sshd regression: keyword AuthenticationMethods extra arguments at end of line
On Sat, 5 Jun 2021, Daniel Jakots wrote: > Hi, > > I updated some machines of mine to a newer snapshot and got some > problems with sshd. > > Old snapshot is from 2021-05-19. > New snapshot is from 2021-06-05 (today). > > I use the default config (only change is LogLevel VERBOSE) and at the > end I put some custom config which I give here: > > 90 # Custom config > 91 PermitRootLogin without-password > 92 > 93 # 2FA (yubikey or totp) > 94 PasswordAuthentication yes > 95 AuthenticationMethods publickey,password > 96 #AuthenticationMethods publickey > 97 > 98 AllowUsers www > 99 > 100 > 101 # 1FA for those users > 102 Match User zzz > 103 AuthenticationMethods publickey > 104 Match Address 192.168.111.34/32 > 105 AllowUsers xxx > 106 AuthenticationMethods publickey > 107 > 108 # For 2FA but also to allow root from legit IP > 109 Match Address 192.0.2.221 > 110 AuthenticationMethods publickey > 111 AllowUsers root www xxx yyy > 112 > > > sshd doesn't start. With debug mode: > $ /usr/sbin/sshd -d > /etc/ssh/sshd_config line 103: keyword AuthenticationMethods extra arguments > at end of line > /etc/ssh/sshd_config line 106: keyword AuthenticationMethods extra arguments > at end of line > /etc/ssh/sshd_config line 110: keyword AuthenticationMethods extra arguments > at end of line > /etc/ssh/sshd_config: terminating, 3 bad configuration options Thanks for the report - a patch in snaps broke AuthenticationMethods in Match blocks. It will be fixed shortly. -d
Re: ssh segfault: hostkeys_check_old passes NULL to sshkey_ssh_name
On Wed, 26 May 2021, James Cook wrote:
> On Wed, May 26, 2021 at 10:26:00AM +1000, Damien Miller wrote:
> >
> > On Sat, 22 May 2021, James Cook wrote:
> >
> > > >Synopsis:ssh segfault: hostkeys_check_old passes NULL to
> > > >sshkey_ssh_name
> > > >Category:user
> > > >Environment:
> > > System : OpenBSD 6.9
> > > Details : OpenBSD 6.9-current (GENERIC.MP) #28: Wed May 19 16:59:40
> > > MDT 2021
> > >
> > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > >
> > > Architecture: OpenBSD.amd64
> > > Machine : amd64
> > > >Description:
> > > I see a segfault ssh-ing to one of my computers:
> > >
> > > falsifian moth ~ $ ssh james@angel
> > > no such identity: /home/falsifian/.ssh/unencrypted_id_rsa: No such file
> > > or directory
> > > (james@angel) Password:
> > > Segmentation fault (core dumped)
> >
> > Thanks for the very detailed report. Please try this:
> >
> > diff --git a/clientloop.c b/clientloop.c
> > index 33a43ba..3716dc0 100644
> > --- a/clientloop.c
> > +++ b/clientloop.c
> > @@ -1938,7 +1938,7 @@ hostkeys_check_old(struct hostkey_foreach_line *l,
> > void *_ctx)
> > if (!sshkey_equal(l->key, ctx->old_keys[i]))
> > continue;
> > debug3_f("found deprecated %s key at %s:%ld as %s",
> > - sshkey_ssh_name(ctx->keys[i]), l->path, l->linenum,
> > + sshkey_ssh_name(ctx->old_keys[i]), l->path, l->linenum,
> > hashed ? "[HASHED]" : l->hosts);
> > ctx->old_key_seen = 1;
> > break;
>
> I've been running with exactly that change since I filed the report,
> and I haven't had any trouble. In particular I was able to successfully
> connect to the host that caused the problem in the first place.
Thanks - fix committed
-d
Re: ssh segfault: hostkeys_check_old passes NULL to sshkey_ssh_name
On Sat, 22 May 2021, James Cook wrote:
> >Synopsis:ssh segfault: hostkeys_check_old passes NULL to sshkey_ssh_name
> >Category:user
> >Environment:
> System : OpenBSD 6.9
> Details : OpenBSD 6.9-current (GENERIC.MP) #28: Wed May 19 16:59:40
> MDT 2021
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
> I see a segfault ssh-ing to one of my computers:
>
> falsifian moth ~ $ ssh james@angel
> no such identity: /home/falsifian/.ssh/unencrypted_id_rsa: No such file
> or directory
> (james@angel) Password:
> Segmentation fault (core dumped)
Thanks for the very detailed report. Please try this:
diff --git a/clientloop.c b/clientloop.c
index 33a43ba..3716dc0 100644
--- a/clientloop.c
+++ b/clientloop.c
@@ -1938,7 +1938,7 @@ hostkeys_check_old(struct hostkey_foreach_line *l, void
*_ctx)
if (!sshkey_equal(l->key, ctx->old_keys[i]))
continue;
debug3_f("found deprecated %s key at %s:%ld as %s",
- sshkey_ssh_name(ctx->keys[i]), l->path, l->linenum,
+ sshkey_ssh_name(ctx->old_keys[i]), l->path, l->linenum,
hashed ? "[HASHED]" : l->hosts);
ctx->old_key_seen = 1;
break;
Re: Fwd: Re: ssh_config(5) ProxyJump option not working in the latest snapshot
ugh, that's embarassing
ok & thanks djm
On Mon, 21 Dec 2020, Theo Buehler wrote:
> On Mon, Dec 21, 2020 at 10:15:33AM +0100, Theo Buehler wrote:
> > On Mon, Dec 21, 2020 at 08:10:59PM +1100, Damien Miller wrote:
> > > Sorry, this snuck back in along with another commit.
> > >
> > > Does this fix it?
> >
> > Yes. I was hesitating doing something equivalent to this, but went for
> > the plain revert in my proposed diff.
> >
> > ok tb
>
> Sorry, I did not look carefully enough at the second part of the diff.
> This bit should have been removed as in the first bit:
>
> Index: readconf.c
> ===
> RCS file: /cvs/src/usr.bin/ssh/readconf.c,v
> retrieving revision 1.345
> diff -u -p -r1.345 readconf.c
> --- readconf.c21 Dec 2020 09:19:53 - 1.345
> +++ readconf.c21 Dec 2020 10:36:24 -
> @@ -2784,9 +2784,6 @@ parse_jump(const char *s, Options *o, in
> goto out;
> } else {
> /* Subsequent argument or inactive configuration */
> - if (parse_ssh_uri(cp, NULL, NULL, NULL) == -1 &&
> - parse_user_host_port(cp, NULL, NULL, NULL) != 0)
> - goto out;
> r = parse_ssh_uri(cp, NULL, NULL, NULL);
> if (r == -1 || (r == 1 &&
> parse_user_host_port(cp, NULL, NULL, NULL) != 0))
>
Re: Fwd: Re: ssh_config(5) ProxyJump option not working in the latest snapshot
Sorry, this snuck back in along with another commit.
Does this fix it?
diff --git a/readconf.c b/readconf.c
index cec6844..85e8c6f 100644
--- a/readconf.c
+++ b/readconf.c
@@ -2769,7 +2769,7 @@ parse_jump(const char *s, Options *o, int active)
{
char *orig, *sdup, *cp;
char *host = NULL, *user = NULL;
- int ret = -1, port = -1, first;
+ int r, ret = -1, port = -1, first;
active &= o->proxy_command == NULL && o->jump_host == NULL;
@@ -2785,14 +2785,19 @@ parse_jump(const char *s, Options *o, int active)
if (first) {
/* First argument and configuration is active */
- if (parse_ssh_uri(cp, , , ) == -1 &&
- parse_user_host_port(cp, , , ) != 0)
+ r = parse_ssh_uri(cp, , , );
+ if (r == -1 || (r == 1 &&
+ parse_user_host_port(cp, , , ) != 0))
goto out;
} else {
/* Subsequent argument or inactive configuration */
if (parse_ssh_uri(cp, NULL, NULL, NULL) == -1 &&
parse_user_host_port(cp, NULL, NULL, NULL) != 0)
goto out;
+ r = parse_ssh_uri(cp, NULL, NULL, NULL);
+ if (r == -1 || (r == 1 &&
+ parse_user_host_port(cp, NULL, NULL, NULL) != 0))
+ goto out;
}
first = 0; /* only check syntax for subsequent hosts */
} while (cp != sdup);
On Mon, 21 Dec 2020, Theo Buehler wrote:
> Not sure if you saw that. Seems to be a logic error due to the fact that
> parse_ssh_uri() has three possible return values (-1, 0, 1), not 2.
> Full original report is here:
>
> https://marc.info/?l=openbsd-bugs=160844761615469=2
>
> - Forwarded message from Theo Buehler -
>
> Date: Sun, 20 Dec 2020 14:18:02 +0100
> From: Theo Buehler
> To: Raf Czlonka
> Cc: bugs@openbsd.org
> Subject: Re: ssh_config(5) ProxyJump option not working in the latest snapshot
>
> > I can see that there's been a number of changes committed to OpenSSH
> > recently[0] so, unless there's a snapshot-only change, this is most
> > likely related.
>
> Reverting this part of the change in readconf.c r1.344 "fixes" it for me.
> The issue I run into with 'ssh -J host1 host2' is that parse_ssh_uri()
> returns 1, in which case there no longer is a fallback to
> parse_user_host_port(), so options->jump_host remains unset and the
> "Setting implicit ProxyCommand from ProxyJump" path is no longer taken
> in main().
>
> Index: readconf.c
> ===
> RCS file: /cvs/src/usr.bin/ssh/readconf.c,v
> retrieving revision 1.344
> diff -u -p -r1.344 readconf.c
> --- readconf.c17 Dec 2020 23:10:27 - 1.344
> +++ readconf.c20 Dec 2020 11:49:16 -
> @@ -2778,12 +2778,12 @@ parse_jump(const char *s, Options *o, in
>
> if (first) {
> /* First argument and configuration is active */
> - if (parse_ssh_uri(cp, , , ) == -1 &&
> + if (parse_ssh_uri(cp, , , ) == -1 ||
> parse_user_host_port(cp, , , ) != 0)
> goto out;
> } else {
> /* Subsequent argument or inactive configuration */
> - if (parse_ssh_uri(cp, NULL, NULL, NULL) == -1 &&
> + if (parse_ssh_uri(cp, NULL, NULL, NULL) == -1 ||
> parse_user_host_port(cp, NULL, NULL, NULL) != 0)
> goto out;
> }
>
>
> - End forwarded message -
>
Re: ssh warning: the ED25519 host key for '' differs from the key for the IP address ''
On Thu, 29 Oct 2020, Jeremie Courreges-Anglas wrote: > On Thu, Oct 29 2020, Damien Miller wrote: > > On Wed, 28 Oct 2020, Jeremie Courreges-Anglas wrote: > > > >> On Wed, Oct 28 2020, Damien Miller wrote: > >> > On Mon, 26 Oct 2020, Jeremie Courreges-Anglas wrote: > >> > > >> >> On Fri, Oct 23 2020, Damien Miller wrote: > >> >> > On Fri, 23 Oct 2020, Jeremie Courreges-Anglas wrote: > >> >> > > >> >> >> > >> >> >> I upgraded my ports builder from snaps yesterday and I hit this when > >> >> >> running cvs up: > >> > > >> > [big snip] > >> > > >> > I think I have replicated your problem. Can you roll your known_hosts > >> > back to just the ecdsa-sha2-nistp256 keys, apply this patch and attempt > >> > a few connections? You should see no more conflicts between IPv4/IPv6 > >> > addresses. > >> > >> Here's a v6->v4 case which didn't improve. I believe that the data > >> provided below should help you reproduce the issue, if not there's > >> something weird going on. Feel free to send more patches my way. > > > > Thanks - I think the following patch should fix it. If it doesn't > > then can you please rerun your testing with some extra logging: > > > > ssh -oLogVerbose=sshconnect.c:*,clientloop.c:*,hostfile.c:* ... > > No new host keys and no warnings this time: Thanks for catching this and your help in wrestling it to the ground :) I'll commit it shortly. -d
Re: ssh warning: the ED25519 host key for '' differs from the key for the IP address ''
On Wed, 28 Oct 2020, Jeremie Courreges-Anglas wrote:
> On Wed, Oct 28 2020, Damien Miller wrote:
> > On Mon, 26 Oct 2020, Jeremie Courreges-Anglas wrote:
> >
> >> On Fri, Oct 23 2020, Damien Miller wrote:
> >> > On Fri, 23 Oct 2020, Jeremie Courreges-Anglas wrote:
> >> >
> >> >>
> >> >> I upgraded my ports builder from snaps yesterday and I hit this when
> >> >> running cvs up:
> >
> > [big snip]
> >
> > I think I have replicated your problem. Can you roll your known_hosts
> > back to just the ecdsa-sha2-nistp256 keys, apply this patch and attempt
> > a few connections? You should see no more conflicts between IPv4/IPv6
> > addresses.
>
> Here's a v6->v4 case which didn't improve. I believe that the data
> provided below should help you reproduce the issue, if not there's
> something weird going on. Feel free to send more patches my way.
Thanks - I think the following patch should fix it. If it doesn't
then can you please rerun your testing with some extra logging:
ssh -oLogVerbose=sshconnect.c:*,clientloop.c:*,hostfile.c:* ...
diff --git a/clientloop.c b/clientloop.c
index cda0845..2cbf6d1 100644
--- a/clientloop.c
+++ b/clientloop.c
@@ -1878,13 +1878,20 @@ hostkeys_find(struct hostkey_foreach_line *l, void
*_ctx)
return 0;
}
- /* Record if address matched against a different hostname. */
- if (ctx->ip_str != NULL && (l->match & HKF_MATCH_HOST) == 0 &&
- strchr(l->hosts, ',') != NULL) {
- ctx->other_name_seen = 1;
- debug3_f("found address %s against different hostname at "
- "%s:%ld", ctx->ip_str, l->path, l->linenum);
- return 0;
+ /* If CheckHostIP is enabled, then check for mismatched hostname/addr */
+ if (ctx->ip_str != NULL && strchr(l->hosts, ',') != NULL) {
+ if ((l->match & HKF_MATCH_HOST) == 0) {
+ /* Record if address matched a different hostname. */
+ ctx->other_name_seen = 1;
+ debug3_f("found address %s against different hostname "
+ "at %s:%ld", ctx->ip_str, l->path, l->linenum);
+ return 0;
+ } else if ((l->match & HKF_MATCH_IP) == 0) {
+ /* Record if hostname matched a different address. */
+ ctx->other_name_seen = 1;
+ debug3_f("found hostname %s against different address "
+ "at %s:%ld", ctx->host_str, l->path, l->linenum);
+ }
}
/*
@@ -2277,7 +2284,7 @@ client_input_hostkeys(struct ssh *ssh)
ctx->ip_str ? ctx->ip_str : "(none)");
if ((r = hostkeys_foreach(options.user_hostfiles[i],
hostkeys_find, ctx, ctx->host_str, ctx->ip_str,
- HKF_WANT_PARSE_KEY|HKF_WANT_MATCH)) != 0) {
+ HKF_WANT_PARSE_KEY)) != 0) {
if (r == SSH_ERR_SYSTEM_ERROR && errno == ENOENT) {
debug_f("hostkeys file %s does not exist",
options.user_hostfiles[i]);
Re: ssh warning: the ED25519 host key for '' differs from the key for the IP address ''
On Mon, 26 Oct 2020, Jeremie Courreges-Anglas wrote:
> On Fri, Oct 23 2020, Damien Miller wrote:
> > On Fri, 23 Oct 2020, Jeremie Courreges-Anglas wrote:
> >
> >>
> >> I upgraded my ports builder from snaps yesterday and I hit this when
> >> running cvs up:
[big snip]
I think I have replicated your problem. Can you roll your known_hosts
back to just the ecdsa-sha2-nistp256 keys, apply this patch and attempt
a few connections? You should see no more conflicts between IPv4/IPv6
addresses.
diff --git a/clientloop.c b/clientloop.c
index cda0845..9f25950 100644
--- a/clientloop.c
+++ b/clientloop.c
@@ -2277,7 +2277,7 @@ client_input_hostkeys(struct ssh *ssh)
ctx->ip_str ? ctx->ip_str : "(none)");
if ((r = hostkeys_foreach(options.user_hostfiles[i],
hostkeys_find, ctx, ctx->host_str, ctx->ip_str,
- HKF_WANT_PARSE_KEY|HKF_WANT_MATCH)) != 0) {
+ HKF_WANT_PARSE_KEY)) != 0) {
if (r == SSH_ERR_SYSTEM_ERROR && errno == ENOENT) {
debug_f("hostkeys file %s does not exist",
options.user_hostfiles[i]);
Explanation: in clientloop.c r1.353 I added some additional checks to
stop UpdateHostKeys that were intended to prevent exactly this situation.
Unfortunately I forgot to flip the flag to allow the new code to actually
execute.
Basically, clientloop.c:hostkeys_find() will try look for host keys on
known_hosts lines that *do not* match the current hostname/IP and disable
UpdateHostkeys if they exist. However, the above HKF_WANT_MATCH flag was
causing hostkeys_find() to only ever be called with matching lines.
I missed this when I did my testing, because I tried a subtly different
case: known_hosts lines with non-matching IP addresses but matching
hostnames. These make it through the HKF_WANT_MATCH filter.
-d
Re: ssh warning: the ED25519 host key for '' differs from the key for the IP address ''
On Mon, 26 Oct 2020, Jeremie Courreges-Anglas wrote: > > I think these were the problems that I fixed around 2020/10/14. If > > you remove line 12 from your known_hosts and reconnect with a ssh > > built after that then you should be fine. > > Indeed I'm fine after removing line 12: > > --8<-- > russell ~$ ssh -6 anon...@ftp.hostserver.de > PTY allocation request failed on channel 0 > > To use anonymous CVS install the latest version of CVS on your local machine. > Then set your CVSROOT environment variable to the following value: > anon...@ftp.hostserver.de:/cvs > > -->8-- > > But if I later try to connect using IPv4: Could you try removing line 12 and reconnect with -vvv in the flags? I'd like to see what UpdateHostKeys is doing... Thanks for spending time looking at this. The interactions between UpdateHostkeys and CheckHostIP are not fun :( -d
Re: ssh warning: the ED25519 host key for '' differs from the key for the IP address ''
On Fri, 23 Oct 2020, Jeremie Courreges-Anglas wrote: > > I upgraded my ports builder from snaps yesterday and I hit this when > running cvs up: > > --8<-- > russell ~$ ssh anon...@ftp.hostserver.de > Warning: the ED25519 host key for 'ftp.hostserver.de' differs from the key > for the IP address '2a00:15a8:0:100:d91f:5023:0:1' > Offending key for IP in /home/jca/.ssh/known_hosts:2 > Matching host key in /home/jca/.ssh/known_hosts:12 > Are you sure you want to continue connecting (yes/no)? ^C > russell ~$ grep -n -F -e ftp.hostserver.de -e 217.31.80.35 -e > 2a00:15a8:0:100:d91f:5023:0:1 ~/.ssh/known_hosts > 1:ftp.hostserver.de,217.31.80.35 ecdsa-sha2-nistp256 > E2VjZHNhLXNoYTItbmlzdHAyNTYIbmlzdHAyNTYAAABBBF7jym1iJpFZfWWS+TTCGQv/CcVoFR4MVCR45YB6mmTL3V5bWwIQ8ggYGgbLcRV+M9VQL2zm0Nykw5HXbFXQ9D8= > 2:2a00:15a8:0:100:d91f:5023:0:1 ecdsa-sha2-nistp256 > E2VjZHNhLXNoYTItbmlzdHAyNTYIbmlzdHAyNTYAAABBBF7jym1iJpFZfWWS+TTCGQv/CcVoFR4MVCR45YB6mmTL3V5bWwIQ8ggYGgbLcRV+M9VQL2zm0Nykw5HXbFXQ9D8= > 11:ftp.hostserver.de,217.31.80.35 ssh-rsa > B3NzaC1yc2EDAQABAAABAQDlCI96jPiGKnN07xj5ZhVPvo0gMo3TZOMtuf02afv9xm6+2vQlVqJThnavg3W0u6gaHV45MtldA/P4DaQbG50DPof9mJ3y1U2hbl+kU8tTfpVMC0WdXHbTpSmdkp5KVirFwZcubd2UFn8dXNtosULMahghvI2WzynLiO/hILzMrKE3J9LMG9mH2cbB3dAZ2KsHklQnrPb8xWhvaskcs3z94LgNyZbxF3uhOZBz019m5ba/DMjyoTLoNNNSRZ/Ur8JQIRSVzQPUwJ+AXCiZ8OoPF6RNmU9WjTFPt5K7dr4kOyZpDTBu103b2TUaJfiB/Gz2BNqyK11tLjLfXQO6Wez5 > 12:ftp.hostserver.de,217.31.80.35 ssh-ed25519 > C3NzaC1lZDI1NTE5IGtEuMXXJNl4whGkEOPWiq/XHgfzejdJvOKFL8S3kZDL > -->8-- > > I have "family inet6 inet4" on this machine, so IPv6 is tried first. > > On my laptop I hit the same issue with a dual-stack server of mine, both > with ssh -4 and ssh -6 (I can provide details if needed). > > After cvs up -D2020/10/03, ./ssh/obj/ssh doesn't spit the warning, it > happens again with cvs up -D2020/10/04. > > cc'ing djm since this *looks* like fallout from the recent > UpdateHostKeys changes. I think these were the problems that I fixed around 2020/10/14. If you remove line 12 from your known_hosts and reconnect with a ssh built after that then you should be fine. -d
Re: FIDO key does not work with ssh
On Mon, 31 Aug 2020, Evan Tann wrote: > Hi Damien, > > Sure thing. Please see the output of `ssh -vvv user@host` below. Thanks for the quick reply. > debug1: ssh-sk-helper: ready to sign with key ECDSA-SK, provider internal: > msg len 245, compat 0x400 > debug1: sshsk_sign: provider "internal", key ECDSA-SK, flags 0x01 > debug1: sk_probe: 1 device(s) detected > debug1: sk_probe: selecting sk by cred > debug1: sk_open: fido_dev_open /dev/fido/0 failed: FIDO_ERR_INTERNAL This is what is failing. You might be able to get more detail by placing libfido2 in debug mode: env FIDO_DEBUG=1 ssh -vvv ... But please also try updating src/sys/dev/usb/uhidev.c up to 1.83 (the current revision) and rebuilding your kernel. There was an attempt at working around a xhci(4) problem that caused more problems that it solved. The bad commit was included in the kernel you are running but was since backed out. Per your dmesg, fido0 -> uhub2 -> uhub0 -> xhci0 so it may well be that. -d
Re: FIDO key does not work with ssh
On Mon, 31 Aug 2020, open...@evantann.com wrote: > >Synopsis:ecdsa-sk no longer works with latest snapshot > >Category: > >Environment: > System : OpenBSD 6.7 > Details : OpenBSD 6.7-current (GENERIC.MP) #52: Sun Aug 30 17:55:06 > MDT 2020 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > As of a recent snapshot, my Yubikey with an ecdsa-sk key no longer > works with ssh. Where the ssh process would typically pause to confirm > presence, now it fails immediately with the following: > > Confirm user presence for key ECDSA-SK SHA256: > sign_and_send_pubkey: signing failed for ECDSA-SK "$keypath": > invalid format > $user@$ip: Permission denied (publickey). > >How-To-Repeat: > 1. Insert a single Yubikey into a USB port. > 2. Generate an ecdsa-sk key with normal options, i.e. not a resident > key. > 3. Attempt to ssh into any service that uses your ecdsa-sk key. > > This can be reproduced with or without ssh-agent running. Hi, Thanks for the report - plase send the output of a failing ssh session in verbose mode, i.e. ssh -vvv user@host Thanks, Damien
Re: ssh asks for key password incorrectly?
On Mon, 21 Oct 2019, Ted Unangst wrote: > Damien Miller wrote: > > On Sun, 20 Oct 2019, Ted Unangst wrote: > > > > > Ah, so when this happens, it's on a machine that doesn't have > > > id_ed25519.pub. > > > Here's a before and after ssh -vvv for reference. > > > > ah, so you have just the private key id_ed25519 and no corresponding > > pubkey on this machine? > > not intentionally, just happenstance. anyway, since that seems to be the root > cuase, and it's kinda odd, feel free to ignore if this is how it should work. I think it might be possible to provide a better experience if the key is in the newer OpenSSH format (which all ed25519 keys are). I'll make a patch :) -d
Re: ssh asks for key password incorrectly?
On Sun, 20 Oct 2019, Ted Unangst wrote: > Ah, so when this happens, it's on a machine that doesn't have id_ed25519.pub. > Here's a before and after ssh -vvv for reference. ah, so you have just the private key id_ed25519 and no corresponding pubkey on this machine? So, what usually happens is that ssh can test whether or not a key has a chance of being accepted by sshd if it has the pubkey. That is what is happening here: > debug1: Next authentication method: publickey > debug1: Offering public key: t...@carbolite.home.tedunangst.com ED25519 > SHA256:KQM4nnWGRt2PxBx9AZIST6zCR6j4XQAQLSdpRfm9jfg agent > debug3: send packet: type 50 > debug2: we sent a publickey packet, wait for reply > debug3: receive packet: type 51 It seems to have an ed25519 key in your agent that ssh tests against the server, but the server isn't interested. If it were then ssh would invoke the private key (either from disk or, in this case, via ssh-agent) to sign a challenge and perform a real authentication attempt. The try-key-valid vs signed-auth-attempt are separate because ssh tries to avoid unwrapping or invoking private keys unless there is a chance they will be accepted. Anyway, in this case the key wasn't prima facie acceptable so ssh continues to try other keys. Eventually it arrives at your id_ed25519 key: > debug1: Trying private key: /home/tedu/.ssh/id_ed25519 > Enter passphrase for key '/home/tedu/.ssh/id_ed25519': Here, there is no .pub file available to perform the public key test described above. So ssh has no option but to try to unwrap the private key in order do the try-pubkey-valid test. If you add a corresponding .pub file then ssh can just test it without unwrapping the private key. I can't recall any changes being made to this behaviour recently, but it's possible that I'm wrong. -d
Re: ssh asks for key password incorrectly?
On Sun, 20 Oct 2019, Ted Unangst wrote: > I have two OpenBSD machines, let's call them laptop and desktop. desktop is a > bit older, and has a ecdsa-sha2-nistp256 key in .ssh/authorized_keys. laptop > is configured with a ssh-ed25519 .ssh/id_ed25519 key file. The keyfile has a > password and I use ssh-agent and ssh-add to unlock it. > > What happens: I ssh from laptop to desktop and ssh asks for the id_ed25519 > password. This doesn't accomplish much, since it isn't authorized on desktop > anyway. > > Expected: If the key doesn't work, I should be asked for the remote system > password, not the key password. The key has already been unlocked via ssh-add. > > Theory: ssh tries the key, doesn't work, then gets confused when it goes back > into the .ssh for more options and asks to unlock a key it's already seen. > > I think this is a regression, I've had similar setup for ages and never > noticed this before. Could you send the output of "ssh -vvv desktop" from the laptop side? Also, what are the permissions for ~/.ssh/id_ed25519*?
Re: ssh_config: Match exec broken
I've reverted it On Wed, 7 Mar 2018, Stuart Henderson wrote: > On 2018/03/03 04:52, Klemens Nanni wrote: > > Just upgraded the latest snapshot > > > > OpenBSD 6.3-beta (GENERIC.MP) #25: Fri Mar 2 14:41:23 MST 2018 > > > > The following ssh_config(5) snippet is now broken: > > > > Match exec "echo %n | grep -qxE 'some|nifty|regex'" > > Include some/config > > > > $ ssh some_host > > Unsupported Match attribute echo > > /home/kn/.ssh/config line 42: Bad Match condition > > > > Reverting the following commit fixes this and I can connect again > > regardless of matching: > > > > revision 1.124 > > date: 2018/03/02 03:02:11; author: djm; state: Exp; lines: +19 -8; > > commitid: nNRsCijZiGG6SUTT; > > Allow escaped quotes \" and \' in ssh_config and sshd_config quotes > > option strings. bz#1596 ok markus@ > > > > Related, I have a bunch of machines with address match lines including quotes: > > Match Address "192.168.0.0/16,2001:xxx:::/48" > > It seems this wasn't required before (for some reason I thought it was), but > it was accepted - this now prevents sshd startup until the "s are removed. > > Fortunately I discovered this on a machine where I have serial console :-) >
Re: Serious vulnerability in RSA and other crypto algorithms
can you demonstrate this attack with small-modulus RSA key? E.g. the attached On Tue, 16 Jan 2018, Gabriel Withington wrote: > There is a serious flaw in cryptography based on semiprimes. While attempts > at breaking such cryptography typically focus on factoring semiprimes, the > approach I have identified sidesteps this challenge entirely. I have yet to > evaluate my techniques performance on keys of practical length, a number of > features suggest that it should be highly efficient. > > What I recognized that the goal of decrypting a message does not require > knowing the prime factors. Cryptography is possible due to an intrinsic > characteristic of semiprimes that there exists an exponent 'k' such that x^k > mod n = 1 where 'n' is a semiprime number and 'x' is an arbitrary integer > with x < n. And a number can be encrypted with the formula x^e mod n = y > where 'y' is the encrypted message. Then decrypted with the formula y^d mod > n = x where d+e = k+1. (Really d+e = i*k+1 where i is a positive integer.) > > The formula x^r mod n (for positive integer 'r') acts as a clock function, > which includes a predictable periodicity. For powers if i*k, the formula > passes through one and the next power (i*k+1) gives the original power back. > And for the public key exponent 'e', a message can be decrypted using > i*k+1-e, regardless of what the private key exponent is. > > All of that is to say that given an encrypted message and the associated > public key, you just need to find the loop exponent 'k' and the problem > becomes trivial. > > The good news is that searching for k is highly efficient. All that is > needed is two different exponents which provide the same result. The goal is > two exponents 'r' and 's' such that x^r mod n = x^s mod n since the > difference will be a power which produces one in the formula. This can be > found by testing different exponents and storing them along with the results > in two hashes. The hash keyed in exponents avoids recalculating previous > attempts and the hash keyed in results makes finding duplicate values as > quick as a hash lookup. > > This reduces the difficulty to a birthday problem. (If you have 'n' people > in a room, what are the odds two or more have the same birthday. > https://en.wikipedia.org/wiki/Birthday_problem) The tested exponents can be > spread out to limit repetition of similar distances, this means that each > new exponent is compared against all previous ones with a portion of the > comparisons being unique. And the unique portion will be a fraction of the > total number of previous attempts. Which means that the searched space > increases geometrically in both time and memory space. > > And that's the type of thing you want when you're trying to break > cryptography. > > (If you consider the space of semiprime 'n' to be what is searched, this > approach is actually quite a bit better than the birthday problem. You need > 367 people to guarantee that two have the same birthday but you don't need > to try all 'n' possible exponents but all possible distances between > exponents which can be contained in 'n'. I'm an applied mathematician and > never really liked number theory so I'm just going to guess and say you need > about sqrt n tries to cover the whole space. So far, outstanding.) > > The other piece of really good news is that the value which is being > searched for isn't unique. Any exponent which gives unity is sufficient for > decryption and there are guaranteed to be at least two which are less than > n. And the number of potential values increases with increasing key length > (not absolutely but on average). Which means that longer keys actually give > more chances to find a suitable exponent and the odds increase with each > exponent tried. > > There's some obvious detail I've added but I feel like the takeaway is that > simply looking for the loop exponent 'k' rather than trying to factor > semiprimes makes the challenge of breaking RSA and related methods far > easier. In fact, I believe that this method will allow for the cracking of > keys with a reasonable length in a reasonable time on existing hardware. (My > guess is that this approach may break keys in sub-linear time relative to > key length.) > > Now for the bad news. The exponent identified in the search I described > above is not the same as the 'k' I've been discussing. Each value 'x' which > is encrypted has it's own loop exponent which can be a factor (therefore > smaller) than the 'k' specific to the controlling semiprime. If an exponent > which gives a result of unity for a value 'x', that exponent can be used to > decrypt that message. But it is likely that a different exponent will be > needed for a different message 'x' (really, message chunk since the total > message is broken up into pieces for encryption). > > In order to address this, it seems wise to begin searching with an x of 2 > for greater computational efficiency. Once a working
