SSH その6

1 ：名無しさん＠お腹いっぱい。：2008/02/12(火) 11:20:40

SSHに関する情報交換のスレッドです。
FAQ、リンク集は >>2-5 あたり。

過去ログ
　Part1：http://pc.2ch.net/unix/kako/976/976497035.html
　Part2：http://pc.2ch.net/unix/kako/1028/10281/1028157825.html
　Part3：http://pc5.2ch.net/unix/kako/1058/10582/1058202104.html
Part4：http://pc8.2ch.net/test/read.cgi/unix/1102242908/
　Part5：http://pc11.2ch.net/test/read.cgi/unix/1145484540/

130 ：名無しさん＠お腹いっぱい。：2008/06/23(月) 01:09:01

>>129
君には無理。

131 ：名無しさん＠お腹いっぱい。：2008/06/27(金) 04:55:39

君には無理とかじゃなく何回読み返しても質問の意図がまったく解らん

132 ：名無しさん＠お腹いっぱい。：2008/07/20(日) 16:44:22

自作プログラムをscpで送りつけてsshでリモート実行したら
> scp a.out 192.168.1.20:tmp
a.out 100% 6497 6.3KB/s 00:00
> ssh 192.168.1.20 ~/tmp/a.out
/libexec/ld-elf.so.1: Shared object "libstdc++.so.5" not found, required by "a.out"
と言われて実行できません。
libstdc++の問題なのはわかるのですが、その先がわかりません
基本的なことですがよろしくお願いします。

133 ：名無しさん＠お腹いっぱい。：2008/07/20(日) 16:46:27

>>132
ssh は関係ありません。
gcc -static で、static リンクしてください。

134 ：名無しさん＠お腹いっぱい。：2008/07/20(日) 16:51:54

libstdc++.so.5は今は古いな。
ローカルホストにlibstdc++.so.6をインストールして、
それとリンクしたa.outを作ってscpで送り付けるか、
リモート側にlibstdc++.so.5をインストールするかのどちらか。
スタティックリンクは最後の手段で、普通はお勧めしない。

135 ：名無しさん＠お腹いっぱい。：2008/07/20(日) 16:55:11

>>134
> スタティックリンクは最後の手段で、普通はお勧めしない。
なんで？

136 ：名無しさん＠お腹いっぱい。：2008/07/20(日) 16:56:50

>>132
最初から192.168.1.20のホスト上でコンパイルしろよ。何も悩まなくて済むよ。

137 ：名無しさん＠お腹いっぱい。：2008/07/20(日) 16:57:55

すいません、超基本的なことでした
libstdc++.so.5が入ってなかったです
ありだとうございました

138 ：名無しさん＠お腹いっぱい。：2008/07/25(金) 03:38:09

OpenSSH-5.1p1に上げたら
ssh host command ってやった時に
.bashrcを読んでくれなくなった…
おかげで$HOME/binにあるコマンドを実行するのにいちいち
ssh host $HOME/bin/command ってやらなきゃならなくなって大困り…

元のに戻すかなあ…

139 ：名無しさん＠お腹いっぱい。：2008/07/25(金) 06:51:23

>>138
.bashrcは、ログインシェルは読まない。読むのは非ログインシェルのみ。
ログイン時に読ませたい設定は $HOME/.bash_profile等に書く。

140 ：名無しさん＠お腹いっぱい。：2008/07/25(金) 11:59:02

>>139
ssh host command ってやった時にはログインシェルが起きるの?
ログインシェルじゃないシェルが起きてそれがcommandをexecするんだと
思っていたんだけど…

141 ：名無しさん＠お腹いっぱい。：2008/07/25(金) 12:13:13

ssh host command の場合、非ログインシェルが起きるのは昔からだな。

142 ：名無しさん＠お腹いっぱい。：2008/07/25(金) 12:17:48

>>138
bashが、shの名前(argv[0])で起動されてるとか、
bash --posix で起動されてたりすると
.bashrcを読み込まない。

143 ：名無しさん＠お腹いっぱい。：2008/07/25(金) 13:08:16

