CentOS scp 没有密码无法工作

发布于 2024-10-21 06:15:08 字数 2774 浏览 7 评论 0原文

我一直在尝试使用 ssh 公钥从一个 EC2 实例 连接到另一个实例,但经历了一段非常艰难的时期。

这是场景: 我需要在脚本中让框 2 scp 框 1 中的文件。该脚本需要能够在没有密码的情况下进行 scp,因此我需要设置公钥。

在框 2 上,我运行了 ssh-keygen –t rsa 并生成了 id_rsa 和 id_rsa.pub 我将 id_rsa.pub 复制到框 1 我将 id_rsa.pub 移动到 .ssh 并运行 cat id_rsa.pug >>>授权密钥 我将两个机器上所有 .ssh 目录的权限更改为 700,并将文件本身更改为 600。 我已将 box 1 上的 sshd_config 设置更改为:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

然后重新启动 ssh

/sbin/service sshd restart

当我尝试从 box1 进行 scp 或 ssh 进入 box1 时,出现错误:

Address 67.22.33.1 maps to ec2-67-22-33-1.compute-1.amazonaws.com, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
tomcat@tomcat1.****.com's password:

有什么想法吗?


我进行了更改并尝试 scp to tomcat1 但失败了。这是输出:

debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to tomcat1.****.com [67.22.33.15] port 22.
debug1: Connection established.
debug1: identity file /home/tomcat/.ssh/identity type -1
debug1: identity file /home/tomcat/.ssh/id_rsa type 1
debug1: identity file /home/tomcat/.ssh/id_dsa type -1
debug1: loaded 3 keys
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
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
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
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
The authenticity of host 'tomcat1.****.com (67.22.33.15)' can't be established.
RSA key fingerprint is 5a:3e:fe:be:b8:0e:05:63:bf:ab:c8:4f:e5:91:db:a0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'tomcat1.****.com,67.22.33.15' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/tomcat/.ssh/identity
debug1: Offering public key: /home/tomcat/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/tomcat/.ssh/id_dsa
debug1: Next authentication method: password

I have been trying to connect from one EC2 instance to another using ssh public keys and have been having a very tough time.

Here is the scenario:
I need to have box 2 scp a file from box 1 in a script. This script will need to be able to scp without a password so I need to setup public keys.

On box 2 I ran ssh-keygen –t rsa and generated id_rsa and id_rsa.pub
I copied id_rsa.pub to box 1
I moved id_rsa.pub to .ssh and ran cat id_rsa.pug >> authorized_keys
I changed permissions of all .ssh directory to 700 on both boxes and the files themselves to 600.
I have changed the sshd_config settings on box 1 to:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

And then restarted ssh

/sbin/service sshd restart

When I try to scp or ssh into box1 from box1 I get the error:

Address 67.22.33.1 maps to ec2-67-22-33-1.compute-1.amazonaws.com, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
tomcat@tomcat1.****.com's password:

Any ideas?


I made that change and tried scp to tomcat1 and it failed. Here is the output:

debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to tomcat1.****.com [67.22.33.15] port 22.
debug1: Connection established.
debug1: identity file /home/tomcat/.ssh/identity type -1
debug1: identity file /home/tomcat/.ssh/id_rsa type 1
debug1: identity file /home/tomcat/.ssh/id_dsa type -1
debug1: loaded 3 keys
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
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
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
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
The authenticity of host 'tomcat1.****.com (67.22.33.15)' can't be established.
RSA key fingerprint is 5a:3e:fe:be:b8:0e:05:63:bf:ab:c8:4f:e5:91:db:a0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'tomcat1.****.com,67.22.33.15' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/tomcat/.ssh/identity
debug1: Offering public key: /home/tomcat/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/tomcat/.ssh/id_dsa
debug1: Next authentication method: password

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

Hello爱情风 2024-10-28 06:15:08

您的授权密钥行应该是

AuthorizedKeysFile     %h/.ssh/authorized_keys

服务器正在错误的目录中查找您的服务器。

Your authorized keys line should be

AuthorizedKeysFile     %h/.ssh/authorized_keys

The server is looking in the wrong directory for your server.

柳絮泡泡 2024-10-28 06:15:08

更新 - 已修复

restorecon -R -v -d /root/.ssh

这是 RH 的一个已知问题,其中目录被错误标记,并且 PAM 在作为 init 脚本运行时阻止 sshd 读取授权主机。如果您偶然发现 /var/log/audit/audit.log,您将会看到错误。看起来很少见,但一旦发生就会很痛苦!

更多详细信息请访问 https://bugzilla.redhat.com/show_bug.cgi?id=499343< /a>

原始帖子

我刚刚遇到了看起来正是这个问题。我有一个调整不佳的 VirtualBox(我没有告诉 vbox 使用 64 位)——当我克隆并重新启动(在 vbox RedHat 64 位模式下)时,它开始要求我输入密码。

原始图像很好——具有相同的设置——所以我认为与网络相关的建议可能是相关的,或者与服务器密钥有关。

然而奇怪的是,如果在盒子上,我杀死自动启动的 sshd 进程,然后以 root 身份手动运行 /usr/sbin/sshd,我可以无密码登录。 一个愚蠢的解决方法,但可用。

