oscerd commented on code in PR #28215:
URL: https://github.com/apache/camel/pull/28215#discussion_r4334869264
##########
components/camel-ssh/src/main/java/org/apache/camel/component/ssh/ResourceBasedSSHKeyVerifier.java:
##########
@@ -18,30 +18,66 @@
import java.io.IOException;
import java.io.InputStream;
-import java.math.BigInteger;
import java.net.InetSocketAddress;
import java.net.SocketAddress;
-import java.security.NoSuchAlgorithmException;
+import java.nio.charset.StandardCharsets;
+import java.security.GeneralSecurityException;
+import java.security.MessageDigest;
import java.security.PublicKey;
-import java.security.spec.InvalidKeySpecException;
import java.util.Base64;
-import java.util.LinkedList;
-import java.util.List;
+import java.util.Collections;
+import java.util.Locale;
+
+import javax.crypto.Mac;
+import javax.crypto.spec.SecretKeySpec;
import org.apache.camel.CamelContext;
import org.apache.camel.support.ResourceHelper;
-import org.apache.camel.util.IOHelper;
+import org.apache.sshd.client.config.hosts.HostConfigEntry;
import org.apache.sshd.client.keyverifier.ServerKeyVerifier;
import org.apache.sshd.client.session.ClientSession;
-import org.bouncycastle.util.Arrays;
+import org.apache.sshd.client.session.ClientSessionCreator;
+import org.apache.sshd.common.AttributeRepository;
+import org.apache.sshd.common.config.keys.KeyUtils;
+import org.apache.sshd.common.config.keys.PublicKeyEntry;
+import org.apache.sshd.common.config.keys.PublicKeyEntryResolver;
+import org.apache.sshd.common.session.SessionContext;
+import org.apache.sshd.common.util.net.SshdSocketAddress;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
/**
* ServerKeyVerifier that takes a camel resource as input file to validate the
server key against.
- *
+ * <p>
+ * The resource uses the OpenSSH known_hosts format, and its entries are
matched as OpenSSH matches them. Each host
+ * pattern of an entry is compared, ignoring case, with the host name or
address the client connects to (the host
+ * configured on the endpoint, or the {@code HostName} that {@code
~/.ssh/config} gives for it, as it is written and
+ * never resolved through DNS, so an IPv6 address such as {@code ::1} is not
expanded), written {@code host} for port 22
+ * and {@code [host]:port} for another port: {@code *} and {@code ?} are
wildcards, a pattern starting with {@code !}
+ * excludes the hosts it matches, and hashed entries are supported. The server
is accepted when an entry of its host
+ * lists the key it presents. It is rejected when that key is listed in a
matching {@code @revoked} entry, or when its
+ * host has entries without a marker but none of them lists that key. {@code
failOnUnknownHost} only decides for a host
+ * without such an entry: {@code @revoked} and {@code @cert-authority} entries
do not list a host, and host certificates
+ * are not supported. A resource that cannot be read, or that has a line that
cannot be read, rejects every server.
*/
public class ResourceBasedSSHKeyVerifier implements ServerKeyVerifier {
+ private static final int DEFAULT_PORT = 22;
+ private static final String MARKER_REVOKED = "@revoked";
+ private static final String MARKER_CERT_AUTHORITY = "@cert-authority";
+ private static final String HASHED_HOST_PREFIX = "|1|";
+ private static final String HASH_ALGORITHM = "HmacSHA1";
+ private static final int HASH_LENGTH = 20;
+
+ /**
+ * The host configuration that the client connected with, which the ssh
producer and consumer put in the connection
+ * context of the session: the entries are matched against its {@code
HostName} as it is written. Without it, the
+ * address the client connected to is used, which writes an IPv6 address
such as {@code ::1} in its full form.
+ *
+ * @since 4.24
Review Comment:
Thanks. I'd keep `@since 4.24` here, on purpose:
- Backports to the maintenance branches keep the `@since` of the change on
`main`. `KnativeTransportConfiguration` has `@since 4.23` on both
`camel-4.22.x` and `camel-4.18.x`, and `EmptyConsumerCache` has `@since 4.21`
on `camel-4.18.x`. Neither branch has a patch-level `@since` such as `4.22.3`.
- It keeps this PR a straight cherry-pick of #27821, with its 16 files
identical to `main`. Writing `4.22.3` here would also mean `4.18.6` in #28218,
so each line would document a different version for the same constant.
If the project wants `@since` to name the first release of each line, that
convention belongs on `main` first, for example `@since 4.18.6, 4.22.3, 4.24`.
I'd do it there in a follow-up rather than in the backports.
_Claude Code on behalf of Andrea Cosentino_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
