「Tailscale SSH」が正式版に到達。面倒な鍵管理が不要のSSH、VSCode拡張機能でリモートファイルも編集可能
「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
xzパッケージに仕込まれた3年がかりのバックドア、スケール直前に見つけたのはMicrosoftの開発者 | gihyo.jp
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ディストリビューションにはほぼ含まれているデータ圧縮プログラ
広く使用されている「xz」にssh接続を突破するバックドアが仕込まれていた事が判明。重大度はクリティカルでLinuxのほかmacOSにも影響 | ソフトアンテナ
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ログインの失敗が大量に記録されているとSSHログインが極端に遅くなる - Repro Tech Blog
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を再起動
おすすめ.ssh/config設定 - 2023-04-03 - ククログ
はじめに つい先日、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)として置かれてる生のパスワードなどを削除した
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
.ssh/configで複数アカウント運用するならIdentitiesOnlyを有効化すべし
去年の12月に「Gitで複数アカウントのssh接続ができたー」みたいな記事を書いてましたが、最近また問題が勃発。各リポジトリのgitのconfigファイルで正しくssh接続名を指定しても、sshでユーザ切り替えをしようとしても、なぜかユーザーが切り替わりません。 自分の環境ではGitHubアカウントごとにssh接続用の秘密鍵を使い分けているのですが、どうしても片方の秘密鍵でログインされてしまいます。 おかしいなと思ってググったら、~/.ssh/configで複数アカウントを運用する上で重要な設定IdentitiesOnly yesが抜けていたことが判明しました。 問題点 gitのconfigファイルに接続先を正しく設定していても、なぜかpermission deniedになってしまう。 さらに、sshコマンドでアカウント切り替えをしようとしても、なぜかアカウントが切り替わらない。 例） $
DockerとSSHでセキュリティと手軽さを両立したリモート開発環境を構築する
リモートワークが一般的になり、一方でさまざまな課題が生じてきています。特にコミュニケーションの課題などは多くの人に関係するため大きな関心を集め、急速にさまざまなソリューションが出てきています。一方で開発業務に目を向けると、少しずつ進みつつあるものの、デファクトと言えるほどのものもなく、情報もあまり共有されていないように思います。そこで、筆者がいろいろと試行錯誤をしながら行った施策について紹介したいと思います。 はじめに 今の開発現場ではDockerなどを使った仮想化コンテナを使うことが一般的になっています。そのため、ソースリポジトリ（Gitなど）と仮想化コンテナを使えば、各開発者が開発環境を構築し、業務を進められます。つまり、オフィスのPCを自宅に持ち帰るか、もしくは自宅のPC上で開発環境を構築してしまえばそれで問題は解決するのです。 しかし、どちらの方法もセキュリティや情報管理の観点から
ssh公開鍵認証設定まとめ - Qiita
ssh 公開鍵認証設定まとめ sshでLinuxサーバーへ接続する際のまとめ。 クライアント: Mac サーバー: CentOS 6.5 を想定 公開鍵、秘密鍵を生成する # このコマンドの後にパスワードの設定を聞かれる。 # パスワード無しの場合は何も入力せずにEnterを押す (非推奨) ssh-keygen -t rsa デフォルトの設定では、 公開鍵: ~/.ssh/id_rsa.pub 秘密鍵: ~/.ssh/id_rsa 秘密鍵は 絶対に流出させない ようにすること。 流出したら鍵を作りなおして、サーバーに登録した公開鍵を削除して登録しなおせば良い。 ※2018/10/02追記 最近はrsa鍵を使うのは古い。 おすすめはecdsa、CentOS5等古い環境にアクセスするならrsa、ssh周りの知識があるならed25519が良さげ。 * ecdsa 521bit(512bitでは
If you’re not using SSH certificates you’re doing SSH wrong
If you’re not using SSH certificates you’re doing SSH wrongUpdated on: June 8, 2023 SSH is ubiquitous. It's the de-facto solution for remote administration of *nix systems. But SSH has some pretty gnarly issues when it comes to usability, operability, and security. You're probably familiar with these issues: SSH user experience is terrible. SSH user on-boarding is slow and manual. Connecting to ne
フレッツ光回線でscpが遅かった話 - Qiita
この記事は、Supershipグループ Advent Calendar 2021の7日目の記事になります。 先日、sshを使用したファイル転送が回線速度と比べて異常に遅いという現象に遭遇したので、その際に行った調査を再現しつつ原因や対策について書いてみたいと思います。 要約 OpenSSHはデフォルトでinteractiveなセッションに af21 、non-interactiveなセッションに cs1 をDSCP値としてIPヘッダに設定する フレッツ網はIPヘッダのDSCP値を帯域優先サービスで使用しており、契約に応じて指定された優先度以外が設定されたパケットの転送は保証されない そのため、OpenSSHをデフォルト設定のままフレッツ網で使うと通信ができなかったり、速度低下などの悪影響を受ける可能性がある OpenSSHがDSCP値を設定しないようにするためには、IPQoS noneを設
踏み台EC2を廃止してSession Manager接続に置き換えました
こんにちは、エウレカ SRE チームの原田です。 今年 (2021年) エウレカでは、公開鍵認証で接続するEC2の踏み台サーバを廃止し、代わりに各サーバへの接続をIAMで認証できるSSM Session Managerへのリプレースを行いました。本記事ではそのモチベーションや、実装のポイントを紹介していきたいと思います。 旧来の踏み台サーバ 旧来の踏み台サーバエウレカで長く運用されていた踏み台サーバ (Gateway) は以下のようなものでした。 各開発者は、自分の秘密鍵を使って踏み台サーバへSSHを行う ( 踏み台サーバ上には各開発者の個別ユーザーおよび公開鍵が登録されている )踏み台上では、接続が許可されているSSH対象のサーバの秘密鍵がユーザー毎に配置されており、その鍵で各サーバにSSHするMySQL / Elasticsearch / Redis など、Private Subnet
混沌を極めるWindowsのssh-agent事情 - Qiita
どうしてこうなった。 何の話？ WindowsでのSSH-AGENTとSSHの話です。 この記事での用語: SSHとssh, SSH-AGENTとssh-agent この記事では、SSH-AGENTと書いたときにはカテゴリとしてのSSHエージェントを意味します。 ssh-agentと書いたときには、実行プログラムとしてのssh-agentコマンドを意味します。 同様に、SSHと書いたときにはカテゴリとしてのSSHクライアントを意味します。 sshと書いたときには、実行プログラムとしてのsshコマンドを意味します。 SSH-AGENTって？ SSH-AGENTは、秘密鍵での署名を代行1してくれるツールです。 SSH-AGENT に秘密鍵をロードしてしまえば、あとはパスワード(パスフレーズ)入力なしでSSH認証できる agent forward機能を使うことで、SSHした先でさらにSSHすると
ssh-agentを利用して、安全にSSH認証を行う
SSH認証、皆さんどのような手順で行ってますか？ ローカルで作業する分にはいいものの、 クラウド上にサーバーを立てて、そこからgitに接続... などの場面で、まさか秘密鍵をサーバーに置くなんて危険な真似はしてないですよね？ (これ死亡フラグです。) そんな危険度100%のあなたに是非お伝えしたいのが、ssh-agent。 すっごく簡単に説明すると、彼は、ユーザーと常に一緒に行動してくれて、 必要な時に「はいっ」と秘密鍵を渡してくれる、ハイパーセキュリティボーイなのです。 今日はそんなssh-agentの使い方をまとめてみたいと思います。 (Macでの使用を想定しております。ご了承下さい。) 1. ローカルで鍵の作成 まずは通常のssh認証と同じようにローカルで秘密鍵の作成を行っていきます。 ここは特に問題ないと思うので省略。 (不明な方はこのリンクが参考になります。) 2. ssh-ag
SSH defaults, config, and priorities | Root
Over the years I’ve collected a rather messy ~/.ssh/config which resulted in some undesired behavior as a result of me misunderstanding how the config file prioritizes its options. Today I investigated that. In short, this is what I found: Priority goes from top to bottom Defaults MUST come last Host specificity is NOT a factor of priority Host sections can be specified multiple times Multiple hos
SSH接続をWebブラウザの純粋なHTTP上で実現する - nwtgck / Ryo Ota
HTTPといえばHTML/CSS/JavaScriptや画像などの小さめの限りがあるデータを手に入れるためによく使われている印象がある。REST APIのようなHTTPを使ったAPIでも限りのあるデータがリクエストとレスポンスになる印象が強い。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「Tera Term 5.0」がリリース ～18年ぶりのメジャーバージョンでUnicodeに全面対応／来年で30周年を迎える老舗のリモートログオンクライアント
https://twitter.com/mootastic/status/1612413906248699906
