Mailing List Archive

I asked for x448 key exchange support in 2017, and even offered to
write the code for it. The devs didn't want it, citing that they'd
rather add support quantum-resistant exchanges instead. Eventually we
got sntrup761x25519-sha512@openssh.com, which provides 128-bit of
symmetric security.

I'd like sntrup761x448-sha512@openssh.com, which would provide ~256
bits of symmetric security.

--
Joseph S. Testa II
Founder & Principal Security Consultant
Positron Security

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Some time ago I made a proposal to add a mechanism that would allow a
hook to be executed whenever an unsuccessful login attempt was made:
https://bugzilla.mindrot.org/show_bug.cgi?id=3384.

The idea was to manage a blacklist to lock out hosts that repeatedly
attempted to login by trying common passwords. Unfortunately, I could
not get much attention and gave up on it.

Thomas

Am 18.10.23 um 19:13 schrieb Chris Rapier:
> Hey all,
>
> So I do some development based on openssh and I'm trying to think of
> some new projects that might extend the functionality, feature set, user
> workflow, performance, etc of ssh.
>
> So open ended question:
>
> Do any of you have a wish list of things you'd like to see in ssh?
>
>
> Mostly I'm just curious to see what the larger community is thinking of
> rather than being driven entirely by what I think is cool.
>
>
> Chris
> _______________________________________________
> 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

That's a good idea but I think fail2ban might be a better solution to
this than extending the application itself. The main issue being that
maintaining and managing a blocklist like that within ssh might be
cumbersome in large organizations.

On 10/18/23 1:42 PM, Thomas Köller wrote:
> Some time ago I made a proposal to add a mechanism that would allow a
> hook to be executed whenever an unsuccessful login attempt was made:
> https://bugzilla.mindrot.org/show_bug.cgi?id=3384.
>
> The idea was to manage a blacklist to lock out hosts that repeatedly
> attempted to login by trying common passwords. Unfortunately, I could
> not get much attention and gave up on it.
>
> Thomas
>
> Am 18.10.23 um 19:13 schrieb Chris Rapier:
>> Hey all,
>>
>> So I do some development based on openssh and I'm trying to think of
>> some new projects that might extend the functionality, feature set,
>> user workflow, performance, etc of ssh.
>>
>> So open ended question:
>>
>> Do any of you have a wish list of things you'd like to see in ssh?
>>
>>
>> Mostly I'm just curious to see what the larger community is thinking
>> of rather than being driven entirely by what I think is cool.
>>
>>
>> Chris
>> _______________________________________________
>> 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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Am 18.10.23 um 20:12 schrieb Chris Rapier:
> That's a good idea but I think fail2ban might be a better solution to
> this than extending the application itself. The main issue being that
> maintaining and managing a blocklist like that within ssh might be
> cumbersome in large organizations.

AFAIK fail2ban works by scanning through the logs periodically, which
IMO is a really clumsy solution.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

If one does add such a plugin, it should be in a place where it can delay for an exponentially increasing time (or return a delay time to SSH). You don’t want to just reject the login, because they might keep hammering you.

From: openssh-unix-dev <openssh-unix-dev-bounces+herbie.robinson=stratus.com@mindrot.org> On Behalf Of Chris Rapier
Sent: Wednesday, October 18, 2023 2:12 PM
To: openssh-unix-dev@mindrot.org
Subject: [EXTERNAL] Re: ssh wish list?

[.EXTERNAL SENDER: This email originated from outside of Stratus Technologies. Do not click links or open attachments unless you recognize the sender and know the content is safe.]

That's a good idea but I think fail2ban might be a better solution to
this than extending the application itself. The main issue being that
maintaining and managing a blocklist like that within ssh might be
cumbersome in large organizations.

