Perl入学式 全6回のPerl入門講座。東京、大阪、沖縄、札幌で開催。(東京は4月と10月スタート、それ以外は5月スタート) YAPC::Japan Perlを軸としたITに関わる全ての人のためのカンファレンス。 東京 吉祥寺.pm 五反田.pm 大阪 なにわPerl 沖縄 沖縄.pm
Dockerを使い始めた人がよくする質問といえば、「どうすればコンテナに入れますか?」です。その質問に対して、「コンテナ内でSSHサーバを起動すればいいよ」と答える人たちがいますが、これは非常にマズいやり方です。なぜその方法が間違いなのか、そして代わりにどうすればよいのかをこれから紹介します。 注:本記事へのコメントやシェアは、 Dockerブログ にアップされた標準版から行ってください。よろしくお願いします。 コンテナでSSHサーバを起動すべきではない …もちろん、コンテナ自体がSSHサーバである場合は除きます。 SSHサーバを起動したくなる気持ちは分かります。それはコンテナの”中に入る”簡単な方法だからです。この業界の人ならほぼ全員がSSHを一度は使ったことがあります。多くの人がSSHを日常的に使用し、公開鍵や秘密鍵、パスワード入力の省略、認証エージェント、そして時にはポート転送やその
Hadoopクラスタを運用する際に ulimit で nofile (プロセスがopenできるファイルディスクリプタ数の上限)の設定を変更しておくべき*1というのはもはや常識的なお話ですが、そこには実は罠がある。たぶんRHELのデフォルト通りならハマらないんだろうけど、手を入れている環境だとハマる。ので、その話。 要するにハマった。のを解決したよ多分! まだ最終的な確認できてないけど! 各書籍での解説 とりあえず、国内で売られているHadoop関連書籍の記述を確認しておこう。まずHadoop徹底入門。 ファイディスクリプタの設定は、/etc/security/limits.conf に記述します。エディタを利用して、limits.conf に以下のように記述します。ここでは、Hadoopの各種ノードを起動するユーザーを hadoop とします[12]。 hadoop soft nofile
お久しぶりです。ずいぶん記事を書くのをサボっていてごめんなさい。ディノでもAdvent Calendarやろうよ、なんて話もあったんですが、タイミングを逸した感がありますね。毎日とは言わなくても、またボチボチ書いていきたいと思います。 さて、今日は社内での雑談の話題から、「~/.ssh/authorized_keys2」ファイルはobsolete(古い、時代遅れ)だよ、という話題です。 SSH1とSSH2が混在していたころの習慣だと思うのですが、~/.ssh/authorized_keysにはSSH1の公開鍵を、~/.ssh/authorized_keys2にはSSH2の鍵を置くきまりだと聞いたことがあります。しかし、これはもはや正しくないようです。 OpenSSH3.0のリリースノートには下記のような記述があります。 2) The files /etc/ssh_known_hosts2
概要 SSHで公開鍵暗号を使って認証する際に参考となる情報を載せています。 また公開鍵暗号方式のメリット、デメリットや公開鍵暗号方式の仕組みを簡単にまとめています。 実際の設定作業は最低限必要な手順だけを記しています。 おさえておきたいこと クライアントが公開鍵を生成する。 サーバはその公開鍵をクライアントから受け取る。 接続の確立時にサーバとクライアントはそれぞれの公開鍵をもとに簡単な通信を行う。 通信の結果が、共通の公開鍵を持つ二者のみで可能であったことを確認するために秘密鍵を使う。 秘密鍵はクライアントが保管しており、サーバや他のクライアントが利用することはない。 秘密鍵はクライアントが公開鍵を生成する際、同時に生成される。 対象読者と前提条件 unixの簡単な知識が必要です。 MacOS、Linux、BSDなど Unix系のOSを使用していることを想定しています。 クライアントはO
概要 社内プロキシに様々なサイトへのアクセスをブロックされたり、社外サーバにsshできなかったりする人向けに社外プロキシを立ててあらゆるサイトにアクセスする方法のまとめです。(後述しますが半分くらいネタポストです。) 他にも以下のような効果がありますので、プロキシフリーな会社にお勤めもし良かったら参考にして頂ければと思います。 なぜか2015年になっても存在するカフェとかホテルとかでの保護されていなかったりする無線wifiを使っても盗聴されない。 日本からアクセスできないサイトにアクセスできる。(海外のデータセンタ上のVMを使った場合) なお、非認証プロキシを例にしてます。認証プロキシでもあまり変わらないとは思いますが、環境が無いため未確認です。また、プロキシの挙動や設定方法はプロキシサーバの種類や設定によって多岐に渡るため、全てのプロキシで同じ方法が使えるとは限らないとは思います。 最後
what [hoge@fuga ~]$ ssh baz@xxx.xxx.xxx.xxx Permission denied (publickey). [hoge@fuga ~]$ Permission denied (publickey). って何? ってことで、OpenSSHについて知らなすぎるので知る。 勉強材料 書籍「入門OpenSSH」にお世話になりました。 Amazon CAPTCHA OpenSSHでユーザーがログインするまでの流れ 一般ユーザーがクライアントを用いてサーバーにログインを試みると、クライアントとサーバーデーモンのあいだで2種類の確認作業(認証)が行われます: 1.そのサーバが本当に「ユーザのログインしたいサーバ」であるかどうかを確認する、ホスト認証。 2.そのユーザがサーバにログインする資格があるかどうかを確認する、ユーザ認証。 ホスト認証の仕組み クライアント
この記事は、1分で実現できる有用な技術 Advent Calendar 2014 – Qiitaの1日目の記事です。 去年もこのAdvent Calendarに参加していて【1分で実現できる有用な技術】Mac OS X 10.9(Mavericks)でズーム機能を使うという記事を書いていました。 今日1日中、このネタを考えたのですがパッとしたものが思いつきませんでしたので、Macにssh-copy-idを作る方法を解説します。 通常対象のサーバに公開鍵を登録する場合、一度サーバにsshして、.sshディレクトリを作成して、パーミッションを変更して…といった手段が必要です。コマンドにすると5行くらいになりますし、公開鍵をコピーしなければなりません。 local $ ssh user@server server $ mkdir .ssh server $ chmod 700 .ssh serv
VMwareではほとんど設定を行わずにSSH接続することが出来たのですが、Virtualbox上のゲストOSにSSHで接続しようとしたらちょっと手間取ったのでメモしておきます。 環境 Virtualbox 4.1.14 Ubuntu 12.04 MacOSX 10.7.4 2種類の方法 方法は2つあります。 NAT + ポートフォーワーディング ホストオンリーアダプタ “NAT + ポートフォーワーディング” のほうが楽なのですが、毎回ポートを考慮しなければならないことや、ネットワーク層に関する問題はネットワーク層で解決したほうがスマートなので私は “ホストオンリーアダプタ” を選択しました。 NAT + ポートフォーワーディング この方法ではポートフォーワーディングの設定を行うことでゲストOSにアクセスします。 まず仮想マシンの設定を開き、ネットワークタブで表示される「ポートフォーワー
Linux/Unixサーバにsshしている際、sshdを再起動したとする。 sshdは一度終了する訳だから、現在接続しているsshも切断されるかと思いきや、接続は継続する。 今まであまり気にしていなかったけど、この振る舞いについて調べてみた。 先ず、現象の確認から 対象サーバにssh接続し、sshdを再起動してみる。 $ ssh ryozo@192.168.56.12 # 対象サーバに接続 $ hostname centos1.example.jp $ sudo service sshd restart sshd を停止中: [ OK ] sshd を起動中: [ OK ] $ hostname centos1.example.jp sshdは一度停止されているにもかかわらず、対象サーバからは切断されていない。 プロセス構造から理由を探る sshdプロセスの構成 先ず、sshdプロセスの構
毎晩、家に帰ってきてからPUTTYを使ってサーバにログインして作業しているのですが、毎回ユーザIDとパスワードを入力するのが大変です。 特にパスワードは覚えられるような文字列でもないので、毎回、パスワード管理ソフトを立ち上げて、コピーしているという有様。。。 なんとか、簡単にログインする方法がないかと探してみたところ、コマンドラインにユーザIDとパスワードを渡すことができるんですね。 そこで、PUTTYのショートカットを作成して、「プロパティ」⇒「ショートカット」⇒「リンク先」のところに以下のように設定しました。 "C:Program Files (x86)PuTTYputty.exe" -load 「セッション名」 -l 「ユーザ名」 -pw 「パスワード」 これで、ようやく、ダブルクリックするだけで、自動でログインまでできるようになりました! 他にもいろいろと使えそうなコマンドライン引
意外と知らない人がいるようなのでブログに書いておきます。 GitHub のアドレスのあとに .keys を付けるとその人の SSH 公開鍵が表示される。 たとえば id774 さんの公開鍵であれば https://github.com/id774.keys を参照すれば良い。 ぜひ自分のアカウントで試してみて欲しい。 新規に用意するサーバーの ~/.ssh/authorized_keys に上記アドレスを wget したものを置いて適切なパーミッションを設定しておけばすぐに公開鍵認証ができるというわけである。 もうそろそろ公開鍵をメールで送ってくれとかいう文化が滅亡して GitHub から勝手に公開鍵を持っていくのが常識な世界になってほしい。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く