ほほほのほ - tech

Benchmark

anonymous@undisclosed.example.com (Anonymous) — Sat, 04 May 2024 08:20:00 +0000

Benchmark

気分に応じて採取したBenchmark記録

Hardwareに関するメモ

anonymous@undisclosed.example.com (Anonymous) — Fri, 09 Jan 2015 11:46:47 +0000

Hardwareに関するメモ

手元にある各種Hardwareに関するメモ使わなくなると更新されなくなるので、日付やFirmware Revisionに注意の事

OpenGear CM4008 恐らくCM4016やCM4048でも同様

TCP/IPに於けるICMPの取り扱いについて

anonymous@undisclosed.example.com (Anonymous) — Wed, 23 Feb 2011 04:38:51 +0000

TCP/IPに於けるICMPの取り扱いについて

ただいま書きかけでございます

Abstruct

近年、TCP/IPの利用において、ICMPを全て捨ててしまうような実装が一般化している。この手法は、IPv4ネットワークにおいては実質上ほぼ問題なく動作する。しかしながら、IPv6ネットワークを利用したり、IPv4でも特別な環境では問題なることがあり得るものである。

本文書は、ICMP及びICMPv6に関して説明すると共に、ファイアウォールなどでフィルターを書く際のサンプルとなる設定情報を公開することが目的である。

はじめに

ICMPとは、Internet Control Message Protocolの略であり、RFC792にて規定されている。IPv6用のICMPv6は数回の改訂の後、RFC4443によって定義された。

本文書では、特に断りがない限り、ICMPと記載した場合、RFC792にて規定されているものを、またICMPv6と記載した場合、RFC4443にて規定されているものを示すものとする。なお、関連するRFCとして、RFC4727にてExperimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP and TCP Headersが発行されている。本文書では、この実験的な値に関しては割愛する。

正確な仕様などについては、以下のリンクより英語版を参照されたい。また、読解の役に立つように、日本語に翻訳したものへのリンクも掲載しておく。なお、日本語訳に関しては複数の翻訳があるものもあるが、今回利用した翻訳のみを掲載した。

RFC	Title	Original	日本語版
RFC792	INTERNET CONTROL MESSAGE PROTOCOL	オリジナル	日本語訳
RFC4443	Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification	オリジナル	日本語訳
RFC4727	Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP and TCP Headers	オリジナル	日本語訳

他の参考URLとして以下を挙げる。必要に応じて参照されたい。

RFCを作成された方々及び日本語版情報を集めて公開されているIshida Soさんに感謝いたします。

本文書は、私的に作成したものであり、無償かつ無保証で掲載するものである。内容は正確であることを目標に記述しているが、間違い、勘違い、曖昧な部分が含まれている可能性があることに留意して頂きたい。

ICMPとは何か？

ICMPとファイアウォール

設定例

Datalink Layerでの冗長化プロトコル

anonymous@undisclosed.example.com (Anonymous) — Wed, 02 Aug 2023 03:25:00 +0000

Datalink Layerでの冗長化プロトコル

TCP/IPを利用する際、さまざまなLayerで冗長化Protocolが定義されているが、特に利用頻度が高いのはおそらくDatalink Layer（特にEthernet)におけるそれだろう。すぐに思いつく限りでもVRRP/HSRP/CARPは思いつくし、どうやらGLBPというのもあるらしい。

Protocol Summary

以下に各プロトコルに関する簡単な説明を記載する。

HSRP

Hot Standby Router Protocolの略

Cisco(TM)によって設計・実装された冗長化プロトコル。1998年、RFC2281で説明されている。プロプラエタリ実装であり、仕様は非公開。

HSRPは非常に古いProtocolであり、現在はversion2が主流。v2でIPv6がサポートされ、実装状の改善(安定性の向上、規模拡張容易性等の向上など)もされているため、現時点で利用するならv2であるべきである。

複数のNode間で共通のIP Addressを保持し、その中から代表(Master)を選出し、Masterがパケットの転送を行う

HSRPはあくまで共通のIP Addressを選出するためのProtocolであり、動作中のRouterの各種状態(NAT状態や経路表)は同期しないので、状態をもつ上位層プロトコルの取り扱いには注意が必要。

VRRP

Virtual Router Redundancy Protocolの略

HSRPがプロプラエタリ実装であるため、さまざまな実装でHSRPで実装された機能を利用できるようにIETFで検討されたProtocol。

複数のNode間で共通のIP Addressを保持し、その中から代表(Master)を選出し、Masterがパケットの転送を行う

VRRPはあくまで共通のIP Addressを選出するためのProtocolであり、動作中のRouterの各種状態(NAT状態や経路表)は同期しないので、状態をもつ上位層プロトコルの取り扱いには注意が必要。

(2023現在)現実的には最も普及・利用されているL2 Redundancy Protocolと言えるだろう

VRRPは各種Network機器に実装されており、HSRPを開発したCisco社のNetwork機器でも利用可能なことが多い

Opensource実装

https://gitlab.com/fredbcode/Vrrpd (Moved from GitHUB)
- ~~Advanced VRRPd (Archived at 2023/04/14)~~
Keepalived
FRR Routing Daemon
rVRRPd

他多数

CARP

Common Address Redundancy Protocolの略

OpenBSD Projectによって開発された VRRP 代替Protocol。

現在、OpenBSD, FreeBSD, NetBSDは標準でKernelもしくはKernel Moduleとして取り込まれている。LinuxやmacOSなどのPlatformでは、uCARP(Userland CARP)やCARP-rsなどの実装があるが、uCARP/CARP-rsはすでにArchive状態であり、更新は停止していると思われる。

簡単な歴史

IETFは1990年代後半、Routerの冗長性を確保するためのProtocol策定作業を開始した。Ciscoはこの分野における特許を取得していたため、それをIETFに通知、1998年にはHSRPに関する特許を通知した。さまざまな議論の末、IETF VRRP WGは、Ciscoが合理的で非差別的なライセンス条件の下で第三者に特許を利用できるようにする限り、特許技術に依存したまま、VRRPを承認することを決定した。その際、VRRPはHSRPプロトコルにあった問題を解決したため、CiscoはHSRPを独自のものとして主張しつつ、VRRPも使用し始めた。

以上の経緯より、Ciscoは、OpenBSD開発チームに対し、HSRPに特許を適用することを通告した。この際に提示されたCisco側のライセンス条件がOpenSourceとしてのVRRP実装を妨げたため、OpenBSD開発チームはVRRPの代替となるCARPの開発を開始した。OpenBSDはセキュリティに重点を置いており、CARPでやり取りされる通信を保護するために暗号技術を使用するようにCARPを設計した。また、Masterを決めるためのアルゴリズムも再設計したため、CARPはVRRPと根本的に異なる実装であって、Ciscoの特許を侵害しないことが保証された。

なお、Ciscoの保持するHSRPに関する米国特許は2014年に失効したが、このHSRP/VRRP/CARPの３つのプロトコルは現在も並行して共存している。

