search for: asyncssh

I updated to the latest versions of libfido2 and openssh-portable tonight, with an intention to test out the security key functionality and look closely at the changes over the last couple of months to see if I need to change anything in my AsyncSSH implementation to stay in sync. However, it seems that libfido2 no longer provides the ?libsk-libfido2.so? library that it used to. That was something I was counting on being able to link against in AsyncSSH, so I didn?t have to directly call into libfido2 and could instead use the much simpler sk_...

...rk without fiddling with middleware binaries, etc. > > Please give this a try - security key support is a substantial change and > it really needs testing ahead of the next release. I?ve been following this work with great interest, as I?ve been looking to add this support to my Python ?AsyncSSH? package. I got a chance to look more closely at this over the last few days, and I?ve now got an initial implementation working and interoperating with OpenSSH-portable HEAD! As part of my testing, I?ve been experimenting with not only plan SK keys, but also various combinations of creating certi...

Peter Stuge wrote: > > Matthieu Hautreux wrote: >> The change proposed by Cyril in sftp is a very pragmatic approach to >> deal with parallelism at the file transfer level. It leverages the >> already existing sftp protocol and its capability to write/read file >> content at specified offsets. This enables to speed up sftp transfers >> significantly by

...ve seems to have proven too big a bite at least once :) I am not at all familiar with the openssh codebase, but if that helps and if that sounds like a doable idea, we can certainly propose to provide some dedicated test stubs addressing the server side, written e.g. in asynchronous python based on asyncssh, that at first sight has all that is needed to carry out fine-grained tests in this area; even if temporarily, i.e. until some agreement can be found on what the client side should look like > It would be nice to know what the precise technical issues are that have > prevented support for th...

Hi, As of this morning, OpenSSH now has experimental U2F/FIDO support, with U2F being added as a new key type "sk-ecdsa-sha2-nistp256 at openssh.com" or "ecdsa-sk" for short (the "sk" stands for "security key"). If you're not familiar with U2F, this is an open standard for making inexpensive hardware security tokens. These are easily the cheapest way

I?m working on an implementation of ?gssapi-with-mic? authentication for my AsyncSSH package and trying to get it to interoperate with OpenSSH. I?ve gotten it working, but there seems to be a discrepancy between the OpenSSH implementation and RFC 4462. Specifically, RFC 4462 says the following in section 3.4: Since the user authentication process by its nature authenticates...

...ortable OpenSSH Version: 6.8p1 Hardware: All OS: All Status: NEW Severity: major Priority: P5 Component: sshd Assignee: unassigned-bugs at mindrot.org Reporter: ronf at timeheart.net Today I tested my AsyncSSH client against OpenSSH 7.1 and noticed that it had a problem with the reply message coming back from tcpip-forward. After a bit of digging, I tracked down the change to OpenSSH 6.8 which I think was part of the fix for bz#2147. According to the OpenSSH spec: If a client passes 0 as port number...

On Jan 17, 2017, at 9:57 AM, Douglas E Engert <deengert at gmail.com> wrote: > On 1/16/2017 2:09 PM, Ron Frederick wrote: >> I?m working on an implementation of ?gssapi-with-mic? authentication for my AsyncSSH package and trying to get it to interoperate with OpenSSH. I?ve gotten it working, but there seems to be a discrepancy between the OpenSSH implementation and RFC 4462. Specifically, RFC 4462 says the following in section 3.4: >> >> Since the user authentication process by its nature...

On Thu, May 04, 2017 at 09:37:59AM +1000, Adam Eijdenberg wrote: > Hi Devin, have you looked at using openssh certificates to help manage [...] > While the feature has been around for a while now (and is really > useful), there doesn't seem to be huge amount of documentation around > it. I found the following useful when getting a client of my running Yeah, when I wrote about it

I spent some time today implementing support for loading U2F keys into the SSH agent from my AsyncSSH library. I got it working, but along the way I ran into a few issues I wanted to report: First, it looks like the value of SSH_AGENT_CONSTRAIN_EXTENSION has changed from the value 3 defined at https://tools.ietf.org/html/draft-miller-ssh-agent-02 <https://tools.ietf.org/html/draft-miller-ssh-ag...

...ink to a patch here - again limited to server side https://bugzilla.mindrot.org/attachment.cgi?id=3120&action=edit that we?ve been able to test on a fedora28 box, and that updated version indeed improves the overall behaviour of the openssh server side for our needs, when used against an python/asyncssh client side Does it make sense for us to submit a PR on the github repo https://github.com/openssh/openssh-portable, or elsewhere ? or were there deeper concerns about that change that need to be further discussed ? Many thanks in anticipation ? Thierry PS I struggled a bit to get this through,...

Hi all, Back in September 2018, I started a thread about implementing the X448 key exchange (see https://lists.mindrot.org/pipermail/openssh-unix-dev/2018-September/037183.html). In February 2020, RFC 8731 (formally specifying X448 in SSH) has been finalized: https://www.ietf.org/rfc/rfc8731.txt. I thought I'd start this conversation up again to see if the interest level has

...to have proven too big a bite at least once :) >> I am not at all familiar with the openssh codebase, but if that helps and if that sounds like a doable idea, we can certainly propose to provide some dedicated test stubs addressing the server side, written e.g. in asynchronous python based on asyncssh, that at first sight has all that is needed to carry out fine-grained tests in this area; even if temporarily, i.e. until some agreement can be found on what the client side should look like >> >>> It would be nice to know what the precise technical issues are that have >>>...

Hello, I forgot to mention one other issue in my previous e-mail about the ssh-agent documentation for U2F keys. Right now, https://raw.githubusercontent.com/openssh/openssh-portable/master/PROTOCOL.u2f <https://raw.githubusercontent.com/openssh/openssh-portable/master/PROTOCOL.u2f> has the following text: > ssh-agent requires a protocol extension to support U2F keys. At > present the