SSH その8
FAQ、リンク集は >>2-5 あたり。
■前スレ
SSH その7
http://toro.2ch.sc/test/read.cgi/unix/1266323017/
■過去スレ
その6 http://pc12.2ch.sc/test/read.cgi/unix/1202782840/
その5 http://pc11.2ch.sc/test/read.cgi/unix/1145484540/
その4 http://pc8.2ch.sc/test/read.cgi/unix/1102242908/
その3 http://pc5.2ch.sc/unix/kako/1058/10582/1058202104.html
その2 http://pc.2ch.sc/unix/kako/1028/10281/1028157825.html
その1 http://pc.2ch.sc/unix/kako/976/976497035.html
Q.公開鍵認証などは使用せず、パスワードによる認証を行う場合でも
そのパスワードは暗号化されているのですか？
A.はい、その通りです。
SSHプロトコルでは、まず始めにサーバ<->クライアント間で
暗号化された通信路を確立します。
ユーザ認証はその暗号化通信路の上で行なわれるので、
パスワードなどもちゃんと秘匿されています。
Q.最近、root,test,admin,guest,userなどのユーザ名で
ログインを試みる輩がいるのですが？
A.sshdにアタックするツールが出回っているようです。
各サイトのポリシーに従って、適切な制限をかけましょう。
参考：http://www.st.ryukoku.ac.jp/~kjm/security/ml-archive/connect24h/2004.08/msg00030.html
本家ssh.com
http://www.ssh.com/ / http://www.jp.ssh.com/ (日本語)
OpenSSH
http://www.openssh.com/ / http://www.openssh.com/ja/ (日本語)
OpenSSH情報：http://www.unixuser.org/~haruyama/security/openssh/
日本語マニュアル：http://www.unixuser.org/~euske/doc/openssh/jman/
OpenSSH-HOWTO：http://www.momonga-linux.org/docs/OpenSSH-HOWTO/ja/index.html
TeraTerm/TTSSH
http://hp.vector.co.jp/authors/VA002416/
http://www.sakurachan.org/soft/teraterm-j/ttssh/ (日本語版)
http://sleep.mat-yan.jp/~yutaka/windows/ / http://ttssh2.sourceforge.jp/ (Yutaka氏によるUTF-8対応版,SSH2対応版)
PuTTY
http://www.chiark.greenend.org.uk/~sgtatham/putty/
http://pc8.2ch.sc/test/read.cgi/unix/1084686527/
http://hp.vector.co.jp/authors/VA024651/ (hdk氏による日本語パッチ)
http://yebisuya.dip.jp/Software/PuTTY/ (蛭子屋氏による各種パッチ)
VeraTerm
http://www.routrek.co.jp/product/varaterm/
MacSSH/SFTP
http://pro.wanadoo.fr/chombier/
PortForwarder
http://www.fuji-climb.org/pf/JP/
TRAMP
http://www.nongnu.org/tramp/tramp_ja.html
・RFC4250: The Secure Shell (SSH) Protocol Assigned Numbers
・RFC4251: The Secure Shell (SSH) Protocol Architecture
・RFC4252: The Secure Shell (SSH) Authentication Protocol
・RFC4253: The Secure Shell (SSH) Transport Layer Protocol
・RFC4254: The Secure Shell (SSH) Connection Protocol
・RFC4255: Using DNS to Securely Publish Secure Shell (SSH)
Key Fingerprints
・RFC4256: Generic Message Exchange Authentication for the Secure
Shell Protocol (SSH)
WideのSSH解説
http://www.soi.wide.ad.jp/class/20000009/slides/12/
OpenSSH
http://www.openssh.com/ja/ (日本語) ← 無くなってる
http://www.jp.openbsd.org/openssh/ が日本語ページらしいが、実際は英語。
TeraTerm/TTSSH
http://sleep.mat-yan.jp/~yutaka/windows/ ← 無くなってる
/ http://ttssh2.sourceforge.jp/ (Yutaka氏によるUTF-8対応版,SSH2対応版)
PuTTY
http://pc8.2ch.sc/test/read.cgi/unix/1084686527/
→ 現行スレ Putty その３ 【パティ】http://toro.2ch.sc/test/read.cgi/unix/1302006799/
VeraTerm
→ Poderosaに名称変更 http://sourceforge.jp/projects/sfnet_poderosa/
MacSSH/SFTP
http://pro.wanadoo.fr/chombier/ ← 無くなってる？
PortForwarder
http://www.fuji-climb.org/pf/JP/
→ http://toh.fuji-climb.org/pf/JP/
TRAMP
http://www.nongnu.org/tramp/tramp_ja.html ← ページがない。
→ http://www.nongnu.org/tramp/
MacSSH はこれかな。
X より前の Mac OS 用っぽいから削除でもいいかと。
SFTPクライアント
WinSCP http://winscp.net/
WinSCP 日本語情報 http://sourceforge.jp/projects/winscp/
FileZilla https://filezilla-project.org/
FileZilla 日本語情報 http://sourceforge.jp/projects/filezilla/
Android
connectbot https://code.google.com/p/connectbot/
他にもいいのがある？
iPadについてはお手上げ。
が入ってねーな。SFTPも使えたり結構高性能。
難点は名前がクッソ紛らわしいのと、フォント周りが使いにくい事。
http://www.slideshare.net/tohakushi/ssh-13118950
これも入れといて。
10ページにウソが書いてある。しれっとウソが書いてあると
その先読む気にならないよね。でも頑張って次ページに進む
と「公開鍵で制限出来る事」… ダメだこりゃ
どれがウソ？
秘密鍵（を格納したファイルid_rsa）
公開鍵（を格納したファイルauthorized_keys）
だろ。
スライドなんだから文脈からわかることは聴衆が補完くらいしろや。
秘密鍵で暗号化したものを秘密鍵で復号できないわけなくね
そんなこと書いてある?
できないであってると思うけどな。
ssh2の公開鍵認証は暗号化→復号ではなくデジタル署名→検証
RSAは署名/検証, 暗号化/復号のどちらにも利用できるが、
DSAは署名/検証は出来るが、暗号化/復号は出来ない
筆者はssh2の認証方式を理解していないと判断せざるを得ない
11ページ
誤 公開鍵で出来る事
正 公開鍵認証で出来る事
その先は読む気にならない
は？秘密鍵から公開鍵が得られないとでも？
そもそも秘密鍵で暗号化するっていうのがおかしいんだが。
> は？秘密鍵から公開鍵が得られないとでも？
得られない。中学生でも理解してる。
ssh-keygen -y [-f input_keyfile]
-y This option will read a private OpenSSH format file and print an
OpenSSH public key to stdout.
秘密鍵から公開鍵を得る事は出来ない
書いた奴に聞けよ
そういう文脈だとわかってるやつが
> ssh2の公開鍵認証は暗号化→復号ではなくデジタル署名→検証
> RSAは署名/検証, 暗号化/復号のどちらにも利用できるが、
> DSAは署名/検証は出来るが、暗号化/復号は出来ない
みたいなずれた話を持ち出してくる意図の方がわからん。
> ssh2の公開鍵認証は暗号化→復号ではなくデジタル署名→検証
同じ人の新しいスライドがあるけど、こっちは端折りすぎかな。
http://svnweb.freebsd.org/base/head/crypto/openssh/
>>22
>>14
暗号化に使った鍵で平文化は出来ないよ。そうでないと公開鍵暗号が成立しない。
公開鍵暗号は暗号化鍵を公開鍵として、平文化鍵を秘密鍵とする。
電子署名では暗号化鍵を秘密鍵として、平文化鍵を公開鍵とする。
暗号化鍵から平文化鍵が計算できるアルゴリズムは電子署名にしか使えず、
平文化鍵から暗号化鍵が計算できるアルゴリズムは公開鍵暗号にしか使えず、
どちらの鍵からももう一方の鍵を計算出来ないアルゴリズムはどちらにも使える。
さらに暗号化鍵と平文化鍵を入れ替える事ができる場合は単一の鍵ペアで両方できる。
秘密鍵ファイルの中に公開鍵も一緒に保存してあるか、秘密鍵から公開鍵が算出できるなら平文化できるけど、
電子署名でどちらも満たさない場合は復元できないよ。(普通は署名書として公開鍵添付するからンな事ないが)
ルークよ、ソースを使うのじゃ？
>>23
「公開鍵暗号を暗号化/復号に使うと思い込んでたのはスライド書いた奴だから」
スライドのどこで、それが分かる？
p10 は「秘密鍵/公開鍵」という用語を鍵ペア(データ)のどちらか一方という意味と
それをファイル(文字列)化したものという意味の二つの使い方を同じページで
使ってるのがまずいと思う。
2行目の「秘密鍵からは公開鍵が生成できる」は「いわゆる秘密鍵ファイルには
公開鍵情報も含まれているので、公開鍵情報を取り出せる」という意味だろう。
好意的に解釈すれば。
このスライドを書いた奴は分かってないはず、という見地に立てば、秘密鍵ファイルから
公開鍵を取り出せることを、秘密鍵から公開鍵が生成できると勘違いしているともとれるが。
p11の「公開鍵で制限出来ること」というタイトルに対して「公開鍵認証で出来る事」という案を出しているけど
このページの話題は openssh の sshd の実装の話(他のsshサーバーでもこうなのかどうかは知らないので
間違ってたらごめんだけど)だから、誤りというほどではないと思う。
初心者には勧められない、ということになると思う
ちゃんと自分で解釈を脳内補完できる人には
多少の「誤解を招きかねない」表現も問題ないだろうが
件のドキュメントはそれができない人向けなんじゃ?
初心者にわかりづらくなることもあるよね
> p10 は「秘密鍵/公開鍵」という用語を鍵ペア(データ)のどちらか一方という意味と
> それをファイル(文字列)化したものという意味の二つの使い方を同じページで
> 使ってるのがまずいと思う。
秘密鍵を格納したファイルから公開鍵を取り出す事を「秘密鍵からは公開鍵が
生成できる」と表現したのなら、公開の場で発表する能力が無いって事だ。
もくじを見ると件のページは、おさらいの一部になっている。
ということは自分で脳内補完できる人向けじゃないだろうか。
ウソを拡大再生産する輩を全部憎んでいる
Rばいいのに
人は許しましょう。
>>25
じゃ、お前が教えてやれ。俺は叩く。
おれは君ほど知識ないから。
ここで叩いても気づかないんじゃないかな?
個人的には叩くほどのことじゃない気はする
それがイヤだから2chにいるの
id_rsaにmodules nとpublicExponent eが含まれてるから。
RFC 3447 PKCS #1: RSA Cryptography Specifications February 2003
A.1.2 RSA private key syntax
An RSA private key should be represented with the ASN.1 type
RSAPrivateKey:
RSAPrivateKey ::= SEQUENCE {
version Version,
modulus INTEGER, -- n
publicExponent INTEGER, -- e
privateExponent INTEGER, -- d
prime1 INTEGER, -- p
prime2 INTEGER, -- q
exponent1 INTEGER, -- d mod (p-1)
exponent2 INTEGER, -- d mod (q-1)
coefficient INTEGER, -- (inverse of q) mod p
otherPrimeInfos OtherPrimeInfos OPTIONAL
}
sshに限らず、ツールの100％も使いこなせていないなー
そのディレクトリに、
All components of the pathname must be root-owned directories that are not writable by any other user or group.
こういう制限があるけど、ナンデ？
rootの設定と関係なしにlnとかで好きな場所に出来てしまうからじゃ?
例えば、chroot先を/home/oresama/ に指定するとき oresama がroot以外not writableになってると
oresamaは自分のホームディレクトリのはずなのにディレクトリもファイルも作れない。
ちょっと厳しくないかと思う。
「あのぉ、root先輩、ChrootDirectoryを /home/watashi/dakeno/himitsu/ にしてもらえませんかぁ。」って頼んで
「おっふ、やっといた」となったら
rmdir /home/watashi/dakeno/himitsu
ln -s /root /home/watashi/dakeno/himitsu
「計画通〜り」ってことだよね。
このためには/home/watashi/dakeno がwritableでなければ出来ないでしょ。
himitsu は writableでもかまわないんじゃないだろうか。
Chrootにつっこまれる他のユーザを騙すことはできるようになるな
/etc/shadowとか自由に作れるがそれでいいのか?
いくない。それは、いくないな。
あんま詳しくないけど、chroot先とホームディレクトリは別々じゃなかったけ？
http://beta.slashdot.org/story/201419
試してみたい
何か使えない理由ある？
暗号化通信は当局が解読可能な状態にしないと駄目なんだっけ？
VPN張る事自体問題視されるとか聞いたことあるけど
どなたかRSA1、RSA、DSAの違いにつ
いて教えて頂けませんか？
メリット、デメリットがわからず、どれを使って良いのかわかりません。
自分で調べろやは無しでお願いします。
shでも学んでろ。
532 名無しさん＠お腹いっぱい。 sage 2014/09/14(日) 17:11:01.54
今シェルについて勉強してます。
どなたかash、bsh、cshの違いにつ
いて教えて頂けませんか？
メリット、デメリットがわからず、どれを使って良いのかわかりません。
自分で調べろやは無しでお願いします。
なに(笑
このコピペみたいなカキコは！(笑)
お、俺じゃないんだからね
こんなつまらんことを時々思い出したかのように繰り返してる狂人だからスルー推奨
したら、知らないホストでESTABLISHED接続になってて
# cat /var/log/secure| grep 知らないホスト(ロボット？)
から複数のアタックがあったのだけど、session openってログ無かったんですが、
ssh のセッションがESTABLISHEDになることってあるのでしょうか？
あります
tcpのセッションとsshのセッションを分けて考えないと。
ありがとうございます。
/var/log/secureでsession openになってないので気にしなくていいのですね。
ポートNo変えようかなーと思ってます。
マスコミじゃないんだからクラッキングとか攻撃とか呼ぼうぜ。
回答：sshd自体に脆弱性があれば普通に吹っ飛ばされるよ。
http://jvndb.jvn.jp/ja/contents/2008/JVNDB-2008-002571.html
http://jvndb.jvn.jp/ja/contents/2008/JVNDB-2008-002570.html
http://jvndb.jvn.jp/ja/contents/2006/JVNDB-2006-000763.html
http://jvndb.jvn.jp/ja/contents/2003/JVNDB-2003-000274.html
パスワード認証許可してないかノックしてるんだろ。
秘密鍵も送ってくるユーザーの多いこと多いこと。
http://freetibet.org/about/human-rights-tibet
の中身を返すようにしてる
coolですな。
なんでサポート切っちゃうんでしょうか
ftp 覗いてみたら tcp_wrappers_7.6.tar.gz のタイムスタンプは Apr 8 1997 だった
とりあえずはpf.confでやるけど
pam_accessとかpam_login_accessとか。
http://marc.info/?t=139815213700004
http://marc.info/?t=139827570900003
manとか見るとクライアントのIPから逆引きでホスト名を確認して
IPアドレスとホスト名のマッピングが出来なかったら接続を許可しないって動きの
ようにみえるんだけど…
この辺の詳しい動きがよくわからん
100〜のスレッドの続きを読む