>>138
というか、
ssh host command の場合、ログイン先で
bash -c command が実行されるが、
-c オプション付きでは .bashrc は読み込まれない。
これは昔から変わっていない。
前のバージョンでは読み込んでいたと思っている記憶が間違っているのでは?

144 ：名無しさん＠お腹いっぱい。：2008/07/25(金) 15:42:45

>>143
いや、5.0p1に戻したらちゃんと.bashrcを読んでくれる。
bashのマニュアルには
「bashは、自分を起動したのがリモートシェルデーモン(通常はrshd)か
どうかを調べます。rshdによって実行されているとbashが判断した場合、
~/.bashrc が存在し、かつ読み込み可能であれば、 bash はコマンドを
このファイルから読み込んで実行します。」
とあるので、これが効いている模様。

bashのソース(バージョン3.2、パッチ039まで)を見ると、
リモートから起動されているかどうかは
run_startup_files()の中の
if ((run_by_ssh || isnetconn (fileno (stdin))) && shell_level < 2)
のところで判定している。
ところが、OpenSSH-5.0p1のsshdからつなぐと
isnetconn(fileno(stdin))が1になって
結果的に~/.bashrcを読んでくれるのに対し、
OpenSSH-5.1p1でつなぐとisnetconn(fileno(stdin))がなぜか0になって
そのため~/.bashrcを読んでくれない。
さらにlib/sh/netconn.cのisnetconn()を見ると
getpeername(fd, &sa, &l)がOpenSSH-5.1p1の場合だけなぜかエラーになり、
そのせいでこの関数が0を返している。

これが原因だと判明したのだが、
どこを直せば良いのか思案中…

145 ：名無しさん＠お腹いっぱい。：2008/07/25(金) 16:03:25

isnetconn() 以前の問題として、
run_by_sshが偽になってるのがそもそもの間違いでは。
バージョンによっては、たまたま isnetconn() が真になってくれていたから
結果的にうまく動いていたように見えていただけで、
本来は run_by_ssh が真になるべきなのでは。

146 ：名無しさん＠お腹いっぱい。：2008/07/25(金) 16:12:20

俺的には逆に .bashrcなど読まれると困るな。
5.1p1ではあえてbashを欺いて.bashrcを読ませないように修正を入れたんじゃないか?

147 ：名無しさん＠お腹いっぱい。：2008/07/25(金) 16:26:39

>>145
そうでもない。
SSH_SOURCE_BASHRCがdefineされていない限り
run_by_sshは必ず0になるようになっている。
2.05aのあたりでこの挙動がデフォルトになるように変わったらしい。
…ということはSSH_SOURCE_BASHRCをdefineしてbashを作り直せば
いいのかも知れんが、気分的にそれはちょっとしたくない。
sshdの方の修正で何とかならんかな…
>>146
bashを欺くためだけにわざわざ変なことをするとは考えにくいな。

148 ：名無しさん＠お腹いっぱい。：2008/07/25(金) 16:33:13

getpeername()がエラーになる場合というと、
例えば、ネット直結じゃなくてpty経由になってるとかだけど、
だとすると ssh -T host command にすると解決したりしないか?

149 ：名無しさん＠お腹いっぱい。：2008/07/26(土) 02:30:09

そんな簡単な話でもないみたい >>148
ssh -T host command でも残念ながら動作は変わらなかった。

それで調査を進めたところどうも
5.1p1のsession.cの427行目にある
#define USE_PIPES が悪さをしているっぽい。
これがあるために、直後のdo_exec_no_pty()で
#ifdef USE_PIPESの方のコードが強制的に使われる。
#elseの方ではsocketpairを使っているので
シェルへのstdinがネット経由になるが
#ifdef USE_PIPESの方ではpipeを使っているので
シェルへのstdinがネット経由にならない、
という事情のような気がする。
>>148さんの書き込みがヒントになった。ありがとう。

427行目の #define USE_PIPES を取っ払ってコンパイルしたら
5.1p1でも ssh host command で ~/.bashrc を読むようになった。
これでいく。皆様、協力感謝します。
それにしてもなぜ #define USE_PIPES がこんなところにあるんだろう。
除去し忘れか何かか?