On 10/18/23 1:42 PM, Thomas Köller wrote:
> Some time ago I made a proposal to add a mechanism that would allow a
> hook to be executed whenever an unsuccessful login attempt was made:
> https://bugzilla.mindrot.org/show_bug.cgi?id=3384<https://bugzilla.mindrot.org/show_bug.cgi?id=3384>.
>
> The idea was to manage a blacklist to lock out hosts that repeatedly
> attempted to login by trying common passwords. Unfortunately, I could
> not get much attention and gave up on it.
>
> Thomas
>
> Am 18.10.23 um 19:13 schrieb Chris Rapier:
>> Hey all,
>>
>> So I do some development based on openssh and I'm trying to think of
>> some new projects that might extend the functionality, feature set,
>> user workflow, performance, etc of ssh.
>>
>> So open ended question:
>>
>> Do any of you have a wish list of things you'd like to see in ssh?
>>
>>
>> Mostly I'm just curious to see what the larger community is thinking
>> of rather than being driven entirely by what I think is cool.
>>
>>
>> Chris
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev@mindrot.org<mailto:openssh-unix-dev@mindrot.org>
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev<https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev>
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org<mailto:openssh-unix-dev@mindrot.org>
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev<https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org<mailto:openssh-unix-dev@mindrot.org>
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev<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

Chris Rapier wrote in
<9b9c0475-7c4f-468a-b6bf-7921fb5e276c@psc.edu>:
|So I do some development based on openssh and I'm trying to think of
|some new projects that might extend the functionality, feature set, user
|workflow, performance, etc of ssh.

Despite my own two year old SIGUSR1 for ssh-agent that i rebase
all the time.

