SSH その8
SSH で接続すると、日本語入力ができなくなるのだが、、これって無理なの？
Cygwin → LinuxMint
LinuxMint → LinuxMint(別ユーザー)
ターミナル または 、ssh -X で手元に表示したアプリでも日本語入力できない。
LinuxMint単独だと、 Mozcとかで日本語入力できてるんだけど。 >>139
この場合日本語入力はローカル側のが使われるんだよ。sshログイン先のホストのものではない。
必要な環境変数が設定されてないとエスパー。 >139-142
失礼しやした。
結論から言うと、リモート先で、
export XMODIFIERS="@im=fcitx"
と入力することによって、
GUIアプリ(Firefoxとかgvim)でも、日本語入力(Mozc)ができるようになりました。
で、後は、この export 文を設定ファイルで自動読み込みさせたい。
.bashrc に書くのはイマイチだし、
かといって、.ssh/rc に 書くと、
今度は、sshが、 xauth を読まなくなる。
これについては、
SSHのマニュアルか
http://www.unixuser.org/~euske/doc/openssh/jman/sshd.html
個人ページ
http://namazu.org/~tsuchiya/ssh/
http://uncorrelated.no-ip.com/20101225.shtml
を参考に対処できそう。 自己レス
>>143
LinuxMint→LinuxMint へ、ssh -X でリモートログインした場合、
export XMODIFIERS="@im=fcitx"
すれば、gvim等のGUIアプリでも日本語入力のインターフェースが使えた。
だけど、~/.ssh/rc に記述すると xauth関連が良く分からないのであきらめ。
おとなしく、exportを手打ちするか、source することにした。
それから、
cygwin → LinuxMint へ ssh -X で リモートログインした場合は、
リモートの Xアプリ(gvim)にて、日本語入力インターフェースを使う方法が見つからなかった。
orz cat .ssh/id_rsa | ssh username@remotehost 'cat >> .ssh/authorized_keys; chmod 600 .ssh/authorized_keys'
これだと秘密鍵をremotehostに持ち出すことになるよね？
このあと特にエラーが出るわけでもないから初心者だと気づかないかも。 なんで秘密キーを公開キーのファイルに追記してんの？ｗ >>146
公開鍵登録しろよ。多分id_rsa.pub >>147-149
川本安武とかいうバカが元凶のようだ。
http://books.google.co.jp/books?id=iUcoBQAAQBAJ&;lpg=PR1&hl=ja&pg=PA35#v=onepage&q&f=false ~/はシェルに依存だから。
>>や;も意図したとおりに解釈してくれないかも知れないが。 ~/ を解釈しないシェルって何だ？
dashもbusyboxのshも解釈するぞ /bin/shがThompson ShellとかBourne ShellでOpenSSHが入ってる環境とか
無理やり作ろうとしても大変だなｗｗ うん、ありますね。
で、それをわざわざ使わせて
「~/ はこのシステムでは使えない、だからスクリプトを書く時は~/を使うな」
と教え込むんでしょうか？ ~ を解釈しないシェルで ~ を使ってしまう危険性より
ホームディレクトリ以外で >>150 のコマンドを実行してしまう危険性の方が高いんじゃないかな。 >>158
ホームディレクトリで実行する方が危険だろ。
それ以外ならエラーで済む。
お前、川本とかいうバカ本人? まだわかって無いの?
何冊売れたか知らんけど、その記述を鵜呑みにした読者を危険に晒してるんだぞ。
死ねば? >>150 = >>159 はここで作者disる暇あったらgihyoに本の回収絶版でも申請すれば？ だから訂正でも謝罪でも訴訟でもなく作者の死を望んで何になるのよ とりあえずお前があの本以外から一切の情報を仕入れず、ネットで検証もせず
鵜呑みにしてやらかして逆切れしたことはわかった 新山祐介さんの「入門OpenSSH」最強伝説がまた証明されてしまったな
ttp://www.unixuser.org/~euske/doc/openssh/book/index.html
おまえらネットも本も間違ってるから絶対に参考にするな
新山祐介さんの「入門OpenSSH」だけを参考にしろ
これ一冊あれば何もいらない 間違った記述すると、瞬殺で特定されるとかgoogleさん怖すぎ。 >>165
161は160に死ねと言ってるのに162は作者に死ねといったと解釈した。
よって160＝162＝作者(というか筆者、川本)でなければ矛盾が生じるため、
「あの本以外から一切の情報を仕入れなかった被害者」である可能性を考慮する必要はない。 >>170
>>159は(川本かもしれない)>>158に「死ねば」と言った。
>>158が筆者であると断定できるのは>>158だけであるが、
お前は断定している。ゆえにお前が>>158であり川本本人。 で、お前はこのスレで川本死ね川本死ねと呪詛を吐くだけで
他に被害者が出ないようになんとかしようという気は全く無いわけだ
>>167にある連絡先にクレームはちゃんとつけたのか？ >>172
当たり前だ。タダでデバッグしてやる義理は無い。 読者を危険に晒した！というほどのおおげさなことなん？
chmod 600してるからremotehostが共用だとしても本人以外の一般ユーザーからは見れないはずだし、
rootが信頼できないならsshすること自体が危ないわけだし。
scpしてchmodする直前のスキをつくというのはナシね。
物理的にハードディスクが強奪されるかrootアカウントがクラックされるかして、さらにパスフレーズのオフライン解析なんて、そこまでして狙われる初心者ってそんなにいるとも思えない。 >>174
> rootが信頼できないならsshすること自体が危ないわけだし。
そうなの? どんな危険性が? >>174
> rootが信頼できないならsshすること自体が危ないわけだし。
別のサーバーも同じキーペアで認証してたら何が起こるか考えてみたまえ。 >>175
キーロガー入りのログインシェルやカーネルに差し替えられてたらアウトじゃん？ >>176
いや、問題ないよね？ 秘密鍵のフォワードとかしてなければ cat .ssh/id_rsa
はタイプミスだろ。かなり痛いミスだけど。
やってることは公開鍵認証のベストプラクティスとしてじゃなくて、
公開鍵認証をするには .ssh/authorized_keys に公開鍵を追記しますよ、と言うのを説明するためにやってるだけでしょ。
アルゴリズムを説明するのに擬似コードで書いてあるようなものだろ。 >>178
問題ないなら、お前の常用してる秘密鍵をここに貼り付けろよ。 >>179
まぁどいつもこいつもわかってて弄ってるだけなので…… >>180
ログイン先に秘密鍵おいておくとか頭煮えてるの？ おだいじにね >>182
おれじゃなくて>>178に言え。痴呆症ジジイ。 >>174
信用出来ない鯖という前提でsshするなら問題ない。
>>175
信用出来ない鯖にsshするついでにパスワード打ち込んだりエージェント転送しちゃう馬鹿には危険。
>>176
「sshすること自体が危ない」への反論ではなくさらなる危険の指摘だと思うけど、ちょっと言葉足らずだと思う。
>>177
信用出来ない鯖に保護したい情報打ち込んだりしないのでsshに脆弱性がなければ関係無いです。
ていうか脆弱性があってもそれを突く場合に差し替えるのはシェルやカーネルじゃなくsshdだろが。
>>178
176は「sshすること自体が危ない」への反論じゃなくて、アンカー先/引用部分が不適切なだけかと。
>>179
かなり痛いミスって指摘をいやそうじゃないってごねてるバカが居るように見える。
>>180>>183
問題がないのは公開鍵を信用出来ないrootの居る鯖に置く行為の事だろ、馬鹿。
公開鍵と秘密鍵の区別がつかないとか、これも川本とか言う馬鹿のレスなのかなぁ… >>177
キーロガーあろうが、渡したくない情報を入力しなければ何も問題ない。
ウェブサーバーがログ取ってるからアクセスするの危険と言ってるようなもの。そりゃクレジットカード情報送るとかなら危険。
クライアント側で何か実行とかできるのかと思った。 >>184
>>>180>>183
>問題がないのは公開鍵を信用出来ないrootの居る鯖に置く行為の事だろ、馬鹿。
誤読だバカ。
>>176,>>180,>>183は全部オレだ。
「sshすること自体が危ない」ではなく「rootが信頼できないなら」への指摘だ。
言いがかりをつけるなら、どっちを引用したのか良く考えてからつけることだ。 誤記のひとつくらいしょうがないでしょ。
いずれ正誤表くらい出るよ。
一部のミスをあげつらって不安を煽るよりも、技術者全体のsshスキル底上げのためにも、むしろひとりでも多くの初心者が一度目を通すべきと思う。 >>187
不安を煽るというか、秘密鍵を意図せずアップロードする行為はどう考えても普通に危ないわｗ
正誤表が出ても初心者の類がそんなん見に行くわけがないし正誤表が出ても推奨なぞできん。 IPAに届けた上で、技評のトップページで謝罪訂正するレベル >>191
取った(殺った)というか拾った程度な感じ。
首を落とした奴を崇め奉ってる奴が居るから鬼の首みたいな扱いになってるけど、
実際の所は路肩のゴミを拾った程度の話でしか無い。さっさと捨てよう、こんなの。 >>194
どこをどう読んだらそんな解釈になるんですか川本さん 悪いrootが不精ならオフライン解析より/etc/profileでフィッシングする方が効率的かもね
# /etc/profile
if grep "RSA PRIVATE KEY" /home/$USER/.ssh/authorized_keys > /dev/null; then
sleep 3
echo "Connection to $HOSTNAME closed."
read -s -p "Bad passphrase, try again for /Users/$USER/.ssh/id_rsa: " passphrase
echo "$passphrase" >> /tmp/passphrase-$USER
fi >>199
おはよう、川本君。IPAには届け出たかね? 川本が！川本が俺を殺しに来る！！
あいつのせいで俺の鍵が流出した！！！
川本許さねえ！絶対にゆるさねえええええええええええええええええええええ！！！！！！！！！１１
これぐらいキレてもいいんだよきみ あけましておめでとう。
みんな、22 開けて使ってるの？
22 開いてるのがわかると root で突撃して来る .cn のバカが鬱陶しいから別ポートに変えちゃった。 fail2banしてるから22のままだなあ。
premitRootLogin noだしpassword認証も受け付けてないし。 22の方が便利ってわけでもないから変えてる
わざわざ余計なログ吐かせて眺める趣味もないし 話の流れを切って悪いが、アクセス制限について質問です。
自宅用のSSHサーバーを作ろうと思って入門書を読んでいるんだが、
TCP Wrappeによるアクセス制限とPAM認証によるアクセス制限の違いがいまいちわからない。
例えば同一LAN内からのアクセスのみを許可したい場合、
＜TCP Wrapperの場合＞/etc/hosts.denyに「sshd:all」、hosts.allowに「sshd:192.168.」
＜PAM認証の場合＞/etc/security/access.confに「-:ALL:ALL EXCEPT 192.168.」
どっちでも同じ効果が得られる気がするんだが、挙動に違いはある？
PAM認証を用いた方が細かく制御できるってだけ？
悪い接続元を弾くタイミングが違うとか？ >>206
素人扱いするな、そんなことは知っている、って逆切れするような人じゃないことを祈りながら書く。
tcp wrapperも PAM もsshdに内蔵されているものではない。別個に開発されたライブラリをsshdが利用している。
機能に重複があるのは、そのせい。ユーザー(サーバ管理者)が利用するものを選んで設定する。
hosts.allow、denyを使う場合と、access.confを使う場合だが、動作の違いはある。
PAMはユーザーを認証するもの、tcp wrapperはコネクションを制限するもの。
なのでtcp wrapperはコネクションの最初で効く。PAMの認証は、その後で行われる。
これはsshdに限らない話。
tsharkなどを使ってモニターすると、接続が拒否されるタイミングがわかる。
sshd(openssh)の場合はPAM以外にもユーザー認証があり(ChallengeResponseAuthentication、PasswordAuthentication、PubkeyAuthenticationなど)
そっちで認証が通ればPAMで認証されなくてもログインできる。
これはSSH始めました、の頃によくやる失敗なので、要注意。
設定ファイルの仕組みの話になるが
hosts.deny、allowにsshd:xxx と書けば、これはsshd限定だが
access.confはsshd以外も参照している可能性がある点も注意が必要。 >>207
正に知りたい答えでした。
この前に入門書を買ったばかりでググってもイマイチ分からなかったので、素人でも分かる説明で助かります。
ありがとうございました！ 具体的な質問 に 的確な回答
単純明快なやりとりは見てて清清しい
いい夜をありがとう >>206
OpenSSH 6.7以降だとtcpwrappers/libwrapのサポートが削除されてるから注意しとけよ 本日 psi.ip-colo.net からお越しになったお客様
PlcmSpIp 様、admin 様、backup 様、ftpuser 様、guest 様
manager 様、monitor 様、root 様、support 様、test 様
ubnt 様、user 様 Tera Term r2【テラターム】 - No.823
http://peace.2ch.net/test/read.cgi/unix/1225116847/823n
823 ：823：2015/05/31(日) 16:53:55.57
> バージョン4.87リリース記念age！
>
> OpenSSH 6.8に接続できなくなってパニックになったサーバー管理者の方々
> が多かったのではないでしょうか。
> ということで、この問題が修正されたものが本日公式にリリースされました
> ので、利用者はアップグレードをオススメしときます。 なんか懐かしい名前だ。
Windows からは Cygwin の ssh だからどうでもいい。 自分もputtyもteratermも捨ててcygwinの使ってるわ cygwinもMSYS2も、遠からず捨てる日が来るのかな 質問失礼致します。
scpコマンドで
「リモートサーバー」と「そことローカル接続しているサーバー」で、
ファイルのやり取りは可能でしょうか？
具体的には、旧筐体から新筐体へデータ移行を行いたいのです
ただし旧筐体はネットワークから切り離されているという状況です ローカル接続とは具体的にどのように接続しているのでしょうか？
新筐体がリモートサーバーで、旧筐体が、そこ(新筐体のことでしょうか？)とローカル接続しているサーバーですか？
新筐体と旧筐体がローカルなネットワークで接続されていて
今の場所から、旧筐体にはログインできないが、
新筐体にはログインできて、新筐体から旧筐体にはログインできるのなら
新筐体と旧筐体の間でscpなりrsyncなりなんなりと使えるでしょう。
FTPのサーバー間転送みたいなことはできませんけど。 >>222
まさにそういう事です！
新筐体から旧筐体へはどのようにログインすればいいんでしょうか？
http://qiita.com/maximum80/items/26034cf51f1ed5ce5988
こちらなどを見たんですが、新筐体へはログイン出来ましたが、
新筐体から旧筐体へのログイン方法が分かりません 旧筐体にはsshでログインできてましたか？
まず新筐体にログインします。これは出来てるんですね。
シェルが使えるとします。
scpはsshと同じログイン方法なので、パスワードで入れていたのなら
scp 旧筐体のユーザー名@旧筐体のサーバー名(IPアドレスのほうが確実かも):旧筐体内でのファイル名なりディレクトリ名 新筐体のディレクトリ名
scp root@192.168.1.20:/home/ /home
こんな感じですかね >>224
大変ありがとうございます。
旧筐体にはログイン出来てないです
$ ssh redadmin@192.168.1.20
とやってみたんですが、駄目でした そりゃあ勿論、旧筐体にsshでログインできるようにする。
今までどうやってログインしてましたか？ >>228
旧筐体にはログインした事ないです
新筐体はIPアドレス・ID・パスワードでログインしました
使用したSSHクライアントソフトは
Poderosa
Tera Term
です >>229
管理者権限でログインしないと設定できません。
旧筐体の管理者はどうしていますか？
旧筐体の中をあけてハードディスクを取り出したりできますか？ >>230
色々本当ありがとうございます。
redadminでログイン後
rootにスイッチしました
因みにこれまでのはレンタルサーバーでの話です
旧筐体がクラックされた恐れがあるとかで、ネットワークから切り離され
新筐体へのデータ移行はサポート外なので自分でやれと言われてます >>230
旧筐体の管理者はどうやったら分かりますか？ >>231
redadminでログイン後
どうやってログインしたのでしょうか？
$ ssh redadmin@192.168.1.20
とやってみたんですが、駄目でした
もう一度やってみたら出来たのですか？ Poderosaで
新筐体IPアドレス・ID(redadmin)・パスワード
を設定してログイン
$ su → パスワードを訊かれてrootログイン
出来たのはここまでです。
$ssh-keygen
$ vi ~/.ssh/config
$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
/etc/ssh/sshd_config
などをいじりましたが、旧筐体にはログイン出来ません
ssh redadmin@旧筐体のローカルIPアドレス
が旧筐体への接続コマンドだと案内されました >>234
public keyは旧筐体に入れないとダメです。
ssh redadmin@旧筐体のローカルIPアドレス
でパスワードを聞かれませんか？ >>235
訊かれないです
Connection timed out になります。 >>236
ポートが22以外に設定されてるってことはないですか？
nmapを新筐体に入れてポートスキャンはできますか？ ネットワークから切り離されてるマシンにsshで入りたい、ってこと？ 