150 ：149：2008/07/26(土) 03:10:11

というわけで、一応自分なりにまとめといた
[問題点] OpenSSH-5.1p1のsshdを動かしているシステムに対し、
bashをログインシェルとするユーザがリモートから
ssh host command を実行した場合、~/.bashrcが読まれない。
OpenSSH-5.0p1までは~/.bashrcを読んでいた。
Linux, Solarisでこの現象を確認。
[解決法] session.cの427行目の#define USE_PIPESを
削除して再コンパイル。
[原因?] bashは、リモートからの実行だと判断すると~/.bashrcを
読む機能を備えるが、stdinに対するgetpeername()が失敗すると、
リモートからの実行だと判断せず、~/.bashrcを読まない。一方、
sshd側のsession.cに#define USE_PIPESがあると、後続の
do_exec_no_pty()でsetsockpair()が使われないため、シェルへの
stdinがネット直結にならない。このため、bashがstdinに対する
getpeername()を実行したとき失敗するので、~/.bashrcが読まれ
なくなる。

151 ：名無しさん＠お腹いっぱい。：2008/07/26(土) 08:18:45

追求乙。開発者に通報してくらさい。>>150

152 ：名無しさん＠お腹いっぱい。：2008/07/26(土) 09:28:29

>>149
解決オメ、だけど、
*BSDでは、pipe()が実際にはsocketpair()を使って実装されていて、
pipe()に対するgetpeername()も成功する、んじゃなかったかな。
だから、*BSD上で開発してると問題が発覚しないので、bug fixもされないと。

153 ：名無しさん＠お腹いっぱい。：2008/08/27(水) 00:58:25

sshでログインする前に実行するコマンドを指定して、
そのコマンドを実行後にログインみたいな事って出来ますか？
下記のような事がやりたいです。

ssh user@example.com --hoge vi
(example.comにログイン後、viを起動した状態に)

ご存知でしたら教えてください。よろしくお願いします。

154 ：名無しさん＠お腹いっぱい。：2008/08/27(水) 07:03:19

>>153

ssh -t user@example.com vi

155 ：名無しさん＠お腹いっぱい。：2008/08/29(金) 16:47:48

パスワード認証も受け付けるSSHサーバをいちユーザとして使用しています。
いちユーザが認証方法をパスワードから鍵交換に変更した場合のセキュリティは、
1) 覗き見などによるパスワード流出、サーバなりすましが防げる点で向上
2) 総当たり・辞書攻撃に対しては変化なし
3) 1)の観点により、鍵交換認証にすべし
という理解でよいでしょうか？

156 ：名無し：2008/08/29(金) 19:04:14

鍵の長さがまったく違う。
1024bit 以上の長さの鍵を使える点で、
16文字がせいぜいのパスワード認証の鍵の長さとは比較にならない。

157 ：名無しさん＠お腹いっぱい。：2008/08/29(金) 23:06:00

サーバがパスワード認証してるなら、総合的なセキュリティの強度は
パスワード認証レベルになるんじゃない？

158 ：155：2008/08/30(土) 13:43:27

お返事ありがとうございました。

>>157
そうですよね？鍵認証のご利益は、2)の観点での主張が多いように見受けますが
パスワード認証っていう「穴」があるなら、ご利益はフルに受けられないと感じた次第です。

>>156
言葉足らずですみません。私が感じているのは上記です。
普段いくら長い鍵で認証していても、短かい鍵での認証が許される以上、
セキュリティの強度は後者で決まっちゃうのかなと考えた次第です。

159 ：名無しさん＠お腹いっぱい。：2008/08/31(日) 17:48:56

パスワード認証でローカルのマシンにログインしたいのですが、
最初に鍵認証と勘違いして、必ず鍵のパスワードを聞いてきます。
man ssh でマニュアルを読み、ネットで調べてもなかったんですが、

いきなり、パスワード認証で入れるように指定するコマンドってありますか？

160 ：名無しさん＠お腹いっぱい。：2008/08/31(日) 18:12:17

あります。

161 ：名無しさん＠お腹いっぱい。：2008/08/31(日) 21:27:44

ありがとうございます。安心しました。

