Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
@helloyuki_ さんと @giginet さんがやってて、自分との違いを眺めるのも面白いかと思ったので書いてみる*1。僕の以前の環境は 後悔しているがやめられない開発効率向上術、Neovimを一瞬でVSCode並みに便利にする、自作PC2023: Ryzenをやめた あたりで書いた。 OS Linux、macOS、Windows の3つを、この順に多く使用している。使っている環境が多いほど面倒毎が増えるので、本当なら3つも使わない方が良い。 LinuxはUbuntu 24.04を使っている。よく使うDockerイメージやGitHub Actions環境と同じパッケージ名が使えたり、デスクトップアプリのLinux向けの配布が.deb か .rpm がメインなことが多かったりと、Ubuntuにしておく利点は多い。ただ、手元の Framework Laptop でUbuntu 24.04
OS とデフォルトバージョンのリストを見ると、現在主要な OS は ed25519 鍵に対応しているし、 OpenSSH 7.3 以上であれば、今回紹介する方法は実現できる。のでどれか一つでも試してみましょう。 ファイル構造 ¶複数の端末を使う場合、 dotfiles にして Git で管理することになる。 この場合管理対象が増えてくると構造化して案件やプロジェクトが終了したら ~/.ssh/conf.d/nodes/ の設定ファイルで Include をやめるか conf.old のように名前を変えれば接続先には出ず、不用意にアクセスすることを防止するが設定は保管しておくことができる。(結構、廃止したプロジェクトでも過去のアクセス情報を探すのに ssh/config を確認するケースは多い) $ tree ~/.ssh ~/.ssh ├── conf.d conf はすべてここに入れる
セキュリティ研究者の指摘によるとサイバー攻撃者が侵害後のネットワーク内で、「PuTTY」を使って横方向に移動したり、ファイルを外部に持ち出したりするケースが増えていると指摘しています。 前提 攻撃者がよく使うのは、PuTTY本体だけではありません。 plink.exe(SSHのコマンドライン接続)やpscp.exe(SCP転送)といった関連バイナリを使い、SSHトンネルを張って別端末へ移動したり、特定ファイルを吸い上げたりします。専用マルウェアを新たに落とさずに「正規ツールや既に環境に存在するツール」を利用するため、アラートの優先度が下がったり、後追いの調査が難しくなったりします。 また侵入後にファイルやイベントログなど痕跡を消去する動きがあり「どこにSSHしたのか」「どの踏み台を通ったのか」が見えにくくなります。 レジストリに残る「SshHostKeys」が調査の軸になる LinkedI
メール、DNS、サーバホスティング、クラウドIaaSサービスと数々のサービス立ち上げに参画。近年は過去の経験を活かしてプラットフォームエンジニアリング部門を発足。100を超えるサービス/プロジェクトをホストするプラットフォームに育て上げる。市場や技術の変化を捉え、自らをアップデートし続けることがビジネスを成功に導く秘訣と考えるストラテジスト。 【IIJ 2025 TECHアドベントカレンダー 12/9の記事です】 昨年は「SSHでも二要素認証を使いたい」のタイトルでご紹介したSSHで二要素認証を利用する方法が好評だったので、今年はsudoをパスワードレス認証で使う方法について解説します。ちなみに、昨年の解説通りにSSHで二要素認証を行う環境が整っていれば、sudoでも二要素認証が実現します。 sudoのダメな使い方 かつては特権操作を行うとき、suコマンドを利用して一般アカウントからroo
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 1. はじめに この記事では、エンジニアなら毎日使っていると言っても過言ではない「SSH」が、なぜ安全なのか、その通信の裏側をステップごとに分かりやすく解説していこうと思います。 2. SSH接続の全体像 まずは、SSH接続が確立されるまでの全体の流れを見てみましょう。クライアントがサーバーに接続しようとしてから、安全な通信が始まるまで、裏側ではこんなやり取りが行われています。 この図のステップを、これから一つずつ深掘りしていきます。 3. Step 1-2:通信前のネゴシエーション 本格的な通信を始める前に、クライアントとサーバーは「
安全にssh接続をするために、行う設定をまとめました。後で自分自身が見返せるように作成しました。 環境といたしましては、 client:Windows11 host:Ubuntu22.0.4.1LTS 前提としてroot以外ユーザーでログインします。 公開鍵暗号方式とは 公開鍵暗号方式を簡単に説明すると、次のようなイメージです。 まず、自分専用の「暗号をかける魔法」と「暗号を解く魔法」を準備します。このうち、「暗号をかける魔法」をみんなに公開します。みんなはその魔法を使って、あなた宛てのメッセージを安全に暗号化して送ります。 「暗号を解く魔法」は誰にも教えない秘密の魔法です。 そして、あなただけが知っている秘密の「暗号を解く魔法」を使って、送られてきたメッセージを読み解きます。 これで誰でも暗号化はできるけど、解けるのはあなた専用の魔法だけという仕組み。 イメージで覚える 暗号をかける魔法
メール、DNS、サーバホスティング、クラウドIaaSサービスと数々のサービス立ち上げに参画。近年は過去の経験を活かしてプラットフォームエンジニアリング部門を発足。100を超えるサービス/プロジェクトをホストするプラットフォームに育て上げる。市場や技術の変化を捉え、自らをアップデートし続けることがビジネスを成功に導く秘訣と考えるストラテジスト。 【IIJ 2024 TECHアドベントカレンダー 12/6の記事です】 今年のIIJアドベントカレンダーは「運用」がテーマということなので、運用に欠かせない必携ツール筆頭であるSSHを取り上げ、SSHの秘密鍵を安全に管理する方法について考えたいと思います。 たとえSSH秘密鍵が漏洩しても、安全を確保する方法 踏み台サーバにSSH秘密鍵を置かずに利用する方法 SSH秘密鍵の安全な置き場所を考える SSH秘密鍵は一般的に ~/.sshにファイルとして管理
今回は、SSH接続を劇的に高速化する方法をご紹介します。たった3行の設定を追加するだけで、接続時間を10分の1に短縮できます。しかも、2回目以降の接続では認証も自動的に行われるので、パスワードやパスフレーズの入力も不要になります。 要点 .ssh/configファイルのHost *セクションに以下の3行を追加するだけです。 詳しい説明 1. ControlMaster auto この設定で、1つのSSH接続で複数のセッションを共有できるようになります。新しくSSH接続を確立するたびに認証情報を入力し直す手間が省けて、接続がぐっと速くなります。具体的には: 初回の接続時のみ認証が必要 2回目以降は既存の接続を再利用するため、認証プロセスをスキップ パスワードやパスフレーズの入力が不要になり、接続がほぼ瞬時に完了 2. ControlPath ~/.ssh/mux-%r@%h:%p Contr
2024年7月1日、OpenSSHの開発チームは深刻な脆弱性 CVE-2024-6387 が確認されたとしてセキュリティ情報を発出し、脆弱性を修正したバージョンを公開しました。この脆弱性を発見したQualysによれば、既定設定で構成されたsshdが影響を受けるとされ、影響を受けるとみられるインターネット接続可能なホストが多数稼動している状況にあると報告しています。ここでは関連する情報をまとめます。 概要 深刻な脆弱性が確認されたのはOpenSSHサーバー(sshd)コンポーネント。脆弱性を悪用された場合、特権でリモートから認証なしの任意コード実行をされる恐れがある。 悪用にかかる報告などは公表時点でされていないが、glibcベースのLinuxにおいて攻撃が成功することが既に実証がされている。発見者のQualysはこの脆弱性の実証コードを公開しない方針としているが、インターネット上ではPoC
「Tailscale SSH」が正式版に到達。面倒な鍵管理が不要のSSH、VSCode拡張機能でリモートファイルも編集可能 Tailscale社は、統合的なアイデンティティ管理による鍵管理を不要にした便利なSSHを実現する「Tailscale SSH」が正式版になったことを発表しました。 Tailscale SSH is now out of beta and into general availability! Still juggling SSH keys and managing identities across remote machines? There's a better way: https://t.co/sdvnCckSYg — Tailscale (@Tailscale) March 26, 2024 TailscaleはWireGuardをベースにしたVPN Tai
Linux Daily Topics xzパッケージに仕込まれた3年がかりのバックドア、スケール直前に見つけたのはMicrosoftの開発者 “アップストリームのxzリポジトリとxz tarballsはバックドア化されている(The upstream xz repository and the xz tarballs have been backdoored)”―2024年3月29日、Microsoftに所属する開発者 Andres Freundが「Openwall.com」メーリングリストに投稿したポストは世界中のオープンソース関係者に衝撃を与えた。 backdoor in upstream xz/liblzma leading to ssh server compromise -oss-security 主要なLinuxディストリビューションにはほぼ含まれているデータ圧縮プログラ
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
Development Division/Platform Team/Sys-Infra Unitの伊豆です。Sys-Infra Unitはインフラエンジニア・SRE 的な役割を担っています。 今回は、ある日突然SSHログインが遅くなったときに調査した内容を共有します。 SSHログインに数分かかる ある日、AWS EC2上で動いている開発環境のSSHゲートウェイにSSHログインすると30秒以上かかると報告がありました。-vvvオプションを指定してSSHログインしてみるとpledge: filesystemというログが出力された後、数十秒から数分程度かかってSSHログインが成功する状況でした。 pledge: filesystemやssh slowなどで検索してみると、主に以下のような対処法が挙げられていましたがどれを試しても状況は改善されませんでした。 systemd-logindを再起動
はじめに つい先日、GitHubのRSA SSHホスト鍵が突如差し替えられるという一件がありました。 We updated our RSA SSH host key 詳細に関しては識者による解説に委ねますが、ちょうどタイムリーな話題だったので、SSHをより安全に利用するという観点でおすすめ設定についていくつか紹介します。 なお、クリアコードではSSH以外にもおすすめzsh設定やおすすめEmacs設定という記事も公開しているので参考にしてみてください。 2023年5月11日更新:StrictHostKeyCheckingをyesにする場合の安全なknown_hostsの更新方法について追記しました。 おすすめ設定について クリアコードでは、.ssh/configのおすすめ設定を https://gitlab.com/clear-code/ssh.d にて公開しています。 これは、社内で.ss
※タイトルの元ネタは以下の作品です。 はじめに この記事は、公開鍵暗号の全体感を正しく理解するためのものです。数学的な部分や具体的なアルゴリズムは説明しません。気になる方は最後に紹介するオススメ書籍をご覧ください。 少し長いですが、図が多いだけで文字数はそこまで多くありません。また、専門的な言葉はなるべく使わないようにしています。 ただしSSHやTLSといった通信プロトコルの名称が登場します。知らない方は、通信内容の暗号化や通信相手の認証(本人確認)をするためのプロトコルだと理解して読み進めてください。 公開鍵暗号の前に:暗号技術とは 公開鍵暗号は暗号技術の一部です。暗号と聞くと、以下のようなものを想像するかもしれません。 これは情報の機密性を守るための「暗号化」という技術ですが、実は「暗号技術」と言った場合にはもっと広い意味を持ちます。まずはこれを受けて入れてください。 念のため補足して
1Passwordを使って、ローカルにファイル(~/.configや.env)として置かれてる生のパスワードなどを削除した 最近、コミットはされないがローカルのディレクトリに置かれている.envのようなファイルから生のパスワードやAPI Tokenを削除しました。 これは、ローカルでマルウェアを実行した場合に、ローカルに置かれている生のパスワードやAPI Tokenを盗まれる可能性があるためです。 最近は、npm install時のpostinstallでのデータを盗むようなマルウェアを仕込んだりするソフトウェアサプライチェーン攻撃が多様化しています。 Compromised PyTorch-nightly dependency chain between December 25th and December 30th, 2022. | PyTorch What’s Really Goin
去年の12月に「Gitで複数アカウントのssh接続ができたー」みたいな記事を書いてましたが、最近また問題が勃発。各リポジトリのgitのconfigファイルで正しくssh接続名を指定しても、sshでユーザ切り替えをしようとしても、なぜかユーザーが切り替わりません。 自分の環境ではGitHubアカウントごとにssh接続用の秘密鍵を使い分けているのですが、どうしても片方の秘密鍵でログインされてしまいます。 おかしいなと思ってググったら、~/.ssh/configで複数アカウントを運用する上で重要な設定IdentitiesOnly yesが抜けていたことが判明しました。 問題点 gitのconfigファイルに接続先を正しく設定していても、なぜかpermission deniedになってしまう。 さらに、sshコマンドでアカウント切り替えをしようとしても、なぜかアカウントが切り替わらない。 例) $
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く