SSH over UDP (or "any other non-stream", or "auto-connection-re-
establish" protocol). I do not know how it can work for you all
if you have internet access via wlan; maybe ipsec is also an
option, i do not use it as i am afraid of the setup (on all end
points; there is that interesting thing for OpenBSD, but i never
heard anything real again -- and OpenBSD only of course), and
WireGuard does this really nicely!
Yes i am thankful for the UDP based WireGuard, it improved my SSH
experience tremendously, as eventual "reconnections" are not seen
by OpenSSH at all, it is only the timeouts that keep on ticking.

As WG also then bypasses the normal FILTER firewall once
a connection is established, i can use super strict firewalling
rules on the freely chosen ports WG listens on. This did not work
out with plain SSH even with ControlMaster as after connection
break you, well, have to re-establish a TCP connection, thus
counting against the limit.
(I mean i do have a port-knocking thing that whitelists me for 30
seconds, NOW, before it only could remove all occurrances of the
remote IP from all firewall lists. Now i simply can thereafter
use WG (wg show XX dump) to whitelist in an early "table" any
client that successfully connected (in the last X seconds). What
a relieve!)

Now the only thing that remains is that ~60 second connection
limit for OpenBSD downloads on their main server, since with
64KBit you cannot even download the openssh ball within.

Thank you.

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

Am 18.10.23 um 20:37 schrieb Robinson, Herbie:
> If one does add such a plugin, it should be in a place where it can delay for an exponentially increasing time (or return a delay time to SSH). You don’t want to just reject the login, because they might keep hammering you.

The patch I proposed just invokes an external program on every failed
login attempt detected. I does not implement any policy. And if the
offending host is blocked, by modifying firewall rules or similar, there
could be no hammering.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

I get that. We use fail2ban here because we've a number of ways people
can connect to our systems so we needed something that was more
flexible. It's also nice that it just bans the IP so it can't keep
hammering the service.

I think it depends on your use case. That said, I understand why some
people might not want to use yet another process when all they are
trying to do is ban people spamming your sshd process. No promises but
we can look into it. I don't think the actually banning part would be
all that hard. It's everything that goes along with it in terms of
managing things and making sure it would be performant enough in high
volume scenarios.

On 10/18/23 2:34 PM, Thomas Köller wrote:
> Am 18.10.23 um 20:12 schrieb Chris Rapier:
>> That's a good idea but I think fail2ban might be a better solution to
>> this than extending the application itself. The main issue being that
>> maintaining and managing a blocklist like that within ssh might be
>> cumbersome in large organizations.
>
> AFAIK fail2ban works by scanning through the logs periodically, which
> IMO is a really clumsy solution.
> _______________________________________________
> 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

Chris Rapier wrote in
<98ef47a5-b8d3-4677-acb6-ed424627c820@psc.edu>:
|I get that. We use fail2ban here because we've a number of ways people
|can connect to our systems so we needed something that was more
|flexible. It's also nice that it just bans the IP so it can't keep
|hammering the service.
|
|I think it depends on your use case. That said, I understand why some
|people might not want to use yet another process when all they are
|trying to do is ban people spamming your sshd process. No promises but
|we can look into it. I don't think the actually banning part would be
|all that hard. It's everything that goes along with it in terms of
|managing things and making sure it would be performant enough in high
|volume scenarios.

No need to look, blacklist now blocklist daemon of NetBSD and
FreeBSD already have the necessary patch.

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

On 18/10/2023 19:56, Steffen Nurpmeso wrote:
> SSH over UDP (or "any other non-stream", or "auto-connection-re-
> establish" protocol)

These might not meet your needs exactly, but have you looked at 'et'
and/or 'mosh'?

https://eternalterminal.dev/

https://mosh.org/

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

yeah, sounds nice, but doesn't sshguard & fail2ban already read the needed from the log files?

> On 18 Oct 2023, at 19:42, Thomas Köller <thomas@koeller.dyndns.org> wrote:
>
> Some time ago I made a proposal to add a mechanism that would allow a hook to be executed whenever an unsuccessful login attempt was made: https://bugzilla.mindrot.org/show_bug.cgi?id=3384.
>
> The idea was to manage a blacklist to lock out hosts that repeatedly attempted to login by trying common passwords. Unfortunately, I could not get much attention and gave up on it.
>
> Thomas
>
> Am 18.10.23 um 19:13 schrieb Chris Rapier:
>> Hey all,
>> So I do some development based on openssh and I'm trying to think of some new projects that might extend the functionality, feature set, user workflow, performance, etc of ssh.
>> So open ended question:
>> Do any of you have a wish list of things you'd like to see in ssh?
>> Mostly I'm just curious to see what the larger community is thinking of rather than being driven entirely by what I think is cool.
>> Chris
>> _______________________________________________
>> 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

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 10/18/23 2:56 PM, Steffen Nurpmeso wrote:
> Chris Rapier wrote in
> <9b9c0475-7c4f-468a-b6bf-7921fb5e276c@psc.edu>:
> |So I do some development based on openssh and I'm trying to think of
> |some new projects that might extend the functionality, feature set, user
> |workflow, performance, etc of ssh.
>
> Despite my own two year old SIGUSR1 for ssh-agent that i rebase
> all the time.
>
> SSH over UDP (or "any other non-stream", or "auto-connection-re-
> establish" protocol). I do not know how it can work for you all
> if you have internet access via wlan; maybe ipsec is also an
> option, i do not use it as i am afraid of the setup (on all end
> points; there is that interesting thing for OpenBSD, but i never
> heard anything real again -- and OpenBSD only of course), and
> WireGuard does this really nicely!
> Yes i am thankful for the UDP based WireGuard, it improved my SSH
> experience tremendously, as eventual "reconnections" are not seen
> by OpenSSH at all, it is only the timeouts that keep on ticking.

We have been looking at implementing different protocols other than TCP.
QUIC, for example, looks promising. We're mostly looking at that for
throughput performance though. I don't know if that would work in your
specific use case though.


> Now the only thing that remains is that ~60 second connection
> limit for OpenBSD downloads on their main server, since with
> 64KBit you cannot even download the openssh ball within.

Your throughput is limited to 64Kbps? Is that a limitation of wireguard
or some other issue?
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

I only mentioned this, because if the plugin chose to implement a long sleep, it could break other things in ssh (depending on where it is inserted). If the plugin returns that it would like a certain delay, than SSH can implement the delay and adjust any relevant timeouts. The alternative would be to document whether or not the plug-in is allowed to sleep.

From: openssh-unix-dev <openssh-unix-dev-bounces+herbie.robinson=stratus.com@mindrot.org> On Behalf Of Thomas Köller
Sent: Wednesday, October 18, 2023 3:00 PM
To: openssh-unix-dev@mindrot.org
Subject: Re: [EXTERNAL] Re: ssh wish list?

[.EXTERNAL SENDER: This email originated from outside of Stratus Technologies. Do not click links or open attachments unless you recognize the sender and know the content is safe.]

Am 18.10.23 um 20:37 schrieb Robinson, Herbie:
> If one does add such a plugin, it should be in a place where it can delay for an exponentially increasing time (or return a delay time to SSH). You don’t want to just reject the login, because they might keep hammering you.

The patch I proposed just invokes an external program on every failed
login attempt detected. I does not implement any policy. And if the
offending host is blocked, by modifying firewall rules or similar, there
could be no hammering.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

So what if this was done as a PAM module? That would :

a) reduce the code that the openssh dev team needs to maintain as it
doesn't really touch ssh at all
b) reduces code complexity, path breaking, etc.
c) is self contained and optional for those that really want it.



