OS とデフォルトバージョンのリストを見ると、現在主要な OS は ed25519 鍵に対応しているし、 OpenSSH 7.3 以上であれば、今回紹介する方法は実現できる。のでどれか一つでも試してみましょう。 ファイル構造 ¶複数の端末を使う場合、 dotfiles にして Git で管理することになる。 この場合管理対象が増えてくると構造化して案件やプロジェクトが終了したら ~/.ssh/conf.d/nodes/ の設定ファイルで Include をやめるか conf.old のように名前を変えれば接続先には出ず、不用意にアクセスすることを防止するが設定は保管しておくことができる。(結構、廃止したプロジェクトでも過去のアクセス情報を探すのに ssh/config を確認するケースは多い) $ tree ~/.ssh ~/.ssh ├── conf.d conf はすべてここに入れる
To make it quick, I wish I had known about port forwarding and tunneling earlier. With this blog post, I try to understand it better myself and share some experiences and tips with you. Topics: use cases, configuration, SSH jumphosts, local/remote/dynamic port forwarding, and limitations Use cases # SSH tunneling and port forwarding can be used to forward TCP traffic over a secure SSH connection f
今回は、SSH接続を劇的に高速化する方法をご紹介します。たった3行の設定を追加するだけで、接続時間を10分の1に短縮できます。しかも、2回目以降の接続では認証も自動的に行われるので、パスワードやパスフレーズの入力も不要になります。 要点 .ssh/configファイルのHost *セクションに以下の3行を追加するだけです。 詳しい説明 1. ControlMaster auto この設定で、1つのSSH接続で複数のセッションを共有できるようになります。新しくSSH接続を確立するたびに認証情報を入力し直す手間が省けて、接続がぐっと速くなります。具体的には： 初回の接続時のみ認証が必要 2回目以降は既存の接続を再利用するため、認証プロセスをスキップ パスワードやパスフレーズの入力が不要になり、接続がほぼ瞬時に完了 2. ControlPath ~/.ssh/mux-%r@%h:%p Contr
IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1Password/t/agent.sock" という設定を書いておくと秘密鍵を1Passwordから出すことなくサーバに接続することができます。 こちらの内容については下記ブログなどをご参照ください。 https://dev.classmethod.jp/articles/1Password-git-ssh/ 私はこの方法を愛用していたのですが、 ある日次のエラーが出るようになりました。 Received disconnect from UNKNOWN port 65535:2: Too many authentication failures Disconnected from UNKNOWN port 65535 内容としては、許容されるパスワード試行回数をオーバーしたた
Everything I Know About the XZ Backdoor stateevergreeninblogtagsopen-sourcedate3/29/2024licenseCC BY-SA 4.0This publication was last updated at 12:49 PM EST on April 8th Recently, a backdoor was discovered in XZ, a popular library for lossless data compression. Initial research efforts were predominantly concentrated on unpacking the well-disguised attack vector, while the social aspects of the at
Red HatやDebianを含むLinuxディストリビューションで広く使用されている圧縮ツール「xz」の最新版に悪意のあるバックドアが含まれていた事がわかりました(Ars Technica)。 発見した開発者のAndres Freund氏は、xz version 5.6.0と5.6.1に悪意のあるコードが含まれていることが分かったと指摘しています。幸い、このバージョンは主要なLinuxディストリビューションの製品リリースでは使用されていませんが、Fedora 40やFedora Rawhide、Debian testing/unstable/experimentalなどのベータ版リリースには含まれていたそうです。 macOSのHomebrewでは、複数のアプリがxz 5.6.1に依存している事が判明し、現在xz 5.4.6へのロールバックが行われています。 悪意のある変更は難読化され、バ
SSHの鍵生成には暗号論的に安全な疑似乱数を使おうという話。 暗号論的に安全ではない疑似乱数がどれだけ危険かというのを、簡単なCTFを解くことで検証してみました。 背景 SSH公開鍵に自分の好きな文字列を入れる、という記事を読みました。 かっこいいSSH鍵が欲しい 例えばこのSSH公開鍵、末尾に私の名前(akiym)が入っています。 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFC90x6FIu8iKzJzvGOYOn2WIrCPTbUYOE+eGi/akiym そんなかっこいいssh鍵が欲しいと思いませんか？ かっこいい！真似してみたい！ そこまではいいんですが、問題は実装です。 秘密鍵を生成する際の乱数生成には高速化のために Goのmath/randを使っていますが、乱数が用いられるのは公開しない秘密鍵自体であり、このアルゴリズム自体はLagged Fib
例えばこのSSH公開鍵、末尾に私の名前(akiym)が入っています。 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFC90x6FIu8iKzJzvGOYOn2WIrCPTbUYOE+eGi/akiym そんなかっこいいssh鍵が欲しいと思いませんか？ ed25519のSSH公開鍵の構造 SSH鍵の形式にはRSAやDSA、ed25519などがありますが、最近のssh-keygenではデフォルトでed25519の鍵を生成するということもあり、ed25519を利用していることを前提として進めます。なにより、RSAの公開鍵に比べると短いので末尾部分が目立つはずです。 そもそも、ed25519のSSH公開鍵のフォーマットはどのようなものになっているか確認してみます。まずはssh-keygenコマンドで秘密鍵と公開鍵を生成します。 % ssh-keygen -t ed25
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