OpenBSDにおけるCARPにはL2でのLoad Balance機構(arpbalance)が実装されているが、FreeBSD 10.0以降では(CARPが再実装されたため)LB機能は実装されていない。（それ以前のFreeBSDでLB機構が実装されていたかは確認していない)。また、NetBSDは、Manual Pageを見る限りarpbalanceは実装されてるように見えるが、確認はしていない。このARP Balance機構を利用すると、複数ホストでLoad Balanceできる可能性がある。

VRRPとの非互換性

OpenBSDプロジェクトは、CARPのために、IANAに対し一意の番号を要求したが、拒否された。OpenBSDは特許対応等のためVRRPを「公式」な配布物に組み入れられないため、OpenBSDにおけるL2での冗長化ProtocolとしてはCARPを採用した。そのため、CARPに対し、他と競合しない（予定だった）IP Protocol 112に設定し、IANAに通知した。IANAはこれに対し、返事を拒否した。IANAではプロトコル番号112をVRRPに割り当て(1998年、RFC 2338)、現在でもプロトコル番号112はVRRPによって引き続き使用されている。このため、VRRPとCARPは現在でもプロトコル番号112で衝突したままである。

ただし、プロトコル番号が衝突していても、VRRPグループIDとCARP仮想ホストIDが異なる限り、同じブロードキャストドメインでVRRPとCARPを使用することは可能である。

GLBP

Gateway Load-Balancing Protolの略

Cisco(TM)によって設計・実装された冗長化プロトコル。

HSRP、VRRP、CARPが、複数台のnodeを 1 Master(Active) - Other Slave(Standby) 構成で冗長化を図るのに対し、GLBPは Multi Master構成で利用でき、負荷分散を図れるところが特徴。分散方法を決めるアルゴリズムとしては、host-depended/RoundRobin/Weightedの３種がある。

GLBPは、グループごとに1つのAVG（Active Virtual Gateway）を選択する。他のグループメンバーは、AVGに障害が発生した場合にAVGのバックアップとして機能する。AVGは、自身を含むGLBPグループの各メンバーに仮想MACアドレスを割り当て、AVF（Active Virtual Forwarders）を有効にする。各AVFは、仮想MACアドレスに送信されたパケットを転送する責任を負う。AVFは最大4台まで存在可能である。

IOS 12.2(33)SXIでGLBPがIPv6をサポートした。

その他

上記の他にもさまざまな実装がある。以下に一部を記載する

Extreme Standby Router Protocol (ESRP)
- Extreme社製品に実装されている、高速FailoverおよびL2保護を実装したExtreme社独自プロトコル
Routed Split multi-link trunking (R-SMLT)
- Avaya社独自プロトコル
NetScreen Redundancy Protocol (NSRP)
- Juniper社独自プロトコル。元来は、Juniper社に買収されたNetscreen社の独自プロトコル
Chassis Cluster Redundant Ethernet
- Juniper社独自プロトコル。SRXプラットフォームで使用されている
Multi-active Gateway Protocol (MAGP)
- Mellanox社独自プロトコル。VRRPを元にした、Active-Acvive運用を可能にするプロトコル
VRRPE
- Brocade社独自プロトコル

Protocol間比較

項目	HSRP v1	HSRP v2	VRRP	CARP	GLBP
規格	Cisco独自	同左	RFC3768	OpenBSD独自	Cisco独自
グループ構成	Active 1台	同左	Master 1台	Master 1台	AVG 1台
グループ構成	Standby その他	同左	Backup その他	Backup その他	AVF その他(最大4台)
最大グループ数	255	4095	255	255	1024
パケット転送	Active機	同左	Master機	Master機	AVF機
ARP Requestへの返答	Active機	同左	Master機	Master機	AVG機
Virtual IP Address	未使用アドレス	同左	物理I/Fもしくは未使用アドレス	未使用アドレス	未使用アドレス
Virtual MAC Address	0000.0c07.acXX	0000.0c9f.fXXX	0000.5e00.01XX	0000.5e00.01XX	0007.b400.XXYY
	XX = グループ番号	同左	XX = グループ番号	XX = グループ番号	XX = グループ番号
	XX = グループ番号	同左	XX = グループ番号	XX = グループ番号	YY=MACアドレス番号
Hello Multicast address	224.0.0.2	224.0.0.102	224.0.0.18	224.0.0.18	224.0.0.102
Timer default	Hello 3s	同左	advertise 1s	advbase 1s	Hello 3s
Timer default	Hold 10s	同左	master-down 3s	advsket 0ms	Hold 10s
認証方式	Plane text/MD5	同左	Plane text/MD5	SHA1	Plane text/MD5
preempt	無効	同左	有効	無効	AVG:無効, AVF:有効
動作プロトコル	UDP上	同左	IP上	IP上	UDP上
動作プロトコル	UDP/IPでカプセル化	同左	IPでカプセル化	IPでカプセル化	UDP/IPでカプセル化
メッセージ送信に使うポート	1985/UDP	同左	112/IP	112/IP	3222/UDP

未整理のメモ

anonymous@undisclosed.example.com (Anonymous) — Fri, 12 May 2023 08:30:00 +0000

未整理のメモ

ここには、取りあえずのTipsを適当に置いておく。

dd

ddコマンドにkill -USR1 を送ると、現在の転送状態が表示される。知らなかった。

Adobeの無料フォント

ここで配られている。

VirtualBox

VirtualBoxを利用していると、たまにDisk容量を増やしたくなることがある。というわけで、MacOS-X上のVirtualBoxでWindows Vistaを動かしているDiskを拡張する方法。

VirtualBoxの設定コンソールで、新規Diskを作成する
VirtualBoxのCommandLine toolで以下を実行
- VBoxManage clonehd ~/VirtualBox¥ VMs/OriginalDisk.vdi ~/VirtualBox¥ VMs/NewDisk.vdi –existing
Virtualboxの設定コンソールで、Storageの設定を、OriginalDisk.vdiからNewDisk.vdiに切り替える
Windows Vistaを起動→コントロールパネル→管理ツール→コンピュータの管理→ディスクの管理を選択
1. 起動したDiskを右クリック→ボリュームの拡張を選択し、容量を増やす

これだけ。

英語の数字の表記

英語と米語でbillionの意味が違うというのは何となく覚えていたが、なんとこういうことだったのか？というのが出てたので転記しておく。

なお、塵劫記の写本次第で変化があるらしい。ここでは万進を前提（1万単位で表記が変わる）を採用しているものとする。