所以这是一个 /etc/init.d/sshd 问题。但我无法追踪它是什么......尝试删除该脚本中的大部分内容,但在作为 /etc/init.d/sshd start 调用时它仍然提示输入密码/etc/init.d/sshd start 但在 /usr/sbin/sshd 时则不然。

也许这些评论可以提供帮助,然后有人可以提供进一步的帮助!?

UPDATE - FIXED IT

restorecon -R -v -d /root/.ssh

This is a known issue with RH where directories get mislabelled and PAM prevends sshd from reading authorized_hosts when run as init script. You'll see the errors if you stumble across /var/log/audit/audit.log. Rare it seems but painful when it happens!

More details at https://bugzilla.redhat.com/show_bug.cgi?id=499343

ORIGINAL POST

I've just hit what looks like exactly this problem. I had a poorly tuned VirtualBox (I hadn't told vbox to use 64bit) -- which when I cloned and restarted (in vbox RedHat 64-bit mode), started asking me for a password.

The original image was fine -- with identical settings -- so I think the suggestion of being networking-related might be relevant, or else to do with server keys.

The weird thing however is that if on the box, I kill the sshd process which autostarted, then manually run /usr/sbin/sshd as root, I can log in passwordless fine. A silly workaround, but usable.

So it is an /etc/init.d/sshd issue. But I haven't been able to track down what it is ... have tried chucking out most of the stuff in that script but it still prompts for password when invoked as /etc/init.d/sshd start but not when at /usr/sbin/sshd.

Maybe these comments can help, and someone can then help further!?

天涯沦落人 2024-10-28 06:15:08

尝试从 ~/.ssh/known_hosts 中删除 box1 IP,以便它更新。也许 ssh 由于可能的“中间人”攻击而禁用了密钥身份验证。

如果没有帮助,请添加行
<代码>
GSSAPI 身份验证 否

在 /etc/ssh/ssh_config 文件中。

Try removing box1 IP from ~/.ssh/known_hosts, so it renews. Perhaps ssh disables key authentication due to possible 'man in the middle' attack.

If it won't help, add line

GSSAPIAuthentication no

in your /etc/ssh/ssh_config file.

手心的温暖 2024-10-28 06:15:08

我认为这个链接可以解决您的问题,我用它来解决我的 ssh 无法登录问题。关键是跑
ssh root@node02 'restorecon -R -v /root/.ssh'
此命令将修复 SE
http:// blog.firedaemon.com/2011/07/27/passwordless-root-ssh-public-key-authentication-on-centos-6/

I think this link will solve your problem and I use it to solve my ssh not login problem. The keypoint is to run
ssh root@node02 'restorecon -R -v /root/.ssh'
this command will fix SE
http://blog.firedaemon.com/2011/07/27/passwordless-root-ssh-public-key-authentication-on-centos-6/

栀梦 2024-10-28 06:15:08

按照前面的步骤操作后,我必须在 .ssh 文件夹中将权限设置为“..”:

一旦我有 ~/.ssh:

drwx-------- 2 build build 4096 Nov 4 14:35 。

drwx------ 6 build build 4096 11 月 4 日 14:34 ..

-rw-------- 1 build build 400 11 月 4 日 14:35authorized_keys

它有效!

谢谢。达米安

After following previous steps I had to set the permission to ".." in the .ssh folder:

Once I had for ~/.ssh:

drwx------ 2 build build 4096 Nov 4 14:35 .

drwx------ 6 build build 4096 Nov 4 14:34 ..

-rw------- 1 build build 400 Nov 4 14:35 authorized_keys

It worked!

Thanks. Damian

碍人泪离人颜 2024-10-28 06:15:08

我遇到了完全相同的问题,整个下午都在挠头。
事实证明这是一个 sshd_config 文件的小问题。

首先,将远程主机的 .ssh 文件夹的访问模式更改为仅用户访问。

chmod 700 ~/.ssh

接下来,转到 /etc/ssh/sshd_config,将 StrictModes yes 更改为 StrictModes no。如果它被注释掉,则专门将 StrictModes no 添加到文件中。

这解决了问题。

I had the exact same problem and have been scratching my head for an entire afternoon.
It turned out to be a small sshd_config file issue.

first, change access mod on .ssh folder of the remote host to user access only.

chmod 700 ~/.ssh

next, go to /etc/ssh/sshd_config, change StrictModes yes to StrictModes no. If it's commented out, then specifically add StrictModes no into the file.

That solved the issue.

献世佛 2024-10-28 06:15:08

我刚刚发现的另一件事是,我必须编辑 .ssh/authorized_keys 文件并使主机名完全合格。否则,我无法在 scp/ssh 命令中使用完全限定名称。现在两者都完全合格(例如“host.company.com”)和假设两个主机都位于“company.com”域中,则相对名称(“主机”)有效。 ssh-keygen 仅使用主机名创建了公钥文件。

And one more thing I just found, I had to edit the .ssh/authorized_keys file to and make hostname fully qualified. Otherwise, I couldn't use the fully qualified name in the scp/ssh command. Now both fully qualified (like "host.company.com") & the relative name ("host") work, given that both hosts are in the "company.com" domain. ssh-keygen created the public key file with just the hostname.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文