0%

在利用xterm.js实现终端搜索高亮时需要能够识别终端当前是否在vi编辑器模式,调查后发现xterm.buffer.active.type可以用来实现。

查看对应类型定义发现值只有两种normal和alternate。不明白为什么叫alternate,所以进一步调查,原来这个概念来源于terminal下的alternate screen。这里整体介绍下。

https://static.1991421.cn/2022/2022-07-28-224538.jpeg

alternate screen-备用屏幕

  1. 该中文翻译采用苹果的中文翻译,xshell叫终端替换屏幕
  2. alternate screen是临时性交互输入内容的屏幕,最终还要返回。比如VI模式下,屏幕显示区域与正常模式一样,当激活备用屏幕时,原屏幕内容被保存,当退出备用屏幕时,源内容被恢复。
  3. 所以xterm下的normal/alternate概念并非是原创,而是终端本身的设计上就这两种模式,普通和备用

写在最后

xterm.js只是xterm的一种实现,为了更好的理解xterm.js还是需要多了解xterm-终端模拟器的一些设计。

相关文档

在查看项目时,发现一些项目尤其后端项目有个Makefile文件,这样一些构建命令可以方便的封装调用。

之前没了解过该工具,这里mark下。

特点

  1. Mac/Linux天然支持,这样声明创建后,直接执行即可
    • shell文件的话,还需手动增加执行权限chmod +x *.sh
    • 项目中使用nodejs实现构建工具也行,但是毕竟还有环境依赖
  2. 支持变量传参

举个例子

1
2
3
# 构建前端镜像 make build version=1.0.0
build:
docker build -t stacker/web:v$(version) .

比如封装如上命令到Makefile,以后想打包新镜像文件,直接make build version=1.0.0即可

语法说明

  • 文件名推荐为Makefile,但也可以是makefile
  • 只支持单行注释
  • @开头命令声明,表示该命令输出结果不打印

参考配置

  1. https://gitlab.com/gnachman/iterm2/-/blob/master/Makefile

306医院-皮肤科治疗不理想,因此选择换到了北大人民医院,相对觉得还是强些的,但也遇到了很多麻烦事,比如流程,这里mark下。

携带物品

  • 社保卡-第一次需要开通该医院电子医保需要,之后不需要
  • 手机-挂号,支付等

就医全流程

  1. 微信114挂号-注意不是小程序
    • 每个医生出诊时间不同,推荐还是维持找同一个医生,避免啰嗦嘴皮子说病情,即使就诊信息上都有记录。比如我目前觉得不错的医生是周二周三出诊,因此我就挂这两天的号。
  2. 进入医院时扫码填写防疫信息
  3. 门口左侧自助取号机取号,推荐使用手机-支付宝-电子医保支付
  4. 门诊楼就诊-皮肤科在4楼,扫码签到等待叫号
  5. 就诊后,在4楼或者其它楼层均可直接自助机支付药费
  6. 根据药品情况去一楼或者四楼取药
  7. 由于需要走商业保险报销,因此需要发票,而医院不提供电子发票,所以只能在人工支付窗口排队,打印发票,有时需要提醒医生挂号费也打印下发票

个人觉得不合理的地方

  1. 医院门口取号机器有些不能用了,没有任何提示,因此在真正取号时,只要觉得有问题,直接找人问,别在那一直试,白浪费时间。
  2. 皮肤科取药的队伍是跟治疗的一个排队,造成前面可能非常慢,白浪费时间,这时建议直接找门诊医生说让她安排人进去拿药吧,几分钟的事,在那排个把小时,纯粹浪费。
  3. 不同医院间就诊信息不同步,因此比如在A医院做过的检查在B医院不认,无端造成浪费,因此建议就诊的话,维持一个医院不变好些。

总而言之

  1. 对比306医院皮肤科,北大人民医院的更专业些,因此最近该病的治疗一直在该医院了。
  2. 医院看病总能看到很多不合理的地方,尽可能采取各种手段为自己节约时间吧。

Alfred除了Mac版之外,对于iPhone/iPad也有移动App版,经过一段时间使用,这里将个人的实践总结下

推荐入手?

先说结论

  1. remote本身只是桌面版Alfred的延伸,本质还是操作了Mac版Alfred,因此可玩性有,只是还比较鸡肋
  2. 如果没有远程控制Mac的场景,个人不建议购买,毕竟并不常用

有需求的继续👇

下载/资费

  • 付费/4.99刀,国区有上架,不需要走外区,下载地址
  • 未提供Android版,且作者无计划支持
  • remote使用并不要求Mac版必须购买了powerpack license,但想通过workflow trigger实现复杂功能的话,还是需要购买为好,因此非powerpack用户,remote可玩性不高

定位

The ultimate iOS command centre for Alfred. Your iPhone or iPad now becomes a perfect day-long companion to your Mac.

官网介绍如上,可以了解到,Alfred remote定位是Mac版Alfred的控制中心,借由remote操作桌面版Alfred下的命令/workflow,从而实现Mac的远程操作。

局限性

  1. 当前Alfred Remote没有支持同步Mac系统剪贴板,做到iOS上也有剪贴板历史支持

使用

配置

  1. Mac版开启Remote Server

https://static.1991421.cn/2022/2022-07-23-234044.jpeg

  1. iPhone/iPad Remote App下添加设备

    如果Wi-Fi网络下寻找不到该Mac可以直接输入IP/端口添加,根据提示输入短语即可添加成功,添加成功后即可在首页面板上看到对应Mac设备

https://static.1991421.cn/2022/2022-07-23-234317.jpeg

  1. 定制化remote操作面板

    在Mac Alfred Remote下按需定制面板,比如添加系统命令/workflow等。添加完成后,iPhone会自动同步更新

  2. remote系统设置

    为了更好的使用remote app,推荐设置中心开启以下设置项

    https://static.1991421.cn/2022/2022-07-23-234633.jpeg

使用场景

这里列举下当前我的一些贫瘠的使用场景

  1. 在利用Mac看电影时,可以通过remote来操作音量或者网页滚动操作
  2. 打开常用app/网页
https://static.1991421.cn/2022/2022-07-23-233342.jpeg

写在最后

  1. 一开始是冲着Alfred的喜爱购买,在吃灰多年之后,现在决定用起来,发现还是有场景需要的,毕竟可以远程操作Mac。
  2. 希望作者可以继续维护下去吧,期待能出些新的玩法/特性

最近用户反馈我们的WebShell在使用ssh密钥登陆Ubuntu系统时报认证错误,为此调查了下。

https://static.1991421.cn/2022/2022-07-18-215907.jpeg

SSH2模块下报错如下

Client: publickey auth failed
Error: All configured authentication methods failed

排查

  1. 公私钥密码使用的RSA加密算法
  2. 尝试本地终端SSH登陆,终端App为Mac自带Terminal

ssh -v -i ~/test.pem ubuntu@1.221.54.8

​ 登陆发现可以成功,而WebShell报错,因此WebShell大概率有问题

注意

  • SSH如果报错Permissions 0644 for ‘test.pem’ are too open.即需要确保私钥文件权限合适,执行chmod 400 test.pem解决文件权限
  • SSH登陆成功后,想退出直接输入exit即可

分析

  1. 本地终端Terminal或iTerm2均可登陆成功,WebShell不可以,WebShell中用到了node模块ssh2。同使用该模块的shell产品,如tabby/electerm,均登陆失败,因此可确定跟ssh2模块实现有关。
  2. ubuntu22.04是2022年4月发布的新系统,使用老版系统是发现没有该问题,因此也跟系统升级有关,查询发现新系统默认禁用SSH--RSA签名

综上可以确定新系统关闭RSA验证引发了该问题,而本地终端可以应该该情况支持,但node下ssh2模块明显没支持。

解决方案

确定了现象/问题,解决方案有以下几种

方案1-服务器配置修改

sudo vi /etc/ssh/sshd_config

增加如下配置PubkeyAcceptedKeyTypes +ssh-rsa

重启sshd服务sudo service sshd restart

方案2-公私钥算法调整

重新创建公私钥,生成算法选其它的,比如ed25519

方案3-客户端SSH2升级

实际处理逻辑应该是本地终端一样做了处理。社区大佬已有PR,支持,在没有合并发布新SSH2包之前可以临时调整版本到关联如下commit来解决。

1
"ssh2": "git@github.com:Eugeny/ssh2.git#22735cecf1d9c118b2b8af1c2f80fe5b04996fe1",

测试以上三种方案,均可解决

不提倡的ssh-rsa

摘自OpenSSH官网的一段介绍

Future deprecation notice

It is now possible[1] to perform chosen-prefix attacks against the SHA-1 hash algorithm for less than USD$50K. For this reason, we will be disabling the ssh-rsa public key signature algorithm that depends on SHA-1 by default in a near-future release.

This algorithm is unfortunately still used widely despite the existence of better alternatives, being the only remaining public key signature algorithm specified by the original SSH RFCs.

客户端SSH2实现

Ubuntu22.04虽然默认关闭了ssh-rsa但支持rsa-sha2-512/256,而这两个摘要算法与ssh-rsa都是采用的RSA算法只是摘要算法选择的SHA2而非SHA1。因此只要客户端在签名时将ssh-rsa公钥的签名算法设置为sha2-512/256即可。

之所以登录失败是因为当前客户端在做签名时走的SHA1,而服务端已不支持

https://static.1991421.cn/2022/2022-08-27-225321.jpeg

https://static.1991421.cn/2022/2022-08-27-233926.jpeg

具体 change见https://github.com/Eugeny/ssh2/commit/22735cec

写在最后

综上RSA安全性目前还是有保证的,仅是SHA1摘要算法安全性较低,因此面对已经生成的RSA公钥并不需要过多担心,更多是注意不要使用SHA1即可

相关文档