Top 20 OpenSSH Server Best Security Practices
OpenSSH is the implementation of the SSH protocol. OpenSSH is recommended for remote login, making backups, remote file transfer via scp or sftp, and much more. SSH is perfect to keep confidentiality and integrity for data exchanged between two networks and systems. However, the main advantage is server authentication, through the use of public key cryptography. From time to time there are rumors
SSH力をつけよう
5. RFC RFC 4250 The Secure Shell (SSH) Protocol Assigned Numbers RFC 4251 The Secure Shell (SSH) Protocol Architecture RFC 4252 The Secure Shell (SSH) Authentication Protocol RFC 4253 The Secure Shell (SSH) Transport Layer Protocol RFC 4254 The Secure Shell (SSH) Connection Protocol RFC 4255 Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints RFC 4256 Generic Message Exchange Authent
sshを使いこなすための7つの設定 - 射撃しつつ前転 改
五月病が抜け切らないIT系新入社員に贈るシリーズ第1段。 ~/.ssh/configにはいろいろな設定が書けるが、周囲を見渡した限り、あまり活用されているようには見受けられない。そこで、今回は便利な設定をいくつか集めてみた。 長いホスト名に短い名前をつける Host exp1 HostName verrrryyy.looooong.hostname.example.jp ssh verrrryyy.looooong.hostname.example.jpの代わりにssh exp1でログインできるようになる。 ちなみに、zshの場合、configファイルに登録されたホスト名はsshコマンドを打つときに補完されるので更に便利。 特定のホストへログインするときのユーザ名や鍵をカスタマイズする Host github.com User tkng IdentityFile ~/.ssh/id_rsa
入門OpenSSH 新山 祐介 著
「入門OpenSSH」 (新山 祐介 著) は、 2006年6月に秀和システムから刊行されました (2009年末に絶版)。 秀和システム 「入門OpenSSH」のページ ここで公開している原稿は、最終的な版下になる前のものです。 実際に出版された書籍とは異なっている部分があります。 重大な間違い等がありましたら、新山までお知らせください。 () 注意: 本書が刊行された時点での OpenSSH のバージョンは 4.3 でした。 現時点(2011年2月)における OpenSSH のバージョンは 5.8 です。 変更履歴 2010/09/12: 公開。 目次 はじめに 第1章. OpenSSH を導入するにあたって 1.1. OpenSSH とは 1.2. OpenSSH にはできないこと 1.3. OpenSSH ができること 第2章. OpenSSH をインストールする 2.1. 現在イン
もういい加減GNU Screen使え - 高原芳浩のKeep-Alive
ディノでは京都1箇所+都内2箇所＋社内の計4箇所に分散されていたデータセンターを京都に集約しつつあります。私は昨日からその関連作業でネットワークチームと京都に来ています。作業の多くが遠く離れたコンピュータを介して行われる事になると同一データセンターのサーバに対してたくさんのSSHを立あげて作業するこは、ネットワーク的に効率的ではありません。クラウド環境がもてはやされている昨今おなじような状況の方も少なくないと推察されます。そこでリモートコンピュータでのオペレーションを効率的にする方法としてGNU Screenをご紹介します。というか、ネットが瞬断したくらいでいちいち文句垂れる奴は迷惑なのでいい加減にGNU Screenを使えばいいとおもいます。 やり方まず、作業用のサーバをデータセンター側に一つ作ります。このサーバへはローカルからSSHのAgentForwardを介してアクセスするので自分
sshでポートフォワード
sshには言わずと知れた「ポートフォワード」という機能があります。 読んで時の如しで、sshの暗号化されたトンネルを利用し、任意のポートに来た通信を転送できます。 何がうれしいかと言うと、リモートの 5432番 をローカルの 5432 にマッピング出きる。 つまり、sshさえ繋がれば、そのサーバから見える範囲ならなんでも使える！と言うことです。 1・ローカルへリモートのポートをマッピング 例えば、二つのホスト（chiba, shiga）があるとします。 chibaに、shigaの5900ポートをフォワードする場合は以下のようになります。
SSH秘密鍵のパスフレーズは（つけるなら）11文字以上にしましょうねという話 - 本当は怖いHPC
twitter上で、「SSHの秘密鍵って、盗まれて.bash_history見られたらアクセスし放題だから危ないからパスフレーズを付けるべき」という話があった。個人的には、パスフレーズは気休め程度にしかならないと思っているので付けていない。そもそも、SSH秘密鍵のパスフレーズは、ネットワーク越しのパスワードとは違うもので（だから違う名前がついているのだが）、ZIPファイルのパスワードと似たようなものだ。攻撃者がファイルをローカルにコピーしてじっくり解析できる。 よって、パスフレーズが役に立つのは、 秘密鍵（とシェルのログ）を盗まれ、 秘密鍵を盗まれたことに気づき、 素早くすべての接続先ホストにおいて盗まれた秘密鍵を無効にする という場合だ。このシナリオなら、攻撃者によって接続先に不正にアクセスされるのを防ぐことができる。 パスフレーズによって、どれくらいの猶予が生まれるのか？ パスフレーズ
高速にWeb開発をするために便利ないくつかのTIPS - KAYAC Engineers' Blog
outputz でいまだに1位になれたことがない村瀬です。 社内で開発をスムーズにするための tips 集を紹介したので、まとめておきます。 記事ではデモができないので便利さが伝わらない物も多いですが参考になれば幸いです。 screenとかzshとか便利だよ！と言う話は社内ではさんざんしているのでありません。 また、OSX 限定の内容もあります。 でははじめましょう。 keychain keychain と言っても OSX の KeyChain ではなく、コマンドラインのツールです。 これは ssh-agent をより便利にするためのラッパーです。これを使用すると ssh の秘密鍵のパスワードを一度入力するとあとはパスワードなしで ssh 接続できるようになります。 「同じこと二回も言わせんな！」といつも切れているような人は導入すると良いでしょう。 使い方は $ keychain ~/.s
超カンタンGit公開リポジトリ構築 - がぶちゃんの日記
わけあってオープンソースにできないのでgithubが使えない。 有料でprivateにできるけど、せっかくサーバ持ってるし。 ということでGitの公開リポジトリを立てました。 似たような運用方法でGitを使おうと思ってる人のために構築手順を残しておきます。 運用方法 公開リポジトリを複数人でpull/push ssh経由でアクセス 手順 そのまえに... 1. 開発者のグループを統一しておく。 うちの環境ではもともとユーザをusersグループに所属させていたので、usersグループでリポジトリも操作することにしました。別で管理したいなら適当なグループを作って、sshで接続するアカウントをそのグループに所属させておいてください。 2. リポジトリ作る。 mkdir -p /var/git/hoge cd /var/git/hoge git --bare init --shared 3. グル
Firefoxからsshのダイナミック転送を使って非公開サーバへアクセスする - 射撃しつつ前転 改
sshにはダイナミック転送という機能がある。この機能を使うと、sshはアプリケーション側にはSOCKSプロクシとして振る舞うが、そこからsshの接続先までは暗号化された状態で通信が行われる。 これだけだと通常のトンネリングとどう違うのかよくわからないかもしれないが、ダイナミック転送の場合は転送ポートを指定する必要がない。ここがダイナミックと表現される所以だろう。 例えば、オフィスAにある開発サーバdev1にオフィス外からアクセスしたいとする。しかし、dev1はオフィス外には公開されておらず、踏み台サーバladd1を経由してしかアクセスするしかない。ladd1はsshのみが動いており、これまではsshのトンネリング機能を使ってアクセスしてきたのだが、ウェブアプリケーションをデバッグする際はいちいちウェブアプリケーションのポート毎にトンネルを掘るのが面倒くさい。オフィスに限らずデータセンターへ
続・$HOME/.ssh/configを活用していますか？ — ディノオープンラボラトリ
以前の記事「$HOME/.ssh/configを活用していますか？」では、設定ファイルを少し頑張って書けば普段のSSHライフが随分変わりますよ、と紹介しました。今日はその続編です。前回よりマニアックな設定を紹介します。 2段以上先のサーバにログインする Dynamic Forward機能を使う 共通設定をまとめて書く 2段以上先のサーバにログインする 目的のサーバにログインするために、踏み台的なサーバを経由しないと入れない環境があります。例えば、dmz経由でないとDBサーバにログインできない環境、というのは良くある構成でしょう。 このような場合に、ProxyCommandパラメータが利用できます。 上の設定で「ssh db1」とすると、sshでdmzに接続し、dmzから192.168.0.201へログインします。これを利用するには踏み台サーバにncコマンドが必要ですが、大抵の環境にインスト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