Number of zeros	U.S. & scientific community	Other countries	日本
3	thousand	thousand	千
6	million	million	百　　　万
9	billion	1000 million (1 milliard)	十　　　億
12	trillion	billion	一　　　兆
15	quadrillion	1000 billion	千　　　兆
18	quintillion	trillion	百　　　京
21	sextillion	1000 trillion	十　　　垓
24	septillion	quadrillion	一　　　秄
27	octillion	1000 quadrillion	千　　　秄
30	nonillion	quintillion	百　　　穣
33	decillion	1000 quintillion	十　　　溝
36	undecillion	sextillion	一　　　澗
39	duodecillion	1000 sextillion	千　　　澗
42	tredecillion	septillion	百　　　正
45	quattuordecillion	1000 septillion	十　　　載
48	quindecillion	octillion	一　　　極
51	sexdecillion	1000 octillion	千　　　極
54	septendecillion	nonillion	百　恒河沙
57	octodecillion	1000 nonillion	十　阿僧祇
60	novemdecillion	decillion	一　那由他
63	vigintillion	1000 decillion	千　那由他
66		vigintillion	百不可思議
69		1000 vigintillion	十無量大数
69 - 120
303	centillion
600		centillion

しかし、これだとその人の背景を知らないと正しい数字を理解できないかも。困ったものである。

SVNでRepositoryを作成

これも毎回調べているので、メモにしておく。

# mkdir /path/to/repos
# svnadmin create /path/to/repos
# cd /path/to
# svn import data file:///path/to/repos -m "Initial Import"

CVSでRepositoryを作成

毎回調べているので、メモにしておく。

# mkdir /path/to/repos
# cvs -d /path/to/repos init
# cd /path/to/data
# cvs import -m "Strings" modulename vendorTag ReleaseTag

例

# mkdir /REPOS/CVSroot/MUNCHKIN
# cvs -d /REPOS/CVSroot/MUNCHKIN init
# cd ~/Work/code/munchkin
# cvs import -m "Munchkin initial" munchikin seirios 1.0

TCP Stream に file を cat する

普通は、こんな事をする必要がないんだが、どうしてもこの手を使わないといけないことがあったので、やり方のメモ。

netcatをinstallする
catしたいファイルを作成する(for ex. t)
nc server port < t

これでなんとかなる。

なお、今時のFreeBSDには nc は標準で入っている

対ARP Spoofing

ちょっと気になったのでARP Spoofing対策手法を調べてみた。

本当は、Xen Domain 0 の bridgeを使って、pfで色々頑張るか、bpfで頑張るのが筋だと思うんだけど、今の状態では難しいので、staticにarpを切る方法を。

# see man arp(8)

# arp -s hostname MACaddrs
もしくは
# arp -f filename
# cat filename
hostname1 MACaddr1
hostname2 MACaddr2
....
#

として、MAC Addressをstaticに書いておくのがよさそう。ただ、VRRPとかRIPで頑張っている場合などはちょっと問題。

まぁ、defaultを見てMACアドレス書き換えるような奴が現れたら考えよう。

そうそう、当然だけど、ICMP Router RedirectはDomain0で防御するのが吉です。

Web Redirect

いつも忘れてしまうので、メモ

取りあえず、5秒で http://some.where/URL/に飛ぶようにするMETA Tag.

<META HTTP-EQUIV="Refresh" CONTENT="5; URL=http://some/where/URL/" />

OSの安全性

ISO/IEC 15408でOSに関する安全性が規定されている。
もともとはTCSEC/ITSECであり、これが統合され、ISO/IEC15408 Common Criteria(CC)として定義された。

CCはセキュリティの評価基準であり、7段階の評価保証レベル(Evaluation Assurance Level / EAL)が規定されている。

CCは日本でも取り込まれ、JISECとして公表されている。

CC EAL	ITSEC	TCSEC	Description
EAL1	E0-E1	D-C1	機能テスト
EAL2	E1	C1	構造化テスト
EAL3	E2	C2	方式的テスト、及びチェック
EAL4	E3	B1	方式的設計、テスト及びレビュー
EAL5	E4	B2	準形式的設計、及びテスト
EAL6	E5	B3	準形式的検証済み設計、及びテスト
EAL7	E6	A	形式的検証済み設計、及びテスト

機器故障率とMTBF

MTBF

Mean Time Between Failureの略であり、機器もしくはパーツ単位での単体平均故障時間を表す。
MTBFが長いほど機器は故障しにくいことを意味する。
このMTBFを用いて、機器の保守対応や予備機材購入、システムの冗長化手法を数値化して検討することが可能になる。

機器故障率

機器の故障確率はMTBFを元に計算できる。
MTBFが同一の機器の場合、単体MTBFを機器数で割った値が同一機器群における(少なくとも1台が壊れるまでの)時間となる。
たとえば、MTBFが3年の機器が36台あるとすると、
3年 ÷ 36台＝ 36ヶ月 ÷36台＝ 1ヶ月／台
となり、1ヶ月に1台程度の頻度で機器が故障する可能性が高いと想定できる。

システム全体の故障機器発生確率を求める場合の例を以下に記載する。

例）故障確率がそれぞれ 1台/1ヶ月、1台/2ヶ月、1台/3ヶ月である機器群によって構成されたシステムの故障確率は
 1/1 + 1/2 + 1/3 = 11/6
従って、システム中の機器が故障する確率は6ヶ月に11台

以上の計算から、上記例の場合、おおむね1月に2台弱の機器が故障すると予測できる。
但し、上記計算は、「何が壊れるのか」は述べていない。また、当然「実際に壊れる台数」を述べている物でもない。あくまで確率であることに注意。

mtree

mtreeを使う。マニュアルを見ても良くわからなかったので、適当に色々やってみる。

取りあえず、Hash Listを作成するなら

# mtree -c -K sha1digest -p . > HashList

取りあえず比較するなら

# mtree -p [Dir] < HashList

でなんとかなる。

Vendor CodeとDevice Code

今回InstallしたPCでは、kernelがこんなWarningを出した。

vendor 0x8086 product 0x0326 (interrupt system, interface 0x20, revision 0x09) at pci2 dev 0 function 1 not configured

で、ちょっと調べてみた。

こういうときはGoogle様のお告げを聞こう。

