㈠ linux生成的rsa秘钥在哪
方法一， 有的时候经常需要登录ssh，每次都需要输入密码，会比较繁琐。所以设置了一下使用RSA公钥认证的方式登录Linux。 首先需要在服务器端设置/etc/ssh/sshd_config # vim /etc/ssh/sshd_config 修改如下两行为yes。其实大多数情况下不用修改，默认就是yes。 RSAAuthentication yes PubkeyAuthentication yes (1) 如果客户机和服务器都是Linux机器，那么我们使用下面的方法：(后面第2节会提到怎么在Windows下使用Putty生成密钥对) 我们需要在客户端生成RSA密钥对。使用ssh-keygen命令： # ssh-keygen -t rsa 参数t的意思是type，后面跟着加密类型，这里我们是rsa。 然后会提示你输入密钥保存完成文件名，这里我们需要使用默认的id_rsa，之后才能正常才能登录。如果你生成的密钥作为其他用处，那么可以命名为其他名称： Generating public/private rsa key pair. Enter file in which to save the key (/home/cake/.ssh/id_rsa): 之后会提示你输入一个passphrase，我们这里可以留空，这样我们登录的时候就不许输入密码。 Enter passphrase (empty for no passphrase): Enter same passphrase again: 然后会提示你密钥生成成功。这是你的私钥保存为~/.ssh/id_rsa，你的公钥是~/.ssh/id_rsa.pub 我们现在需要做的是，把id_rsa.pub的内容，添加的服务器端的~/.ssh/autherized_keys文件最后。 你可以把这个文件上传到服务器端，然后使用命令： # cat id_rsa.pub >> ~/.ssh/autherized_keys 到这里就完成了。 (2) 在Windows下使用Putty生成密钥对： Putty的安装目录下有个puttygen.exe程序，我们运行这个程序。 之后点击Generate，开始生成密钥对。我们需要根据提示，在指定方框内随机滑动鼠标。这是为了根据鼠标轨迹，产生一些随机数据。 之后生成结束，我们点击Save Private Key将私钥存放在某个目录中。然后赋值最上面文本框中的全部内容，粘贴到Linux服务器端的autherized_key的最后。 我们现在可以关闭这个小程序。 现在打开Putty，在左边的选项中，选择Conneciton–SSH–Auth，在Private key file for authentication中，选择刚才保存的私钥路径就可以了。 到此位置，Putty也可以不用密码登录了。 方法二 使用Linux主机生成的密匙 1、生成密匙 [root@ .ssh]#ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: e4:9a:47:a7:b4:8a:0b:98:07:b8:70:de:6b:16:2c:0croot@ 2、将 /root/.ssh/id_rsa.pub改名为/root/.ssh/authorized_keys [root@ .ssh]#mv /root/.ssh/id_rsa.pub /root/.ssh/authorized_keys 3、将私钥id_rsa拷贝到远程客户端 1)、如果远程客户端是linux，拷贝到远程客户端/root/.ssh/即可 2)、putty作为远程客户端在 putty不能识别直接从服务器拷贝来的私钥，需要使用puttygen.exe进行格式转换 (1)、打开puttygen.exe --> Conversions --> Import Key (2)、选择拷贝过来的私钥文件id_rsa (3)、Save private key->id_rsa.ppk(保存私钥) 4、打开putty.exe 1)、Session --> Host Name (填写服务器地址或者域名) 2)、Connection --> SSH --> Auth (点Browse选择刚生成的id_rsa.ppk) 3)、open 成功打开后出现如下提示： login as: root Authenticating with public key "imported-openssh-key" ---------------------------------------------------------------------------------- 当然你有可能会遇到这个错误 [因为我遇到了，呵呵]： Permissions 0755 for '你配置的公钥文件路径' are too open. 这个是因为这几个文件权限设置的有点问题 执行命令： chmod 600 你的文件
㈡ RSA公私钥和签名、验签过程
RSA又叫非对称加密算法，这类加密算法有2个秘钥，你可以选择一个作为私钥（自己保存，重要），另一个作为公钥（对外公开，谁都可以知道）。其中用私钥加密的内容只能用对应的公钥解密，同理用公钥加密的内容也只能用对应的私钥解密。
假设A生成了一对秘钥，私钥自己保存，公钥对外公开，且B获得了A的公钥。在A和B通信的过程中：
A向B发送信息：A用自己的私钥加密，B可以用其公钥解密；
B向A发送信息：B用（A给的）公钥加密数据，A可以用自己的私钥解密；
这样就保证了数据的安全传输；但是这中间存在问题，如果B向A发送数据的过程中被C拦截了，且C也雀简获得了A的公钥，这样C就可以用缓岁兄公钥重新加密一份数据发送给A，这样就篡改了B发送给A的数据。为了辨别这种情况，就要说到数字签名的作用了。
因为在数据传输过程中有可能被篡改，因此我们要使用数字签名技术来校验发送扰袭方的身份，并且事后发送方无法抵赖。这里还以A和B为例，来看下数字签名的主要过程：
数字签名是什么？
㈢ 四、公钥和私钥，加密和数字签名
本文涉及到支付宝SDK的内容，均摘自支付宝开放平台。
因为支付宝SDK使用RSA来加密和生成数字签名，所以本文中涉及到的概念也都是针对于RSA的。
一对儿密钥生成后，会有公钥和私钥之分，我们需要把私钥保存下来，而把公钥发布出去。一对儿公钥和私钥，不能由其中一个导出另一个。
比如使用支付宝SDK的时候，我们商户端会生成一对儿密钥A和B，A是私钥，B是公钥，支付宝也会生成一对儿密钥C和D，C是私钥，D是公钥。我们商户端需要把商户端私钥A保存下来，而把商户端公钥B发布出去给支付宝，支付宝需要把支付宝私钥C保存下来，而把支付宝公钥D发布出去给我们商户端。
加密是指我们使用一对儿密钥中的一个来对数据加密，而使用另一个来对数据解密的技术，需要注意的是公钥和私钥都可以用来加密，也都可以用来解密 ，并不是规定死了只能用公钥加密私钥解密，但是加解密必须是一对儿密钥之间的互相加解密，否则不能成功。
加密的目的是为了保证数据的不可读性，防止数据在传输过程中被截获。
知道了加密这个概念，我们先看一下支付宝的加密过程，再引出数字签名这个概念。接着第1小节的例子，当我们商户端和支付宝互相发布了公钥之后，我们商户端手里就有 商户端私钥 和 支付宝公钥 两个密钥，支付宝手里也有 商户端公钥 和 支付宝私钥 两个密钥。现在假设我们商户端要给支付宝传输订单信息，那么为了保证传输订单信息时数据的安全性，结合我们商户端手里所拥有的密钥，可以有两套加密方案
貌似这两套加密方案都能达到对订单信息加密的效果，而且如果采用方案二，我们商户端甚至只需要存储支付宝公钥这一个密钥，都不用去申请一对儿商户端的公私钥来维护，支付宝也不用保存我们一堆商户那么多的商户端公钥了，这不是更简单吗，那为什么支付宝开放平台让我们采用的是方案一而不是方案二呢？下面来回答一下。
支付宝开放平台说明：当我们采用RSA（1024位密钥）来加密的时候，支付宝分配给所有商户的支付宝公钥都是一样的，即支付宝针对那么多的商户只负责维护一对儿支付宝公私钥，这就意味着支付宝公钥随便什么人拿到后都是一样的；而当我们采用RSA2（2048位密钥）来加密的时候，支付宝会分配给每个商户单独的一个支付宝公钥，即支付宝为每一个的商户单独的维护一对独立的支付宝公私钥，当然一个商户下的多个App的支付宝公钥是一样的。RSA是早就支持的，RSA2是最近才支持的。
知道了上面这段话，现在假设我们采用的是方案二，并且采用RSA加密（很多老业务并没有使用RSA2加密），业务逻辑将会是下面这样。
这就出问题了， RSA加密下，支付宝公钥是公开发布的，而且所有的商户用的都是同一个支付宝公钥（上面声明了RSA2加密下，支付宝才针对每个商户维护了一对儿公私钥），攻击者很容易就能获取到，而 notify_url 也很容易被截获，那攻击者拿到这两个东西就可以做和商户一样的操作来发起支付请求，这样就会一直给小明充钱了。
所以 支付宝就需要确认支付请求确实是商户发给他们的，而不是攻击者发给他们的。 这就用到了 数字签名 ，我们会通过方案一的实现流程来引出数字签名的具体概念。如果我们采用的是方案一，我们商户端保存的就是商户端私钥和支付宝公钥，而支付宝保存的就是需要存着商户端公钥和支付宝私钥的，业务逻辑将会是下面这样。
这样就可以保证交易的安全性了，我们也可以看出使用支付宝SDK保证交易的安全性注重的其实不是订单信息是否加密，而是如何确保商户端和支付宝能够互相确认身份，订单信息是明文的，但是后面拼接了数字签名。
数字签名其实就是明文数据加密之后得到的一个密文，只不过它是用私钥加密生成的而已，我们一般会把数字签名拼接在明文数据后面一起传递给接收方，接收方收到后用公钥解密数字签名，从而验证发送方的身份、以及明文数据是否被篡改。数字签名的生成过程其实就是一个加密过程，数字签名的验签过程就是一个解密过程。
数字签名的目的有两个：一、发送方和接收方互相验证身份；二、验证数据是否被篡改。
从上面第一部分我们知道为了确保商户和支付宝交易的安全性，约定采用的是给订单信息加数字签名传输的方式。支付宝也为我们提供了 一键生成RSA密钥的工具 ，可以帮助我们很快的生成一对商户端公私钥。以下会对支付宝SDK的支付流程做个大概的解释，并点出实际开发中我们使用支付宝SDK时应该注意的地方。
由我们商户端自己生成的RSA私钥（必须与商户端公钥是一对），生成后要保存在服务端，绝对不能保存在客户端，也绝对不能从服务端传输给客户端。
用来对订单信息加签，加签过程一定要在服务端完成，绝对不能在客户端做加，客户端只负责用加签后的订单信息调起支付宝来支付。
由我们商户端自己生成的RSA公钥（必须与商户端私钥是一对），生成后需要填写在支付宝开放平台。
用来给支付宝服务端验签经过我们加签后的订单信息，以确保订单信息确实是我们商户端发给支付宝的，并且确保订单信息在传输过程中未被篡改。
这个和我们就没关系了，支付宝私钥是他们自己生成的，也是他们自己保存的。
用来对支付结果进行加签。
支付宝公钥和支付宝私钥是一对，也是支付宝生成的，当我们把商户端公钥填写在支付宝开放平台后，平台就会给我们生成一个支付宝公钥，我们可以复制下来保存在服务端，同样不要保存在客户端，并且不要传输给客户端。
用来让服务端对支付宝服务端返给我们的同步或异步支付结果进行验签，以确保支付结果确实是由支付宝服务端返给我们服务端的，而且没有被篡改，对支付结果的验签工作也一定要在服务端完成。
上面已经说过了： 订单信息的加签和支付结果的验签是一定要在服务端做的，绝对不能在客户端做。
下面是在客户端对订单信息加签的过程，仅仅是为了模拟服务端来表明订单信息是如何通过加签最终转变为orderString的， 千万不要觉得订单信息的加签过程也可以放在客户端完成 。
假设我们服务端收到了来自支付宝服务端的支付结果，即： 支付结果+数字签名 。
那么我们服务端就会对支付结果进行验签，怎么个验法呢？
㈣ RSA 公钥和私钥
首先明确一点，公钥和私钥是成对出现的。一个负责加密，另一个负责解密。公开的就是公钥，自己留着的就是私钥。所以不管加密还是解密密钥都是可以是公钥或者私钥的。
所以如果别人发东西给我，我就需要把加密密钥给别人，解密密钥自己藏着，这样就是公钥加密，私钥解密。
如果我想让别人确认我的身份，我就需要把解密密钥给别人，加密密钥自己留着，给自己加密，别人获得密文后用我的解密密钥才可以解密。所以这里就是公钥负责解密，私钥负责加密。
例如服务器证书，一个证书中通常包含很多字段，其中包括：
浏览器收到证书时会对签名颁发机构进行检查。如果这个机构是个很有权威的公共签名机构，浏览器可能已经知道其公开密钥了（浏览器会预先安装很多签名颁发机构的证书），然后用公钥解密，获得相关信息，例如获得证书里面的Web站点的名称和主机名，看看与当前浏览器的地址栏中的地址是否匹配，不匹配的话，浏览器就会给出警告（你可能看到过），提示当前证书是颁给xxx域名的，不是给当前域名的，让你注意。