similar to: Question regarding encryption

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?

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

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

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)

>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

Below is a patch that adds the ability to have a none cipher and mac for protocol version 2. By default, sshd will not allow these to be used; an admin will have to explicitly allow them in the Ciphers and MACs section of sshd_config. Additionally, the client will not use these unless explicitly instructed to by the user. The actual name of the cipher is 'none2', to distinguish it

http://bugzilla.mindrot.org/show_bug.cgi?id=1340 Summary: Support for Camellia block cipher to OpenSSH-portable. Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Miscellaneous AssignedTo: bitbucket at mindrot.org

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

Hello everybody, I've read the ssh protocol draft http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-24.txt and I wonder if the feature documented in section 7.1, page 15, last paragraph, is implemented in OpenSSH or not (sshd chooses the first free non privileged port to forward when the specified port number is 0). I need this feature and, if it isn't implemented yet, I

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

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

I am using sshfs with FUSE to mount a remote directory over ssh/sftp (on linux). It would be nice if df could be able to show the total size/free space of the mounted directory. I am aware that returning size/free space would have some limitations. For example, if a subdir of the mounted directory has another filesystem mounted on the remote server, this can not be represented simply. However,

I was directed to the following site by one of our customers regarding a keyserver built into openssh. There's a patch for 3.4p1 on their site, but the license isn't very clear, nor is it clear if they have approached the openssh team regarding the inclusion of this subsystem into openssh proper. I've been asked to patch Mandrake's openssh with this feature, but I'm

I have found that this server, <snip> debug1: Remote protocol version 1.99, remote software version 3.1.0 F-SECURE SSH - Process Software SSH for OpenVMS debug1: no match: 3.1.0 F-SECURE SSH - Process Software SSH for OpenVMS </snip> does not follow the IETF secsh draft [1] related to the SSH_MSG_USERAUTH_PASSWD_CHANGEREQ message. <snip> ... Normally, the server responds