问个SSH, public key 登陆的问题。

zhuao

标题: 问个SSH, public key 登陆的问题。

两台机器都是fedora 5的；
用ssh-keygen生成key, 把public key放到作为服务器的fedora上。
然后ssh登录，但总是会走到密码验证上去；还是不能实现用public/private key自动登陆，郁闷。
下面是debug的信息，请各位帮着看一下。谢谢

[aihua@localhost .ssh]$ ssh -v -v -i ~/.ssh/id_dsa aihua@10.239.12.121
OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 10.239.12.121 [10.239.12.121] port 22.
debug1: Connection established.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/aihua/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 130/256
debug2: bits set: 505/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '10.239.12.121' is known and matches the RSA host key.
debug1: Found key in /home/aihua/.ssh/known_hosts:1
debug2: bits set: 492/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/aihua/.ssh/id_dsa (0x85c7478)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Miscellaneous failure
No credentials cache found

debug1: Miscellaneous failure
No credentials cache found

debug2: we did not send a packet, disable method
debug1: Next authentication method: publickey
debug1: Offering public key: /home/aihua/.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
aihua@10.239.12.121's password:
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 0
debug1: Sending environment.
debug1: Sending env LANG = zh_CN.UTF-8
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
Last login: Mon Nov 20 09:42:23 2006 from 10.239.35.205
[aihua@jzhux ~]$
          zhuao 当前在线

fush_linux

SSH 协议简介

概念. SSH是指Secure Shell，SSH协议族由IETF（Internet Engineering Task Force） 的Network Working Group制定，SSH协议的内容SSH协议是建立在应用层和传输层基础上的安全协议。 传统的网络服务程序，


SSH的安全验证

从客户端来看，SSH提供两种级别的安全验证。
　　　　
　　第一种级别（基于口令的安全验证），只要你知道自己的帐号和口令，就可以登录到远程主机，并且所有传输的数据都会被加密。但是，这种验证方式不能保证你正在连接的服务器就是你想连接的服务器。
　　　　
　　第二种级别（基于密匙的安全验证），需要依靠密匙，也就是你必须为自己创建一对密匙，并把公有密匙放在需要访问的服务器上。如果你要连接到SSH服务器上，客户端软件就会向服务器发出请求，请求用你的密匙进行安全验证。服务器收到请求之后，先在你在该服务器的用户根目录下寻找你的公有密匙，然后把它和你发送过来的公有密匙进行比较。如果两个密匙一致，服务器就用公有密匙加密"质询"（challenge）并把它发送给客户端软件。客户端软件收到"质询"之后就可以用你的私人密匙解密再把它发送给服务器。
　　与第一种级别相比，第二种级别不需要在网络上传送用户口令。另外，第二种级别不仅加密所有传送的数据，而"中间人"这种攻击方式也是不可能的（因为他没有你的私人密匙）。但是整个登录的过程可能慢一些。

SSH密钥通道的建立方法


有些时候，我们在复制/移动文件到另一台机器时会用到scp，因为它比较安全。但如果每次都要输入密码，就比较烦了，尤其是在script里。不过，ssh有另一种用密钥对来验证的方式。下面写出我生成密匙对的过程，供大家参考。

    第一步：生成密匙对，我用的是rsa的密钥。使用命令 "ssh-keygen -t rsa"

   [user1@rh user1]$ ssh-keygen -t rsa
   Generating public/private rsa key pair.
   Enter file in which to save the key (/home/user1/.ssh/id_rsa):
   Created directory '/home/user1/.ssh'.
   Enter passphrase (empty for no passphrase):
   Enter same passphrase again:
   Your identification has been saved in /home/user1/.ssh/id_rsa.
   Your public key has been saved in /home/user1/.ssh/id_rsa.pub.
   The key fingerprint is:
   e0:f0:3b:d3:0a:3d:da:42:01:6a:61:2f:6c:a0:c6:e7 user1@rh.test.com
   [user1@rh user1]$

     生成的过程中提示输入密钥对保存位置，直接回车，接受默认值就行了。
     其中公共密钥保存在 ~/.ssh/id_rsa.pub
         私有密钥保存在 ~/.ssh/id_rsa

     生成密钥之后把这个密钥对中的公共密钥复制到你要访问的机器上去，并保存为  
   scp id_ras.pub remote@rh:/home/rh/.ssh/authorized_keys        

     登陆访问的机器修改用户 .ssh 目录的权限，使用命令 "chmod 755 ~/.ssh"
     
      chmod 755 ~/.ssh
修改之后，你再用ssh scp sftp 之类的访问那台机器时，就不用输入密码了，用在script上更是方便。

这种方法的好处在于：ssh访问目标机器的用户修改密码后，不会产生任何影响。

zhuao

chmod 755 .ssh  (on server)

神呀，居然是这个原因。

前两天还有那个corkscrew 的 chmod 600

这个不能多不能少的访问权限真是害死人了.faint.

刚才重新验证了一把,还有那个authorized_keys的chmod权限应该为640.


谢谢二楼.

zhuao

现在回过头,使用代理去连接外部的服务器。还是连不上；并比较了连接内部成功和连接外部失败的log文件：