On 10/18/23 4:03 PM, Robinson, Herbie wrote:
> I only mentioned this, because if the plugin chose to implement a long sleep, it could break other things in ssh (depending on where it is inserted). If the plugin returns that it would like a certain delay, than SSH can implement the delay and adjust any relevant timeouts. The alternative would be to document whether or not the plug-in is allowed to sleep.
>
> From: openssh-unix-dev <openssh-unix-dev-bounces+herbie.robinson=stratus.com@mindrot.org> On Behalf Of Thomas Köller
> Sent: Wednesday, October 18, 2023 3:00 PM
> To: openssh-unix-dev@mindrot.org
> Subject: Re: [EXTERNAL] Re: ssh wish list?
>
> [.EXTERNAL SENDER: This email originated from outside of Stratus Technologies. Do not click links or open attachments unless you recognize the sender and know the content is safe.]
>
> Am 18.10.23 um 20:37 schrieb Robinson, Herbie:
>> If one does add such a plugin, it should be in a place where it can delay for an exponentially increasing time (or return a delay time to SSH). You don’t want to just reject the login, because they might keep hammering you.
>
> The patch I proposed just invokes an external program on every failed
> login attempt detected. I does not implement any policy. And if the
> offending host is blocked, by modifying firewall rules or similar, there
> could be no hammering.
>
> _______________________________________________
> 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

Am 18.10.23 um 22:31 schrieb Chris Rapier:
> So what if this was done as a PAM module? That would :
>
> a) reduce the code that the openssh dev team needs to maintain as it
> doesn't really touch ssh at all
> b) reduces code complexity, path breaking, etc.
> c) is self contained and optional for those that really want it.

