Mailing List Archive

Please help test recent changes
Hi,

We've landed some fairly significant changes in OpenSSH recently and
would appreciate your help in testing them. The biggest of the changes
are:

1. Conversion of the ssh and sshd mainloop from select() to poll()

This should be entirely invisible to users, so any behaviour change
is a bug. If you see something and want to help debug it further,
uncomment the DEBUG_CHANNEL_POLL #define in channels.c for helps of
extra debug logging.

2. Restricted agent keys.

This is a large set of changes to add destination- and path-restricted
keys to ssh-agent. A full writeup is at on the website at
https://www.openssh.com/agent-restrict.html - I'm interested to hear
feedback on how this works in practice, UI and things that could be
improved (as well as bug reports).

3. Running down the remaining RSA/SHA2 corner-cases

There has been a fair bit of work to identify and fix the remaining
cases where various things behaved badly wrt RSA signature algorithms.
Recent fixes include hostbased authentication and UpdateHostkeys.
Again, [almost] any change in visible behaviour here is a bug.

All of these changes are in git and will be in tomorrow's snapshot
(20220108).

Thanks!

Damien Miller
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Please help test recent changes [ In reply to ]
On 2022-01-07 at 09:52 +1100, Damien Miller wrote:
> Hi,
>
> We've landed some fairly significant changes in OpenSSH recently and
> would appreciate your help in testing them. The biggest of the
> changes
> are:
> (...)
>
> All of these changes are in git and will be in tomorrow's snapshot
> (20220108).
>
> Thanks!
>
> Damien Miller

Hello Damien

That's very interesting.

I have thought about this some time ago (maybe it was mentioned on this
list?), but I had only considered each ssh(1) prepending its parameters
to the agent. This approach is more robust, although I would include in
SSH_AGENTC_EXTENSION a string for identifying how the connection was
made (typically the ssh call, which could be untrue, of course). This
could be useful for debugging, or when there are earlier hops through
unknown hosts.


I think the document should reference somewhere the more secure option
of chaining ssh connections using ProxyJump, that this restriction
doesn't apply there and ssh-agent considers such connections as local.


As a further step, I would add the ability to specify wildcard
destinations, e.g.
ssh-add -h "*.prod.example.com" ~/.ssh/production.key

for a key which could be used on any subdomain of prod.example.com, but
not anywhere else.

The restrictions are expressed in a right-associative way, which IMHO
seem unintuitive. Something like "charybdis.example.org from
scylla.example.org" or "charybdis.example.org<scylla.example.org" would
perhaps emphasize better the beginning of the restriction is not fixed.
What do other people think about it?

It's not mentioned in the document, but I expect that when ssh-add parses
restrictions that they support ports as well
ssh-add -h "scylla.example.org>medea@charybdis.example.org:2222"



I think "the keys for all the hosts that the user lists must be present
in the right place (the machine running ssh-add) and the right time."
intends to be "*at* the right time.", but it's probably better to state
explicitly "at the time ssh-add is run".

I see ssh-add gets added -H to choose a known_hosts file, good. But the
text in ssh-add.1 "ssh-add will use the default ssh_config(5) known
hosts files:", while strictly correct, may make it seem that it will
somehow parse ~/.ssh/config or /etc/ssh/ssh_config for
UserKnownHostsFile directives. I suggest
"ssh-add will use the known hosts files:
~/.ssh/known_hosts, ~/.ssh/known_hosts2, /etc/ssh/ssh_known_hosts, and
/etc/ssh/ssh_known_hosts2, which is the default used by ssh_config(5)"



A potential issue I see is, given the example:

$ ssh-add -h "perseus@cetus.example.org" \
-h "scylla.example.org" \
-h "scylla.example.org>medea@charybdis.example.org" \
~/.ssh/id_ed25519

Poseidon is root on cetus, and wants some files that medea saves in
charybdis.
When victim logs in as perseus@cetus.example.org (forwarding ssh-
agent), Poseidon impersonates perseus and logs in to
poseidon@scylla.example.org *without using this key* (e.g. with
keyboard-authentication). He is then able to connect to
medea@charybdis.example.org using the forwarded ssh-agent.

