similar to: Port 0 forwarding implemented?

Hello all. I posted here a few days ago about the support of dynamic selection of the port to forward (ssh -R 0:host:port), which refers to section 7.1 of http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-24.txt . My posts were from lcml at pixel.it, while this is from lucio at sulweb.org. Nevermind, It's always me. Here is the patch that adds support for that thing. It's

https://bugzilla.mindrot.org/show_bug.cgi?id=2948 Bug ID: 2948 Summary: implement "copy-data" sftp extension Product: Portable OpenSSH Version: -current Hardware: All URL: https://tools.ietf.org/html/draft-ietf-secsh-filexfer- extensions-00#section-7 OS: All Status: NEW

Hello, I had some difficulties in order to convert private keys between different implementations of SSH. So, I wrote the following patch to allow export of SSH2 RSA and DSA private keys into IETF SECSH format. Note that I also slightly revised the IETF SECSH key import code. Usage: use of the "-e" option on a private key file generates an unencrypted private key file in IETF SECSH

Old news, but ... http://lwn.net/Articles/298833/ I first posted about this back in 2001 and it's still not resolved: http://osdir.com/ml/ietf.secsh/2001-09/msg00000.html 1) high latency networks are a reality that will never go away. In fact they will only become more prevalent since distributed networks continue to grow broader but (surprise) the speed of light remains a constant. 2)

Hi, I have a question about signal forwarding support in sshd of OpenSSH. http://www.openssh.org/txt/draft-ietf-secsh-connect-15.txt says that |4.9 Signals | | A signal can be delivered to the remote process/service using the | following message. Some systems may not implement signals, in which | case they SHOULD ignore this message. | | byte SSH_MSG_CHANNEL_REQUEST

Hi there, I'm developing ssh client in pure java and, recently, I'm trying to improve the port forwarding support on that stuff. However, it seems to me that sshd of OpenSSH has not supported 'cancel-tcpip-forward' request. http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-17.txt says that | A port forwarding can be cancelled with the following message. |

>Is there a simple way to achieve this behavior? Is there a document on >the sftp protocol somewhere? http://search.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-00.txt -- Darren J Moffat

Dear list, Attached is a patch that adds support for the SSH_FXP_LINK request, as described in draft-ietf-secsh-filexfer-07 onwards, to the sftp server and client. It is for and has been tested on the current portable snapshot but also applies to openbsd CVS. Thanks, -- Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-sftp-hardlink-pcvs-v2.patch

http://www.ietf.org/internet-drafts/draft-ietf-secsh-newmodes-05.txt So what do people think of this?

An updated version of my patch for Kerberos v5 support is now available from http://www.sxw.org.uk/computing/patches/openssh-2.5.2p1-krb5.patch This patch includes updated Kerberos v5 support for protocol version 1, and also adds GSSAPI support for protocol version 2. Unlike the Kerberos v5 code (which will still not interoperate with ssh.com clients and servers), the GSSAPI support is based on

I'd like to address several issues raised by people in relation to my notice of the ssh(R) trademark to the OpenSSH group. Also, I would like to make a proposal to the community for resolving this issue (included at the end). First, I'll answer a number of questions and arguments presented in the discussion. > "the SSH Corp trademark registration in the US is for a logo

Hello, It seems to me the algorithm negotiation of the transport layer has a bug, it does not follow the specification of draft-ietf-secsh-transport-24, page 19, where the behaviour of first_kex_packet_follows is specified. I've got an ssh client that sends an SSH_MSG_KEXINIT message and specifies only 'diffie-hellman-group1-sha1' as key exchange algorithm. It sets

there is now a draft: http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-00.txt if someone could please check whether sftp-server.c comlies :)

Hi, According to IETF draft draft-ietf-secsh-transport-14.txt, different ciphers(encryption), MAC and compression can be used for one direction say server-to-client and a completely different cipher, MAC and compression for the other direction client-to-server of the same connection. Is this supported today in OpenSSH, and if not, are there plans to support it in any future releases of the

On Fri, 8 Nov 2024 at 03:16, Darren Tucker <dtucker at dtucker.net> wrote: > > On Thu, 7 Nov 2024 at 07:55, Chris Rapier <rapier at psc.edu> wrote: > >[...]I had been using > > Blake2b512 for the hashing algorithm but I want to put in a path to use > > xxhash instead. Maintaining backward compatibility means I need to know > > something about the remote.

Hi, According to IETF draft draft-ietf-secsh-transport-14.txt, different ciphers(encryption), MAC and compression can be used for one direction say server-to-client and a completely different cipher, MAC and compression for the other direction client-to-server of the same connection. Is this supported today in OpenSSH, and if not, are there plans to support it in any future releases of the code?

On Thu, Mar 14, 2002 at 12:12:20PM -0800, Bob Smith wrote: > i find it amusing that the OpenBSD web site states on the main index page > "Our efforts emphasize portability, standardization,...." but by not > following standards like secsh's key format you're failing according to > your own goals. This is not exactly the truth. You have to consider your user base

I'm looking for a way to have the server allocate an available port number when using remote port forwarding. In draft-ietf-secsh-connect-25.txt such a feature is described but I fail to see if/how this is actually supported by openssh. Quote from the draft: If a client passes 0 as port number to bind and has 'want reply' TRUE then the server allocates the next available

Hi, This may or may not cause concern for some people (considering a lot of people store all of their keys on a single client system). Snippet from draft-ietf-secsh-agent-00.txt: 2. Security Considerations This protocol is designed only to run as a channel of the SSH protocol. The goal of this extension is to ensure that the users private keys never leave the machine they are

Hi, i notice in draft-ietf-secsh-gsskeyex-06.txt that the value for SSH_MSG_USERAUTH_GSSAPI_ERRTOK is not defined. does anyone know what this should be (i guess *will* be in a future rev)? thanks glen