SSH
MAC下配置使用ssh服务：
1.生成密室对ssh-keygen -t rsa，在当前目录下生成密室对
2.将私匙拷贝到~/.ssh目录下
3.将公匙拷贝到服务器的~目录下，并在服务端执行cat id_rsa.pub >> ～/.ssh/authorized_keys
4.在服务端配置sshd服务，编辑/etc/ssh/sshd_config（注意不是/etc/sshd_config文件）文件：
#禁用root账户登录，非必要，但为了安全性，请配置
PermitRootLogin no
# 是否让 sshd 去检查用户家目录或相关档案的权限数据，
# 这是为了担心使用者将某些重要档案的权限设错，可能会导致一些问题所致。
# 例如使用者的 ~.ssh/ 权限设错时，某些特殊情况下会不许用户登入
StrictModes no
# 是否允许用户自行使用成对的密钥系统进行登入行为，仅针对 version 2。
# 至于自制的公钥数据就放置于用户家目录下的 .ssh/authorized_keys 内
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
#有了证书登录了，就禁用密码登录吧，安全要紧
PasswordAuthentication no
5.配置完sshd服务，重新启动sshd服务
sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist // MAC下启动ssh服务
sudo launchctl unload -w /System/Library/LaunchDaemons/ssh.plist //MAC下停止ssh服务
6.执行ssh -i ~/.ssh/private_key username@ip 就可以无密码登录了
7.为了简化命令可以配置/etc/ssh/ssh_config文件，将其中的IdentityFile设置为~/.ssh/private_key，这样就可以使用 ssh username@ip登录了
SSH 公钥检查是一个重要的安全机制，可以防范中间人劫持等黑客攻击。但是在特定情况下，严格的 SSH 公钥检查会破坏一些依赖 SSH 协议的自动化任务，就需要一种手段能够绕过 SSH 的公钥检查。
SSH 连接远程主机时，会检查主机的公钥。如果是第一次该主机，会显示该主机的公钥摘要，提示用户是否信任该主机：
[root@master ~]# ssh 10.11.3.61
The authenticity of host '10.11.3.61 (10.11.3.61)' can't be established.
RSA key fingerprint is 5a:8e:00:2f:a3:e4:cf:d1:f9:29:b8:24:e7:36:28:cd.
Are you sure you want to continue connecting (yes/no)?
当选择接受，就会将该主机的公钥追加到文件 ~/.ssh/known_hosts 中。当再次连接该主机时，就不会再提示该问题了。
省去连接时进行公钥确认：
在首次连接服务器时，会弹出公钥确认的提示。这会导致某些自动化任务，由于初次连接服务器而导致自动化任务中断。或者由于 ~/.ssh/known_hosts 文件内容清空，导致自动化任务中断。
SSH 客户端的 StrictHostKeyChecking 配置指令，可以实现当第一次连接服务器时，自动接受新的公钥。只需要修改 /etc/ssh/ssh_config 文件，包含下列语句：
[root@master ~]# vi /etc/ssh/ssh_config
StrictHostKeyChecking no
或者使用
[root@master ~]# ssh IP -oUserKnownHostsFile=/dev/null -oStrictHostKeyChecking=no
https://segmentfault.com/a/1190000001732729
http://www.111cn.net/sys/linux/80188.htm
http://blog.csdn.net/revitalizing/article/details/50091357
http://guoluming30038ip6.blog.163.com/blog/static/20530022820124411235581/
SSH配置：
http://www.jianshu.com/p/1fdcd9d9cb2f
http://qa.blog.163.com/blog/static/19014700220152342658225/
http://www.cnblogs.com/ggjucheng/archive/2012/08/19/2646346.html
http://blog.csdn.net/hitabc141592/article/details/8523184
