| commit | 4ea5023365baf81ae70383b880afd901b5e63307 | [log] [tgz] |
|---|---|---|
| author | Thomas Wolf <twolf@apache.org> | Fri Oct 21 18:29:50 2022 +0200 |
| committer | Thomas Wolf <twolf@apache.org> | Fri Oct 21 22:16:37 2022 +0200 |
| tree | d48e5c9af59acfb33743a0610bac7301021869b2 | |
| parent | 77b97c87f972289493d3fdda7a7676a53471e3a6 [diff] |
[SSHD-1302] AbstractClientChannel: don't close inverted output streams Closing them when the channel closes leads to the strange situation that the application reads from an already closed InputStream. That's not a good idea. It's the caller's responsibility to close the input stream obtained from Channel.getInvertedOut() or getInvertedErr(). And of course it should do so only after it has read all the data it wanted, and the channel is closed. It's not a real problem if the stream is not closed (for instance, if the application never even called getInvertedOut() and never read anything). Closing doesn't do much anyway except awaking a potentially waiting read() call. Moreover, if the channel is short-lived and didn't transmit a lot of data, the application may well start reading from the stream only after the underlying SSH channel is already closed. One problem with this ChannelPipedInputStream is that it may buffer up to a full SSH channel window. If the window size is large, that may consume a lot of memory if the application only reads infrequently (or doesn't read at all). However, not reading from such a stream is bad practice anyway if there is any chance that there might be a substantial amount of data; as with processes, it may lead to a blocked execution when buffers fill up or the channel window is exhausted.
Apache SSHD is a 100% pure java library to support the SSH protocols on both the client and server side. This library can leverage Apache MINA, a scalable and high performance asynchronous IO library. SSHD does not really aim at being a replacement for the SSH client or SSH server from Unix operating systems, but rather provides support for Java based applications requiring SSH support.
server-sig-algs extensions.supported - DRAFT 05 - section 4.4supported2 - DRAFT 13 section 5.4versions - DRAFT 09 Section 4.6vendor-id - DRAFT 09 - section 4.4acl-supported - DRAFT 11 - section 5.4newline - DRAFT 09 Section 4.3md5-hash, md5-hash-handle - DRAFT 09 - section 9.1.1check-file-handle, check-file-name - DRAFT 09 - section 9.1.2copy-file, copy-data - DRAFT 00 - sections 6, 7space-available - DRAFT 09 - section 9.2filename-charset, filename-translation-control - DRAFT 13 - section 6 - only client sideeddsa optional module), sk-ecdsa-sha2-nistp256@openssh.com, sk-ssh-ed25519@openssh.com , ssh-rsa-cert-v01@openssh.com, ssh-dss-cert-v01@openssh.com, ssh-ed25519-cert-v01@openssh.com , ecdsa-sha2-nistp256-cert-v01@openssh.com, ecdsa-sha2-nistp384-cert-v01@openssh.com, ecdsa-sha2-nistp521-cert-v01@openssh.comNote: The above list contains all the supported security settings in the code. However, in accordance with the latest recommendations the default client/server setup includes only the security settings that are currently considered safe to use. Users who wish to include the unsafe settings must do so explicitly. The following settings have been deprecated and are no longer included in the default setup:
Caveat:: According to RFC 8332 - section 3.31
Implementation experience has shown that there are servers that apply authentication penalties to clients attempting public key algorithms that the SSH server does not support.
When authenticating with an RSA key against a server that does not implement the “server-sig-algs” extension, clients MAY default to an “ssh-rsa” signature to avoid authentication penalties. When the new rsa-sha2-* algorithms have been sufficiently widely adopted to warrant disabling “ssh-rsa”, clients MAY default to one of the new algorithms.
This means that users that encounter this (and related) problems must modify the supported security settings explicitly in order to avoid the issue.
Special notice: ssh-rsa was left in as part of the default setup since there are still a lot of systems / users using it. However, in future version it will be removed from the default. We therefore strongly encourage users to migrate to other keys (e.g. ECDSA, ED25519) as soon as possible.
Java 8+ (as of version 1.3)
The code only requires the core abstract slf4j-api module. The actual implementation of the logging API can be selected from the many existing adaptors.
sshd-common - contains basic classes used throughout the project as well as code that does not require client or server network support.
sshd-core - contains the basic SSH client/server code implementing the connection, transport, channels, forwarding, etc..
sshd-sftp - contains the server side SFTP subsystem and the SFTP client code.
sshd-scp - contains the server side SCP command handler and the SCP client code.
sshd-ldap - contains server-side password and public key authenticators that use an LDAP server.
sshd-git - contains replacements for JGit SSH session factory.
sshd-osgi - contains an artifact that combines sshd-common and sshd-core so it can be deployed in OSGi environments.
sshd-putty - contains code that can parse PUTTY key files.
sshd-openpgp - contains code that can parse OpenPGP key files (with some limitations - see relevant section)
sshd-cli - contains simple templates for command-line client/server - used to provide look-and-feel similar to the Linux ssh/sshd commands.
sshd-contrib - experimental code that is currently under review and may find its way into one of the other artifacts (or become an entirely new artifact - e.g., sshd-putty evolved this way).
Including tests
mvn clean install
Without tests
mvn -Pquick clean install