技術者見習いの独り言

このブログを検索

テスト

日付: 1月 20, 2011 0 Comments

リンクを取得
Facebook
×
Pinterest
メール
他のアプリ

投稿テスト

リンクを取得
Facebook
×
Pinterest
メール
他のアプリ

ssh-rsa，非推奨のお知らせ

2020-05-28T14:11+9:00 追記これは SHA-1 を用いた RSA 鍵についての話で，OpenSSH 7.2 以降で生成・利用される RSA 鍵はまだ利用可能です 2020-05-28T19:27+9:00 追記既に生成されている RSA 鍵でもホスト・クライアントの両方が OpenSSH 7.2 以降ホスト・クライアントの両方が OpenSSH 7.2 以降，ただしサーバー側は OpenSSH 7.4 以外であれば SHA-2 で署名するので大丈夫なようです。（OpenSSH 7.4 はバグがあるようです） ssh-rsaという名前は"公開鍵の形式"と"公開鍵を使った署名方式"の二つで使われていて、廃止対象となっているのは署名方式の方だけです。なのでOpenSSH 7.2以降を入れれば、鍵自体は古いOpenSSHで生成した物がそのまま使えます。 — いわもとこういち (@ttdoda) May 28, 2020 openssh-unix-devで指摘が出ていますが、OpenSSH 7.4のバグで、サーバ側が7.4だとrsa-sha2-256/512が使えると通知してこないのでssh-rsaでユーザ認証が行われてしまいます。これはユーザ認証時のみの問題で、ホスト鍵の確認には影響しません。 https://t.co/oyNVS08jGI — いわもとこういち (@ttdoda) May 30, 2020 本文 OpenSSH 8.3 がリリースされたとのこと OpenSSH 8.3 released (and ssh-rsa deprecation notice) [LWN.net] これに伴ない，ssh-rsa は将来的に deprecate になり，デフォルトでこの鍵形式を利用する機能自体が無効化されることが改めて告知されました。サーバー側がこの形式を利用しているかどうを確認するには，`HostKeyAlgorithms` ディレクティヴから ssh-rsa を取り除いた上で以下のコマンドを使うこと ssh -oHostKeyAlgorithms=-ssh-rsa user@host `HostKeyAlgorithms` は ~/.ssh/config で利用する...

tar(1) はなぜオプション引数にハイフンが不要なのか？

TL;DR tar(1) の引数はオプションではなく key だから歴史 tar(1) は Unix v7 (1979) で導入されたが、その前身は Unix v4 (1973) の tp(1) 、更にこれは Unix v1 (1971) の tap(1) に遡る。 80年代に入りSystemV v.s. BSDといったことが起きたりし、PWB/UNIX (Programmer's WorkBench)で導入された cpio(1) と tar(1) 、どちらがUnixの標準アーカイバか争われた結果、IEEE Std. 1003.1-2001 (POSIX.1-2001) を以って tar(1) は規格から削除され、代わりに IEEE Std 1003.2-1992 で導入された折衷案の pax(1) が標準となった。よって、現在実装中立な tar(1) の仕様書がそもそも存在しない。最後の中立規格は1997―1998年策定のSUSv2 (UNIX V98) の仕様となる。ちなみに、Unix v4 は C 言語が導入されカーネルやコマンドが全面的にアセンブリから C に書き直された歴史的なリリースで、PWB/UNIXは Unix v6 を fork して世界最大のユーザーを抱えるサイトとしてベル研究所内部で運用された Unix バージョン。様々な開発者向けのコマンドが開発されたようだ。たとえばバージョン管理システムの祖先、 sccs(1) はPWB/UNIXが初出。（なぜかこちらは、DEVELOPMENT コマンドという註釈つきで現行の IEEE Std. 1003.1-2017 な POSIX に残っている。）仕様 tap(1) の頃から一貫して、 NAME tap -- manipulate DECtape SYNOPSIS tap [ key ] [ name ... ] DESCRIPTION tap saves and restores selected portions of the file system hierarchy on DECtape. [..] The function p...

MTU，MSS の計算と最適化の便利な手段をまとめる

MTU/MSS の計算 IP ヘッダや Ethernet フレームの計算は結構大変だけれどもこのサイトを使えばわりとラクに導出できます。 https://baturin.org/tools/encapcalc/ たとえば MTU 1454 の環境（フレッツ網で ISP と PPPoE で接続した場合）の MSS は次の画像のとおり 1414 と計算可能です。この MTU 1454 の根拠は，フレッツ網では PPPoE で接続する際，NTT の収容ビルから事業者装置までの間は L2TP で接続しており，そこで PPPoE ヘッダを認証用の PPP ヘッダだけ残して取り払い，PPP over L2TP の状態にすると，IP (20 byte) + UDP (8 byte) + PPP (2 byte) + L2TP (16 byte) = 46 byte なので，1500 - 46 = 1454 byte になります。参考サイトさきほどのサイトでは L2TPv3 の計算はできるけど L2TP の計算が出来ないのが惜しいところ。 MTU の最適化前述の手段で計算した値をルーターやクライアントに設定しても良いですが，既に通信が可能な環境ならばヒューリスティックに最適な MTU を導出することもできます。 ping コマンド PS C:\Users\orumin> ping -f -l 1424 -n 1 8.8.8.8 8.8.8.8 に ping を送信しています 1424 バイトのデータ: 8.8.8.8 からの応答: バイト数 =68 (1424 を送信) 時間 =3ms TTL=119 8.8.8.8 の ping 統計: パケット数: 送信 = 1、受信 = 1、損失 = 0 (0% の損失)、ラウンドトリップの概算時間 (ミリ秒): 最小 = 3ms、最大 = 3ms、平均 = 3ms たとえば Windows なら，このようにして ping のパケットサイズを指定し DF ビットを立てます（＝分割を禁止する）。こうすると，MTU を超過するようなパケットを送出すると以下のようになります。 PS C:\Users\orumin> ping -f -l 1425 -n 1 8.8.8.8 8.8.8...

Powered by Blogger