タグ

sshに関するmooonymannのブックマーク (19)

  • 何でもSSHでやってしまいませんか? | POSTD

    私はかつて、 ssh-chat というプログラムを書きました。 ssh http://t.co/E7Ilc0B0BC pic.twitter.com/CqYBR1WYO4 — Andrey ???? Petrov (@shazow) December 13, 2014 アイデアは単純なもので、ターミナルを開いてこのようにタイプするだけのことです。 $ ssh chat.shazow.net たいていの人はこの後に続けてlsコマンドをタイプするのでしょうが、ちょっと待って。よく見てください。そこにあるのはシェルではなく、なんとチャットルームですよ! 詳しいことはわからないけど、何かすごいことが起こっているようですね。 SSHはユーザー名を認識する sshでサーバーに接続するときに、sshクライアントはいくつかの環境変数をサーバーへの入力として渡します。その中のひとつが環境変数$USERです。

    何でもSSHでやってしまいませんか? | POSTD
  • Dockerでホストを乗っ取られた - Qiita

    注意 件記事ですが、私の不適切な行動(拾ったスクリプトを検証なく走らせる)が原因です。「dockerは(特に何もしなくとも)危険」との誤解を皆様に与えた点、ご迷惑をおかけいたしました。申し訳ございません。 拡散されている記事を削除するのはさらなる誤解を招きかねないと思いましたので、冒頭に注意を付記しております。以下の記事は、「自分が何してるかをきちんと検証できないとセキュリティホールを生み出す」という意味で参考にして頂ければ幸いです。 追記 Twitterやはてブで言及いただきました皆様、ありがとうございます。 件はpullしてきたイメージが悪意ある開発者によるものかどうかにかぎらず、不適切な設定をしていると起こり得ます。 ※コメント欄に質問への回答という形で、私がそのときに走らせていたイメージの一覧を挙げておりますが、どのイメージも評判あるものだと思います。 皆様におかれましては「あ

    Dockerでホストを乗っ取られた - Qiita
  • sshでリモートサーバーをマウント、便利にsshfs - Unix的なアレ

    開発の作業をしているときは、複数のホストのサーバーを行き来していろいろとオペレーションをするようなことがあると思います。 そんなときに1つのサーバーから作業できるよう、ssh経由でリモートのサーバーをマウントし、Localのファイルシステムのように見せることができるsshfsを紹介したいと思います。 sshfsのインストール Debian/Ubuntuならaptで簡単インストールできます。なお、fuseグループに入っている必要があるので、その設定まで実施します。なお、ユーザー名はwadapで実施します。 $ sudo apt-get install sshfs $ sudo adduser fuse wadap $ newgrp fuse以上、簡単ですね。 早速リモートホストをマウント リモートホストをマウントするのは簡単です。マウントポイントをつくって、sshfsコマンドを実行するだけ。

    sshでリモートサーバーをマウント、便利にsshfs - Unix的なアレ
  • sshした先に.bashrcや.vimrcを持って行きたい人のためのsshrc - Qiita

    いろんなサーバーにsshしてちょろっと設定を確認したりするときってあると思います。 ただその時にllがつかえなかったり、vimのタブが空白4つがいいのに8文字分の広さのtab文字だったりして、ちょっとずつストレスが溜まっていきます。 やっぱりserverfaultでもおなじ苦労をしている人がいました。 vim - How to bring .vimrc around when I SSH? - Server Fault http://serverfault.com/questions/33423/how-to-bring-vimrc-around-when-i-ssh ただここにあるようにdotfilesとして保存して先でcloneするのもとても面倒くさい。第一各サーバーへ変更を入れないといけないし。SSHの秘密鍵みたいに携えていきたい。 そこで探していたらsshrcというツールを見つけて

    sshした先に.bashrcや.vimrcを持って行きたい人のためのsshrc - Qiita
  • ウェブリブログ:サービスは終了しました。

    「ウェブリブログ」は 2023年1月31日 をもちましてサービス提供を終了いたしました。 2004年3月のサービス開始より19年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 ※引っ越し先ブログへのリダイレクトサービスは2024年1月31日で終了いたしました。 BIGLOBEのサービス一覧

    ウェブリブログ:サービスは終了しました。
  • SSHの代わりになるかもしれない「Mosh」を使ってみました - サーバーワークスエンジニアブログ

    こんにちは。サービス開発グループの竹永です。 最近カメラを買ったのですが、周りにねこがほとんど居ないのでしょんぼりしています。 さて突然ですが、僕は電車に2時間ほど乗って遠出するのが結構好きです。 しかし、電車に乗っている間は僕のメインの通信手段であるWiMAXで、通信ができない状態になることが稀によくあります。車窓から田んぼが見えたら、かなりの確率で繋がりません。 電車内で「サーバーをいじって遊ぼう」と思ってSSH接続をしても、キー入力が反映されるまでタイムラグが有り、電車がトンネルに入れば接続が切れます。 接続が切れるたびに再接続するのは面倒ですし、なにより作業中に1分ぐらい固まってから「接続切れちゃった」とSSHに言われるのは辛いです。 そんな訳で、先輩に教えていただいたMoshを使ってみました。 Moshってなに Mosh(mobile shell)はモバイル回線のような不安定なイ

    SSHの代わりになるかもしれない「Mosh」を使ってみました - サーバーワークスエンジニアブログ
  • インフラエンジニアじゃなくても押さえておきたいSSHの基礎知識 - Qiita

    最近はクラウド上のサーバーを利用する事も多くなってきた。 サーバーの用意やネットワーク周りの設定はインフラ部門がやってくれるけど、アプリのデプロイ/設定は開発者がする事が多いので、開発メインでやってるエンジニアでも最低限SSHの知識は必要になる。 また、Vagrant等でローカル環境にVMを作成する事もあるので、ローカル環境内でSSHを使用するケースも増えてきた。 というわけでインフラエンジニアじゃなくてもSSHクライアントの知識は必須になってきているので、改めてSSHの再学習をしてみることにした。 SSHとは 暗号や認証の技術を利用して、安全にリモートコンピュータと通信するためのプロトコル。 SSHでは以下の点で従来のTelnetより安全な通信が行える。1 パスワードやデータを暗号化して通信する。 クライアントがサーバーに接続する時に、接続先が意図しないサーバーに誘導されていないか厳密に

    インフラエンジニアじゃなくても押さえておきたいSSHの基礎知識 - Qiita
  • Linuxサーバの反応が遅い(重い)場合の原因の調査手順

    概要 Linuxサーバの反応が遅い場合の調査手順のメモ。 実行する場合は自己責任でお願いします。 原因として考慮すべき事項 サーバが遅い場合には様々な原因がありますが、以下を考慮します。 CPU負荷 メモリ不足 ディスクI/O負荷 ネットワークI/O負荷 まず、どれが原因か調査する必要があります。 top コマンド 最初は「top」コマンドを利用します。 top - xx:xx:xx up 0 min, 1 user, load average: 1.44, 0.51, 0.18 Tasks: 87 total, 1 running, 86 sleeping, 0 stopped, 0 zombie Cpu(s): 0.7%us, 0.3%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 2057692k total, 291

  • ssh XForwardingを速くする設定 | さかな前線

    おさかなさんも先日,24歳を迎えました.もう若くはないです. しかしキャビアで有名なチョウザメは寿命が150年〜200年にも達するそうです. 手元の環境でssh XForwardingするとき速度が遅くて困っていたのですが,ちょっと調べると高速化Tipsがあり,効果覿面でしたのでメモがてらに. How to speed up X11 forwarding in SSH – Linux FAQ ~/.ssh/configに Host * Compression yes CompressionLevel 9 TCPKeepAlive yes Ciphers blowfish-cbc,arcfou こんな感じの記述を追加します. ふつう % ssh -YC hogehoge@fugafuga とするとX転送とCompressionが有効な状態になりますが,暗号化処理が結構重たく遅くなるようです.

  • SSHの圧縮 - ふなWiki

    圧縮の方法 コマンド ユーザごとの設定ファイル ~/.ssh/config システム全体にわたる (system-wide) 設定ファイル /etc/ssh/ssh_config teraterm なら TERATERM.INI puttyなら putty.ini 圧縮率 http://www.unixuser.org/~haruyama/security/openssh/support/addendum.html#add_6 6. 圧縮および圧縮レベルの設定の目安 OpenSSH では、遅いネットワーク環境でのデータ転送速度を上げるためにデータを圧縮しながら転送することができます。書 156ページには「圧縮を行うかどうかの目安は 4-?. 節を参照してください」と書かれていますが、実際には書に目安は書かれていませんでした。 以下は著者の環境において、さまざまな回線速度および圧縮レベル

  • tmuxで大量のサーバーを操る最高の方法 - Qiita

    こんにちはこんにちは 私は日々大量のサーバーで作業をする必要があるので tmux が欠かせません そんな中最高便利な記事が先日公開されました Tmuxでウィンドウをインタラクティブに移動する - Qiita [キータ] しかしこの記事が全く話題になっていません おそらく理解されていないのだと思います ということで私がもう少し詳しく説明したいと思います 先程の記事と同様に ssh-configにはパターンが使えるので便利 - Qiita [キータ] tmuxで色んなホストにsshする時に便利な.ssh/config - Qiita [キータ] の合計 3 記事を組み合わせて初めて達成できる最高のソリューションを紹介します tmux のウィンドウの名前 tmux で大量のウィンドウを立ち上げて ssh しているとどのウィンドウがどこのホストにいるのか分からなくなります そこで先程紹介した 2

    tmuxで大量のサーバーを操る最高の方法 - Qiita
  • 「Write failed: Broken pipe」によりsshが切断された時の対処法 - Qiita

    現象 sshでリモートサーバにログインしているときに「Write failed: Broken pipe」と表示されて接続が切れてしまうことがあります。 sshはある程度の時間操作をせずにいるとタイムアウトにより自然に切断される仕組みになっているためであり、クライアント側orサーバ側でsshの設定を変更する必要があります。

    「Write failed: Broken pipe」によりsshが切断された時の対処法 - Qiita
  • sshのconfigファイルの書式(日本語マニュアル)

    OpenSSH SSH クライアント 設定ファイル 書式 ~/.ssh/config /etc/ssh/ssh_config 説明 ssh (1) は以下のものから (この順序で) 設定情報を取得します: コマンドラインオプション ユーザごとの設定ファイル 各設定項目にはそれぞれ最初に見つかったものが使われます。設定ファイルはいくつかのセクションに分かれており、これらは"Host"キーワードにより区切られています。あるセクションの設定が適用されるのは、コマンドラインから与えられたホスト名が、このキーワードで指定されているパターンのどれかにマッチするときだけです。 各設定項目で最初に見つかった値が使われるので、ホストに特化した宣言をファイルの先頭近くに置くようにし、一般的なものを後に置くのがよいでしょう。 設定ファイルは以下のような形式になっています: 空行、および # で始まる行は、コメン

  • ssh-agentの基本 - Qiita

    説明するほどのでもない気がするけど、書いてとせがまれたので書いてみる。 適当に書いたので、細かい説明とか用語の使い方がおかしいのは大目に見てもらう方向で。 ssh-agentは、sshの鍵をssh-agentデーモン(?)に保持させておいて、使い回せるようにするツール。 使い方は、ssh-agentを起動して、そのシェル内でssh-add でkeyを追加するだけ。

    ssh-agentの基本 - Qiita
  • SSH-AGENT (1)

    認証エージェント 書式 ssh-agent [-c | Fl s] [-d ] [-a bindするアドレス ] [-t 鍵のデフォルト生存時間 ] [コマンド [引数 ...] ] ssh-agent [-c | Fl s] -k 説明 ssh-agent は (RSA や DSA の) 公開鍵認証で使われる認証鍵を保持するプログラムです。基的には、まずssh-agent を X セッションあるいはログインセッションの始めに起動させ、これ以外のすべてのウインドウやプログラムがそのssh-agent プログラムのクライアントとして起動するようにします。エージェントは環境変数を使うことにより、他のマシンにssh (1) を使ってログインするときに自動的に検出され、認証に利用できます。 オプションには次のようなものがあります: -a bindするアドレス Unix ドメインソケットをbi

  • ec2インスタンスとの接続でknown_hostsを書き込まなくする - Qiita

    ec2インスタンスの実態が変わるたびに、known_hostsを削除する必要が出てきます。 めんどくさくなってGoogle検索していたら解決策がありました。 ~/.ssh/config に以下を記述します。 これでec2のHostKey(サーバ側のkey)をチェックしないで、クライアントのknown_hostsにも書き込みません。 ただ、 man in the middle が可能になります。 クライアントからサーバへの経路のどこかで、サーバをなりすますことができれば、偽物のサーバにログインしていてもクライアントは気づかないことになります。

    ec2インスタンスとの接続でknown_hostsを書き込まなくする - Qiita
  • SSH接続エラー回避方法:.ssh/known_hostsから特定のホストを削除する/削除しないで対処する3つの方法 - Qiita

    (2014年02月28日:初投稿) (2020年01月24日:Ubuntu 18.04 LTS で動作確認) ssh接続エラー(ワーニング)になり接続できないことがある。 * エラー原因のknown_hostsの設定削除する方法 * 手軽にエラーを無視する方法 * エラーとならないようにサーバ側を設定する方法 について記載する。 ただし、これらの方法がセキュリティ的によいのかは各自判断が必要。 ssh接続先サーバがOSを再インストールしたとか、接続先サーバがDHCPでアドレスが変わるとか、接続先サーバがホスト名を付け替えたとか、そういったときに次のエラー(ワーニング)が発生して接続ができない。 $ ssh remote_host @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOS

    SSH接続エラー回避方法:.ssh/known_hostsから特定のホストを削除する/削除しないで対処する3つの方法 - Qiita
  • GitでSSH接続のHost Key Verificationを無視する - Qiita

    SSH接続の際に、対象ノード(今回はgithub)に一度も接続したことがなければ、ホスト鍵確認のため、下記のような確認プロンプトが表示される。 Initialized empty Git repository in /var/git/example.org/.git/ The authenticity of host 'github.com (12.12123.123)' can't be established. RSA key fingerprint is 99:99:99:99:99:99:99:99:99:99:99:99:99:99:99:99. Are you sure you want to continue connecting (yes/no)?

    GitでSSH接続のHost Key Verificationを無視する - Qiita
  • 社内プロキシに虐げられてる人たちはVPSとか借りて社外にプロキシ立ててsshトンネルで繋ぐとウハウハですよってお話 - Qiita

    概要 社内プロキシに様々なサイトへのアクセスをブロックされたり、社外サーバにsshできなかったりする人向けに社外プロキシを立ててあらゆるサイトにアクセスする方法のまとめです。(後述しますが半分くらいネタポストです。) 他にも以下のような効果がありますので、プロキシフリーな会社にお勤めもし良かったら参考にして頂ければと思います。 なぜか2015年になっても存在するカフェとかホテルとかでの保護されていなかったりする無線wifiを使っても盗聴されない。 日からアクセスできないサイトにアクセスできる。(海外のデータセンタ上のVMを使った場合) なお、非認証プロキシを例にしてます。認証プロキシでもあまり変わらないとは思いますが、環境が無いため未確認です。また、プロキシの挙動や設定方法はプロキシサーバの種類や設定によって多岐に渡るため、全てのプロキシで同じ方法が使えるとは限らないとは思います。 最後

    社内プロキシに虐げられてる人たちはVPSとか借りて社外にプロキシ立ててsshトンネルで繋ぐとウハウハですよってお話 - Qiita
  • 1