Ubuntuはデフォルトで文字コードとしてUTF-8を使っているため，ターミナルを使ってEUC-JP環境のサーバにsshした時，日本語の文字化けが起こってしまう．cocotというツールを使えばこれを防ぐことができる．便利． cocot - COde COnverter on Tty http://vmi.jp/software/cygwin/cocot.html $ mkdir src $ cd src $ wget http://vmi.jp/software/cygwin/cocot-20080315.tar.bz2 $ tar jxvf cocot-20080315.tar.bz2 $ cd cocot-20080315 $ ./configure $ make $ sudo make installPacoを使っている場合は最後のsudo make installを以下のようにすれ
OpenSSH で生成した秘密鍵を使って Poderosa で公開鍵認証をしようと思ったのですが 「Wrong Key Format」なるアラートがでて困り果てました。 いろいろ調べてみると OpenSSHの鍵ファイルは変換しないと使えない ・・・それ先に言ってくださいｚｚ SECSH 形式への変換方法 PuTTYに付属している「PuTTYgen」というプログラムを利用します。 ※このままPuTTYに乗り換えてもいいんジャマイカ？ PuTTY（SSHクライアント）をインストールしてください。 更に日本語化するならPuTTYjpをインストールしてください。 PuTTYgenを起動します。 Loadボタンを押しOpenSSH 側で生成した秘密鍵を読込みます。 秘密鍵を無事に読込めれば、以下のメニューを選択する Conversions ⇒ Export ssh.com key SECSH
Download PuTTY: latest release (0.82) Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team Download: Stable · Pre-release · Snapshot | Docs | Privacy | Changes | Wishlist This page contains download links for the latest released version of PuTTY. Currently this is 0.82, released on 2024-11-27. When new releases come out, this page will update to contain the latest, so this is
OpenSSLライブラリを使ってプログラミング(1) OpenSSLライブラリを使ってプログラミング(2) 証明書・検証についての予備知識 の続き 証明書ファイルの形式 証明書のエンコーディングにはPEM形式とDER形式(ASN.1形式)があるみたいだけど、OpenSSLではPEM形式の方が扱いやすいみたい(※PEM = Privacy Enhanced Mail、DER = ASN.1 Distinguished Encoding Rules)。PEM形式の証明書は次のようなもの。 -----BEGIN CERTIFICATE----- MIICFzCCAYACBAht6ywwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCSVQxETAP BgNVBAgMCENhbGFicmlhMRowGAYDVQQKDBFQeXRoYWdvcmVhbiBPcmRlcjEkMC
Rubyの部屋 Rubyについて 最初からオブジェクト指向のサポートを意識して作られた、Perlに優るとも劣らない機能を持つ日本産のインタプリタ（スクリプト）言語です。もともとの傾向としては移植性が高いのですが、OS独自の機能を利用するためのライブラリも充実していますし（Windows独自の便利で面白い機能へのアクセス手段も豊富）、TkをはじめとするGUIライブラリとの連携もスムーズで、趣味プログラミングの観点から見ても、凝った用途に十分対応できる幅広さがあります。また楽しく気軽にプログラミングできる言語としても定評があります。 対応プラットフォーム： 多くのUNIX、DOS、Windows、MacOS Xなど 公式サイト： オブジェクト指向スクリプト言語Ruby Rubyニュース
目的 sshでリモートホストでコマンドを実行するときに、PATHやその他の環境変数を設定して実行したい。 例えば、勝手にコマンドのバージョンアップができない重要なサーバで、自分のホーム以下にインストールしたコマンドをssh経由で実行したいのだが、PATHが/usr/local/binなどにしか通っていなくて困っている。 結果 sshdの設定変更 (PermitUserEnvironment=yes)、sshd再起動 ~/.ssh/environment に環境変数を書く (VAR=VAL 形式で一行一変数で) ※ "~" や "$" の置換はしてくれないので、PATHを書くときはフルパスで書くこと。 ※ ~/.ssh/rc に書いてもダメです 以下、詳細。 sshのmanによると… sshd(8)の "LOGIN PROCESS" の項目によると、sshでログインした時の処理順序は、以下:
Windows(cygwin)で、SSH, Subversion, gitosis(Git)サーバを立てるときに、色々調べたのでメモ cygwin install setup.exeを実行。 cygrunsrv, openssh, git, python などを入れる。お好みで subversion, vim, emacs なども。 sshサーバ 以下のサイトが参考になった http://www.uechan.com/yeti/tips4.html http://new.micro-vnc.jp/documents/archieve/sshwindows/ http://www.rouge.gr.jp/~fuku/tips/cygwin-sshd/ Windowsの環境変数 CYGWIN = binmode ntsec tty を設定。 cygwin上で $ mkpasswd -l > /
blog@browncat.org Web, Linux, Ubuntu, Mac, PDA, 携帯電話, プログラミング, ソフトウェア＆落書き httpのproxyを介して外部接続出来るcorkscrewを使ってssh接続出来るというのでメモ。最近出張がちで忙しくて更新が滞ってます。実は今も出張中のホテルだったりして。でRSSを斜め読み中発見した便利そうな記事。 http://www.ubuntugeek.com/how-to-use-ssh-via-http-proxy-using-corkscrew-in-ubuntu.html Bob’s blog » Blog Archive » SSH connection though proxy (2) — Client on linux Tunneling SSH over an HTTP-Proxy Server ubuntuならap
SSHプロトコルを使ってリモート・ホストと暗号化通信するコマンド。セキュリティを確保しながらリモート・ホストに接続できるため，telnetに代わって標準的に利用されている。利用方法には，1.リモート・ホストへログインして対話的にコマンドを実行する，2.実行するコマンドを引数として指定する，3.リモート・ホストとの間で暗号化トンネルを確立してポート転送する――の三つの形態がある。 ssh [-l ユーザー名] [-v] [-q] [-1] [-2] [-4] [-6] [-N] [-b IPアドレス] [-e エスケープ文字] [-o オプション] [-p ポート番号] [-F 設定ファイル] [-i 秘密鍵ファイル] [-c 暗号方式] [-m メッセージ認証コード] [-L ポート番号:ホスト:ホスト側ポート番号] 接続先ホスト | ユーザー名@接続先ホスト [コマンド] または ssh
ポートフォワーディング（port forwarding）とは、ローカルコンピュータの特定のポートに送られてきたデータを、別な通信経路を用いてリモートコンピュータの特定ポートに送信する事です。 この通信経路には、SSHを利用する事が多いです。 SSHの通信路を使用することによって、通信を暗号化することができます。 通信のイメージは図のようになります。 通常は、各アプリケーションが、それぞれのポートを使用して暗号化されていない平文で通信を行います。 しかし、このままではパケットの盗聴などセキュリティに危険が生じます。 そこで登場するのが、”SSHを利用したポートフォワーディング（Port Forwarding）”です。 この方法によって、通信は暗号化されたSSHの経路を通ります。 従って、平文よりも安全性を高める事ができます。 では、実際の通信の経路を追ってみましょう。 通常の通信では、各アプ
本記事では、「Corkscrew」というクロスプラットフォームプログラムを利用し、HTTP経由でSSHのトンネリング接続を行う方法を紹介する。 あなたには、出社してから必要なファイルを自宅に置き忘れてきたことに気付いたという経験はないだろうか？あるいは、出先でこういった忘れ物に気付いたことはないだろうか？企業やISPのなかには、こういった状況への対応を困難にする厳しいファイアウォール設定がなされているところもある。そして実際に、こういった厳しい設定が絶対に必要だというケースが存在している一方で、それほどではないというケースも存在している。とは言うものの、HTTPプロキシの使用が強制され、SSHが使えない環境であっても、HTTPプロキシを経由してSSHに接続することが可能なのである。 先に述べておくが、本記事は外部へのSSHアクセスがポリシーで明示的に禁じられている環境において、ファイアウォ
必要に迫られてsshトンネリングをしたのでメモ。 sshトンネリングを使うときの要求としては多分2つあって、「sshプロトコルを使って暗号化されたセッションの中で他のプロトコルをセキュアに利用したい(カプセル化したい)」場合と、「そもそもsshポートしか開いていない場合にそのポートを他のプロトコルの経路として使いたい」場合があると思う。 どちらの場合でも使い方は基本的に同じ。 例えばPostgreSQLサーバに接続するpsqlコマンドをsshトンネリングして使う場合を想定してみる。 【前提条件】 ・ローカルサーバ:localhost ・リモートサーバ:remote.com ・リモートサーバユーザ:remoteuser ・リモートsshサーバポート:22 ・リモートPostgreSQLサーバポート:5432 ・データベース名:testdb ・データベースユーザ:dbuser まずローカルサー
twitter上で、「SSHの秘密鍵って、盗まれて.bash_history見られたらアクセスし放題だから危ないからパスフレーズを付けるべき」という話があった。個人的には、パスフレーズは気休め程度にしかならないと思っているので付けていない。そもそも、SSH秘密鍵のパスフレーズは、ネットワーク越しのパスワードとは違うもので（だから違う名前がついているのだが）、ZIPファイルのパスワードと似たようなものだ。攻撃者がファイルをローカルにコピーしてじっくり解析できる。 よって、パスフレーズが役に立つのは、 秘密鍵（とシェルのログ）を盗まれ、 秘密鍵を盗まれたことに気づき、 素早くすべての接続先ホストにおいて盗まれた秘密鍵を無効にする という場合だ。このシナリオなら、攻撃者によって接続先に不正にアクセスされるのを防ぐことができる。 パスフレーズによって、どれくらいの猶予が生まれるのか？ パスフレーズ
gitosisとはどのレポジトリをどのユーザーに公開するか管理するソフト。 非常に便利です。 基本的に http://openbooth.org/archives/60.html http://openbooth.org/archives/65.html http://openbooth.org/archives/82.html http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way を見ればインストールできます。 上記のリンクで足らない事は /etc/ssh/sshd_configのAllowUsersにgitを足しておく事（上記リンクに従って設定した場合）と Ubuntuの場合/etc/init.d/ssh reloadじゃ駄目でrestartなこと、 redmine等とリンクさせる場
なんだかやけに長い説明ばかり検索に引っかかったので書きました。 Linuxのローカル環境でDockerコンテナ内のXアプリ（GUIアプリ）を利用するには $ xhost localhost + を実行した後に $ docker run --rm --net host -e "DISPLAY" container_image_name x_app_binary_path とすれば良いです。 もっと読む SSHなどよく知られたサービスポートで何も対策せずにいると数えきらないくらいの攻撃リクエストが来ます。不必要なログを増やしてリソースを無駄にし、もし不用意なユーザーやシステムがあると攻撃に成功する場合もあります。 SshguardはC作られており、flex/bisonのパーサールールを足せば拡張できますがカスタム版をメンテナンスするのも面倒です。必要なルールを足してプルリクエストを送ってもマー
エラーが発生する原因は下記が理由。 /usr/bin などの「普通のパス」に svnserve がインストールされている場合は何もしなくても SSH トンネリング経由でクライアント側からそれを実行できるが、そうでない場合はそのままでは実行できない。そして、サーバ側のログインシェルのパスの設定をいじってもそのような「普通でないパス」を検索できるようにはできない。というのも、SSH トンネリングではログインシェルを起動せずにコマンドの実行を行う必要があるからだ。 SSH は独自にコマンド検索パスを持っている。 [Subversion] 普通でないパスに入っている svnserve をトンネリングで使用したい調べたところ、これは ssh サーバ sshd の設定によって、 ssh 経由でリモートからコマンドを発行したとき、コマンドサーチパスである PATH をはじめとしたユーザ環境に制限がかけら
問題の内容ssh 経由で git を使うときに、環境の問題で次のようなエラーが出ることがあります。 $ git pull bash: git-upload-pack: command not found fatal: The remote end hung up unexpectedly 原因はエラーメッセージの通りで、git-upload-pack コマンドにパスが通っていないためエラーになっています。共用レンタルサーバ*1で ローカルに git をインストールして、ssh 経由で ~/.bashrc などの環境変数が読み込こまれず PATH が変更されなかったときなどに、この状態になります。 解決の仕方クライアント側のその場しのぎな方法として、コマンドラインオプションでパスを指定することができます。 $ git pull --upload-pack /home/username/loc
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
