著者:takahashi
nginxやAmazon ALBなどのロードバランサー経由でLaravelにアクセスさせたときにHTTP/HTTPSを振り分ける方法
nginxやロードバランサーなどを使ってWebサーバーにアクセスさせた際に困るのが、一部の情報が本体のWebサーバーまで到達しない点。
特に、クライアントがHTTPでアクセスしているのか、HTTPSでアクセスしているのか、などの情報はそのままの状態で取得するのは困難です。
こういった環境と、HTTPかHTTPSどちらで接続されているのかを判定したうえでDOMのURLを書き換えるタイプの機能を持つフレームワークやプログラムとの相性は特に最悪で、Webサーバーに対してHTTPでアクセスされた時点で”クライアントからHTTPでアクセスされている”と判定して、すべてのアセットのアドレスをhttp://から始まるURLに置き換えて返してしまい、結果jsやcssが読み込めずに表示崩れや不具合になってしまうことがあります。
最近人気のLaravelもこの機構を持っており、そのままの状態でnginxやLBを間に置いてしまうと、httpsでアクセスしたときにページが正常に表示されない問題が発生してしまいます。
幸いにも、HTTPSかどうかの部分についてnginxやロードバランサーが代わりに取得し、その情報をヘッダーに含めて投げてくれる場合が多いので、今回はLaravel上でこのヘッダ情報を使って簡単にHTTP/HTTPSを判定できるようにしてみました。
Laravelプロジェクトフォルダ内の
routes/web.php
の最初あたりに、次のコードを追加します。
<?php
// 2018/10/26追記: 一部修正しました。
/*
|--------------------------------------------------------------------------
| Web Routes
|--------------------------------------------------------------------------
|
| Here is where you can register web routes for your application. These
| routes are loaded by the RouteServiceProvider within a group which
| contains the "web" middleware group. Now create something great!
|
*/
//ここから
//リバースプロキシ経由のHTTP/HTTPS判定
if(array_key_exists('HTTP_X_FOWARDED_PROTO',$_SERVER) === true){ //"HTTP_X_FOWARDED_PROTO"ヘッダーが存在していたら
if(strtoupper($_SERVER["HTTP_X_FOWARDED_PROTO"]) == "HTTP"){ //strtoupper("HTTP_X_FOWARDED_PROTO")の中身が"HTTP"だったら
URL::forceScheme('http'); //すべてのURLをhttpに書き換える
} else {
URL::forceScheme('https'); //すべてのURLをhttpsに書き換える
}
}
//ここまで
$_SERVERはPHPにおいて、サーバー情報および実行時の環境情報がすべて格納されるスーパーグローバル変数です。
この中に、リクエストヘッダの中身もすべて格納されるので、その中からnginxやAmazon ALBやClassic Load BalancerがHTTP/HTTPSの情報を格納する”X_FOWARDED_PROTO”ヘッダーを参照して、どちらでアクセスされたかを判定しています。
ifを敢えてHTTPかどうかで判定している理由は万が一、”$_SERVER[“HTTP_X_FOWARDED_PROTO”]”にhttpでもhttpsでもない不正な値が入っていた場合も、とりあえずhttps://で吐き出すようにするためです。
こんな形で処理を加えてやれば、Laravelでもnginxやロードバランサーを使用していても正常にHTTPとHTTPSの切り替えが行えるようになると思います。
少しでも参考になりましたらしたら幸いです。
著者:takahashi
Certbotでnginxプラグインを使用した際に”UnicodeDecodeError”が出てしまった場合の対処法
CentOS 6.10でCertbotのインストールとSSL証明書の取得をnginxプラグインで行った際に、下記のようなエラーが発生。
2018-10-08 15:34:01,329:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
File "/opt/eff.org/certbot/venv/bin/letsencrypt", line 11, in <module>
load_entry_point('letsencrypt==0.7.0', 'console_scripts', 'letsencrypt')()
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/main.py", line 1364, in main
return config.func(config, plugins)
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/main.py", line 1233, in certonly
installer, auth = plug_sel.choose_configurator_plugins(config, plugins, "certonly")
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/plugins/selection.py", line 228, in choose_configurator_plugins
installer = pick_installer(config, req_inst, plugins, installer_question)
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/plugins/selection.py", line 32, in pick_installer
config, default, plugins, question, (interfaces.IInstaller,))
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/plugins/selection.py", line 106, in pick_plugin
verified.prepare()
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/plugins/disco.py", line 251, in prepare
return [plugin_ep.prepare() for plugin_ep in six.itervalues(self._plugins)]
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/plugins/disco.py", line 251, in <listcomp>
return [plugin_ep.prepare() for plugin_ep in six.itervalues(self._plugins)]
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/plugins/disco.py", line 132, in prepare
self._initialized.prepare()
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_nginx/configurator.py", line 145, in prepare
self.parser = parser.NginxParser(self.conf('server-root'))
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_nginx/parser.py", line 38, in __init__
self.load()
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_nginx/parser.py", line 45, in load
self._parse_recursively(self.config_root)
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_nginx/parser.py", line 66, in _parse_recursively
self._parse_recursively(subentry[1])
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_nginx/parser.py", line 56, in _parse_recursively
trees = self._parse_files(filepath)
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_nginx/parser.py", line 207, in _parse_files
parsed = nginxparser.load(_file)
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_nginx/nginxparser.py", line 123, in load
return loads(_file.read())
File "/usr/lib64/python3.4/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 1345: ordinal not in range(128)
2018-10-08 15:34:01,331:ERROR:certbot.log:An unexpected error occurred:
どうやら、Certbot内のpythonスクリプトで何かエラーが発生しており、そのせいでSSL証明書の取得ができなくなってしまっているようです。
エラー内容をよく見ていくと
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 1345: ordinal not in range(128)
とあり、どうやら文字コードの問題が発生していることは分かりました。
とりあえず調べていくと、こちらの記事を発見。
どうやら、nginxの設定ファイルにコメントなどで日本語が入っていると、Let’sEncryptのnginxプラグインがその日本語部分を解釈できない(asciiコードとして解釈しようとしてしまう)のが原因のようです。
とりあえずの対策として、nginxの全設定ファイルから日本語やその他のマルチバイト文字をすべて取り除けば解決するようです。
自分の環境でもnginxからすべての日本語を取り除いたところ、正常に動作し、SSL証明書取得まで行うことができました。
ただ、Let’sEncryptを使用するから、という理由だけでnginx内のコンフィグで日本語が一切使用できないのはちょっと辛いものがあるので、改良されてほしいですね。
著者:takahashi
Let’s Encrypt + MyDNS でワイルドカードSSL証明書を自動更新する方法
昨日の記事で、無料DDNSサービスであるMyDNSで、手動でDNSの編集をしなくてもワイルドカード証明書を取得・更新できるようになったことをお伝えしました。
今回は実際に自動的にワイルドカード証明書を取得・更新為の設定方法をご紹介したいと思います。
まず前提として、まだMyDNSに登録をしていない方は、先に登録しておく必要があります。
また、MyDNSはDDNSサービスであり、IPアドレスを定期的に書き換えることが前提の仕組みになっています。
そのため、たとえ固定のIPアドレスを取得していたとしても、定期的に向き先のIPアドレスをMyDNSに通知する必要があります。
1週間通知しないと、ドメインIPの正引きが停止し、1か月間通知しないと、アカウントが削除されてしまいますが、IPアドレスの通知はプログラムを使って通知することができるようになっていますので、通知スクリプトをcronなどで定期的に実行することで、手動のメンテナンスなしで利用の継続が可能です。
https://www.mydns.jp/?MENU=030のSTEP4にある要件さえ満たしていればどんな言語やプログラムを使ってもOKなのですが、一から作るのはちょっと面倒なので、インターネット上で有志の方が作成したサンプルコードを利用した方が確実かつ手軽なので、活用することをお勧めします。
アカウントの作成方法とIPの自動更新設定についてはネット上に参考資料が沢山出ているため今回は割愛します。
上記の手順まで完了したら、自動更新スクリプトをサーバーに入れ込んでいきます。
ターミナルを開き、次のコマンドをroot権限で実行します
cd ~ #ホームフォルダなどの作業スペースへ移動 wget 'https://github.com/disco-v8/DirectEdit/archive/master.zip' -O DirectEdit-master.zip #MyDNSの自動更新スクリプトをダウンロード unzip DirectEdit-master.zip #ダウンロードしたZipを解凍 mv DirectEdit-master /opt/ #解凍したフォルダを/opt/に移動
次に、自動DNS書き換えの設定をしていきます。
vi /opt/DirectEdit-master/txtedit.conf
内容を下記のように書き換えます。
$MYDNSJP_URL = 'https://www.mydns.jp/directedit.html'; //そのまま
$MYDNSJP_MASTERID = 'mydnsXXXXXX'; //MyDNSユーザーID
$MYDNSJP_MASTERPWD = 'yourmydnspasswd'; //MyDNSパスワード
$MYDNSJP_DOMAIN = 'example.com'; //MyDNSに登録したドメイン名
権限を変更します。
cd /opt/DirectEdit-master chown root:root ./ chmod 700 ./*.php //DNS自動更新プログラム chmod 600 ./*.conf //設定ファイル
これで下準備はOKです。
それではMyDNS自動更新スクリプトを使ってdns-01認証でワイルドカード証明書を取得してみます。
certbot-auto certonly --manual \ #certbot-autoコマンドは環境によって名前が異なる場合があります。 --preferred-challenges=dns \ --manual-auth-hook /opt/DirectEdit-master/txtregist.php \ --manual-cleanup-hook /opt/DirectEdit-master/txtdelete.php \ -d example.com -d *.example.com \ #※左記以外のサブドメイン(たとえばa.example.com)はMyDNSのスクリプトではエラーになるため指定できません。サブドメインのSSLを取得する場合は別途従来のhttp-01認証で取得してください。 --server https://acme-v02.api.letsencrypt.org/directory \ --agree-tos -m hoge@example.com \ #Let'sEncryptからの通知を受け取るアドレスを指定します。 --manual-public-ip-logging-ok
これでおそらくワイルドカード証明書を取得できたかと思います。
一度上記のコマンドを実行してしまえば、次回以降の更新では
certbot-auto renew #環境によってコマンドが異なります。
コマンドのみを実行すれば更新することができますのでcronなどで定期実行させればサーバーが自動でSSL証明書を更新するようになります。
ワイルドカード証明書を手軽に使ってみたい、という方は是非試してみてください。
著者:takahashi
無料DDNSサービスのMyDNSがLet’s Encryptのワイルドカード証明書取得の自動化をサポート。
個人的にもいろいろなところでお世話になっている無料のDDNS(Dynamic Domain Name Server)、MyDNSがLet’sEncryptのdns-01認証の自動化に対応したようです。
2018.07 Let’s Encrypt用API提供開始
Let’s Encryptで、DNS-01方式でサーバー証明書を取得する場合の、–manual-auth-hookならびに–manual-cleanup-hook用のスクリプトをGitHubに公開しました。
詳しくはREADMEをお読みいただければわかるかと思いますが、これによりワイルドカードのサーバー証明書の取得および更新が非常にしやすくなったかと思います。
どうぞご活用ください。
MyDNSとは、自宅サーバ勢御用達の無料DDNSホスティングサービス。
DNSホスティングとの違いは、定期的にサービスに対してIPアドレスを通知することにより、IP固定契約をしていなくても自分の回線とドメイン名を継続的に紐づけることを可能にしている点です。
管理画面からの変更もできますが、プログラムからも通知できるような仕組みを供えているので、cronなどを利用すれば特に操作しなくてもサーバーからMyDNSに対して継続的にIPアドレスを通知し続けることもできます。
一方Let’s Encyptは一定の条件を満たせば無料でSSL証明書を発行してもらうことができるサービス。
以前にも何度か取り上げていますし、ご存知の方も多いかと思いますが、最近はワイルドカード証明書の取り扱いも開始し、ドメインごとにSSL証明書を取得する必要がなくなりました。
ただし、このワイルドカード証明書をLet’s Encryptで取得するためには、DNSサーバの設定を操作して指定された値を登録することでドメインの所有権を確認する”dns-01″方式で認証する必要があります。
また、DNSサーバーに設定する値はドメインの更新時も変化するため、更新のたびにDNSサーバーの値を書き換える必要があり、Let’s Encryptの証明書期限も3か月しかないため、かなり大変でした。
今回、MyDNSが自動更新に対応したことにより、スクリプト一つで自動的にLet’sEncryptから指示された値を自動的にMyDNS側に登録することができるようになったため、一度成功させてしまえば以降はユーザーの操作が一切なくても継続的にワイルドカード証明書の取得、更新が可能となりました。
次回の記事で、実際の設定方法をご紹介したいと思います。
もし待てない、という方はMyDNSさんのGitHubリポジトリに方法が記載されていますので、そちらをご参照いただければと思います。
著者:takahashi
nginxでnet::ERR_CONTENT_LENGTH_MISMATCHが出た時の対処法
今まで普通に動いていたサイトが、ある日突然正常に表示されなくなるという問題に遭遇。
Chromeの開発者ツールで調べると
net::ERR_CONTENT_LENGTH_MISMATCH
上記のメッセージが大量に発生しており、サイトのアセットの読み込みに失敗していたようでした。
ERR_CONTENT_LENGTH_MISMATCHはヘッダーのContentLengthと実際に受け取ったバイト数が違うと発生するようです。
nginxでのERR_CONTENT_LENGTH_MISMATCHの解決法 – Qiita
いろいろなサイトを見てみると、サーバーにNginxを使っている場合、サイトのキャッシュの保存が失敗したときに先程のエラーが出現するようで、その場合は指定パスに書き込み可能なディレクトリを用意すれば解消するようです。
しかし、今回問題が発生した環境では、該当のログが見当たらなかったため、問題が発生していたサイトのキャッシュを禁止する方法で対策してみました。
変更としてはnginxの設定ファイルを下記のように修正します。
server {
server_name .example.com;
listen 443;
ssl on;
ssl_certificate /path/to/hoge.crt;
ssl_certificate_key /path/to/hoge.key;
client_max_body_size 1g;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Fowarded-Proto \$scheme;
proxy_max_temp_file_size 0; #この記述を追加
location / {
proxy_pass https://localhost:8081;
}
}
これでnet::ERR_CONTENT_LENGTH_MISMATCHエラーが消滅し、とりあえず無事サイトが表示されるようになりました。
しかしなぜ突然こんなエラーが出るようになってしまったのか…原因は分かっていないので、さらに調査が必要そうです。
著者:takahashi
GoogleがGoogle Chrome 69をリリース。テスト中だった新UIがついに正式版に。
GoogleがGoogle Chrome 69をリリースしました。
新バージョンに更新してまず最初に目につくのがツールバー部分のデザインの変更でしょう。
以前
Google Chrome Ver.68でChromeの新しいデザインが利用可能に。
でご紹介したテスト中の新UIが、正式版として実装されたものと思われます。
Chrome68で実装されていたテスト版のUIはこんな感じでした。
正式版ではタブの追加ボタンが再び右端のタブの右側に戻り、直感性が上がりました。
また、今までアプリモードでは右クリックメニュー以外からは一切メニューにアクセスできませんでしたが、
タイトルバーから一部メニューにアクセスできるようになりました。
アプリ上から拡張機能の設定も行えるため、さらに便利になりそうです。
そして今回の最も多きな変更はやはりSSL関連。
SSLが有効となっているサイトの表示が、ついに灰色の鍵マークとなり、Chromeの”SSLは適用されていて当たり前”という考え方がより色濃く感じられるようになりました。
なお、次バージョンのChrome 70 では、ついにhttpサイトへつないだ際に文字入力をすると、赤文字の”保護されていません”表示が行われるように変更されるとのことです。
Google Chrome、HTTPSサイトの「保護された通信」を非表示に 「デフォルトで安全が前提」 – ITMedia エンタープライズ
Chrome 69からHTTPSの表記が変化！Chrome 70以降も要チェック！ – 常時SSL Lab.
まだSSL対応をしていない皆さんはお早めに。
著者:takahashi
テストサーバーの仮想マシンに大量のI/Oエラー… 調べたらホストマシンのディスク不良だった件
今朝会社に来て、テストサーバーのシェルに接続しようとしたところ、接続できない状態に。
今回接続できなくなったのは、Windows上に建てたLinux仮想サーバーでした。ホストOS側のWindowsはリモートデスクトップで何とか接続することができたので状況を確認すると…
ほぼすべての仮想マシンでIOエラーが出ていました…
このマシンは以前からやや不安定な挙動は見せてはいたのですが、ドライバのアップデートやメモリの増設を行った後、暫くは問題なく稼働してはいました。
が、再びIOエラーが出てしまったので流石にハードを疑わざるを得なくなってきました。
案の定、S.M.A.R.T.情報を確認したところ回復不能セクタも出ていた模様。
ホストOS側でも読み込みに失敗する症状も出始めていたので、HDDを交換することになりました。
S.M.A.R.T.情報を監視するアプリを入れて置けばメールでの通知もできたとのことで、テスト環境とはいえ、怪しいと思った時点で監視ツールを入れておけばよかったなとちょっと後悔です。
著者:takahashi
有線LANはあるけど無線LANがない…！ そんな時に役に立つWIndowsで逆テザリング(Hotspot化)する方法
最近はビジネスホテルなどでも無線LANが標準で提供されるところも増えてきました。
しかし一部のホテルや施設などでは未だに有線LANだけの提供だけ、というところがある場合もありますし、どこかの場面で急に無線LANが必要になる場合もあるかもしれません。
特に、スマートフォンなタブレットなどの端末は有線LAN接続が困難な機種が多いので、いざというときに有線LANしか使えない環境だと不安です。
そんな状況下のとき、もし無線・有線LAN搭載のWindows 10 PC一台さえあれば簡単に解決することができます。
通知エリアの無線LANアイコンを押すと、
”モバイルホットスポット”というアイコンがあるのがわかるかるかと思います。
実はこれが今回の目的の機能になります。
モバイルホットスポットって何だろう? – テザリング機能の使い方 – マイナビニュース パソコン
モバイル回線をスマホなどを通じてPCに提供することを”テザリング”と呼ぶのに対し、ホットスポット機能はPCが接続するネットワークをスマホなどのWi-Fi端末へ流す使われ方が多い為、しばしば”逆テザリング”と呼ばれます。（やってることはテザリングとほぼ変わりません。）
実は他のOS(macOS、Linux)でも”逆テザリング”する機能はありますが、Windowsには標準で、他OSにはない仕組みを持っています。
それは1つのWi-Fiアダプタを仮想的に分割し、Wi-FiからWi-Fiへネットワークを中継することができる機能です。
基本的に他OSでは、別のネットワークアダプタのネットワークを”逆テザリング”することしかできません。
つまり、共有する元のネットワークにつながるネットワークアダプタとWi-Fiの電波を端末に発信するネットワークアダプタはハード的に別でないといけません。
一般的にノートPCではWi-Fiアダプタと有線LANポートをひとつづつ備えている構成が多いかと思いますので、この場合は有線LANでつないでいるネットワークをWi-Fiから飛ばす、というような使い方に限られます。
しかしWindowsでは、Wi-Fiアダプタでネットワークにつないだまま、同じWi-Fiアダプタから他の端末に対してWi-Fiのアクセスポイントを提供することができます。
この機能はVirtual Wi-Fiと呼ばれています。
また、Windows 10ではBluetoothを搭載していればBluetoothのPANプロファイルを使って逆テザリングすることもできます。
Bluetoothを除く上記の機能は、正式なGUIが実装されたのはWindows 10からですが、機能自体はWindows 7から利用することができます。
Windows 7をお使いで、GUIでホットスポットのON/OFFを行いたいのであれば、
を使うと実現できます。
いざというときにWi-Fiルーターが必要になった際に役に立ちそうですね。
著者:takahashi
恐ろしすぎる”SIMハイジャック”の恐怖
ネットニュースの記事で、こんなニュースが流れてきました。
電話番号が奪われてしまうSIMハイジャックの脅威とは？ – Gigazine
によると、アメリカではある日突然、SIMカードが”乗っ取られて”しまう”SIMハイジャック”なるサイバー攻撃が増加しているようです。
上記の記事によると、アメリカのMNOであるT-Mobile社を利用するユーザーの端末のもとに、ある日突然SIMカードが更新されたというメッセージが届き、それ以降その端末がモバイルネットワークへ接続不可能となってしまったとのこと。
ユーザーの家族がユーザーの番号へ電話をかけたところ、全く知らない人物が電話に出て、SIMをハイジャックしたことを暴露した…という流れ。
被害にあったユーザーは電話番号で認証情報を連携していたSNSや各Webサービスのアカウントをごっそり乗っ取られてしまったそうです。
そしてこの原因が驚くことにキャリアの本人確認不足。
その気になればだれでも手に入ってしまう情報のみで本人を断定し、まったくの第三者に対して、SIMを再発行して渡してしまったようです。
こちらの記事も、同様の被害にあい、仮想通貨を奪われてしまったユーザーのケースです。
ハッキングで仮想通貨を盗まれた海外の投資家がTモバイルを告訴！なぜ仮想通貨取引所ではなく携帯電話会社を訴えたのか、詳細まとめ！ – やさしいビットコイン入門講座
こちらの記事では何故か訴訟した側を叩くような流れになっていますが、本人確認を怠った時点で明らかにT-Mobile側の落ち度であり、多数の被害者がいるにも関わらず今のところ対策が注意喚起のみという、通信事業者としてあり得ない事態となっています。
最近のサイバー攻撃は、システムからそれを管理する”人”を対象としたものにシフトしています。システムの技術的な”あら”を探すより、それを管理する管理者を騙した方がはるかに簡単だからです。
管理者が”クラッキング”されている現状が続く以上、どんなに堅牢なシステムを築いたところで全くの無意味となってしまうでしょう。
ちなみに、日本国内では法律で厳密な本人確認が義務付けられており、手続きを行う際は必ず身分証の原本が求められるようになっているなど、しっかりとした個人認証が行われています。
失敗を犯した存在に後ろ指を指すのは簡単です。
モバイルネットワーク事業者に限らず、何らかのサービスを提供している立場に自分自身がいる場合は、本人確認は厳密に行うように心がけていきたいですね。
著者:takahashi
PostgreSQL “対向(peer)認証に失敗しました” エラーが出るときの対処法
PostgreSQLでちゃんとユーザーにログイン権限とパスワードを設定しているのに、
psql: FATAL: ユーザ "postgres" で対向(peer)認証に失敗しました
のようなエラーが出てしまった場合の対処法です。
そもそもPeer認証とは
CentOS6でPostgreSQLインストール – My Octopress Blog
Peer認証とは、カーネルからクライアント上のシステムユーザ名を取得し、PostgreSQLデータベースユーザと同一である場合のみ接続が許可される仕組みです。
つまり、Postgresql内のユーザーとUNIXユーザで、ユーザー名が一致してさえいれば認証情報なしでログイン出来てしまう仕組みです。
パスワードを打たなくてもいいのは楽ですが、例えばユーザーごとに権限を変えて置いて、場合によって使い分けたいときや一時的に別のpsqlユーザーとしてログインしたいときなどはかなりやりづらいですし、psql側でユーザーを作る際に、同名のUNIXユーザーも追加する必要が出てくるのでとてもめんどくさいです。
この挙動を変更するには、pg_hba.conf （だいたいpsqlのデータフォルダか/etcにあるはずです。）を編集します。
ファイルを開くと
#ローカルで動いているpsqlへアクセスする場合 local all all peer #他のクライアントからpsqlへアクセス可能にする場合(例) host all all 127.0.0.1/32 peer
などとなっているか、あるいはコメントアウトされているかと思いますので、これを書き換えます。
#ローカルで動いているpsqlへアクセスする場合 local all all md5 #他のクライアントからpsqlへアクセス可能にする場合(例) host all all 127.0.0.1/32 md5
パスワード認証させたい場合は”peer”の部分を”md5″に変更して保存し、psqlのデーモンを再起動させます。
これで再度ログインを行えば、今度はパスワードを求められ、正しい情報を入力すればどのユーザーでもログインできるようになるかと思います。