Poison


  • 首页

  • 归档

  • 标签

  • 搜索
close
Poison

OpenSSH

发表于 2022-08-11

OpenSSH 8.8 存在不兼容的改动,导致 macOS 升级至 Ventura 后因 macOS 上的 OpenSSH 版本升级至了 9.0 后当连接的服务端 OpenSSH 版本为低版本(如:6.6.1)时 SSH 连接时无可互用的签名算法导致提示输入密码(服务端允许密码登录时)或者直接提示 Permission denied, please try again.(服务端不允许密码登录时)。如果使用 verbose 模式查看 ssh 时的 debug 信息,可以发现如下输出:

1
2
3
4
5
6
7
8
debug1: send_pubkey_test: no mutual signature algorithm
debug1: Trying private key: /Users/Poison/.ssh/id_ecdsa
debug1: Trying private key: /Users/Poison/.ssh/id_ecdsa_sk
debug1: Trying private key: /Users/Poison/.ssh/id_ed25519
debug1: Trying private key: /Users/Poison/.ssh/id_ed25519_sk
debug1: Trying private key: /Users/Poison/.ssh/id_xmss
debug1: Trying private key: /Users/Poison/.ssh/id_dsa
debug1: Next authentication method: password

建议的解决方案为升级服务端的 OpenSSH 版本,如果实在无法升级,则推荐修改客户端 ssh 配置临时启用使用 SHA-1 哈希算法的 RSA 签名。OpenSSH 8.8 Release 文档中关于此部分的描述如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Potentially-incompatible changes
================================

This release disables RSA signatures using the SHA-1 hash algorithm
by default. This change has been made as the SHA-1 hash algorithm is
cryptographically broken, and it is possible to create chosen-prefix
hash collisions for <USD$50K [1]

For most users, this change should be invisible and there is
no need to replace ssh-rsa keys. OpenSSH has supported RFC8332
RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys
will automatically use the stronger algorithm where possible.

Incompatibility is more likely when connecting to older SSH
implementations that have not been upgraded or have not closely tracked
improvements in the SSH protocol. For these cases, it may be necessary
to selectively re-enable RSA/SHA1 to allow connection and/or user
authentication via the HostkeyAlgorithms and PubkeyAcceptedAlgorithms
options. For example, the following stanza in ~/.ssh/config will enable
RSA/SHA1 for host and user authentication for a single destination host:

Host old-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa

We recommend enabling RSA/SHA1 only as a stopgap measure until legacy
implementations can be upgraded or reconfigured with another key type
(such as ECDSA or Ed25519).

[1] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and
Application to the PGP Web of Trust" Leurent, G and Peyrin, T
(2020) https://eprint.iacr.org/2020/014.pdf
References

OpenSSH - release 8.8
ssh(1) - Linux manual page

Poison

HTTP Hijacking

发表于 2022-08-08

最近查了个 HTTP 劫持的问题,本文简要记录。背景是近期不少用户反馈扫码出来的为黄色网站,由于历史原因,存在部分二维码的入口为 HTTP 协议,这部分请求通过 301 跳转至 HTTPS 页面实现。虽然已经启用了 HSTS,但是对于首次访问,始终存在被劫持的风险(域名未在 preload 名单中)。

阅读全文 »
Poison

System.nanoTime()

发表于 2022-08-03

最近查了个关于 System.nanoTime() 的问题,起因是业务里面将 System.nanoTime() 返回的数值作为了业务中的唯一值,最后发现了值相同的数据,询问编写这块代码的同事,同事反馈说当时编写的时候以为 System.nanoTime() 的精度很高,不会出现重复的数据。但是从现象来看,出现了重复的数据。

我们可以用一段简单的代码复现该问题:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public class Test {

private static volatile long a = -1, b = -2;

public static void main(String[] args) {
long max = 1_000_000;
new Thread(() -> {
for (int i = 0; i < max; i++) {
a = System.nanoTime();
}
}).start();
new Thread(() -> {
for (int i = 0; i < max; i++) {
b = System.nanoTime();
}
}).start();
for (int i = 0; i < max; i++) {
if (a == b) {
System.out.println("nanoTime not unique");
}
}
}

}
阅读全文 »
Poison

