SSHのログイン先でも最適化されたvimが使いたい

サーバでオペレーションするときに、ちょっとトラブルシュートしたりするくらいならよいのですが、定期的にログインして作業するサーバがそれなりにあって、その生産性があまり無視できなくなったのでSTNSにstns-setupという機能を設けました。 STNS導入済みのクライアントでstns-setupコマンドを実行すると、事前に定義しておいたコマンドを実行することが出来ます。 $ stns-setup アトリビュートはこんな感じです。 [users.example] id = 1000 name = "example" setup_commands = [ "git clone https://github.com/pyama86/dotfiles.git /home/example/dotfiles", "/bin/sh

More

STNSが単体でのTLS暗号化&クライアント認証に対応しました

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-09-22-22-54-23

先日STNS,libnss-stnsともに0.2.2をリリースしました。主な変更内容は下記のとおりです。 TLS暗号化に対応 TLSを利用したクライアント認証に対応 retry_requestパラメーターでクライントのリトライ回数を指定可能にした ubuntu14.04における再起動が完了しない不具合を修正 TLS関連 これまではnginxなどと組み合わせてTLS/SSL暗号化を提供していましたが、@naoto_gohkoさんからissueを頂いたのと、昨今みんな出来るだけサーバ立てたくないんだろうなぁというフォースを感じたので、単体でTLS暗号化に対応し、サーバ、クライアント共にパラメータを追加しています。 STNS.jp Configuration tls_ca = "keys/ca.pem" # using only client authentication tls_cert = "keys/server.crt" tls_key = "keys/server.key" クライアント、サーバいずれもパラメーターの内容は一緒ですが、サーバのtls_ca及び、クライアントのTLS関連のパラメーターについてはクライアント認証を行うときだけ指定してください。 TLS暗号化だけを利用する場合 stns.conf tls_cert = "keys/server.crt" tls_key = "keys/server.key" libnss_stns.conf api_end_point = ["https://example.jp:1104/v2"] TLSクライアント認証を利用する場合 stns.conf tls_ca = "keys/ca.pem" tls_cert = "keys/server.crt" tls_key

More

~/.ssh/configを分割管理できるpincというコマンドを世に産んだ

初夏が猛暑!皆様いかがお過ごしでしょうか? 昨今、サーバインフラのクラウド化により一人のエンジニアが複数のサービスのサーバに対してSSH接続することも多くなってきました。また多くのサーバでグローバルIPを保つ必要がなくなり、リバースプロキシを置いて管理する構成が増えてきたように思います。そこで悩まされるのが~/.ssh/configの管理じゃないでしょうか? ファイルが500行くらいになったり、新しいエンジニアが入るたびに 「xxxに接続したいんですけど、繋がらないんですよぉ~」 「なっぁぁぁにぃぃぃ~~~~!?この内容を~/.ssh/configに黙って書いてくれ!!!1」 なんてやり取り多いですよね。。そういったやり取りをなるべく少なく出来るようにGolangでpincというコマンドを開発しました。 インストール OS Xで利用することが多いかと思いますのでhomebrewを準備しています。 $ brew tap pyama86/pinc $ brew install pinc 使い方 $ pinc init initコマンドにより~/.ssh配下にconf.dディレクトリ、pinc.yml、base_configファイルが作成されます。 conf.d 配下に作成されたディレクトリ、ファイルを再帰的に読み込みます。 pinc.yml includeディレクティブ配下に配列でファイル、ディレクトリを定義すると再帰的に読み込みます。 base_config ~/.ssh/configをコピーしたファイルです $ pinc gen initファイルで作成、定義されたファイルをマージし、~/.ssh/configファイルを作成します。 便利な使い方 複数サービスを提供している会社の場合、~/.ssh/pinc.ymlに下記のように定義することで、複数サービスの~/.ssh/configを一元管理できるようになります。 include: - /path/to/ServiceA_File -

More

パスワード暗号化について学びを得た

スクリーンショット 2016-05-29 11.03.17

今日はパスワードの暗号化について書いてみたいと思います。 きっかけはSTNSにSudoパスワードを追加した際に@matuuさんよりご指摘をいただいたのがきっかけです。 これまでパスワード暗号化に対する知見が全く無く、「とりあえずSHA256あたりでハッシュ化しとけば漏洩してもダイジョウV!!!」なんて思ってたものですから、これを機に調べてみました。 パスワードの暗号化が有効に働く機会として最も可能性が高いのは、サーバに何らかの手段で侵入され、データベース、ソースコードが参照された状態だと思います。要するに侵入者にすべてを見られた状態でもパスワードを知られ得ないことを目的として暗号化するわけです。 パスワードの暗号化時によく用いられる強固にする手法としてはSalt、Stretchingの2種類があります。今回はこの2点についてまとめてみました。 Saltを利用しパスワード暗号化を強化する Saltというのは御存知の通り塩です。パスワードに塩を足して、いい塩梅にするわけです。前提となる話として、パスワードクラックの手法の一つにレインボーテーブルを用いた手法があります。 レインボーテーブルとは予め一定量の文字列をハッシュ化したものを辞書化しておき、辞書と突合することにより瞬時に元のパスワードがわかるというものです。たとえば、下記のようなコマンドの結果をひたすら作りこんでおけば、passwordやp@sswordのようなパスワードは瞬時に破られてしまいます。 % echo -n 'password' | shasum -a 256 5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8 - % echo -n 'p@ssword' | shasum -a 256 0fd205965ce169b5c023282bb5fa2e239b6716726db5defaa8ceff225be805dc - これに対する有効な対策として、パスワードの文字列を長くすることにより、辞書に登録され得ない値を設定することが挙げられますが、我々人類の多くは怠惰であり、パスワードマネージャーを使うのもニュータイプに限られるため、システム側でなんとかしてやる必要があります。 それに対する一つの手段がSaltです。具体的にはユーザーに入力されたパスワードに何らかの文字列を追加してからハッシュ化し、保存してあげることにより、ユーザーに意識させることなく、パスワード暗号化を強固にすることが出来ます。 手軽にやるのであればユーザー名をハッシュ化したものをSaltとして利用してあげるのが良さそうです。 % echo -n 'pyama' | shasum -a 256 6b513449d1d9f85a652dc54f440603ec19761708c801eb8cd12fc96ee6cedbc9 - % echo -n '6b513449d1d9f85a652dc54f440603ec19761708c801eb8cd12fc96ee6cedbc9password' | shasum

More

STNSでSudoパスワードをサポートした

STNS 0.0.4、libnss-stns 0.0.6リリースしました。今回の主な機能追加は下記のとおりです。 sudoersアトリビュートでsudo用パスワードを指定可能にした STNSがダウンしている時にロックファイルを作成し、一定時間通信を抑制する sudoersアトリビュートの追加 これまでSTNSを利用する場合、sudoersに下記のような設定を追加し、パスワード未利用での運用が必要でした。 /etc/sudoers example ALL=(ALL) NOPASSWD:ALL 今回のアップデートにより、NOPASSWD:ALLを指定せずとも、Linuxの認証基盤であるPAMと連携することにより、sudo時のパスワードが指定可能となりました。 PAMについては@ITのSambaユーザーのパスワード管理 PAMを利用して認証を行うの記事がイメージをつかみやすいと思います。 まずSTNSに下記のような設定を追加します。 /etc/stns/stns.conf [sudoers.example] password = "f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2" hash_type = "sha256" # $ echo "test" | sha256sum # f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2 これはsudoersの設定としてexampleを定義し、パスワードにtestという文字列のSHA256ハッシュを指定します。 このようにパスワードはハッシュ値で指定し、現状はSHA256とSHA512に対応しています。 次にsudoを実行するサーバのPAMの設定を行います。 /etc/pam.d/sudo #%PAM-1.0 auth sufficient libpam_stns.so sudo example # この行を追加 auth

More

STNSに組織体系を管理するLinkGroup機能を追加しi386に対応しました

STNSとは SSH公開鍵ログイン時の時の公開鍵の取得及びLinux上のユーザー、グループの名前解決を行う仕組みです。 設定ファイルにTomlを用いており、下記のワークフローでユーザー管理ができるようになります。 1.Pullリクエスト 2.レビュー 3.デプロイ Linuxユーザーと公開鍵を統合管理するサーバ&クライアントを書いた[更新] 更新内容一覧 LinkGroup機能で部署体系を表現可能になった i386に対応 Go 1.6対応 APIレスポンス修正 バグフィックス LinkGroup機能で部署体系を表現可能になった グループを定義する際に、グループに所属するユーザーをリンク可能となったことで、部署表現が可能となりました。 [groups.department] id = 2000 users = ["example1"] link_groups = ["division"] [groups.division] id = 2001 users = ["example2","example3"] このような定義を行った時に、departmentにはexample1-3が所属し、divisionにはexample2-3が所属するというような表現出来ます。 $ id example1 uid=1001(example1) gid=2000(department) groups=2000(department) $ id example2 uid=1002(example2) gid=2001(division) groups=2001(division),2000(department) APIレスポンス修正 これまではユーザーとグループのレスポンスが同じ形式でしたが、そのレスポンス形式を必要な情報のみ記載する形式としました。 before $ /usr/local/bin/stns-query-wrapper /user/name/pyama

More

デプロイユーザーをSTNSで管理する

Untitled (1)

先日リリースしたSTNS 0.0.2においてlink_usersという設定項目を追加し、デプロイユーザーをまとめて管理する仕組みを追加しました。 困りごと 僕が所属しているムームードメインでは複数のエンジニアが在籍しており、アプリケーションのデプロイにはCapistranoを利用しています。 デプロイする際にはデプロイ専用のユーザーを各サーバにchefで作成し、人員の増減があった場合は、都度デプロイユーザーのauthorized_keysを書き換えるような運用を行っていました。 この場合、例えばデザイナーがスポットでデプロイが必要だったりした時にいちいちchef流さなければならなかったり、authorized_keysファイルの中身って公開鍵だけしか書いてないので、そもそも管理が煩雑だったりします。 link_usersとは 先の困り事を解決するためにユーザーの公開鍵をマージする機能を追加しました。 [users.pyama] keys = ["ssh-rsa aaa"] [users.tukki] keys = ["ssh-rsa bbb"] [users.deploy] link_users = ["pyama", "tukki"] 上記の定義を行うと、deployユーザーの公開鍵を取得すると下記の出力になります。 /user/local/bin/stns-key-wrapper deploy ssh-rsa aaa ssh-rsa

More

STNSのパッケージリポジトリを公開しました

スクリーンショット 2016-02-20 19.16.51

先日記事を書いたSTNSのyum,aptリポジトリを公開したので紹介と、追加機能についてまとめてみました。 STNSとは これまでLDAPやサーバごとに管理されていたLinuxユーザー、グループや、SSHの公開鍵をTOMLフォーマットの設定ファイルを用いた、JSONフォーマットのAPIで集中管理出来るようになるサーバとクライアントから成るシステムです。特にLDAPと比較し、導入、ユーザー管理が容易な点が特徴です。 前回の記事:Linuxユーザーと公開鍵を統合管理するサーバ&クライアントを書いた リポジトリ yum,apt共にshellスクリプトを実行するだけでリポジトリを追加することが出来ます。なお対応しているのは64bit版OSのみのためご注意ください。 CentOSの場合 $ curl -fsSl https://repo.stns.jp/scripts/yum-repo.sh | sh $ yum install stns libnss-stns ubuntuの場合 $ curl -fsSl https://repo.stns.jp/scripts/apt-repo.sh | sh $ apt-get install stns libnss-stns また前回の記事のバージョンに加えて下記に対応しています。 STNSから情報を取得するクライアントラッパーを分離 名前解決時のベーシック認証に対応 chain_ssh_wrapperで複数の問い合わせ先から公開鍵を取得可能になった chef Cookbookが爆誕 STNSから情報を取得するクライアントラッパーを分離 これはgolangでCGOを利用してコンパイルした場合に、netライブラリを利用するとgoroutineのデッドロックが発生した場合に検知できずに、固まってしまう状況が発生したためです。 go 1.5.1 linux/amd64 deadlock detection failed $ /usr/local/bin/stns-query-wrapper /user/name/pyama { "pyama" : {

More