なんかDriver Agent(http://listing.driveragent.com/)というサイトがある。
ここで、ちまちま調べれば、必要な情報が見つかるだろう。（でも重たい）
これよりも、The PCI ID Repository(http://pci-ids.ucw.cz/)の方がいい。早いし。

これで、8086 → Intel がわかり、0326 → 6700/6702PXH I/OxAPIC Interrupt Controller A であることがわかる。

ああ、NetBSDでは対応していないっぽいなぁ。

Opensslで証明書の情報を見る

RemoteのSSL接続サーバーの証明書の情報を見る方法

openssl s_client -connect [URL]:443 < /dev/null 2> /dev/null | openssl x509 -noout -subject -dates

AESNIの計算速度をOpenSSLで測る

anonymous@undisclosed.example.com (Anonymous) — Wed, 03 Jun 2015 06:15:17 +0000

AESNIの計算速度をOpenSSLで測る

OpenSSLを用いて、演算速度(暗号演算性能)を測定する。

FreeBSDの場合(AES-NIなし): /usr/bin/openssl speed aes-256-cbc
FreeBSDの場合(AES-NIあり): /usr/bin/openssl speed -engine cryptodev -evp aes-256-cbc

測定結果

以下 AES256-CBCでの測定結果

HP DL365G5 / AMD Opteron 2384 2.7GHz / XenServer 6.5SP1
FreeBSD 10.1 PVHVM / vCPUx2 / 2048M / OpenSSL 1.0.1l-freebsd 15 Jan 2015

type	16 bytes	64 bytes	256 bytes	1024 bytes	8192 bytes
no AES-NI	54914.45k	58765.42k	60038.89k	155310.19k	155993.34k

HP DL360Gen8 / Intel Xeon E312xx 1.79GHz / XenServer 6.5SP1
FreeBSD 10.1 / vCPUx1 / 1024M / OpenSSL 1.0.1l-freebsd 15 Jan 2015

type	16 bytes	64 bytes	256 bytes	1024 bytes	8192 bytes
no AES-NI	47192.64k	50545.86k	51148.71k	110930.60k	113857.88k
AES-NI	234559.88k	245204.99k	249549.28k	248483.50k	249318.06k

Lost Password and Clear to Factory Default

anonymous@undisclosed.example.com (Anonymous) — Mon, 15 Oct 2018 08:02:52 +0000

Lost Password and Clear to Factory Default

ハードウェアの初期化とパスワード復活方法

Cisco2621 初期化方法

Cisco 2600のパスワードリカバリー方法

もし、以下の設定が入っている場合、うまく復旧できない。

no service password-recovery

この場合、起動時に

PASSWORD RECOVERY FUNCTIONALITY IS DISABLED

が出るので、諦める？？

一応、cisco曰くstartup configurationが壊れるが復旧可能とあるが、うまく行かなかった。なぜ？？

ciscoのConsoleポートにシリアルケーブルを繋ぐ
- 9600 bps, 8 bit, non-parity, stop-bit 1の設定をする
電源を入れる
Break信号を送る。
- FlashのイメージをDecompressしている時にBreakすること
confreg 0x2142を入力
Power Cycleを実施
- rommonからresetを入力すればよい
これで初期設定モードで立ち上げるので、最初の質問にnoを応える
loginして、write eraseする

以下を実行

router# configure terminal
router(config)# config-register 0x2102
router(config)# end
router#

reloadする

Netscreen 初期化方法

もう、Netscreen25なんてわざわざ記録しておく必要は無いと思うけど、一応。

Hardwareに貼ってあるシールからシリアル番号を取得する
Serial Consoleを接続する
ID, Password共に、メモしたシリアル番号を入力する
自動的に初期化プロセスが動き出す
終了

opengear CM4008 Password Recovery and Initialization and Firmware Update

opengear製CM4008は、便利なConsole Serverであり、また、Monitoring Proverとしても利用できる。

このHardwareの初期化に関して。

電源を入れる
背面にあるERASEボタンを2度押す
初期化完了

これで、IP Address: 192.168.0.1 User: root, Password: defaultで、sshでloginできる。

もちろん、Webからも、https://192.168.0.1でlogin可能。

Firmwareの更新は、以下の方法で。

Webでloginし、最上段にあるFirmware Revisionを確認
ftp://ftp.opengear.com から最新のcm4008*.flashを入手
Administration : System : Firmwareを選択
Firmware Upgrade Fileのchooseボタンで、更新するファイルを選択
これでFirmwareの更新は終了

AP7900 Password Recovery and Initialization

APC(http://www.apc.com/index.cfm) AP7900(Switched Rack Mount PDU)のパスワード消去方法

以下の作業は、各電源には影響を与えないはず。

Serial Cableを刺す。
- AP7900のSerial Cableは特殊なので注意
Terminalから接続し、“User Name :“のPromptが出るのを確認
Network Management Cardのリセットボタンを押す
- Status LEDが橙色と緑色の早い点滅になるはず
再度Network Management Cardのリセットボタンを押す
- Terminalからの接続が切れるので、再度Terminalから接続する
- Status LEDが消灯した後、緑色で点灯する
30秒以内にTerminalから”Enter”を押して、“User Name :“のPromptを出す
Loginする
- User ID: apc
- Password: apc
新しいパスワードを設定する

結構時間がかかるので注意

初期化する場合、以上のpassword recover作業後、

AP7900にLoginする
3 Systemを選択
4 Toolsを選択
4 Reset Only TCP/IP to Defaultsを選択
2 Reset to Defaultsを選択
“ESC”を数回押してTopに戻る
4 Logoutを選択し、Logoutする
しばらく待つと初期化される

初期状態のUser IDはapc、Passwordはapcとなる

RAIDについて

anonymous@undisclosed.example.com (Anonymous) — Sat, 03 Sep 2022 13:10:00 +0000

RAIDについて

昔書いたRAID規格の整理表。

実質RAID50/51はいらないかなぁ。まぁ、メモって事で。

http://ja.wikipedia.org/wiki/RAID
規格	説明
RAID0	耐故障性のないディスクアレイ方式。複数のディスクをつなげて単純に1台に見せる。コンキャットネートディスク(Concat)ということもある。
RAID1	二重化(ミラーリング/Mirror)方式。複数台のディスクを完全に同期させ、同一の情報を持つ完全なコピーとして動作させる。耐障害性に優れているが、効率は悪い。また、RAIDの最大の弱点であるコントロー>ラーの故障にも対応しやすい。RAID1は最低でも2台のHDDが必要である。
RAID1+0	RAID0によってConcatしたDiskをRAID1によってMirrorすることによって作られるディスク。大容量で、完全に二重化されているため、耐障害性に優れている。なお、RAID0とRAID1を組み合わせて利用する場合、先にRAID1を用いてMirrorしたDiskをRAID0を用いてConcatするべきである。これは、Concatするディスクがすでに二重化されているためにRAID0を構成する全ディスクの耐故障性が高まってるからである。
RAID2	ビット単位での専用誤り訂正符号ドライブ方式。ハミングコードを用いたECCによる冗長化機構を利用しているため、全RAID中もっとも耐障害性に優れている。現在のHDDの信頼性は、ECCを用いる必要があるほど低くないため、RAID2を利用することはなく、市販製品もない。
RAID3	ビット・バイト単位での専用パリティードライブ方式。RAID2における誤り訂正符号作成方式を排他的論理和(XOR)によってパリティーに変換する手法に置き換え、演算コストを低減した物である。最低3台のHDDを利用し、1台を誤り訂正政府号に割り当て、残り複数台にデータを記録する。RAID5によって効率・性能が大幅に改善されたため、現在ではRAID3は利用されない。
RAID4	ブロック単位での専用パリティードライブ方式。RAID2,RAID3と同様、最低3台のHDDが必要となる。RAID3では、ビット・バイト単位で誤り訂正を行うため、I/O効率が低い。この問題をブロック単位で扱うことによって改善した物である。RAID5によって効率・性能が大幅に改善されたため、現在ではRAID4は利用されない。
RAID5	ブロック単位でのパリティー分散記録方式。RAID5は複数のハードディスクに誤り訂正符号データと共に分散させて記録することで、RAID3、RAID4のボトルネックを回避する方式であルーターだし、読み出しは>高速に行えるが、パリティー計算を行う必要があるため書き込みは遅くなる。RAID5は耐故障性、読み出し速度の面から、現在最も利用されているRAID手法である。
RAID5+0	RAID10と同様にRAID5で構成されたディスクをConcatすることで、耐故障性の高い巨大なディスクを作成する手法。近年ではHDDの大容量化が進み、RAID 50を必要とする局面はあまり無くなっている。
RAID5+1	RAID5で構成されたディスクセットをRAID1でMirrorする手法。近年HDDの大容量化が進んだため、HDD1台が故障した場合のRAID5の復旧に時間がかかるようになっている。この問題を回避するため、完全に冗長化された仕組みをもってディスクを構成する場合にRAID51を用いる。
RAID6	フロック単位での複数パリティー分散方式。HDDを最低4台必要とする。RAID5では、同時に2台のディスクが故障した場合（復旧中にディスクが故障する場合も含む）対応ができない。この問題に対応するために開発された。パリティー情報を複数作成するため、RAID 5よりもさらに書き込みが遅くなる。
RAIDZ	ZFS上に実装されたRAID同等の機能。RAID5やRAID6には、パリティ更新時に何らかの障害が発生した場合、データとパリティが一致しなくなり、システム上では正常に見えても内部ではデータ破壊が進んでいるという状態（サイレントクラッシュ）に陥るという致命的な欠点がある。またストライプ幅より小さいデータを書き込む際、全体のデータとパリティを読み込んで再計算をする必要があり、パフォーマンスが著しく低下するという弱点もある。RAIDZは常にストライプ全体への書き込みを行う。これに、コピーオンライトを組み合わせることによりRAID5やRAID6が持つサイレントクラッシュの問題を完全に回避できる。
RAIDZ1	パリティが1つのRAIDZ (RAID5相当)
RAIDZ2	パリティが2つのRAIDZ (RAID6相当)
RAIDZ3	パリティが3つのRAIDZ

RAIDの遅さ

RAID/RAIDZは、読み出し、書き込み時に、Parityを再計算して問題がないことを確認する。これは、たとえばRAID5において512Bytesのデータを読み出す場合、512*3(Disk書き込みの最小単位。最近では4Kのものもあるが分かりやすく考えるためにあえて512Bytesで考えている)の読み出しを行う。これは、読み出しに余計な時間がかかるということであり、特に細かいファイルを大量に読み出す際に性能劣化が発生するということを意味する。

RAIDによる冗長性＋容量を採るか、Mirrorによる冗長性＋読み出し速度を採るかは状況によるが、特にHDDを利用する場合、大きく効いてくるので注意が必要。特に、AppleのTimeMachineを利用するのであれば、Mirrorを利用するなどの高速化を視野に入れる必要がある。

RAIDに関する若干の考察

自宅などでRAIDを用いたNASなどを構築するときのためのメモ

前提条件

FreeBSDでZFSを利用するものとする
考慮対象は Mirror(RAID1), RAIDZ1, RAIDZ2、及びRAID0(Concat/Striping)とする
故障理由に書き込み寿命等の要件は考慮しないものとする
Mirroringを採用した場合、
- 書き込み速度は1倍、
- 読み込みは並列読み込みできるものとし、n台のDIskでMirrorをするなら単純にn倍になるとする
RAIDZを利用する場合、
- Parity計算にかかる時間は概ね無視できる（CPUに十分な計算力があると仮定）
- 書き込み速度は1倍（Parity計算を無視できるとする）
- 読み込み速度は1倍（ParityからのData再計算はしないとする）

仮定条件

Diskへの書き込みに関して、Errorは出ない

実際には、HDDからの情報読み出しにおいては、回復不能なエラーが発生する可能性がある。以下はSeagate製品のカタログから抜き出している。

Consumer向けHDDで、 1bit/10^14bit 程度
Enterprise向け高信頼HDDで 1bit/10^16bit 程度

これは、Consumer 向け2TB disk 5本で構築されたRAID5システムにおいて、一回全領域を読み出した場合、60%の確率で1bit、「回復不能」のエラーが発生する可能性があることを示している。なお、Enterprise向け高信頼HDDならば、同条件で1bitの「回復不能」エラーが発生する確率は単純に0.6%である。つまり、Rebuildを実施した場合、Consumer向けHDDでは60%の確率でRebuildに失敗することを意味する。ただし、実際には、Disk容量を100%使い切ることはないであろうことから、失敗する確率はもう少し低くなると考えられる。

注意点

以下、Disk2本でRAIDZ1を組むという本質的には無意味な設定を検討している。これは、実際には構築できない設定が含まれることを意味するが、思考実験でもあるので、注意して欲しい。

Diskが2本の場合

可能な選択は、

1	Mirror	Disk 1本分	READ 2倍	WRITE 1倍	最小破損台数2台	最大故障台数1台
2	RAIDZ1	Disk 1本分	READ 1倍	WRITE 1倍	最小破損台数2台	最大故障台数1台

の２種類。

この場合、書き込み速度は変わらないが、読み出し速度はMirrorの方が単純に2倍早くなる Diskが1台故障した場合、復旧にかかる時間は、

Mirrorの場合、単純なコピーで済む
RAIDZ1の場合、Parityからのデータ再計算が必要になるため、CPUの計算量を無駄に消費する

結論：単純にMirrorを選択すべき。

以下、同容量での組み合わせでRAID vs Mirrorという条件が発生したらMirrorのみを考慮するものとする

Diskが3本の場合

可能な選択は、

1	3本Mirror	Disk 1本分	READ 3倍	WRITE 1倍	最小破損台数3台	最大故障台数3台
2	3本でRAIDZ2	Disk 1本分	READ 1倍	WRITE 1倍	最小破損台数3台	最大故障台数2台
3	3本でRAIDZ1	Disk 2本分	READ 1倍	WRITE 1倍	最小破損台数2台	最大故障台数1台

の4種類。

結論：実際に選択可能な選択は事実上(1)か(3)となる。

これは、必要となる容量と同時故障台数予測を以ってで考えるべき

・Diskが4本の場合可能な選択は、

1	4本でMirror	Disk 1本分	READ 4倍	WRITE 1倍	最小破損台数4台	最大故障台数3台
2	4本でRAIDZ2	Disk 2本分	READ 1倍	WRITE 1倍	最小破損台数3台	最大故障台数2台
3	4本でRAIDZ1	Disk 3本分	READ 1倍	WRITE 1倍	最小破損台数2台	最大故障台数1台
4	2本でMirror、2setでMirror	Disk 1本分	READ 4倍	WRITE 1倍	最小破損台数4台	最大故障台数3台
5	2本でMirror、2setでRAID0	Disk 2本分	READ 2倍	WRITE 1倍	最小破損台数2台	最大故障台数2台

の5種類。

(1)と(4)は実質同等であるが、管理の複雑さを考慮すると、選択肢は(1)となる
(2)と(5)は容量は等価。読み込み速度は(5)の方が2倍早くなるが、故障時のリスクが(5)の方が大きくなる
(2)場合、Diskが２本破損しても稼働する
(5)の場合、DiskをA,B,C,Dとした場合、(A,B)+(C,D)という構成とし、Aが破損したと考えた場合、
- C or Dが破損した場合は、稼働する
- Bが破損した場合、(A,B)が破損し、Volume全体が破損する

となるため、3台中2台までは破損しても稼働する＝2/3=0.66台まで破損に対応できると考えられる。

障害復旧に関しては、(1)=(4)<(5)<(3)<(2)となる。

結論：実際の選択としては、(1),(2),(3)となる。これは必要となる容量に応じて検討するべき。ただし、読み出し速度が重要な局面では、(2)の代わりに(5)を選択する局面がある

Diskが5本の場合

事実上可能な選択は

1	5本でMirror
2	5本でRAIDZ2
3	5本でRAIDZ1

となる。

議論はDiskが4本の場合と同じ。ただし、Diskが4本の場合と異なり、(5)の選択肢はない

Diskが6本の場合

事実上可能な選択は

1	6本でMirror	Disk 1本分	READ 6倍	WRITE 1倍	最小破損台数6台	最大故障台数5台
2	6本でRAIDZ2	Disk 4本分	READ 1倍	WRITE 1倍	最小破損台数3台	最大故障台数2台
3	6本でRAIDZ1	Disk 5本分	READ 1倍	WRITE 1倍	最小破損台数2台	最大故障台数1台
4	2本でMirror、3setでRAID0	Disk 3本分	READ 2倍	WRITE 1倍	最小破損台数2台	最大故障台数3台
5	2本でMirror、3setでRAIDZ1	Disk 2本分	READ 2倍	WRITE 1倍	最小破損台数4台	最大故障台数4台
6	3本でMirror、2setでRAID0	Disk 2本分	READ 3倍	WRITE 1倍	最小破損台数3台	最大故障台数4台

一般の用途において、5多重は考慮の対象から外して問題ない。従って、(1)は対象から外れる。
(2)と(4)は容量が必要な場合に検討対象となる。
(4)と(6)は読み込み速度が重要な場合に検討対象となる。
- ただし、(4)は、故障条件が厳しすぎて、実質１台の故障しか許容できないところに問題がある。
  - 最小２台の故障でVolumeが壊れる。最大３台までは破損しない可能性もある
(5)は、同時故障台数の許容量は大きいが、これなら(6)の方が有効
- Diskが5本以上ある場合、RAIDZ1では同時故障の許容度が低すぎる。これで問題がない場合もあるが、復旧時の負荷を考えると(3)は外さざるを得ない

sshに関して

anonymous@undisclosed.example.com (Anonymous) — Sat, 13 May 2023 06:15:00 +0000

sshに関して

技術メモなどに色々バラバラに書いていたssh関係を一度まとめる。詳細は色々な本などにあるだろうし、過去記事のまとめ程度に抑えておく。

ssh とは

sshは、Secure Shell から名前をとった、リモート端末との通信を行うためのプロトコル、コマンドのことをいう。

大本に、rsh(remote shell)がある。rshは、Remote Shellから名前をとったもの
- 他に、telnetやrloginなどもある。何れにしても暗号化などの保護はない。なお、telnetにSSL/TLSを組み合わせたtelnetsもあるが、ほぼ利用されていない。
rshには、通信保護の機構はなく、通信内容はRPCを利用し、生データが流れていた
sshでは、RPCを利用することをやめ、ssh daemonとssh client間で暗号化された通信路を用いてデータをやりとりする

sshはRFCにより仕様が規定および公開されている。(20190925時点で調べたもの。今ではもっとあるんだろうけど、面倒だから調べてない)

RFC 4250 : The Secure Shell (SSH) Protocol Assigned Numbers
RFC 4251 : The Secure Shell (SSH) Protocol Architecture
RFC 4252 : The Secure Shell (SSH) Authentication Protocol
RFC 4253 : The Secure Shell (SSH) Transport Layer Protocol
RFC 4254 : The Secure Shell (SSH) Connection Protocol
RFC 4255 : Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
RFC 4256 : Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)

機能関係

以下、CEoR改を実装するために必要となりそうなsshの機能のみに限定してのメモ

対象とする実装は、 OpenSSH とする。これは、CEoRで管理をしたい対象がFreeBSD/OpenBSD/Linux系のOS環境であり、これらには標準的にOpenSSHが採用されているからである。

Option	Config Param name	default	descriptions
-A/-a			認証Agentの転送を許可/禁止
-D			Debug logを引数で指定したファイルに書き出す(-v/-vv/-vvv出力)
-e	EscapeChar	`~`	`文字`/`^文字` 指定文字/制御文字をエスケープ文字にする
-e	EscapeChar	`~`	none: エスケープ文字を禁止する。(Binary Dataに対して透過になる)
-F		~/.ssh/config	設定ファイルを指定する。システムdefaultは無視される
-f			sshの認証後、BackGroundに移行する
-J			引数で指定されたマシンを踏み台にして対象ホストに接続する
-J			対象ホストの名前解決ができなければならない
-L	LocalForward		Local forward
-l	User		login名
-N			リモートコマンドを実行しない (-Mと併せて使う)
-n			stdinを/dev/nullに切り替える。Passphraseなどを入力する必要がある場合 `-f` を使う
-O			-Mで作ったMasterへの制御コマンドを送る。 check: Masterがあるかのチェック
			forward: port forwardを要求 / cancel: port forwardをキャンセル
			exit: Master Processを終了する / stop: これ以上の分岐を禁止する
-o			設定ファイルと同じ形式でのオプション指定
-M	ControlMaster	no	単一のネットワーク接続において、複数セッションを共有するか
-Q			問い合わせ。cipher(対象暗号の種類)/cipher-auth(認証付き暗号化をサポートする対象暗号の種類)
			mac(メッセージ認証コードの種類)/kex(鍵交換アルゴリズム)/key-cert(証明書の鍵の形式)

-q			quiet mode
-R	RemoteForward		リモーロフォワード
-S	ControlPath		Master modeにおける制御用Socketファイルの指定
-T/-t	RequestTTY		セッションに対してTTYを要求するか？ no:要求しない/yes:要求する(-t)/forcce:強制的に割り当て(-tt)
-X/-x	ForwardX11	no	X11接続を転送するか yes:許可/no:禁止
-y			logをsysぉg経由で飛ばす。defaultではstderrに出力される
	BatchMode	no	Password/Passphrase入力を求めるか？
	CheckHostIP	yes	knwnhostsファイルのエントリーとの比較を行うか？
	ConnectionAttmpts	1	接続試行回数
	ConnectTimeout		TCP Connectionが成立するまでのTimeout時間の設定
	ControlPath		Master modeにおける制御用Socketファイルの指定
	ControlPersist		no: MasterはForegroundのまま、最初のClientが終了した直後に終了
			yes / 0 : MasterはBackgroundに移行し、永続的に保持される
			数値(秒) / 時間形式 : idleな時間が指定値を越えると接続が終了
			OpenSSH 5.6以降でのみ利用可能
	ForwardAgent	no	認証エージェントへの接続を転送するか
	IdentityFile		利用する秘密鍵
	IdentityFile		force: 常に要求 /auto: loginセッションの時だけ要求する

ControlMaster

Masterになる場合、 -M もしくは -o ControlMaster=yes を指定し、 ControlPath=[SocketFilename] を指定する。
Masterの接続を流用する場合、-o ControlMaster=no を指定し、 ControlPath=[SocketFilename] を指定する。
- ControlPathに指定されたSocket Fileがない場合には、通常の接続が行われる
-o ControlMaster=autoを指定すると、「Master接続が利用できる場合にはそれを利用、利用できない場合には自動的に新しい接続を作成」する
ControlPathの引数にはEscape Sequenceが利用できる
- %L : Localのホスト名の最初の部分
- %l : localのホスト名(hostnameコマンドの返り値)
- %h : remoteのホスト名
- %n : コマンドラインで指定された(remote)ホスト名
- %p : remoteのport番号
- %r : remoteのログイン名
- %u : sshを実行したユーザーのログイン名
- %i : sshを実行したユーザーのUID
- %C : %l%h%p%r

ControlMasterに関するCommand line

ssh -M 127.0.0.1
- Masterとして動作し、RemoteのTTYを掴む。
- 制御用socketは(FreeBSDの場合)/tmpに置かれる
- 制御用socketのファイル名を取得する方法がない
ssh -M -S [SocketFileName] 127.0.0.1
- Masterとして動作し、RemoteのTTYを掴む。
- 制御用socketは-Sの引数に記載された[SocketFileName]になる
ssh -N -f -M -S [SocketFileName] 127.0.0.1
- Masterとして動作し、Socketを作成した後sshはBackgroundに
- 制御用socketは-Sの引数に記載された[SocketFileName]になる
ssh -N -f -O exit -S [SocketFileName] 127.0.0.1
- [SocketFileName]] に紐づいたssh接続が終了する
ssh -N -f -M -S [SocketFileName] 127.0.0.1を２回起動する
- ControlMaster=auto 相当の挙動をする

shell scriptとssh

shell scriptにおいて、ファイルから1行ずつ読み込んで処理をするような場合、以下のようにかける。

while read line; do
  echo ${line}
done < file

ところが、この手を使ってsshを実行すると、なぜか最初の行しか実行されない

while read line; do
  ssh xxx.xxx.xxx.xxx ${line}	# XXX 期待通りに動かない
done < file

原因はsshコマンド実行に伴う標準入力の切替と考えられる。 sshコマンドを実行すると、ローカルホストのstdinからの入力を終了し、sshで指定したリモートホストのstdinからの入力受付を開始する。従って、ローカルホストのファイルの読込みを終了させた上でsshコマンドを実行し、再びreadコマンドを実行しようとしていると考えられる。もちろん、この時点で既にファイルがcloseされている為、whileが終了してしまう。

対策は、sshに-nオプションをつけること。これよって、sshコマンドのstdin切り替えを禁止することが出来る。

この原因がちっともわからず、数時間を無駄にしてしまった。

while read line; do
  ssh -n xxx.xxx.xxx.xxx ${line}	# これで/dev/nullがsshのstdinにつながる
done < file

このほかに、for文で for line in `cat file` で代用する手も考えられるが、これは、行にスペースがある場合、$lineに代入される値が１行まるごとではなく、スペースまでの部分になるので、ここにも明確な罠があると考えられる。これを回避するにはIFSを変えれば良いのだから、

IFS=$'\n'				# 区切り文字を" "から"\n"に変える
for line in `cat file`; do		# while readの代わりにcatで読み込ませる
  ssh -n xxx.xxx.xxx.xxx ${line}
done

あと、whileはちょっと特殊な制御文で、場合によってはwhile内で変数設定しているはずなのにloopをでてくると変数が空のようなことが起こる。これは、Whileと他のコマンドを組み合わせた場合、組み合わせ方次第で処理がsubshellがわで処理されてしまう事が原因である。 shellでpipelineを用いて実行した処理は、subshellで処理される。while loopの内部でpipelineを利用すると、whileブロック全体がsubshellで処理されるため、whileブロックの内部と外部で変数の共有が出来ない。このような場合、whileに対して出力をredirectしてやることで解決できる。

while read line; do
  OUT=`echo ${line} | sed 's/test/test2'`
done < $1
echo ${OUT}

なお、/bin/shの引数に -v や -x をつけると、デバッグに大変に役立つ

sftpとscp関連

scpには様々な問題があるということで、scpはDeprecatedになっており、sftpを利用したファイル転送を利用すべきである。

というわけで、メモ

http://d.hatena.ne.jp/cakephper/20120918/1347935609 http://f99aq.hateblo.jp/entry/20090802/1249222491

要するに、/etc/ssh/sshd_configを修正し、対象Dirをroot:wheelにすること。

ちなみに、sshd_configに ForceCommand internal-sftp を追加しないと、passwdに記載されているshellを実行しようとするので注意。

sshと二要素認証

参考

要するに、BSDでは、上記patchを当てないと出来ないが、RSA AuthenticationとChallenge Response Authenticationを組み合わせて二要素認証にするという話。

/etc/ssh/sshd_config の変更点だけ書いておく。

ChallengeResponseAuthentication yes
RSAAuthentication yes

RequiredAuthentications2 publickey,keyboard-interactive

Password Authenticationを使う事は出来ないっぽいけど、まだ試してない。

sshdでPublickeyをauthorized_keys以外から持ってくる

ちょっと某所で sshd でのPublickey Authentication時のPublickeyを~/.ssh/authorized_keys以外から持ってくる設定について聞かれたので、ちょっと調べてみた。

問題

AuthorizedKeysCommand に公開鍵を引っ張ってくるscriptを指定したんだけど、認証に失敗する
sshd_configに以下の記述
- AuthorizedKeysCommand /tmp/pubkey.sh
- AuthorizedKeysCommandUser hogehoge

pubkey.shは以下の通り

pubkey.sh

#!/bin/bash -e
echo "ssh-rsa AAAA........."

ssh -v の結果

Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

解決

sshdのlogを見ると、error: Unsafe AuthorizedKeysCommand “/tmp/pubkey.sh”: bad ownership or modes for file /tmp/pubkey.sh が/var/log/auth.logに出力されていた
色々調べてみると、以下が判明
- sshdは以下の条件のうち一つでも満たすと、上記エラーを吐く
  1. 他人に書き換えられる可能性のあるDirectoryに設置されている(/tmpとかはやばい)
  2. Ownerがrootではない
  3. Owner以外が書き換えることができる(g+wとかo+wだとまずい)
  4. AuthorizedKeysCommandUser に指定されたUser Accountで実行できない
というわけで、以下のように修正
- Scriptを/usr/local/bin/pubkey.shに設置
- AuthorizedKeysCommand /usr/local/bin/pubkey.sh としてsshd_configに設定
- chmod 750 /usr/local/bin/pubkey.sh を実行
- chown root:nobody /usr/local/bin/pubkey.sh を実行
- sshdを再起動

結論

この手法を使えば、LDAPでsshの公開鍵を引っ張ってくることができそうだ
OpenSSHはSecurity的に相当細かくCheckしているので、ある程度はこの手法を利用しても安全性を確保できそうだ
意外と問題の原因が分かりにくいので、追いかけるのが大変
俺はエスパーじゃないので、何をどうしたいのか説明してくれ

sshの秘密鍵をOS-XのKeychain Accessに登録

OS-Xでman ssh-addしていたら、-KなるOptionを発見した。そういえば、むかーしむかしに見たような気もする。

<node> -K When adding identities, each passphrase will also be stored in your

      keychain.  When removing identities with -d, each passphrase will
      be removed from your keychain.

</note>

つまり、ssh-add -K しておけば、その後はいちいちパスフレーズを入力しなくてもよくなる。

OS-Xでsshdの待ち受けポートを変更する

MacOS-Xでリモートアクセスを許可すると、sshで接続できるようになる。

しかし、/etc/sshd_configをいじってもsshの待ち受けポートが変わらないので調べてみたら、/System/Library/LaunchDaemons/ssh.plistを修正する必要があるということで、以下のように修正

       <key>Sockets</key>
        <dict>
                <key>Listeners</key>
                <dict>
                        <key>SockServiceName</key>
                        <string>65535</string>
                        <key>Bonjour</key>
                        <array>
                                <string>ssh</string>
                                <string>sftp-ssh</string>
                        </array>
                </dict>
        </dict>

このSockServiceNameの文字列sshを待ち受けたいport番号にかえればOK。なお、この例では65535にしているが、ポート番号は適当にどうぞ。

なお、当然、この変更を行った後で

% sudo launchctl unload /System/Library/LaunchDaemons/ssh.plist
% sudo launchctl load /System/Library/LaunchDaemons/ssh.plist

を実行する事。そうしないと、変更が反映されないよ。ま、再起動でもいいけどね。

sshとcron

Backupを取得するに際して、Backupを元々のServerに置いておいたら、Disk破損の時に一気に死ぬ。で、そんな事態は救われないので、BackupをRemoteに置いておくために、Backup Scriptまで作ったわけだが、Serverの内側でcronなどでBackupを取得するのは設定ミスとか管理の分散とかが起こってうれしくない。というわけで、remoteからsshを利用してBackupを取得するようにscriptを作ったのだが、

Pseudo-terminal will not be allocated because stdin is not a terminal.

などといいうErrorが出た。で、これはptyの割り付けないremoteからのコマンドは実行できないということでsshが吐き出すErrorである。

しかし、shell scriptには-tは記載されていて、ちゃんと動くはずだとどはまりをしたわけで…

で、困りに困って調べてみたら、出てました。man ssh

 -t      Force pseudo-tty allocation.  This can be used to execute arbitrary screen-based pro-
         grams on a remote machine, which can be very useful, e.g. when implementing menu ser-
         vices.  Multiple -t options force tty allocation, even if ssh has no local tty.

よく見たら、Multiple -t options force tty allocation, even if ssh has no local tty.だそうな。

要するに、-t -tとしろと。

わかりにくいからメモにしておく。

教訓は、RTFM … orz.

古いNetwork機器に対するssh接続

うちの環境にはいまだに古いAlaxalAのL2 SwitchやApresiaのL3 Switchがあるのだが、これが古いssh protocolをしゃべる。そのため、2023/05時点のmacOS(Ventura/13.3)だとsshで接続しようとした時にsshの暗号化パラメータ(鍵交換や暗号アルゴリズム)が対応していなくて接続できなくなる。

その解消のためには、~/.ssh/configに以下のような設定を入れておくこと。

# for AlaxalA AX2430S
Host [IP Address] [alias name] ...
        HostKeyAlgorithms       ssh-dss
        KexAlgorithms           +diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

# for Apressia
Host [IP Address] [alias name] ...
        KexAlgorithms           +diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

VMware関連

anonymous@undisclosed.example.com (Anonymous) — Sun, 01 Oct 2023 12:40:00 +0000

VMware関連

VMwareはメインで利用するHypervisorではないので、何かやった時に記録するだけ

vSphere 6.7

Vuls関連

anonymous@undisclosed.example.com (Anonymous) — Mon, 26 Sep 2016 02:44:27 +0000

Vuls関連

BBTのBlogに書いた記事 Vulsを試してみよう
VulsまつりでのLT資料 PCI/DSSとVuls @2016/09/26 Vulsまつり LT資料

ほほほのほ - tech

Benchmark

Benchmark

目次

Hardwareに関するメモ

Hardwareに関するメモ

TCP/IPに於けるICMPの取り扱いについて

TCP/IPに於けるICMPの取り扱いについて

目次

Abstruct

はじめに

ICMPとは何か？

ICMPとファイアウォール

設定例

Datalink Layerでの冗長化プロトコル

Datalink Layerでの冗長化プロトコル

Protocol Summary

HSRP

VRRP

Opensource実装

CARP

簡単な歴史

VRRPとの非互換性

GLBP

その他

Protocol間比較

未整理のメモ

未整理のメモ

dd

Adobeの無料フォント

VirtualBox

英語の数字の表記

SVNでRepositoryを作成

CVSでRepositoryを作成

TCP Stream に file を cat する

対ARP Spoofing

Web Redirect

OSの安全性

機器故障率とMTBF

MTBF

機器故障率

mtree

Vendor CodeとDevice Code

Opensslで証明書の情報を見る

AESNIの計算速度をOpenSSLで測る

AESNIの計算速度をOpenSSLで測る

測定結果

Lost Password and Clear to Factory Default

Lost Password and Clear to Factory Default

Cisco2621 初期化方法

Netscreen 初期化方法

opengear CM4008 Password Recovery and Initialization and Firmware Update

AP7900 Password Recovery and Initialization

RAIDについて

RAIDについて

RAIDの遅さ

RAIDに関する若干の考察

前提条件

仮定条件

注意点

Diskが2本の場合

Diskが3本の場合

Diskが5本の場合

Diskが6本の場合

sshに関して

sshに関して

ssh とは

機能関係

ControlMaster

ControlMasterに関するCommand line

shell scriptとssh

sftpとscp関連

sshと二要素認証

sshdでPublickeyをauthorized_keys以外から持ってくる

問題

解決

結論

sshの秘密鍵をOS-XのKeychain Accessに登録

OS-Xでsshdの待ち受けポートを変更する

sshとcron