部署 诡异的 SSH 登录!

lb563 · April 18, 2012 · Last by lzm110 replied at October 15, 2012 · 10462 hits

今天用 ssh 测试本机如下:

1: ssh [email protected] #要求我输入密码

2: cd ~/.ssh && cat id_rsa.pub >> authorized_keys

3: cat authorized_keys #发现我的 key 已经成功加到里面

4: 新打开一个窗口:ssh [email protected] #他要我输入密码

到这里我不疑惑了, 以前我就这样操作后重新登录他不要求我输入密码,但是现在为什么不行了呢?

authorized_keys 是远程的文件,不是你本地的

一个常犯的错误是文件权限不对。$HOME只能自己可写 (0755 或者 0750), .ssh设置成 0700,authorized_keysid_rsa.pub 0644, id_rsa 0600

#1 楼 @linjunpop 我就是把我自己的机器当成远程服务器来测试的!

#2 楼 @doitian 设置 ok,但是还不能登录,会不会我的 ssh 某些服务没有起来呢?

#4 楼 @lb563 你试试 ssh -vvv

#5 楼 @doitian 部分片段: debug2: we sent a keyboard-interactive packet, wait for reply debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 1 Password:

/$HOME 的整个路径上的所有目录也应该是只能 owner 可写

#7 楼 @doitian 如下结果: $ ll ~ drwxr-xr-x+ 36 mile001 staff 1.2K 4 16 21:07 ./ drwxr-xr-x 5 root admin 170B 4 12 13:16 ../

尽量使用ssh-copy-id命令。

现阶段不能保证你的 key 是不是写对了。

你的操作应该没啥问题。

确认你的 id_rsa(私匙) 和 id_rsa.pub(公匙) 是匹配的。

建议你删除这两个文件,重新生成一次。

#10 楼 @zw963 这个怎么查看?我看不出来是否匹配。

我也遇到这个问题,纳闷了好多天了。看楼上的回复,觉得是$HOME 目录的权限问题,因为公司测试服务器上的 $HOME 权限都有问题,经常有警告出现。明天去试试

#11 楼 @lb563

哈~ 我当然不知道如何查看了。所以让你删除重新建立呗。

你没有说你的 linux 版本情况。有的老版本的 ssh,用的是authorized_keys2

#14 楼 @bwlinux mac osx 10.6.* 用的就是 authorized_keys

看下 sshd_config 里定义的是哪个文件,还有检查 authorized_keys 文件权限,如 2 楼所说

按照 #1 楼 @linjunpop 的方法,修改目录和文件权限,我这边的问题解决。非常感谢。

不知道楼主有没有 ok?

自己配这个太容易出错,用 ssh-copy-id 命令

@suupic 用 ssh-copy-id 还挺方便的

#19 楼 @suupic 看了一下这个命令还是比较方便,但是在 mac osx 下还没有这个工具,那就需要自制一个脚本了,我参考了:http://www.devthought.com/2009/09/19/get-ssh-copy-id-in-mac-os-x/ 但是这个方法还是没有解决我的问题。我想我还是重新生成一个 key 算了!

对了,你生成 keys,有没有用密码?如果用了,最后的登录的时候,需要你的 key 的密码。

#22 楼 @bwlinux 这个还真没有。我把自己的公钥放到其它机器上然后登录就不会要求我输入密码! 但是我登录自己的机器就会要求我输入密码!

本机创建公钥

ssh-keygen -t rsa  #一路回车


~/.ssh/id_rsa.pub 复制到服务器下的~/.ssh/authorized_keys
如果没有authorized_keys这个文件就创建一个。

在本机中~/.ssh/id_rsa 很重要,如果不是刚才生成的公钥是没用的。 id_rsaid_rsa.pub 文件名最好不要改

#24 楼 @Ddl1st 这个都是新生成的,如果 id_rsa 和 id_ras.pub 不匹配的话,我放到其它服务器上的公钥应该也不管用,但是实际情况是我放到其它机器上然后登录就不要我输入密码!

#25 楼 @lb563 你确定是当前用户根目录的.ssh 文件下?

#26 楼 @Ddl1st 是的我确定。我一直疑惑,

#18 楼 @linjunpop 当时一鸡冻,看错鸟~

有这么几个问题。1. 远程.ssh 目录权限 2. cp authorized_keys authorized_keys2 3.检查 sshd_config 搜索 strict 那个选项,yes 的话改成 no 重启 sshd

把 ssh -vvv 全贴出来吧

#30 楼 @doitian
好吧我结贴出来看看:

```$ ssh -vvv [email protected] OpenSSH_5.2p1, OpenSSL 0.9.8l 5 Nov 2009 debug1: Reading configuration data /etc/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.1.124 [192.168.1.124] port 22. debug1: Connection established. debug3: Not a RSA1 key file /Users/mile001/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /Users/mile001/.ssh/id_rsa type 1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2 debug1: match: OpenSSH_5.2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.2 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,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-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected] debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected] debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,[email protected],zlib debug2: kex_parse_kexinit: none,[email protected],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-sha256,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-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected] debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected] debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,[email protected] debug2: kex_parse_kexinit: none,[email protected] debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr 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: 133/256 debug2: bits set: 511/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /Users/mile001/.ssh/known_hosts debug3: check_host_in_hostfile: match line 5 debug1: Host '192.168.1.124' is known and matches the RSA host key. debug1: Found key in /Users/mile001/.ssh/known_hosts:5 debug2: bits set: 489/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: /Users/mile001/.ssh/id_rsa (0x1001257a0) debug1: Authentications that can continue: password,keyboard-interactive debug3: start over, passed a different list password,keyboard-interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 1 Password:

#31 楼 @lb563 像是 sshd 禁掉了 pubkey auth, 检查下 /etc/sshd_config

#32 楼 @doitian 此处配置:

#Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress ::

Disable legacy (protocol version 1) support in the server for new

installations. In future the default will change to require explicit

activation of protocol 1

Protocol 2

HostKey for protocol version 1

#HostKey /etc/ssh_host_key

HostKeys for protocol version 2

#HostKey /etc/ssh_host_rsa_key #HostKey /etc/ssh_host_dsa_key

Lifetime and size of ephemeral version 1 server key

#KeyRegenerationInterval 1h #ServerKeyBits 1024

Logging

obsoletes QuietMode and FascistLogging

SyslogFacility AUTHPRIV #LogLevel INFO

Authentication:

#LoginGraceTime 2m PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10

#RSAAuthentication yes PubkeyAuthentication no #AuthorizedKeysFile .ssh/authorized_keys

For this to work you will also need host keys in /etc/ssh_known_hosts

#RhostsRSAAuthentication no

similar for protocol version 2

#HostbasedAuthentication no

Change to yes if you don't trust ~/.ssh/known_hosts for

RhostsRSAAuthentication and HostbasedAuthentication

#IgnoreUserKnownHosts no

Don't read the user's ~/.rhosts and ~/.shosts files

#IgnoreRhosts yes

To disable tunneled clear text passwords, change to no here! Also,

remember to set the UsePAM setting to 'no'.

PasswordAuthentication yes #PermitEmptyPasswords no

SACL options

The default for the SACLSupport option is now "no", as this option has been

depreciated in favor of SACL enforcement in the PAM configuration (/etc/pam.d/sshd).

#SACLSupport no

Change to no to disable s/key passwords

#ChallengeResponseAuthentication yes

Kerberos options

#KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes

GSSAPI options

#GSSAPIAuthentication no #GSSAPICleanupCredentials yes #GSSAPIStrictAcceptorCheck yes #GSSAPIKeyExchange no

Set this to 'yes' to enable PAM authentication, account processing,

and session processing. If this is enabled, PAM authentication will

be allowed through the ChallengeResponseAuthentication and

PasswordAuthentication. Depending on your PAM configuration,

PAM authentication via ChallengeResponseAuthentication may bypass

the setting of "PermitRootLogin without-password".

If you just want the PAM account and session checks to run without

PAM authentication, then enable this but set PasswordAuthentication

and ChallengeResponseAuthentication to 'no'.

Also, PAM will deny null passwords by default. If you need to allow

null passwords, add the " nullok" option to the end of the

securityserver.so line in /etc/pam.d/sshd.

#UsePAM yes

#AllowAgentForwarding yes #AllowTcpForwarding yes #GatewayPorts no #X11Forwarding no #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #UseLogin no #UsePrivilegeSeparation yes

PermitUserEnvironment yes

#Compression delayed #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS yes #PidFile /var/run/sshd.pid #MaxStartups 10 #PermitTunnel no #ChrootDirectory none

#Banner none

override default of no subsystems

Subsystem sftp /usr/libexec/sftp-server

Example of overriding settings on a per-user basis

#Match User anoncvs

X11Forwarding no

AllowTcpForwarding no

ForceCommand cvs server

同时我把设置: #RSAAuthentication yes PubkeyAuthentication no #AuthorizedKeysFile .ssh/authorized_keys

修改为: #RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys

并且执行命令: sudo /usr/sbin/sshd ssh [email protected] #失败

PubkeyAuthentication no -> yes StrictModes yes -> no service sshd restart 或者 /etc/init.d/ssh restart 或者 /etc/rc.d/sshd restart

#33 楼 @lb563 按楼上的修改一下然后到 System Preference -> Sharing 里把 remote login 重启一下

#35 楼 @doitian "remote login" 早就勾上了. 我按照了@wang0109 的方法设置了一下,现在能登录成功而且不要密码。

查了一下:(参考于:http://matt-u.iteye.com/blog/851158) PasswordAuthentication no # 禁止密码认证 (改为 no,默认为 yes 是用密码认证) StrictModes no #修改为 no,默认为 yes.如果不修改用 key 登陆是出现 server refused our key(如果 StrictModes 为 yes 必需保证存放公钥的文件夹的拥有与登陆用户名是相同的.“StrictModes”设置 ssh 在接收登录请求之前是否检查用户家目录和 rhosts 文件的权限和所有权。这通常是必要的,因为新手经常会把自己的目录和文件设成任何人都有写权限。)

#36 楼 @lb563 重启就是取消再勾上

楼主好 我也出现这个问题 按照上述的方法 可以无密码登陆 但是还是会出现 debug3: key_read: missing keytype debug3: key_read: missing whitespace 这样的错误,而且随着多次的登陆后,会需要输入密码。这个问题怎么解决啊?

You need to Sign in before reply, if you don't have an account, please Sign up first.