162 ：名無しさん＠お腹いっぱい。：2008/08/31(日) 21:38:48

サーバー側でパスワード認証を許可していても、
ユーザー側の設定($HOME/.sshとか)で、
パスワード認証を不許可にするような設定ってできますか?

(ログイン元のクライアント側で不許可にするんじゃなくて、
サーバー側で不許可にする方法の質問です)
(サーバーは管理者が別人で、自分にはroot権限が無い場合です)

163 ：名無しさん＠お腹いっぱい。：2008/09/01(月) 12:42:10

>>160
教えてもらえませんか？

164 ：名無しさん＠お腹いっぱい。：2008/09/01(月) 12:53:56

あるって教えてもらったじゃん。

165 ：名無しさん＠お腹いっぱい。：2008/09/01(月) 21:32:39

>>162
man ssh_config

>>163
ssh -o で好きにしろ

166 ：名無しさん＠お腹いっぱい。：2008/09/01(月) 21:50:19

>>165
>man ssh_config

↑それはクライアント側でパスワード認証を禁止する方法ですね。
それは当然知ってます。
そうじゃなくて、サーバー側で禁止する方法を質問してるんです。

167 ：名無しさん＠お腹いっぱい。：2008/09/01(月) 22:12:06

>>166
man sshd_config

168 ：名無しさん＠お腹いっぱい。：2008/09/01(月) 22:22:21

>>167
man sshd_configでは、サーバーの /etc/ssh/sshd_config でしか設定できません。
元の質問のとおり、root権限の無いサーバーで、ユーザーサイドで
sshd_config相当の設定をしたいわけです。
manを読む限りは $HOME/.ssh/sshd_config のようなものはありません。

で、どうやってやるのでしょうか? 答えてください。

169 ：名無しさん＠お腹いっぱい。：2008/09/01(月) 22:41:17

特定のアカウントが公開鍵認証だけに出来たところで、サーバのセキュリティは
さほど変わらないんだし、どうしても自分のアカウントだけ守りたいんならパスワードを
十分な強度にすればいい。もちろんサーバが乗っ取られたら終わりだが。
それが嫌ならサーバのパスワード認証やめてもらうしかない。

170 ：名無しさん＠お腹いっぱい。：2008/09/01(月) 22:55:47

できないなら「できない」って最初から答えろよw

171 ：名無しさん＠お腹いっぱい。：2008/09/01(月) 23:14:01

何を設定しようがsshを話すﾌﾟﾛｸﾞﾗﾑを自分でｲﾝｽｺすることが可能なら
制限などできないが答えだよ

172 ：名無しさん＠お腹いっぱい。：2008/09/01(月) 23:45:59

>>171
「不可能なら」の誤りではないでしょうか？

173 ：名無しさん＠お腹いっぱい。：2008/09/02(火) 00:02:00

>>159
>いきなり、パスワード認証で入れるように指定するコマンドってありますか？
サーバ側の~/.ssh/configにPreferredAuthentications passwordじゃダメ？

174 ：名無しさん＠お腹いっぱい。：2008/09/02(火) 00:59:09

>>173
~/.ssh/config はSSHクライアントの設定ファイルなのでダメです。

175 ：名無しさん＠お腹いっぱい。：2008/09/02(火) 08:01:38

>>162
俺様sshdなら、できるよ

176 ：名無しさん＠お腹いっぱい。：2008/09/02(火) 08:11:12

>>175
すでに稼働してるsshdで、自分のアカウントに対して他人が
パスワード認証でアタックするのを防ぎたいという目的だから、
ユーザー権限で「俺様sshd」をインストールしても解決しない。

177 ：名無しさん＠お腹いっぱい。：2008/09/02(火) 09:18:23

>>176
すでに稼働してるsshdが何なのか書いてない時点で、釣りだろ

178 ：名無しさん＠お腹いっぱい。：2008/09/02(火) 09:27:44

>>177
>>162

179 ：名無しさん＠お腹いっぱい。：2008/09/02(火) 10:54:35

>>178
>>162のどこにも、すでに稼働してるsshdがOpenSSH portableなのか俺様sshd
なのか書かれてない