正常に実行された後、ビルドスクリプトはコマンドを使用して最終バイナリをFTPサーバーにコピーしようとしますscp
。ビルドに時間がかかるので、毎回パスワードを求めるのが嫌いなのでSSHキーペアを設定してみました。
[wbarlow@build-machine]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/wbarlow/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/wbarlow/.ssh/id_rsa.
Your public key has been saved in /home/wbarlow/.ssh/id_rsa.pub.
The key fingerprint is:
7f:b9:c7:a8:1b:77:ce:f8:b6:2a:e3:da:30:68:72:b7 wbarlow@build-machine
[wbarlow@build-machine]$ ssh-copy-id wbarlow@ftp-server
wbarlow@ftp-server's password:
Now try logging into the machine, with "ssh 'wbarlow@ftp-server'", and check in:
~/.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
その後、FTPサーバーにログインしようとしましたが、まだパスワードの入力を求められます。新しく生成されたキーが存在することを確認しました。
[wbarlow@build-machine]$ ssh wbarlow@ftp-server
wbarlow@ftp-server's password:
[wbarlow@ftp-server]$ cat ~/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDGUbr4vUeiY7D6sSrsHm469QAqCClchL
7h/HZ7TAc+1F2KsTTF078OSINqzz8NpKJqhlEusLn644PzYn9LmGTIc7IsMG9s+B2n4bZX
9Ypb0VqLSqTgfE2I0j84+SfAQ6MvGJQ0NupIXxXbaMLDlNq1cetnR8NeN+9JeBq4sI8p/a
ijFVARQ7/XSKwQQN30Nl6flTEM1CTDECJs5YsPOu3P54mF6PG2mBdFra6+VQfAZ6fboq9O
d24VNHLYVtUdK5RpWgx8agUalov0xq/3m2VeC5arrYpCVH1rGx6EMxoQS25kk7t9mzBUCj
ulXGWQX2DPR/Em0OIfvVfe/l4xtFfH wbarlow@build-machine
公開鍵を使用して他のコンピュータ(私のGitストレージホストなど)に認証できるため、クライアントに問題があるようには見えません。
それでは、FTPサーバーが認証されたキーを受け入れるように構成されていること、およびどのタイプのキーを受け入れるように構成されているかどうかを確認します。キーが予想される場所に保存されていることをどのように確認できますか? (ftpサーバーのホームディレクトリはですが、そこからフォルダをコピーしてみ/var/ftp/wbarlow/
ました。).ssh
/home/wbarlow/
私の.ssh
ディレクトリはモード700で、私のauthorized_keys
ファイルはモード600です。また、755を.ssh
ディレクトリとして使用してみました。
/etc/ssh/sshd_config
FTPサーバーで私のファイルを見つけました。内容全体を公開するわけではありませんが、次の行があります。
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication yes
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no
私が知る限り文書、私はこの行が私がやりたいことに合わせて正しく設定されていると思います(s / keyはsshキーペアとは何の関係もありません。そうですか?)。
以下は接続時の詳細出力です。
[wbarlow@build-machine]:~$ ssh -v wbarlow@ftp-server
OpenSSH_6.1p1 Debian-4, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to ftp-server [(ip hidden)] port 22.
debug1: Connection established.
debug1: identity file /home/wbarlow/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/wbarlow/.ssh/id_rsa-cert type -1
debug1: identity file /home/wbarlow/.ssh/id_dsa type -1
debug1: identity file /home/wbarlow/.ssh/id_dsa-cert type -1
debug1: identity file /home/wbarlow/.ssh/id_ecdsa type -1
debug1: identity file /home/wbarlow/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1
debug1: match: OpenSSH_5.1 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
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
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA [SNIP]
debug1: Host 'ftp-server' is known and matches the RSA host key.
debug1: Found key in /home/wbarlow/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
Cannot determine realm for numeric host address
debug1: Unspecified GSS failure. Minor code may provide more information
Cannot determine realm for numeric host address
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
Cannot determine realm for numeric host address
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/wbarlow/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: /home/wbarlow/.ssh/id_dsa
debug1: Trying private key: /home/wbarlow/.ssh/id_ecdsa
debug1: Next authentication method: password
wbarlow@ftp-server's password:
答え1
SSHサーバーの構成設定は通常そこにありますが、/etc/ssh/sshd_config
最初に確認する必要があるのは場所です。特権公開鍵および対応する親ディレクトリサーバーにコピーしました。
リモートに対する正しい権限は次のとおりです。authorized_keys
批判的SSHが機能するには、ssh-copy-id
公開鍵を単にリモートデバイスにコピーするのではなく、公開鍵を使用する理由です。
これを理解するには、ssh-copy-id
それが実行する操作を分析するのが便利です。
最初に行うことは、id_rsa.pub
ターゲットサーバーに安全にコピーすることです。
scp -P port $HOME/.ssh/id_rsa.pub username@ipaddress:destination_path
~/.ssh/
リモートシステムに配置されます。
それも名前を変更する id_rsa.pub
だからauthorized_keys
あなたは結局
$ ~/.ssh/authorized_keys
リモートコンピュータから。
また、権限を設定します。批判的つまり、ファイルauthorized_keys
は次のものより安全でなければなりません。
-rw------- 1 wbarlow wbarlow 802 Nov 25 13:54 authorized_keys
そして、.ssh
ディレクトリは、755
例えば、以下より安全ではありません。
drwx------ 2 wbarlow wbarlow 4096 Jul 29 00:30 .ssh
私はコマンドを使用する傾向があります
ssh-copy-id -i ~/.ssh/id_rsa.pub remote_user@remoteIP
これにより、私が望む特定のキーがリモートに到達する可能性がありますが、接続しようとしたときにsshがローカルコンピュータで利用可能なすべての秘密キーをチェックすると疑われるため、これは問題になるとは思いません。
また、いつものように、他のユーザー/プログラムが適切なファイル権限を持つように、インクルードフォルダ($ HOME)のデフォルト権限を確認してください。
答え2
SSHサーバーの構成設定は通常/etc/ssh/sshd_configにありますが、最初に確認する必要があるのは、サーバーにコピーされた公開鍵とその親ディレクトリの場所と権限です。
/etc/ssh/sshd_config は次のようになります。 sshdサービスを停止して再起動する必要があります。
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys