免费、好用的ssh客户端 tabby

之前用的比较多的ssh客户端主要是:xshell、MobaXterm,也使用了多年,当然主要是使用的免费版,能用是能用,但由于免费版的限制总是有诸多不便,若使用破解版难免密钥不被泄露。 近期试用了一下tabby,感觉非常不错。 Tabby Tabby(原名 Terminus)在我理解就是一个非常好用的ssh客户端,当然也是支持串口通讯等,支持windows、linux、mac系统,当前并未出正式版,但是这个Alpha用起来基本也没啥影响使用的问题。 官网地址:https://tabby.sh Github地址:https://github.com/eugeny/tabby 简单使用方法 1. 下载版本 下载地址:https://github.com/Eugeny/tabby/releases 我们直接下载绿色版即可。 解压至当前目录,在tabby目录中建立data目录,否则所有的配置在系统的user目录下,建立data目录后,所有的配置都会存储在该目录。 2. 配置 tabby配置跟xshell、mobaxterm稍有不同,需要打开 settings – Profiles & connections 里添加 配置。 然后可以通过配置快捷键或者 直接点击窗口最上方的按钮快速选择对应的服务器,这点要比xshell、mobaxterm也是要方便不少。 配置同步 可以自己配置私服服务器进行所有配置资料的同步。 当然如果不想自动同步也可以,直接将config file 拷贝到另一台电脑,只要key的路径全局替换一下,就完成了配置的全部迁移,非常方便。 上述两方式都不想用的话,可以直接用网盘、nas配置同步目录,在不同的电脑将tabby的配置目录直接做同步即可,也可达到所有电脑自动配置同步的目的。 当然我们常用的sftp功能也是支持的。

端口转发导致403错误的解决办法

一、业务背景 有一位客户,目前是要做三级等保,原来的服务器直接在网闸上做了端口映射即可。 客户规划现在将该服务器放到纯内网环境中,内网连接网闸,若需要访问外网,内网访问网闸映射到 可以访问外网的跳板机。这些规则我们无法改变,我们只能考虑一下如何实现即可。 二、实现方式 做法呢,就是在这个跳板机上做一个端口映射 比如内网机器(内网IP是:172.16.2.98)要访问某服务的API,例如要访问 api.jiucool.org,跳板机的IP是:192.168.8.88 , 我们则在 192.168.8.88 机器上做一个端口映射,这里端口映射工具我们可以使用 rinetd、socat、nginx 的socket转发均可。 配置好以后,我们只需要在内网机器上修改 /etc/hosts文件 ,将api.jiucool.org 解析至网闸(网闸映射到192.168.8.88),这样我们访问api.jiucool.org的请求,就转到了 192.168.8.88 机器,然后再将请求转发至真正的服务器。 三、出现的问题 之前有客户提出类似的需求,这种方案是没有问题的,但这次需要访问的API当中,部分正常,部分异常报出403的错误。 四、解决办法 有问题的API服务,经过检查,正常非转发请求,是完全正常的,一旦经过转发就是会报403,对比一下,其实只有header请求的不同。 我们在请求API时,显示的来指定header当中的Host值即可。 因为出问题的这些API是在服务端检查了host绑定关系 ,若与server当中配置的不相等则返回403异常码。 假如该api服务器绑定的ip地址是:223.5.5.5,我们则进行显示绑定,绑定之后,则一切正常。 curl -k -H “Host: 223.5.5.5” https://192.168.8.88

AdGuard Home 净化家庭网络环境

前几个月在家里的服务器上安装了AdGuard Home软件,然后将系统的默认DNS修改为adguard home的地址,开启了整个网络的净化功能。 AdGuard Home 是啥? 官方介绍:AdGuard Home 是一款用以拦截广告与跟踪器的全网络支持软件。在您设置完毕后,它将覆盖您家庭内的所有设备,您无需在客户端再进行任何设置。 工作原理 AdGuard Home 作为 DNS 服务器以重新路由跟踪域到 “黑洞”,从而防止您的设备连接这些服务器。 说白了,就是将各种广告跟踪的服务域名屏蔽解析,让它们无法连接到服务器从而避免被跟踪,被广告骚扰的目的。 哪些类型不能屏蔽 对于部分APP软件使用了 httpdns,这种类型的是无法屏蔽的。 因为HTTPNDS 不走传统的 DNS 解析,而是使用基于 HTTP 协议的 DNS 服务。 当客户端需要 DNS 解析的时候,直接通过 HTTP 协议进行请求这个服务,得到就近的地址。 使用效果如何 下图显示的是最近30天的使用效果,可以将大部分的广告跟踪服务进行拦截。 根据记录发现家里的这些物联网设备,连接是最频繁的,由于家里买了些美的的家电,一个月dns解析次数都达到了20万次,确实很多。 拦截排行榜里可以看出,对用户跟踪最为频繁的当属腾讯、阿里两家,将这些屏蔽了不影响正常功能。 另外还可以根据需要进行自定义拦截,比如先在后台拦截淘宝、天猫,可以跟媳妇说最近淘宝、天猫出问题了,无法访问了,这样晚上在家就不能进行购物了,哈哈。 从上图可以看出,其实整体的网络请求当中,有接近一半其实是无效请求,这些无效请求主要包括广告、网络跟踪服务。这些无效请求大大拖慢了网络整体速度,也严重影响了上网体验。 开启后,网络的平均dns解析时间为7ms,比正常的dns解析时间还是要快不少的。 拦截规则 当然啦,官方提供的adguard home,只是一个工具,若不开启任何规则的话,也是没有任何效果的。具体的拦截功效主要看你的拦截规则是否准确。 这里比较推荐的几个如下: https://raw.githubusercontent.com/privacy-protection-tools/anti-AD/master/anti-ad-easylist.txt https://easylist-downloads.adblockplus.org/easylistchina+easylist.txt https://adguardteam.github.io/AdGuardSDNSFilter/Filters/filter.txt https://banbendalao.coding.net/p/adgk/d/ADgk/git/raw/master/ADgk.txt https://easylist-downloads.adblockplus.org/easyprivacy.txt

2021冬天的冷已让人瑟瑟发抖

上周还是温暖如春的感觉,只身穿一层薄薄的运动外衣就行,这周突然冷的让人瑟瑟发抖。 周一开始已经温度大降,大街勿勿的行人都已经换上的厚厚的羽绒服。 昨天回家看到家里客厅温度差不多在17度左右。 而书房由于在北边温度居然低到了10度左右。 软路由在书房,打开软路由后台,发现待机时,软路由温度已经降到了25度左右,下面带机数量大概在十几个。作为CPU这个温度确实是有点低。 天气变冷,尚未正式供暖,现在处于预热期,其他小区暖气已经很热,同事家里已经达到25度以上,热电集团通知正式供暖要11.20。 由于新小区供暖户数不足,在热电集团那边还签订了不保证供暖效果的协议,若不达标人家是不管的。希望今年的供暖效果能给力一些。

给自己升级一下办公装备

一、现状 由于偶尔要临时出差,所以公司给所有研发人员配备的都是thinkpad系列的笔记本,至于自带的外设,只能说就是能用而已。 所以大家一般都会自己配备一套外设。 之前一直是用的普通版本的雷蛇套装,对于不玩游戏的我来说,还是够用的。 找了一下记录,最近一次购买鼠标大概是在2018年,键盘是在2020年,对于基本办公来说还是不错的。 只是要吐槽一下这个雷蛇键盘,对于这款非机械键盘来说,手感还是非常不错的,也挺舒服,最大的缺点就是上面的字母掉色,刚买回来几个月字母就掉色看不清,当然对于我们经常用键盘至于有没有字母都能准确的按键。 最大的问题是太丑了,看到键盘上白茫茫的一片让人真是感官不好。 至于雷蛇的鼠标用了这么多年还是挺好没啥问题,最早之前用的罗技,用坏两个之后就一直使用雷蛇,感觉还是比较满意。 二、升级新的装备 总体来说更换升级这些个设备,都是为了提升自己的办公舒适度,让自己可以更舒心、舒服的投入到工作中,嗯 ,从这个角度来讲还是很好的。工作好了,升职、加薪有望啊,哈哈 2.1 新的人体工学椅 原来并没有想更换这人体工学椅,正好被同事不断的勾引,后来也想了想,大部分时间都是在办公室里的,本着对自己负责任的态度还是决定跟同事一起升级一把。 最终同事一起,我们一起下了三单,选择的型号是金豪B的高配版本,外加一个躺舒宝,赠送一个挂衣架。为啥选择这款呢,其实之前也不太懂,上个月同事用了这款感觉还算OK,也就跟风了。 2.2 新的机械键盘 之前的用的【雷蛇(RAZER) 萨诺狼蛛Cynosa】这款键盘功能、手感都不错,就是字母掉色以后比较丑,决定就放家里临时晚上办公用吧。 购买了一款相对比较便宜的机械键盘,pbt键帽,性价比还是蛮高,到手300元的价格即可搞定,这个手感也确实不错,用了几天感觉这个颜色基本是不会掉,不存在之前的问题。 这款键盘用来办公,性价比高,声音不会很大,也很舒适。 至于鼠标呢,之前的雷蛇仍在服役中,并且一点问题没有,也没有必要更换。

gitlab 13.x 升级至 14.x 哈希存储转换问题

一、 问题:migrate_to_hashed success,但实际未成功 gitlab 14 版本起,全面启用哈希存储,如果从13.X版本直接升级到14.X版本,且其中的传统存储未进行转换的话,将会升级失败,有如下提示: 所以我们需要在13.X的最后一个版本,当前13系列最后一个版本为:13.12.12 ,将传统存储转换为哈希存储: 但实际上这边遇到了一个奇怪的问题,每次迁移时都提示成功,多次执行都返回如下内容: Enqueuing migration of 41 projects in batches of 200. Done! 二、解决办法 如果传统存储转HASH显示成功,实际没有成功的情况,可以更新下令牌重新转HASH就可以。 具体如下: #进入数据库终端 gitlab-rails dbconsole #执行清空命令 UPDATE projects SET runners_token = null, runners_token_encrypted = null; #退出 exit; # 然后重新执行 hash转储命令,校验后发现已经迁移成功! gitlab-rake gitlab:storage:migrate_to_hashed


正在读取数据……