(he could have used an evil ssh(1) to lie and run it directly from
cetus with a fake binding, but since he needs a valid login to scylla,
it's easier this way)

This is likely unexpected, but I don't see an easy way to avoid it. One
could force the whole path to be connected with the same key (maybe the
code already does this?), but that would forbid using multiple keys
along the path (e.g. one key for the bastion host, then jump from it to
the dev environment that uses its own dev key)

First of all, I think we need to be able to state the source user:
-h "perseus@scylla.example.org>medea@charybdis.example.org"
which requires a new field 'string from_username' on
SSH_AGENT_CONSTRAIN_EXTENSION.

And perhaps ssh-add should default that field to the current user if
unset, although I would consider alternate User values in ~/.ssh/config
to be relatively common.


Finally, two minor nitpicks: a stray backslash in '\public'
and s/pursues/pursued/


Sorry for the long list of comments!


Best regards

?ngel


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Please help test recent changes [ In reply to ]
Hi Damien,

The restricted agent keys functionality sounds really interesting. Are there any plans to support embedding the restrictions in the keys themselves at some point? That would make this much easier to use, but it would require extending the key format and adding the appropriate parsing in ssh-agent or ssh-add.

Anyway, thanks for the great work.

--
Iain

?On 1/6/22, 14:53, "openssh-unix-dev on behalf of Damien Miller" <openssh-unix-dev-bounces+iain.morgan=nasa.gov@mindrot.org on behalf of djm@mindrot.org> wrote:

Hi,

We've landed some fairly significant changes in OpenSSH recently and
would appreciate your help in testing them. The biggest of the changes
are:

1. Conversion of the ssh and sshd mainloop from select() to poll()

This should be entirely invisible to users, so any behaviour change
is a bug. If you see something and want to help debug it further,
uncomment the DEBUG_CHANNEL_POLL #define in channels.c for helps of
extra debug logging.

2. Restricted agent keys.

This is a large set of changes to add destination- and path-restricted
keys to ssh-agent. A full writeup is at on the website at
[snip]


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Please help test recent changes [ In reply to ]
On Fri, 7 Jan 2022, Morgan, Iain (ARC-TN)[InuTeq, LLC] wrote:

> Hi Damien,
>
> The restricted agent keys functionality sounds really interesting.
> Are there any plans to support embedding the restrictions in the keys
> themselves at some point? That would make this much easier to use, but
> it would require extending the key format and adding the appropriate
> parsing in ssh-agent or ssh-add.

I hadn't considered that before - how would it envision it working?

Yes, the key format would require extension and that isn't a trivial
change because of backwards-compatibility :(

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Please help test recent changes [ In reply to ]
On Fri, 7 Jan 2022, ?ngel wrote:

> Hello Damien
>
> That's very interesting.
>
> I have thought about this some time ago (maybe it was mentioned on this
> list?), but I had only considered each ssh(1) prepending its parameters
> to the agent. This approach is more robust, although I would include in
> SSH_AGENTC_EXTENSION a string for identifying how the connection was
> made (typically the ssh call, which could be untrue, of course). This
> could be useful for debugging, or when there are earlier hops through
> unknown hosts.
>
>
> I think the document should reference somewhere the more secure option
> of chaining ssh connections using ProxyJump, that this restriction
> doesn't apply there and ssh-agent considers such connections as local.

Good point; done :)

> As a further step, I would add the ability to specify wildcard
> destinations, e.g.
> ssh-add -h "*.prod.example.com" ~/.ssh/production.key
>
> for a key which could be used on any subdomain of prod.example.com, but
> not anywhere else.

This works already, mostly. The wildcard will be expanded by ssh-add
to all available hostkeys that match it before the key is added.

> The restrictions are expressed in a right-associative way, which IMHO
> seem unintuitive. Something like "charybdis.example.org from
> scylla.example.org" or "charybdis.example.org<scylla.example.org" would
> perhaps emphasize better the beginning of the restriction is not fixed.
> What do other people think about it?
>
> It's not mentioned in the document, but I expect that when ssh-add parses
> restrictions that they support ports as well
> ssh-add -h "scylla.example.org>medea@charybdis.example.org:2222"

Not really - it might be possible to look up a hostkey with an embedded
port number, but there's no validation of it by the protocol thereafter.

> I think "the keys for all the hosts that the user lists must be present
> in the right place (the machine running ssh-add) and the right time."
> intends to be "*at* the right time.", but it's probably better to state
> explicitly "at the time ssh-add is run".
>
> I see ssh-add gets added -H to choose a known_hosts file, good. But the
> text in ssh-add.1 "ssh-add will use the default ssh_config(5) known
> hosts files:", while strictly correct, may make it seem that it will
> somehow parse ~/.ssh/config or /etc/ssh/ssh_config for
> UserKnownHostsFile directives. I suggest
> "ssh-add will use the known hosts files:
> ~/.ssh/known_hosts, ~/.ssh/known_hosts2, /etc/ssh/ssh_known_hosts, and
> /etc/ssh/ssh_known_hosts2, which is the default used by ssh_config(5)"
>
>
>
> A potential issue I see is, given the example:
>
> $ ssh-add -h "perseus@cetus.example.org" \
> -h "scylla.example.org" \
> -h "scylla.example.org>medea@charybdis.example.org" \
> ~/.ssh/id_ed25519
>
> Poseidon is root on cetus, and wants some files that medea saves in
> charybdis.
> When victim logs in as perseus@cetus.example.org (forwarding ssh-
> agent), Poseidon impersonates perseus and logs in to
> poseidon@scylla.example.org *without using this key* (e.g. with
> keyboard-authentication). He is then able to connect to
> medea@charybdis.example.org using the forwarded ssh-agent.

If the target user forwarded their agent to cetus, then the origin
agent would have received a session-bind@ message informing it of this.
Since there are no onward delegations from that host, any attempts to
use keys from there should fail.

> First of all, I think we need to be able to state the source user:
> -h "perseus@scylla.example.org>medea@charybdis.example.org"
> which requires a new field 'string from_username' on
> SSH_AGENT_CONSTRAIN_EXTENSION.

I thought about this, but there is no way to enforce it. The source
username isn't part of any data that ssh-agent can strongly trust
(whereas the destination username is), and the only way the agent could
obtain it is inferring it by the path. However, paths aren't super
trustworthy and the inferrence would be shaky if the user logged in
to the same host as multiple users.

> Finally, two minor nitpicks: a stray backslash in '\public'
> and s/pursues/pursued/

Thanks for the fixes and feedback!

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Please help test recent changes [ In reply to ]
On 06.01.22 23:52, Damien Miller wrote:
> 2. Restricted agent keys.
> This is a large set of changes to add destination- and path-restricted
> keys to ssh-agent. A full writeup is at on the website at
> https://www.openssh.com/agent-restrict.html - I'm interested to hear
> feedback on how this works in practice, UI and things that could be
> improved (as well as bug reports).

Quick introductory remark 1: The text speaks of "italicised" and
"bolded" parts of the syntax definitions, but there seems to be no such
markup within the HTML's '<pre class="proto">' blocks that contain those
fixed-width-font snippets.

QIR2: Haven't got the time, offhand, to actually run tests; I hope to
get at that later. Hence, purely theoretical ranting for now.

---------------

I have to admit that I'm somewhat losing orientation among all the
variations of multi-hop connections that OpenSSH offers by now. To wit:

-------

A. Plain CLI Chaining:

hostA$ ssh -A hostB
hostB$ ssh [ -A ] hostC
[...]

also:

hostA$ ssh -A hostB 'ssh hostC ...'

Out-of-the-box minimal-config-effort way to do it. (Also what we're
bound to see when a third party sets up a "proper" non-GUI jump host
into their networks and gives us access, as it puts config of the second
hop entirely into the jump host and thus *their* hands, but that's
unlikely to be relevant to the topic of agent forwarding, of course.)

-------

B. Tunneling:

hostA$ ssh -D $PORT hostB
hostA$ ssh -o "ProxyCommand $THRU_LCL_SOCKS_AT_$PORT" hostC

(There are variants, like using LocalForward's or some
non-OpenSSH-provided proxy, but I don't see that making for a relevant
difference in *this* discusson.)

We use that one *a lot*, because in order to fully support customers'
systems, we have to access them with browsers as well as per SSH. Our
own new *outgoing*-to-customers jump host is essentially based on such
configs.

-------

C. ControlMaster

D. ProxyJump

Haven't used either much myself, so I'm unclear on relevant details for
the time being. I see ProxyJump recommended in your document, and I hear
that ControlMaster is quite popular in larger sites where a
Nagios/Icinga/... runs checks on target hosts through (multi-hop) SSH
logins (because it wraps the thousands/h of "virtual" SSH logins into a
few actual TCP connections, and thus avoids triggering rate limits all
over the place).

-------

Now, back to the topic at hand: Agent forwarding is unnecessary in
scenario B, and in scenario A, while the agent runs on hostA, all the
automatic maintenance of known_hosts for the hosts you actually *use*
the forwarding for happens on hostB. Yet, having them properly listed in
the known_hosts *on hostA* is vital for the new usage-restrictions
mechanism.

Also, in scenario B, the user will likely know that he's accessing hostC
via hostB, and might try to restrict the key to "hostB>hostC", but hostB
actually remains transparent to the ssh connecting to hostC and the
restriction will fail.

(If someone could pinpoint where known_hosts automaintenance actually
happens in cases C and D, I'd be grateful. Since both are implemented
*exclusively* in OpenSSH AFAIK, there *would* be the remote possibility
of having them automaint known_hosts *both* on the jump host and the
machine running the agent ...)

---------------

Pondering the concepts behind the term "hostnames": Our company doesn't
maintain oodles of internally-visible-only DNS entries. The supporters
typically have a well-padded ~/.ssh/config with lots of entries like, e.g.,

Host CustX-SrvY
HostName 12.34.56.78 # Customer X's public IP
Host CustX-SrvZ
HostName 192.168.76.54 # To be gatewayed through SrvY

(We're used to having to set up a new *server* to replace the old one
for the customers every now and then, so propagating new/changed
IPs/entries by word of mouth works quite well. :-3 )

So, we have a loosely-defined "Host" name, an IP for the "HostName", and
possibly a couple DNS cherries on top, in case OpenSSH makes any
automated lookups. AFAICT it's the "HostName" that becomes the key in
the known_hosts file, and thus, we would have to use *that* in the
"ssh-add -h ..." parameters, too ...

... ugh. Finding and editing *one* entry in .ssh/config when an IP
changes is OK-ish, but sifting through possibly elaborate destination
constraints for every instance where the host may have been chosen to
serve as a jump host ...

I might be missing loads of other people's use cases here, but if an
abstract concept of forwarding constraints were to be introduced in our
company, the most viable approach would IMHO be that of administrative
zones. As in, "this is a cert issued to me by customer X's CA, and I
want it forwarded *only* *via* the known gateways into X's internal
network, so let me markup those in my .ssh/config with 'AuthZone CustX'
and load the cert with 'ssh-add -A CustX $CERTFILE'" ...

(... which *might* be doable with several agents on different ports *as
long as* I do not also have to use my "normal" keypairs to get around
within X's network ...)

Kind regards,
--
Jochen Bern
Systemingenieur

Binect GmbH
Re: Please help test recent changes [ In reply to ]
On 2022-01-07 at 14:07 +1100, Damien Miller wrote:
> On Fri, 7 Jan 2022, ?ngel wrote:
> >
> > I think the document should reference somewhere the more secure
> > option of chaining ssh connections using ProxyJump, that this
> > restriction doesn't apply there and ssh-agent considers such
> > connections as local.
>
> Good point; done :)

Thanks


> > As a further step, I would add the ability to specify wildcard
> > destinations, e.g.
> > ssh-add -h "*.prod.example.com" ~/.ssh/production.key
> >
> > for a key which could be used on any subdomain of prod.example.com,
> > but not anywhere else.
>
> This works already, mostly. The wildcard will be expanded by ssh-add
> to all available hostkeys that match it before the key is added.

That's how I envisioned it would work, as it is converted to hostkeys
on add.



> > It's not mentioned in the document, but I expect that when ssh-add
> > parses
> > restrictions that they support ports as well
> > ssh-add -h "scylla.example.org>medea@charybdis.example.org:2222"
>
> Not really - it might be possible to look up a hostkey with an
> embedded port number, but there's no validation of it by the protocol
> thereafter.

Yes, it would be just a known_hosts lookup. If a host shares their key
on multiple ports, it is effectively the same key for ssh-agent.


> > A potential issue I see is, given the example:
> >
> > $ ssh-add -h "perseus@cetus.example.org" \
> > -h "scylla.example.org" \
> > -h "scylla.example.org>medea@charybdis.example.org" \
> > ~/.ssh/id_ed25519
> >
> > Poseidon is root on cetus, and wants some files that medea saves in
> > charybdis.
> > When victim logs in as perseus@cetus.example.org (forwarding ssh-
> > agent), Poseidon impersonates perseus and logs in to
> > poseidon@scylla.example.org *without using this key* (e.g. with
> > keyboard-authentication). He is then able to connect to
> > medea@charybdis.example.org using the forwarded ssh-agent.
>
> If the target user forwarded their agent to cetus, then the origin
> agent would have received a session-bind@ message informing it of
> this.
> Since there are no onward delegations from that host, any attempts to
> use keys from there should fail.

So, what would the agent (which may have additional keys as well, such
as an unsrestricted id_rsa) do when, after the session-bind "now in
cetus" it receives a session-bind "now in scylla" ?



> > First of all, I think we need to be able to state the source user:
> > -h "perseus@scylla.example.org>
> > medea@charybdis.example.org"
> > which requires a new field 'string from_username' on
> > SSH_AGENT_CONSTRAIN_EXTENSION.
>
> I thought about this, but there is no way to enforce it. The source
> username isn't part of any data that ssh-agent can strongly trust
> (whereas the destination username is), and the only way the agent
> could obtain it is inferring it by the path. However, paths aren't
> super trustworthy and the inferrence would be shaky if the user
> logged in to the same host as multiple users.

The source username for hop N would be the destination username for
hop N-1. On origin we wouldn't really state a source user@host,
although if needed the user could be obtained with getpwuid(getuid())



> Thanks for the fixes and feedback!
>
> -d

You're welcome!


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Please help test recent changes [ In reply to ]
On 1/6/22, 18:29, "Damien Miller" <djm@mindrot.org> wrote:

On Fri, 7 Jan 2022, Morgan, Iain (ARC-TN)[InuTeq, LLC] wrote:

> Hi Damien,
>
> The restricted agent keys functionality sounds really interesting.
> Are there any plans to support embedding the restrictions in the keys
> themselves at some point? That would make this much easier to use, but
> it would require extending the key format and adding the appropriate
> parsing in ssh-agent or ssh-add.

I hadn't considered that before - how would it envision it working?

Yes, the key format would require extension and that isn't a trivial
change because of backwards-compatibility :(

-d

I haven't given the details much thought and haven't delved into the OpenSSH code in quite a while, so my idea is rather sketchy at this point.

What we would want is some way of associating the restrictions with a key so that they are automatically applied when the key is loaded into the agent, either by ssh-add or when triggered by AddKeysToAgent. That would either mean adding the restrictions to the private key, or adding another file that is associated with the key which contains the restrictions. The latter would be easier to implement from a backwards-compatibility standpoint, but I'm not particularly happy about adding another file type.

The file containing the options would be assumed to be in the same directory as the private key, and would be formed by adding an extension such as ".opts" or ".cfg" to the name of the private key.

I don't have any specific ideas as to how to express the restrictions, but we would probably want one line for each allowed path. Also, the ssh-add command line should be able to override the restrictions. Perhaps the syntax might be something like:

AllowedPath: foo.example.com > bar.example.com ...

Alternatively, perhaps it would be possible to include the restrictions as plain-text in the private key, before the "-----BEGIN" line. That assumes that any text outside of the BEGIN ... END sequence is ignored by existing implementations.

As an aside, either approach should allow for adding support for other kinds of restrictions. For example, it might be convenient to add a Timeout parameter that would correspond to the -t option with ssh-add.

--
Iain

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Please help test recent changes [ In reply to ]
On 2022-01-07 at 18:51 +0000, Morgan, Iain (ARC-TN)[InuTeq, LLC] wrote:
> What we would want is some way of associating the restrictions with a
> key so that they are automatically applied when the key is loaded
> into the agent, either by ssh-add or when triggered by
> AddKeysToAgent. That would either mean adding the restrictions to the
> private key, or adding another file that is associated with the key
> which contains the restrictions. The latter would be easier to
> implement from a backwards-compatibility standpoint, but I'm not
> particularly happy about adding another file type.
>
> The file containing the options would be assumed to be in the same
> directory as the private key, and would be formed by adding an
> extension such as ".opts" or ".cfg" to the name of the private key.
>
> I don't have any specific ideas as to how to express the
> restrictions, but we would probably want one line for each allowed
> path. Also, the ssh-add command line should be able to override the
> restrictions. Perhaps the syntax might be something like:
>
> AllowedPath: foo.example.com > bar.example.com ...
>
> Alternatively, perhaps it would be possible to include the
> restrictions as plain-text in the private key, before the "-----
> BEGIN" line. That assumes that any text outside of the BEGIN ... END
> sequence is ignored by existing implementations.
>
> As an aside, either approach should allow for adding support for
> other kinds of restrictions. For example, it might be convenient to
> add a Timeout parameter that would correspond to the -t option with
> ssh-add.
>
> --
> Iain

Good point. A key should probably always have the same restrictions
(after some testing to get those right).

I would include them as armor headers, though:

-----BEGIN ALGO PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,AABBCC...
Destination-constraint: perseus@cetus.example.org
Destination-constraint: scylla.example.org
Destination-constraint: scylla.example.org>medea@charybdis.example.orgscylla.example.org

SGVsbG8gd29ybGQhCg...


I don't think backwards compatibility of the private key is a concern
here. You already need an updated openssh stack to make use of the new
features, and copying private keys between systems isn't generally a
good idea (it's better to have a different key per source host).

Nonetheless, by placing these headers at the end, they seem to be
ignored by prior ssh-add versions (placing them before Proc-Type or
DEK-Info cause "invalid format" errors).


Best regards



_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Please help test recent changes [ In reply to ]
On 09.01.2022 15:56, Ángel wrote:
>On 2022-01-07 at 18:51 +0000, Morgan, Iain (ARC-TN)[InuTeq, LLC] wrote:
>> What we would want is some way of associating the restrictions with a
>> key so that they are automatically applied when the key is loaded
>> into the agent, either by ssh-add or when triggered by
>> AddKeysToAgent. That would either mean adding the restrictions to the
>> private key, or adding another file that is associated with the key
>> which contains the restrictions. The latter would be easier to
>> implement from a backwards-compatibility standpoint, but I'm not
>> particularly happy about adding another file type.
>>
>> The file containing the options would be assumed to be in the same
>> directory as the private key, and would be formed by adding an
>> extension such as ".opts" or ".cfg" to the name of the private key.
>>
>> I don't have any specific ideas as to how to express the
>> restrictions, but we would probably want one line for each allowed
>> path. Also, the ssh-add command line should be able to override the
>> restrictions. Perhaps the syntax might be something like:
>>
>> AllowedPath: foo.example.com > bar.example.com ...
>>
>> Alternatively, perhaps it would be possible to include the
>> restrictions as plain-text in the private key, before the "-----
>> BEGIN" line. That assumes that any text outside of the BEGIN ... END
>> sequence is ignored by existing implementations.
>>
>> As an aside, either approach should allow for adding support for
>> other kinds of restrictions. For example, it might be convenient to
>> add a Timeout parameter that would correspond to the -t option with
>> ssh-add.
>>
>> --
>> Iain
>
>Good point. A key should probably always have the same restrictions
>(after some testing to get those right).
>
>I would include them as armor headers, though:
>
>-----BEGIN ALGO PRIVATE KEY-----
>Proc-Type: 4,ENCRYPTED
>DEK-Info: AES-128-CBC,AABBCC...
>Destination-constraint: perseus@cetus.example.org
>Destination-constraint: scylla.example.org
>Destination-constraint: scylla.example.org>medea@charybdis.example.orgscylla.example.org
>
>SGVsbG8gd29ybGQhCg...
>

I think the trend is (and should be) going towards keeping private keys in
hardware tokens and no longer in files on disk. FIDO, PIV Smartcards, GPG
Smartcards, HSMs, TPMs all allow for very safe private key storage. If you
allow these constraints to be specified in a config file either referenced
under a key fingerprint (probably easiest):

Key SHA:256INGERPRINT:
DestinationConstraint: perseus@cetus.example.org
DestinationConstraint: scylla.example.org
DestinationConstraint:
scylla.example.org>medea@charybdis.example.orgscylla.example.org

Or maybe under a Host section:
Host cetus.example.org
ForwardAgent yes
ForwardKey SHA256:xxx
ForwardKeyConstraint scylla.example.org

then you can still auto load these instead of writing ssh-add scripts. I
think most ssh users who would use this feature probably already have some
mechanism of managing their .ssh/config.

>
>I don't think backwards compatibility of the private key is a concern
>here. You already need an updated openssh stack to make use of the new
>features, and copying private keys between systems isn't generally a
>good idea (it's better to have a different key per source host).
>
>Nonetheless, by placing these headers at the end, they seem to be
>ignored by prior ssh-add versions (placing them before Proc-Type or
>DEK-Info cause "invalid format" errors).
>
>
>Best regards
>
>
>
>_______________________________________________
>openssh-unix-dev mailing list
>openssh-unix-dev@mindrot.org
>https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Please help test recent changes [ In reply to ]
On Mon, Jan 10, 2022 at 7:51 AM Fabian Stelzer <fs@gigacodes.de> wrote:
>
> On 09.01.2022 15:56, Ángel wrote:
> >On 2022-01-07 at 18:51 +0000, Morgan, Iain (ARC-TN)[InuTeq, LLC] wrote:
> >> What we would want is some way of associating the restrictions with a
> >> key so that they are automatically applied when the key is loaded
> >> into the agent, either by ssh-add or when triggered by
> >> AddKeysToAgent. That would either mean adding the restrictions to the
> >> private key, or adding another file that is associated with the key
> >> which contains the restrictions. The latter would be easier to
> >> implement from a backwards-compatibility standpoint, but I'm not
> >> particularly happy about adding another file type.
> >>
> >> The file containing the options would be assumed to be in the same
> >> directory as the private key, and would be formed by adding an
> >> extension such as ".opts" or ".cfg" to the name of the private key.
> >>
> >> I don't have any specific ideas as to how to express the
> >> restrictions, but we would probably want one line for each allowed
> >> path. Also, the ssh-add command line should be able to override the
> >> restrictions. Perhaps the syntax might be something like:
> >>
> >> AllowedPath: foo.example.com > bar.example.com ...
> >>
> >> Alternatively, perhaps it would be possible to include the
> >> restrictions as plain-text in the private key, before the "-----
> >> BEGIN" line. That assumes that any text outside of the BEGIN ... END
> >> sequence is ignored by existing implementations.
> >>
> >> As an aside, either approach should allow for adding support for
> >> other kinds of restrictions. For example, it might be convenient to
> >> add a Timeout parameter that would correspond to the -t option with
> >> ssh-add.
> >>
> >> --
> >> Iain
> >
> >Good point. A key should probably always have the same restrictions
> >(after some testing to get those right).
> >
> >I would include them as armor headers, though:
> >
> >-----BEGIN ALGO PRIVATE KEY-----
> >Proc-Type: 4,ENCRYPTED
> >DEK-Info: AES-128-CBC,AABBCC...
> >Destination-constraint: perseus@cetus.example.org
> >Destination-constraint: scylla.example.org
> >Destination-constraint: scylla.example.org>medea@charybdis.example.orgscylla.example.org
> >
> >SGVsbG8gd29ybGQhCg...
> >
>
> I think the trend is (and should be) going towards keeping private keys in
> hardware tokens and no longer in files on disk. FIDO, PIV Smartcards, GPG
> Smartcards, HSMs, TPMs all allow for very safe private key storage. If you
> allow these constraints to be specified in a config file either referenced
> under a key fingerprint (probably easiest):

There are many trends Many, many tools and systems rely on old
features and would break very badly indeed if support for private keys
is lost. And there are some features of locally stured keys, such as
using multiple keys simultaneously to provide signed keys such as
those supported by Hashicorp Vault, that do not work well with other
key storage formats
(https://www.vaultproject.io/docs/secrets/ssh/signed-ssh-certificates
)

> Key SHA:256INGERPRINT:
> DestinationConstraint: perseus@cetus.example.org
> DestinationConstraint: scylla.example.org
> DestinationConstraint:
> scylla.example.org>medea@charybdis.example.orgscylla.example.org
>
> Or maybe under a Host section:
> Host cetus.example.org
> ForwardAgent yes
> ForwardKey SHA256:xxx
> ForwardKeyConstraint scylla.example.org
>
> then you can still auto load these instead of writing ssh-add scripts. I
> think most ssh users who would use this feature probably already have some
> mechanism of managing their .ssh/config.

For keys such as signed SSH certificates, I'd want to support
providing multiple forwarding keys. I'm not working with those
personally right now, but the linking of only single keyes to SSH
access inerferes with the otherwise supported signed key access.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Please help test recent changes [ In reply to ]
On 10.01.2022 08:07, Nico Kadel-Garcia wrote:
>On Mon, Jan 10, 2022 at 7:51 AM Fabian Stelzer <fs@gigacodes.de> wrote:
>>
>> On 09.01.2022 15:56, Ángel wrote:
>> >On 2022-01-07 at 18:51 +0000, Morgan, Iain (ARC-TN)[InuTeq, LLC] wrote:
>> >> What we would want is some way of associating the restrictions with a
>> >> key so that they are automatically applied when the key is loaded
>> >> into the agent, either by ssh-add or when triggered by
>> >> AddKeysToAgent. That would either mean adding the restrictions to the
>> >> private key, or adding another file that is associated with the key
>> >> which contains the restrictions. The latter would be easier to
>> >> implement from a backwards-compatibility standpoint, but I'm not
>> >> particularly happy about adding another file type.
>> >>
>> >> The file containing the options would be assumed to be in the same
>> >> directory as the private key, and would be formed by adding an
>> >> extension such as ".opts" or ".cfg" to the name of the private key.
>> >>
>> >> I don't have any specific ideas as to how to express the
>> >> restrictions, but we would probably want one line for each allowed
>> >> path. Also, the ssh-add command line should be able to override the
>> >> restrictions. Perhaps the syntax might be something like:
>> >>
>> >> AllowedPath: foo.example.com > bar.example.com ...
>> >>
>> >> Alternatively, perhaps it would be possible to include the
>> >> restrictions as plain-text in the private key, before the "-----
>> >> BEGIN" line. That assumes that any text outside of the BEGIN ... END
>> >> sequence is ignored by existing implementations.
>> >>
>> >> As an aside, either approach should allow for adding support for
>> >> other kinds of restrictions. For example, it might be convenient to
>> >> add a Timeout parameter that would correspond to the -t option with
>> >> ssh-add.
>> >>
>> >> --
>> >> Iain
>> >
>> >Good point. A key should probably always have the same restrictions
>> >(after some testing to get those right).
>> >
>> >I would include them as armor headers, though:
>> >
>> >-----BEGIN ALGO PRIVATE KEY-----
>> >Proc-Type: 4,ENCRYPTED
>> >DEK-Info: AES-128-CBC,AABBCC...
>> >Destination-constraint: perseus@cetus.example.org
>> >Destination-constraint: scylla.example.org
>> >Destination-constraint: scylla.example.org>medea@charybdis.example.orgscylla.example.org
>> >
>> >SGVsbG8gd29ybGQhCg...
>> >
>>
>> I think the trend is (and should be) going towards keeping private keys in
>> hardware tokens and no longer in files on disk. FIDO, PIV Smartcards, GPG
>> Smartcards, HSMs, TPMs all allow for very safe private key storage. If you
>> allow these constraints to be specified in a config file either referenced
>> under a key fingerprint (probably easiest):
>
>There are many trends Many, many tools and systems rely on old
>features and would break very badly indeed if support for private keys
>is lost. And there are some features of locally stured keys, such as
>using multiple keys simultaneously to provide signed keys such as
>those supported by Hashicorp Vault, that do not work well with other
>key storage formats
>(https://www.vaultproject.io/docs/secrets/ssh/signed-ssh-certificates
>)

I'm not suggesting loosing support for locally stored keys. I only would
like to encourage a feature to store these key constraints to be compatible
with both variants of private key storage. (which a separate config
file/header would be)

I don't have an example of using multiple private keys for a signature, but
I don't see any reason why those should not also work with key stored in
hardware. If the current tool works with an ssh-agent then hardware keys
should work just as well.

>
>> Key SHA:256INGERPRINT:
>> DestinationConstraint: perseus@cetus.example.org
>> DestinationConstraint: scylla.example.org
>> DestinationConstraint:
>> scylla.example.org>medea@charybdis.example.orgscylla.example.org
>>
>> Or maybe under a Host section:
>> Host cetus.example.org
>> ForwardAgent yes
>> ForwardKey SHA256:xxx
>> ForwardKeyConstraint scylla.example.org
>>
>> then you can still auto load these instead of writing ssh-add scripts. I
>> think most ssh users who would use this feature probably already have some
>> mechanism of managing their .ssh/config.
>
>For keys such as signed SSH certificates, I'd want to support
>providing multiple forwarding keys. I'm not working with those
>personally right now, but the linking of only single keyes to SSH
>access inerferes with the otherwise supported signed key access.

These config blocks were just an example of how this could look like.
Both could allow multiple keys if needed. (Maybe you could even constrain to
all keys signed by CA XXX).

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Please help test recent changes [ In reply to ]
Quoting Damien Miller (2022-01-06 23:52:09)
> 2. Restricted agent keys.
>
> This is a large set of changes to add destination- and path-restricted
> keys to ssh-agent. A full writeup is at on the website at
> https://www.openssh.com/agent-restrict.html - I'm interested to hear
> feedback on how this works in practice, UI and things that could be
> improved (as well as bug reports).

Can this be made to work when SSHFP host verification is used
(VerifyHostKeyDNS=yes) rather than known_hosts?

Otherwise this is great news - I've largely replaced my old key with a
FIDO token and one of the annoyances is the confirmation window not
telling me which host is it for.

--
Anton Khirnov
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Please help test recent changes [ In reply to ]
On Jan 7 09:52, Damien Miller wrote:
> Hi,
>
> We've landed some fairly significant changes in OpenSSH recently and
> would appreciate your help in testing them. The biggest of the changes
> are:
>
> 1. Conversion of the ssh and sshd mainloop from select() to poll()
>
> This should be entirely invisible to users, so any behaviour change
> is a bug. If you see something and want to help debug it further,
> uncomment the DEBUG_CHANNEL_POLL #define in channels.c for helps of
> extra debug logging.
>
> 2. Restricted agent keys.
>
> This is a large set of changes to add destination- and path-restricted
> keys to ssh-agent. A full writeup is at on the website at
> https://www.openssh.com/agent-restrict.html - I'm interested to hear
> feedback on how this works in practice, UI and things that could be
> improved (as well as bug reports).
>
> 3. Running down the remaining RSA/SHA2 corner-cases
>
> There has been a fair bit of work to identify and fix the remaining
> cases where various things behaved badly wrt RSA signature algorithms.
> Recent fixes include hostbased authentication and UpdateHostkeys.
> Again, [almost] any change in visible behaviour here is a bug.
>
> All of these changes are in git and will be in tomorrow's snapshot
> (20220108).

Took me a while but today I tested this on recent Cygwin. The testsuite
fails at one point:

run test hostkey-agent.sh ...
[...]
cert type sk-ssh-ed25519-cert-v01@openssh.com
cert type sk-ssh-ed25519-cert-v01@openssh.com failed
bad SSH_CONNECTION key type sk-ssh-ed25519-cert-v01@openssh.com
[...]
bad SSH_CONNECTION key type sk-ecdsa-sha2-nistp256-cert-v01@openssh.com
failed hostkey agent

Looking into cat failed-sshd.log I notice this message for *all*
agent-key.*.pub files:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/corinna/tmp/openssh/regress/agent-key.ecdsa-sha2-nistp256.pub' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Unable to load host key "/home/corinna/tmp/openssh/regress/agent-key.ecdsa-sha2-nistp256.pub": bad permissions

Shouldn't the testsuite have generated the files with correct permissions
in the first place? And then again, these are PUB files. Shouldn't
a 644 permission suffice?


Corinna

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Please help test recent changes [ In reply to ]
On Fri, 21 Jan 2022 at 06:33, Corinna Vinschen <vinschen@redhat.com> wrote:

> [...]
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @ WARNING: UNPROTECTED PRIVATE KEY FILE! @
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> Permissions 0644 for
> '/home/corinna/tmp/openssh/regress/agent-key.ecdsa-sha2-nistp256.pub' are
> too open.
> It is required that your private key files are NOT accessible by others.
> This private key will be ignored.
> Unable to load host key
> "/home/corinna/tmp/openssh/regress/agent-key.ecdsa-sha2-nistp256.pub": bad
> permissions
>
> Shouldn't the testsuite have generated the files with correct permissions
> in the first place? And then again, these are PUB files. Shouldn't
> a 644 permission suffice?
>

I've seen this in the past where the test had cached keys of a type that
the current binaries do not support (eg because the new binaries were
configured without openssl). I think it's because the key code tries the
.pub file when the private key file fails to load. Maybe retry in a
clean directory?

--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Please help test recent changes [ In reply to ]
Hi Darren,

On Jan 21 18:55, Darren Tucker wrote:
> On Fri, 21 Jan 2022 at 06:33, Corinna Vinschen <vinschen@redhat.com> wrote:
>
> > [...]
> > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> > @ WARNING: UNPROTECTED PRIVATE KEY FILE! @
> > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> > Permissions 0644 for
> > '/home/corinna/tmp/openssh/regress/agent-key.ecdsa-sha2-nistp256.pub' are
> > too open.
> > It is required that your private key files are NOT accessible by others.
> > This private key will be ignored.
> > Unable to load host key
> > "/home/corinna/tmp/openssh/regress/agent-key.ecdsa-sha2-nistp256.pub": bad
> > permissions
> >
> > Shouldn't the testsuite have generated the files with correct permissions
> > in the first place? And then again, these are PUB files. Shouldn't
> > a 644 permission suffice?
> >
>
> I've seen this in the past where the test had cached keys of a type that
> the current binaries do not support (eg because the new binaries were
> configured without openssl). I think it's because the key code tries the
> .pub file when the private key file fails to load. Maybe retry in a
> clean directory?

I was building and testing in a clean dir from scratch. I cleaned out
the regress subdir, keeping only Makefile, and started the test again
with LTESTS=hostkey-agent but the failure

bad SSH_CONNECTION key type sk-ssh-ed25519-cert-v01@openssh.com

is reproducible. The failed-ssh.log file contains

debug1: kex: host key algorithm: (no match)^M
Unable to negotiate with UNKNOWN port 65535: no matching host key type found. Their offer: ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com^M
FAIL: cert type sk-ecdsa-sha2-nistp256-cert-v01@openssh.com failed
FAIL: bad SSH_CONNECTION key type sk-ecdsa-sha2-nistp256-cert-v01@openssh.com

All other key types work fine, though. The "WARNING: UNPROTECTED
PRIVATE KEY FILE!" messages are the same, though. I attached the
"failed-*.log" files.

All other tests of the testsuite are either skipped (platform dependent)
or succeed.


Thanks,
Corinna
Re: Please help test recent changes [ In reply to ]
On Fri, 21 Jan 2022 at 20:46, Corinna Vinschen <vinschen@redhat.com> wrote:

> [...]
> I was building and testing in a clean dir from scratch. I cleaned out
> the regress subdir, keeping only Makefile, and started the test again
> with LTESTS=hostkey-agent but the failure
>

Did you have any configure flags or anything else in the environment? I
just updated a win10 VM to the current Cygwin (OpenSSL 1.1.1l 24 Aug 2021)
and ran

$ git clone https://anongit.mindrot.org/openssh.git && cd openssh &&
autoreconf && ./configure && make t-exec LTESTS=hostkey-agent

which passed (with the TEST_SSH_UNSAFE_PERMISSIONS warning). Repeating
with TEST_SSH_UNSAFE_PERMISSIONS=1 removed the warning, but both passed
regardless. I don't think I have anything special in my build environment.

--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Please help test recent changes [ In reply to ]
On Jan 21 21:32, Darren Tucker wrote:
> On Fri, 21 Jan 2022 at 20:46, Corinna Vinschen <vinschen@redhat.com> wrote:
>
> > [...]
> > I was building and testing in a clean dir from scratch. I cleaned out
> > the regress subdir, keeping only Makefile, and started the test again
> > with LTESTS=hostkey-agent but the failure
> >
>
> Did you have any configure flags or anything else in the environment? I
> just updated a win10 VM to the current Cygwin (OpenSSL 1.1.1l 24 Aug 2021)
> and ran

Yes, I used the following flags:

--with-kerberos5
--with-libedit
--with-xauth=/usr/bin/xauth
--enable-etc-default-login

I just noticed that these are not exactly the flags used to create the
distro OpenSSH package. Apparently I used an older configure flag
set. The distro package uses (apart from certain installation paths)

--with-kerberos5=/usr
--with-libedit
--with-xauth=/usr/bin/xauth
--disable-strip
--without-hardening
--with-security-key-builtin

Let me try again with a complete distro build...

>
> $ git clone https://anongit.mindrot.org/openssh.git && cd openssh &&
> autoreconf && ./configure && make t-exec LTESTS=hostkey-agent
>
> which passed (with the TEST_SSH_UNSAFE_PERMISSIONS warning). Repeating
> with TEST_SSH_UNSAFE_PERMISSIONS=1 removed the warning, but both passed
> regardless. I don't think I have anything special in my build environment.


Thanks,
Corinna

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Please help test recent changes [ In reply to ]
On Jan 21 12:12, Corinna Vinschen wrote:
> On Jan 21 21:32, Darren Tucker wrote:
> > On Fri, 21 Jan 2022 at 20:46, Corinna Vinschen <vinschen@redhat.com> wrote:
> >
> > > [...]
> > > I was building and testing in a clean dir from scratch. I cleaned out
> > > the regress subdir, keeping only Makefile, and started the test again
> > > with LTESTS=hostkey-agent but the failure
> > >
> >
> > Did you have any configure flags or anything else in the environment? I
> > just updated a win10 VM to the current Cygwin (OpenSSL 1.1.1l 24 Aug 2021)
> > and ran
>
> Yes, I used the following flags:
>
> --with-kerberos5
> --with-libedit
> --with-xauth=/usr/bin/xauth
> --enable-etc-default-login
>
> I just noticed that these are not exactly the flags used to create the
> distro OpenSSH package. Apparently I used an older configure flag
> set. The distro package uses (apart from certain installation paths)
>
> --with-kerberos5=/usr
> --with-libedit
> --with-xauth=/usr/bin/xauth
> --disable-strip
> --without-hardening
> --with-security-key-builtin
>
> Let me try again with a complete distro build...

Same problem. The hostkey-agent test is running ssh-sk-helper. Did you
install all the required devel packages, for instance libfido2-devel,
libcbor-devel, libedit-devel, libssl-devel, libkrb5-devel?

I attached my final config.h, maybe that gives a clue?

Thanks,
Corinna