Shift Operators

发表于 2022-08-01

最近写了些关于 Bit 操作的代码,才发现使用左移操作符时,当右侧操作数(需要移动的位数)大于左侧操作数比特个数时,实际移动位数等同于右侧操作数对左侧操作数比特个数求余。可能说的不是很明白,可以用一个简单的示例来说明,比如以下代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class BitShiftTest {

private static String toBinaryString(int i) {
return String.format("%32s", Integer.toBinaryString(i)).replace(' ', '0');
}

public static void main(String[] args) {
int i = 0b00000000_00000000_00000000_00000001;
int j = i << 35;
System.out.println(j);
System.out.println(toBinaryString(j));
}

}
阅读全文 »
Poison

DeleteOnExitHook

发表于 2022-07-18

严格来说,DeleteOnExitHook 导致的内存占用不应该归结为内存泄漏,开发者应该恰当地使用 java.io.File#deleteOnExit 方法,如果持续对不同的文件调用该方法,那么长时间运行的 JVM 实例的内存最终将被填满。为了规避这个问题,建议应用程序自行进行临时文件管理,而不是依赖于 JVM 退出来进行相应的文件清理操作。

如果通过 Google 搜索 java.io.DeleteOnExitHook memory leak,可知有不少开源项目存在该问题,主要受影响的为长时间运行的服务,java.io.DeleteOnExitHook#files 占用的内存往往在数百兆以上而且随着服务的持续运行会持续增长。

如 HIVE-11768 中提到的 .pipeout 文件问题,其解决方案为自行编写了 ShutdownHookManager 类,该类相比 JDK 提供的 DeleteOnExitHook 新增了 cancelDeleteOnExit 方法,且应用自行管理这部分临时文件的生命周期,不再使用后删除文件并调用 cancelDeleteOnExit 方法移除这部分文件名,以解决内存占用问题。本次 commit 可参考:HIVE-11768 : java.io.DeleteOnExitHook leaks memory on long running Hi… · apache/hive@1a81c26 · GitHub。

附上 JDK 8 中 DeleteOnExitHook 的源码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
/**
* This class holds a set of filenames to be deleted on VM exit through a shutdown hook.
* A set is used both to prevent double-insertion of the same file as well as offer
* quick removal.
*/
class DeleteOnExitHook {
private static LinkedHashSet<String> files = new LinkedHashSet<>();
static {
// DeleteOnExitHook must be the last shutdown hook to be invoked.
// Application shutdown hooks may add the first file to the
// delete on exit list and cause the DeleteOnExitHook to be
// registered during shutdown in progress. So set the
// registerShutdownInProgress parameter to true.
sun.misc.SharedSecrets.getJavaLangAccess()
.registerShutdownHook(2 /* Shutdown hook invocation order */,
true /* register even if shutdown in progress */,
new Runnable() {
public void run() {
runHooks();
}
}
);
}

private DeleteOnExitHook() {}

static synchronized void add(String file) {
if(files == null) {
// DeleteOnExitHook is running. Too late to add a file
throw new IllegalStateException("Shutdown in progress");
}

files.add(file);
}

static void runHooks() {
LinkedHashSet<String> theFiles;

synchronized (DeleteOnExitHook.class) {
theFiles = files;
files = null;
}

ArrayList<String> toBeDeleted = new ArrayList<>(theFiles);

// reverse the list to maintain previous jdk deletion order.
// Last in first deleted.
Collections.reverse(toBeDeleted);
for (String filename : toBeDeleted) {
(new File(filename)).delete();
}
}
}
References

jdk/DeleteOnExitHook.java at jdk8-b120 · openjdk/jdk · GitHub
Memory Leak on DeleteOnExitHook - Stack Overflow
JDK-4513817 File.deleteOnExit consumes memory - Java Bug System
SPARK-14261 Memory leak in Spark Thrift Server - ASF JIRA

1…567…28

138 日志
126 标签
GitHub LeetCode
© 2026 Poison 蜀ICP备16000644号
由 Hexo 强力驱动
主题 - NexT.Mist