The decision whether to accept or reject a login attempt is made by sshd
internally without consulting PAM at all, certainly if user
authentication is not by password but by public key or some other
mechanism. For details, see my patch, which also contains some
documentation.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Brian Candler wrote in
<6219db42-5a0e-4fe5-a38d-ad9ba2d13a2b@pobox.com>:
|On 18/10/2023 19:56, Steffen Nurpmeso wrote:
|> SSH over UDP (or "any other non-stream", or "auto-connection-re-
|> establish" protocol)
|
|These might not meet your needs exactly, but have you looked at 'et'
|and/or 'mosh'?
|
|https://eternalterminal.dev/
|
|https://mosh.org/

Yes i did, maybe 2015 or so, or even earlier.
I am really fine with WireGuard now, and have anything composed
around, or better through it. Except for the very rare situations
where i cannot, of course.

--End of <6219db42-5a0e-4fe5-a38d-ad9ba2d13a2b@pobox.com>

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

Chris Rapier wrote in
<8e8c9940-4b65-448b-8290-336da1299cdf@psc.edu>:
|On 10/18/23 2:56 PM, Steffen Nurpmeso wrote:
|> Chris Rapier wrote in
|> <9b9c0475-7c4f-468a-b6bf-7921fb5e276c@psc.edu>:
|>|So I do some development based on openssh and I'm trying to think of
|>|some new projects that might extend the functionality, feature set, user
|>|workflow, performance, etc of ssh.
...
|> SSH over UDP (or "any other non-stream", or "auto-connection-re-
|> establish" protocol). I do not know how it can work for you all
|> if you have internet access via wlan; maybe ipsec is also an
|> option, i do not use it as i am afraid of the setup (on all end
|> points; there is that interesting thing for OpenBSD, but i never
|> heard anything real again -- and OpenBSD only of course), and
|> WireGuard does this really nicely!
...
|We have been looking at implementing different protocols other than TCP.
|QUIC, for example, looks promising. We're mostly looking at that for

Yes. Yes, that.

|throughput performance though. I don't know if that would work in your
|specific use case though.

Sure it would. OpenSSL put a lot of efforts to have a complete
implementation, as far as i know, and OpenBSD also reported
a success-over-QUIC, but i looked even less. But that comes.

|> Now the only thing that remains is that ~60 second connection
|> limit for OpenBSD downloads on their main server, since with
|> 64KBit you cannot even download the openssh ball within.
|
|Your throughput is limited to 64Kbps? Is that a limitation of wireguard
|or some other issue?

Only when the bandwidth is out. Or when sharing in between many
breaks down the thing. Or when that whoever it is bombs the
neighbourhood with electromagnetic storms so that anything
wireless inclusive DVB-T. The former two happen quite frequently.
'Don't think WireGuard is a resource hog or bandwidth killer from
what i know. But i never have done performance testing.

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

On Wed, Oct 18, 2023 at 03:05:20PM -0400, Chris Rapier wrote:

[snip]

> I don't think the actually banning part would be all that hard. It's
> everything that goes along with it in terms of managing things and making
> sure it would be performant enough in high volume scenarios.

I've tried hard to not jump in here and (obviously) failed.

At the risk of protracting an already overlong sub-thread on this topic,
I believe the unstated assumption (from my perspective) being missed
behind this feature request is that fail2ban and others would move to
this new API, and not use logs anymore -- not that openssh grows fail2ban
features. In a perfect world this means there's a new, stable API that
all the fail2ban-alikes and local programs use, and the ssh project can
be free to modify log output without worrying about breaking every
security stack.

Whether or not that is true is a different issue, as is the stability of
the log message format "de-facto API".

(this time actually out, for real)
paultag

--
:wq
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

In no particular order my wishlist would be:

- Support for the final PQC candidates NIST choose
- Having ssh-key based logins consult PAM so that external modules could
make additional judgement calls or update login statistics.

On Wed, Oct 18, 2023 at 2:13?PM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:

> Chris Rapier wrote in
> <8e8c9940-4b65-448b-8290-336da1299cdf@psc.edu>:
> |On 10/18/23 2:56 PM, Steffen Nurpmeso wrote:
> |> Chris Rapier wrote in
> |> <9b9c0475-7c4f-468a-b6bf-7921fb5e276c@psc.edu>:
> |>|So I do some development based on openssh and I'm trying to think of
> |>|some new projects that might extend the functionality, feature set,
> user
> |>|workflow, performance, etc of ssh.
> ...
> |> SSH over UDP (or "any other non-stream", or "auto-connection-re-
> |> establish" protocol). I do not know how it can work for you all
> |> if you have internet access via wlan; maybe ipsec is also an
> |> option, i do not use it as i am afraid of the setup (on all end
> |> points; there is that interesting thing for OpenBSD, but i never
> |> heard anything real again -- and OpenBSD only of course), and
> |> WireGuard does this really nicely!
> ...
> |We have been looking at implementing different protocols other than TCP.
> |QUIC, for example, looks promising. We're mostly looking at that for
>
> Yes. Yes, that.
>
> |throughput performance though. I don't know if that would work in your
> |specific use case though.
>
> Sure it would. OpenSSL put a lot of efforts to have a complete
> implementation, as far as i know, and OpenBSD also reported
> a success-over-QUIC, but i looked even less. But that comes.
>
> |> Now the only thing that remains is that ~60 second connection
> |> limit for OpenBSD downloads on their main server, since with
> |> 64KBit you cannot even download the openssh ball within.
> |
> |Your throughput is limited to 64Kbps? Is that a limitation of wireguard
> |or some other issue?
>
> Only when the bandwidth is out. Or when sharing in between many
> breaks down the thing. Or when that whoever it is bombs the
> neighbourhood with electromagnetic storms so that anything
> wireless inclusive DVB-T. The former two happen quite frequently.
> 'Don't think WireGuard is a resource hog or bandwidth killer from
> what i know. But i never have done performance testing.
>
> --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
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Wed, 18 Oct 2023, Chris Rapier wrote:

> So what if this was done as a PAM module? That would :

Only work on GNU/Linux, GNU/Hurd, Solaris and IIRC FreeBSD,
but nowhere else as other OSes don’t use PAM (not even all
GNU/Linux distros do).

bye,
//mirabilos
--
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Chris Rapier wrote:
> Hey all,
>
> So I do some development based on openssh and I'm trying to think of some new projects that might extend the functionality, feature set, user workflow,
> performance, etc of ssh.
>
> So open ended question:
>
> Do any of you have a wish list of things you'd like to see in ssh?

Integration of linemode support. I got it working once https://github.com/hyc/OpenSSH-LINEMODE but there seems to be no
interest in merging the work.

It's still valuable when connecting over mobile data and other high latency networks. I get it that the majority of
developers in the US aren't exposed to such networks these days, but they're still very much a reality in the rest
of the world.

--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

> Integration of linemode support. I got it working once
> https://github.com/hyc/OpenSSH-LINEMODE but there seems to be no
> interest in merging the work.
>
> It's still valuable when connecting over mobile data and other high
> latency networks. I get it that the majority of
> developers in the US aren't exposed to such networks these days, but
> they're still very much a reality in the rest
> of the world.

Please note that this would have to mirror most of the
input handling in mosh:

- line-wise editing only works for application that wait for an input
line

- so ncurses-applications (vim, emacs, iptraf, top, ...) resp.
applications that wait for single key presses (raw mode?) need to be
detected somehow

- a lot of inputs (everything outside [\x20-\x7e] needs to flush the
buffer - cursor movements, escape, tab (for completions!), control
sequences, etc.


I'm not sure whether ssh with its simple stream input / stream output
model works here - mosh is a complete terminal emulator because of
these complications!

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

> Do any of you have a wish list of things you'd like to see in ssh?
>
>
> Mostly I'm just curious to see what the larger community is thinking
> of rather than being driven entirely by what I think is cool.


My €0,02:

- https://marc.info/?t=169442622800001&r=1&w=2

- IIRC the ControlMaster stuff doesn't remember for _which_ client
a port forwarding was done, so it can't remove it when this client
quits.
That might arguably be more of a bugfix, though.

- Also, when having a session open via ControlMaster, ~# won't list
connections from _other_ clients, neither port forwardings.
Having more menu options in ~? to see the forwardings, stop them,
and wasn't there an option to _add_ forwardings to established
connections?


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

There are various requests related to extending GSS support (and
patches present in RHEL/Fedora, Debian/Ubuntu etc) but it was rejected
by upstream several months ago.

On Wed, Oct 18, 2023 at 7:17?PM Chris Rapier <rapier@psc.edu> wrote:
>
> Hey all,
>
> So I do some development based on openssh and I'm trying to think of
> some new projects that might extend the functionality, feature set, user
> workflow, performance, etc of ssh.
>
> So open ended question:
>
> Do any of you have a wish list of things you'd like to see in ssh?
>
>
> Mostly I'm just curious to see what the larger community is thinking of
> rather than being driven entirely by what I think is cool.
>
>
> Chris
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>


--
Dmitry Belyavskiy

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev