ssh wish list?

[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-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Joseph S. Testa II]

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 sntrup761x2...@openssh.com, which provides 128-bit of
symmetric security.

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

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

[Thomas Köller]

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:

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

[Thomas Köller]

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.

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

From: openssh-unix-dev <openssh-unix-dev-bounces+herbie.robinson=strat...@mindrot.org> On Behalf Of Chris Rapier
Sent: Wednesday, October 18, 2023 2:12 PM
To: openssh-...@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-...@mindrot.org<mailto:openssh-...@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-...@mindrot.org<mailto:openssh-...@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-...@mindrot.org<mailto:openssh-...@mindrot.org>
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev<https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev>

[Thomas Köller]

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.

[Chris Rapier]

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.

[Steffen Nurpmeso]

Chris Rapier wrote in
<9b9c0475-7c4f-468a...@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)

[Brian Candler]

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/

[hvjunk]

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

[Chris Rapier]

On 10/18/23 2:56 PM, Steffen Nurpmeso wrote:
> Chris Rapier wrote in
> <9b9c0475-7c4f-468a...@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?

[Robinson, Herbie]

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=strat...@mindrot.org> On Behalf Of Thomas Köller
Sent: Wednesday, October 18, 2023 3:00 PM
To: openssh-...@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.]

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

[Thomas Köller]

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.

[Steffen Nurpmeso]

Chris Rapier wrote in
<98ef47a5-b8d3-4677...@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)

[Steffen Nurpmeso]

Brian Candler wrote in
<6219db42-5a0e-4fe5...@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...@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)

[Steffen Nurpmeso]

Chris Rapier wrote in
<8e8c9940-4b65-448b...@psc.edu>:

|On 10/18/23 2:56 PM, Steffen Nurpmeso wrote:
|> Chris Rapier wrote in
|> <9b9c0475-7c4f-468a...@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)

[Paul Tagliamonte]

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

[Ethan Rahn]

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.

[Thorsten Glaser]

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

[Howard Chu]

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/

[Philipp Marek]

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

[Philipp Marek]

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

[Dmitry Belyavskiy]

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.

--
Dmitry Belyavskiy

[Martin Hecht]

Hi Chris,

On 18/10/2023 19:13, Chris Rapier wrote:
> Do any of you have a wish list of things you'd like to see in ssh?

get Roumen Petrovs pkissh implementation merged and maintained upstream

I know this is a huge page with little chances to get accepted, but I'd
like to mention this, because it has been on my personal wish list for a
long time. Sure, I can install pkissh, but if it were upstream, another
5-10 years later, it would probably arrive in the distributions and get
used widely.

Martin

[Martin Hecht]

> On 18/10/2023 19:13, Chris Rapier wrote:
>> Do any of you have a wish list of things you'd like to see in ssh?
>
> get Roumen Petrovs pkissh implementation merged and maintained upstream
>
> I know this is a huge page with little chances to get accepted,

this should read "huge patch", sorry

[Björn Lässig]

Hey Chris,

On Wed, 2023-10-18 at 13:13 -0400, Chris Rapier wrote:
> Do any of you have a wish list of things you'd like to see in ssh?

Meanwhile, a lot of parts have to work together for SSH to work as
desired: ssh-client, ssh-agent, gpg-agent, scdaemon, sshd, pam, ....

As an admin who works with SSH all day in a company whose employees do
everything via SSH, I would like to see better debug options in the
entire stack with the long-term goal of being able to evaluate them
automatically with some data format (json, yaml). Sshd and ssh-agent
cannot be switched to 'debug' mode afterwards without shooting yourself
in the foot.

It would be nice if there were better ways to find out why something
didn't work. For example, we've had corporate firewalls that discarded
certain handshake packets and it was really hard to get the idea of
what was going wrong in the first place.

ESC~#

Börn Lässig

[Dirk-Willem van Gulik]

> On 23 Oct 2023, at 18:19, Martin Hecht <martin...@hlrs.de> wrote:
>
> Hi Chris,
>
> On 18/10/2023 19:13, Chris Rapier wrote:
>> Do any of you have a wish list of things you'd like to see in ssh?
>
> get Roumen Petrovs pkissh implementation merged and maintained upstream

I’d second that. Improvement for X.509 support. Ideally well synced with PKCS#11 (which is working well) for physical devices.

Dw.

[Dave Cottlehuber]

On Wed, 18 Oct 2023, at 19:13, 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?

Line rate ssh. Like if I have a 10G pipe I should be able to push 10G through without spending significant effort tweaking it for this specific transfer. I know this is partially wishful thinking but I’d like it to be easier.

This might be QUIC or some other UDP layer, or it might be something else entirely.

ssh is my go to tool for shifting almost anything from one place to another, except where I’m limited by single tcp streams.

A+
Dave

[Robinson, Herbie]

You aren’t likely to see 10Gb line rate in a single process. Even without any encryption involved, you will only get between 2 and 5Gb using a single process (at least the last time I tried it). The problem is you saturate a CPU with protocol interrupt protocol overhead and you can spread a single data stream over multiple CPUs (at least not with TCP or anything else that assumes out of order packets == congestion). OTOH, if you use GCM on recent hardware where it has been accelerated, the encryption doesn’t add much overhead.

If you are talking multiple processes using accelerated GCM, then it’s possible to hit 10Gb. I would hazard a guess that 8 cores would be more than enough.

From: openssh-unix-dev <openssh-unix-dev-bounces+herbie.robinson=strat...@mindrot.org> On Behalf Of Dave Cottlehuber
Sent: Thursday, October 26, 2023 2:43 PM
To: Chris Rapier <rap...@psc.edu>
Cc: openssh-...@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.]

openssh-...@mindrot.org<mailto:openssh-...@mindrot.org>
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev<https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev>

[Philipp Marek]

Another wish: mtcp