文章二: 使用ssh实现内网穿透及SSH端口转发详解(转)

 ssh  文章二: 使用ssh实现内网穿透及SSH端口转发详解(转)已关闭评论
2月 202021
 

以下内容是关于SSH端口转发的详解使用,文章通俗易懂,比前面的文章一写的更好,强烈推荐!原文地址见文末。

 

SSH有三种端口转发模式,本地端口转发(Local Port Forwarding)远程端口转发(Remote Port Forwarding)以及动态端口转发(Dynamic Port Forwarding)。对于本地/远程端口转发,两者的方向恰好相反。动态端口转发则可以用于科学上网。

SSH端口转发也被称作SSH隧道(SSH Tunnel),因为它们都是通过SSH登陆之后,在SSH客户端SSH服务端之间建立了一个隧道,从而进行通信。SSH隧道是非常安全的,因为SSH是通过加密传输数据的(SSH全称为Secure Shell)。

在本文所有示例中,本地主机A1为SSH客户端,远程云主机B1为SSH服务端。从A1主机通过SSH登陆B1主机,指定不同的端口转发选项(-L、-R和-D),即可在A1与B1之间建立SSH隧道,从而进行不同的端口转发。

本地端口转发

应用场景:

远程云主机B1运行了一个服务,端口为3000,本地主机A1需要访问这个服务。

示例为一个简单的Node.js服务:

var http = require('http');

var server = http.createServer(function(request, response)
{
    response.writeHead(200,
    {
        "Content-Type": "text/plain"
    });
    response.end("Hello O-u-u.com\n");
});

server.listen(3000);

假设云主机B1的IP为103.59.22.17,则该服务的访问地址为:http://103.59.22.17:3000

为啥需要本地端口转发呢?

一般来讲,云主机的防火墙默认只打开了22端口,如果需要访问3000端口的话,需要修改防火墙。为了保证安全,防火墙需要配置允许访问的IP地址。但是,本地公网IP通常是网络提供商动态分配的,是不断变化的。这样的话,防火墙配置需要经常修改,就会很麻烦。

什么是本地端口转发?

所谓本地端口转发,就是将发送到本地端口的请求,转发到目标端口。这样,就可以通过访问本地端口,来访问目标端口的服务。使用-L属性,就可以指定需要转发的端口,语法是这样的:

-L 本地网卡地址:本地端口:目标地址:目标端口

通过本地端口转发,可以将发送到本地主机A1端口2000的请求,转发到远程云主机B1的3000端口。

# 在本地主机A1登陆远程云主机B1,并进行本地端口转发
ssh -L localhost:2000:localhost:3000 [email protected]

这样,在本地主机A1上可以通过访问http://localhost:2000来访问远程云主机B1上的Node.js服务。

# 在本地主机A1访问远程云主机B1上的Node.js服务
curl http://localhost:2000
Hello O-u-u.com

实际上,-L选项中的本地网卡地址是可以省略的,这时表示2000端口绑定了本地主机A1的所有网卡:

# 在本地主机A1登陆远程云主机B1,并进行本地端口转发。2000端口绑定本地所有网卡
ssh -L 2000:localhost:3000 [email protected]

若本地主机A2能够访问A1,则A2也可以通过A1访问远程远程云主机B1上的Node.js服务。

另外,-L选项中的目标地址也可以是其他主机的地址。假设远程云主机B2的局域网IP地址为192.168.59.100,则可以这样进行端口转发:

# 在本地主机A1登陆远程云主机B1,并进行本地端口转发。请求被转发到远程云主机B2上
ssh -L 2000:192.168.59.100:3000 [email protected]

若将Node.js服务运行在远程云主机B2上,则发送到A1主机2000端口的请求,都会被转发到B2主机上。

远程端口转发

应用场景:

本地主机A1运行了一个服务,端口为3000,远程云主机B1需要访问这个服务。

将前文的Node.js服务运行在本地,在本地就可以通过http://localhost:3000访问该服务。

为啥需要远程端口转发呢?

通常,本地主机是没有独立的公网IP的,它与同一网络中的主机共享一个IP。没有公网IP,云主机是无法访问本地主机上的服务的。

什么是远程端口转发?

所谓远程端口转发,就是将发送到远程端口的请求,转发到目标端口。这样,就可以通过访问远程端口,来访问目标端口的服务。使用-R属性,就可以指定需要转发的端口,语法是这样的:

-R 远程网卡地址:远程端口:目标地址:目标端口

这时,通过远程端口转发,可以将发送到远程云主机B1端口2000的请求,转发到本地主机A1端口3000。

# 在本地主机A1登陆远程云主机B1,并进行远程端口转发
ssh -R localhost:2000:localhost:3000 [email protected]

这样,在远程云主机A1可以通过访问http://localhost:2000来访问本地主机的服务。

# 在远程云主机B1访问本地主机A1上的Node.js服务
curl http://localhost:2000
Hello O-u-u.com

同理,远程网卡地址可以省略,目标地址也可以是其他主机地址。假设本地主机A2的局域网IP地址为192.168.0.100。

# 在本地主机A1登陆远程云主机B1,并进行远程端口转发
ssh -R 2000:192.168.0.100:3000 [email protected]

若将Node.js服务运行在本地主机A2上,则发送到远程云主机A1端口2000的请求,都会被转发到A2主机上。

动态端口转发

应用场景:

远程云主机B1运行了多个服务,分别使用了不同端口,本地主机A1需要访问这些服务。

为啥需要动态端口转发呢?

一方面,由于防火墙限制,本地主机A1并不能直接访问远程云主机B1上的服务,因此需要进行端口转发;另一方面,为每个端口分别创建本地端口转发非常麻烦。

什么是动态端口转发?

对于本地端口转发远程端口转发,都存在两个一一对应的端口,分别位于SSH的客户端和服务端,而动态端口转发则只是绑定了一个本地端口,而目标地址:目标端口则是不固定的。目标地址:目标端口是由发起的请求决定的,比如,请求地址为192.168.1.100:3000,则通过SSH转发的请求地址也是192.168.1.100:3000

-D 本地网卡地址:本地端口

这时,通过动态端口转发,可以将在本地主机A1发起的请求,转发到远程主机B1,而由B1去真正地发起请求。

# 在本地主机A1登陆远程云主机B1,并进行动态端口转发
ssh -D localhost:2000 [email protected]

而在本地发起的请求,需要由Socket代理(Socket Proxy)转发到SSH绑定的2000端口。以Firefox浏览器为例,配置Socket代理需要找到首选项>高级>网络>连接->设置:

这样的话,Firefox浏览器发起的请求都会转发到2000端口,然后通过SSH转发到真正地请求地址。若Node.js服务运行在远程云主机B1上,则在Firefox中访问localhost:3000即可以访问。如果主机B1能够访问外网的话,则可以科学上网……

链式端口转发

本地端口转发远程端口转发结合起来使用,可以进行链式转发。假设A主机在公司,B主机在家,C主机为远程云主机。A主机上运行了前文的Node.js服务,需要在B主机上访问该服务。由于A和B不在同一个网络,且A主机没有独立公共IP地址,所以无法直接访问服务。

通过本地端口转发,将发送到B主机3000端口的请求,转发到远程云主机C的2000端口。

# 在B主机登陆远程云主机C,并进行本地端口转发
ssh -L localhost:3000:localhost:2000 [email protected]

通过远程端口转发,将发送到远程云主机C端口2000的请求,转发到A主机的3000端口。

# 在A主机登陆远程云主机C,并进行远程端口转发
ssh -R localhost:2000:localhost:3000 [email protected]

这样,在主机B可以通过访问http://localhost:3000来访问主机A上的服务。

# 在主机B访问主机A上的服务
curl http://localhost:3000
Hello O-u-u.com

 

转自:https://blog.fundebug.com/2017/04/24/ssh-port-forwarding/

文章一:使用ssh实现内网穿透入门及应用(附autossh方法)(转)

 ssh  文章一:使用ssh实现内网穿透入门及应用(附autossh方法)(转)已关闭评论
2月 142021
 

转发一篇关于使用ssh实现内网穿透的文章,写的通俗易懂,原链接见文章末尾。

 

“世界上最遥远的距离就是你在外网请求,我在内网测试。”

这句话的内容,对于开发人员来说,特别容易理解。很多情况下,我们的开发及测试环境在单位的内网下,只能通过位于内网的机器来连接操作,位于外网的机器是连不到内网环境的。比如说,如果我们周末在家工作,而家里的机器又不在单位内网环境下,那该如何连接内网的环境呢?难不成我们还要大周末的跑到单位去加班吗?

答案是否定的。这是种普遍又迫切的需求,叫“内网穿透”。这里我们使用SSH端口转发的技术,解决这种问题。

SSH本地端口转发

假设,host1和host2位于内网,host3位于外网,host3可以连接host1和host2,但host1不能连接host3和host2。我们要做的是,通过位于外网的host3,让host1来连接host2。

具体步骤

首先,在host1上进行如下操作:


ssh -L 2222:host2:22 [email protected]

其中,-L参数指定了“本地主机端口:目标主机:目标主机端口”。这表示,让host1作为sshd服务端,监听它自己的2222端口,然后将所有数据经由host3,转发到host2的22端口。

这种情况下,host1不能连接host3,但由于host1的配置,使得从host1到host3建立了一条“SSH隧道”

然后,在host1上进行如下操作:


ssh -p 2222 [email protected]

其中,-p参数指定了ssh连接的端口,默认为22,这里指定了2222端口。这表示,让host1作为ssh客户端,连接它自己的2222端口,相当于连接host2的22端口。

一般情况下,host2与host3为一台主机,换句话说,我们只要实现连接host3,那么再连接host2也不成问题。

这时,命令分别转换为:


ssh -L 2222:localhost:22 [email protected]
ssh -p 2222 [email protected]

SSH本地端口转发的本质

本质上,SSH本地端口转发,主要是实现以下两个方面:


1. 将本地主机的端口,转发到目标主机的端口
2. 在本地主机上,连接本地主机的端口,相当于连接目标主机的端口

SSH远程端口转发

假设,host1和host2位于内网,host3位于外网,host1可以连接host3和host2,但host3不能连接host1和host2。我们要做的是,通过位于内网的host1,让host3来连接host2,也就是实现所谓的“内网穿透”

具体步骤

首先,在host1上进行如下操作:


ssh -R 2222:host2:22 [email protected]

其中,-R参数指定了“远程主机端口:目标主机:目标主机端口”。这表示,让host3作为sshd服务端,监听它自己的2222端口,然后将所有数据经由host1,转发到host2的22端口。

这种情况下,host3不能连接host1,但由于host1的配置,使得从host1到host3建立了一条“SSH反向隧道”

然后,在host3上进行如下操作:


ssh -p 2222 [email protected]

其中,-p参数指定了ssh连接的端口,默认为22,这里指定了2222端口。这表示,让host3作为ssh客户端,连接它自己的2222端口,相当于连接host2的22端口。

一般情况下,host2与host1为一台主机,换句话说,我们只要实现连接host1,那么再连接host2也不成问题。

这时,命令分别转换为:


ssh -R 2222:localhost:22 [email protected]
ssh -p 2222 [email protected]

SSH远程端口转发的本质

本质上,SSH远程端口转发,主要是实现以下两个方面:


1. 将远程主机的端口,转发到目标主机的端口
2. 在远程主机上,连接远程主机的端口,相当于连接目标主机的端口

SSH实现内网穿透

内网穿透,简单来说就是,利用位于外网的主机,来连接位于内网的主机,这符合SSH远程端口转发的情况。但由于实际情况中,SSH连接经常由于这样那样的问题,导致连接断开,因此我们不得不重新去在内网主机上建立与外网主机的连接,也就是维持这条“SSH反向隧道”,autossh能实现连接断开之后自动重连功能。

自动重连

autossh与ssh用法类似,只要将ssh命令替换成autossh命令即可,如下所示:


autossh -M 2345 -NTR 2222:localhost:22 [email protected]

其中,-M参数指定了autossh监听的端口,注意这里与其转发的端口要区分开。

另外,-N表示禁止执行远程命令,-T表示禁止分配伪终端,这两个参数结合起来表示SSH连接不允许用户交互执行远程操作,只能用来传数据,从而保证了远程主机的安全。

自动登录

每次重新建立连接,autossh都需要确认一下登录身份。要保证自动重连,前提就是要实现自动登录

一种常见的做法,就是使用公钥登录进行免密登录,将host1上的公钥传送至host3上。这样,每次在进行SSH登录的时候,host3都会向host1发送一段随机字符串,host1用自己的私钥加密后将数据返回,然后host3用事先存好的公钥对返回的数据进行解密,如果成功,则证明host1的身份可信,允许直接登录,不再要求密码。

还有一种做法,就是利用sshpass将密码明文传输给autossh,如下所示:


sshpass -p "xxxxxx" autossh -M 2345 -NTR 2222:localhost:22 [email protected]

其中,-p参数指定了登录的密码。除了命令行输入密码的形式,sshpass还包含-f、-e等参数,分别支持文件输入密码及系统环境变量输入密码等形式,如图所示。

其他端口

实现内网穿透,除了转发22端口外,我们也可以转发其他应用的端口,如web服务的80端口、mysql的3306端口等,这里就不一一细说了。

 

来自:http://www.lining0806.com/ssh%E7%AB%AF%E5%8F%A3%E8%BD%AC%E5%8F%91%E5%AE%9E%E7%8E%B0%E5%86%85%E7%BD%91%E7%A9%BF%E9%80%8F/

ssh解析、原理、入门、运用(转)

 linux, ssh  ssh解析、原理、入门、运用(转)已关闭评论
1月 252021
 

转自网上的一篇文章, 描述ssh通俗易懂,原链接见文章末尾。

 

SSH是每一台Linux电脑的标准配置。

随着Linux设备从电脑逐渐扩展到手机、外设和家用电器,SSH的使用范围也越来越广。不仅程序员离不开它,很多普通用户也每天使用。

SSH具备多种功能,可以用于很多场合。有些事情,没有它就是办不成。本文是我的学习笔记,总结和解释了SSH的常见用法,希望对大家有用。

虽然本文内容只涉及初级应用,较为简单,但是需要读者具备最基本的”Shell知识”和了解”公钥加密”的概念。

 

一、什么是SSH?

简单说,SSH是一种网络协议,用于计算机之间的加密登录。

如果一个用户从本地计算机,使用SSH协议登录另一台远程计算机,我们就可以认为,这种登录是安全的,即使被中途截获,密码也不会泄露。

最早的时候,互联网通信都是明文通信,一旦被截获,内容就暴露无疑。1995年,芬兰学者Tatu Ylonen设计了SSH协议,将登录信息全部加密,成为互联网安全的一个基本解决方案,迅速在全世界获得推广,目前已经成为Linux系统的标准配置。

需要指出的是,SSH只是一种协议,存在多种实现,既有商业实现,也有开源实现。本文针对的实现是OpenSSH,它是自由软件,应用非常广泛。

此外,本文只讨论SSH在Linux Shell中的用法。如果要在Windows系统中使用SSH,会用到另一种软件PuTTY,这需要另文介绍。

二、最基本的用法

SSH主要用于远程登录。假定你要以用户名user,登录远程主机host,只要一条简单命令就可以了。

  $ ssh [email protected]

如果本地用户名与远程用户名一致,登录时可以省略用户名。

  $ ssh host

SSH的默认端口是22,也就是说,你的登录请求会送进远程主机的22端口。使用p参数,可以修改这个端口。

  $ ssh -p 2222 [email protected]

上面这条命令表示,ssh直接连接远程主机的2222端口。

三、中间人攻击

SSH之所以能够保证安全,原因在于它采用了公钥加密。

整个过程是这样的:(1)远程主机收到用户的登录请求,把自己的公钥发给用户。(2)用户使用这个公钥,将登录密码加密后,发送回来。(3)远程主机用自己的私钥,解密登录密码,如果密码正确,就同意用户登录。

这个过程本身是安全的,但是实施的时候存在一个风险:如果有人截获了登录请求,然后冒充远程主机,将伪造的公钥发给用户,那么用户很难辨别真伪。因为不像https协议,SSH协议的公钥是没有证书中心(CA)公证的,也就是说,都是自己签发的。

可以设想,如果攻击者插在用户与远程主机之间(比如在公共的wifi区域),用伪造的公钥,获取用户的登录密码。再用这个密码登录远程主机,那么SSH的安全机制就荡然无存了。这种风险就是著名的“中间人攻击”(Man-in-the-middle attack)。

SSH协议是如何应对的呢?

四、口令登录

如果你是第一次登录对方主机,系统会出现下面的提示:

  $ ssh [email protected]

The authenticity of host ‘host (12.18.429.21)’ can’t be established.

RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.

Are you sure you want to continue connecting (yes/no)?

这段话的意思是,无法确认host主机的真实性,只知道它的公钥指纹,问你还想继续连接吗?

所谓”公钥指纹”,是指公钥长度较长(这里采用RSA算法,长达1024位),很难比对,所以对其进行MD5计算,将它变成一个128位的指纹。上例中是98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d,再进行比较,就容易多了。

很自然的一个问题就是,用户怎么知道远程主机的公钥指纹应该是多少?回答是没有好办法,远程主机必须在自己的网站上贴出公钥指纹,以便用户自行核对。

假定经过风险衡量以后,用户决定接受这个远程主机的公钥。

  Are you sure you want to continue connecting (yes/no)? yes

系统会出现一句提示,表示host主机已经得到认可。

  Warning: Permanently added ‘host,12.18.429.21’ (RSA) to the list of known hosts.

然后,会要求输入密码。

  Password: (enter password)

如果密码正确,就可以登录了。

当远程主机的公钥被接受以后,它就会被保存在文件$HOME/.ssh/known_hosts之中。下次再连接这台主机,系统就会认出它的公钥已经保存在本地了,从而跳过警告部分,直接提示输入密码。

每个SSH用户都有自己的known_hosts文件,此外系统也有一个这样的文件,通常是/etc/ssh/ssh_known_hosts,保存一些对所有用户都可信赖的远程主机的公钥。

五、公钥登录

使用密码登录,每次都必须输入密码,非常麻烦。好在SSH还提供了公钥登录,可以省去输入密码的步骤。

所谓”公钥登录”,原理很简单,就是用户将自己的公钥储存在远程主机上。登录的时候,远程主机会向用户发送一段随机字符串,用户用自己的私钥加密后,再发回来。远程主机用事先储存的公钥进行解密,如果成功,就证明用户是可信的,直接允许登录shell,不再要求密码。

这种方法要求用户必须提供自己的公钥。如果没有现成的,可以直接用ssh-keygen生成一个:

  $ ssh-keygen

运行上面的命令以后,系统会出现一系列提示,可以一路回车。其中有一个问题是,要不要对私钥设置口令(passphrase),如果担心私钥的安全,这里可以设置一个。

运行结束以后,在$HOME/.ssh/目录下,会新生成两个文件:id_rsa.pub和id_rsa。前者是你的公钥,后者是你的私钥。

这时再输入下面的命令,将公钥传送到远程主机host上面:

  $ ssh-copy-id [email protected]

好了,从此你再登录,就不需要输入密码了。

如果还是不行,就打开远程主机的/etc/ssh/sshd_config这个文件,检查下面几行前面”#”注释是否取掉。

  RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

然后,重启远程主机的ssh服务。

  // ubuntu系统
service ssh restart

// debian系统
/etc/init.d/ssh restart

六、authorized_keys文件

远程主机将用户的公钥,保存在登录后的用户主目录的$HOME/.ssh/authorized_keys文件中。公钥就是一段字符串,只要把它追加在authorized_keys文件的末尾就行了。

这里不使用上面的ssh-copy-id命令,改用下面的命令,解释公钥的保存过程:

  $ ssh [email protected] ‘mkdir -p .ssh && cat >> .ssh/authorized_keys’ < ~/.ssh/id_rsa.pub

这条命令由多个语句组成,依次分解开来看:(1)”$ ssh [email protected]”,表示登录远程主机;(2)单引号中的mkdir .ssh && cat >> .ssh/authorized_keys,表示登录后在远程shell上执行的命令:(3)”$ mkdir -p .ssh”的作用是,如果用户主目录中的.ssh目录不存在,就创建一个;(4)’cat >> .ssh/authorized_keys’ < ~/.ssh/id_rsa.pub的作用是,将本地的公钥文件~/.ssh/id_rsa.pub,重定向追加到远程文件authorized_keys的末尾。

写入authorized_keys文件后,公钥登录的设置就完成了。

 

转自阮一峰的文章:http://www.ruanyifeng.com/blog/2011/12/ssh_remote_login.html

AWS SSH使用证书登录时出现:Permission denied (publickey). (之前能够连接,而现在却不能连接)问题解决

 aws  AWS SSH使用证书登录时出现:Permission denied (publickey). (之前能够连接,而现在却不能连接)问题解决已关闭评论
12月 062018
 

使用ssh -i /path/my-key-pair.pem [email protected]
出现:Permission denied (publickey). 

出现这样的错误,先确认下手头的私钥pem文件确实对应自己的EC2实例。然后可以通过下面几个步骤排查:

1. 登录所使用的用户名是否正确?
正确的用户名如下所示:
对于 Amazon Linux 2 或 Amazon Linux AMI,用户名称是 ec2-user。
对于 Centos AMI,用户名称是 centos。
对于 Debian AMI,用户名称是 admin 或 root。
对于 Fedora AMI,用户名为 ec2-user 或 fedora。
对于 RHEL AMI,用户名称是 ec2-user 或 root。
对于 SUSE AMI,用户名称是 ec2-user 或 root。
对于 Ubuntu AMI,用户名称是 ubuntu。
另外,如果 ec2-user 和 root 无法使用,请与 AMI 供应商核实。
例如,要使用 SSH 客户端连接到从 Amazon Linux 实例,请使用以下命令:
ssh -i /path/my-key-pair.pem [email protected]

2. 如果登录时还看到类似以下的错误:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for ‘.ssh/my_private_key.pem’ are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: .ssh/my_private_key.pem
Permission denied (publickey).

需要使用下面命令调整证书文件权限
[ec2-user ~]$ chmod 0400 .ssh/my_private_key.pem

3. 如果上面的步骤还是没解决问题,而且可能是之前能够连接,而现在却不能连接了,则可能是实例主目录的权限发生了更改。/home/ec2-user/.ssh/authorized_keys 的目录及文件权限必须限制为仅限所有者
具体操作如下(以 Amazon Linux 实例为例,用户名ec2-user):
chmod 600 /home/ec2-user/.ssh/authorized_keys
chmod 700 /home/ec2-user/.ssh
chmod 700 /home/ec2-user
(测试发现700权限的扩大到755也可以)

Done!!!

*******************************************************
附录1:打开AWS用户名密码登录方式,此处以root登录为例


1.首先 用密钥登陆 
2.给 root 设置密码 sudo passwd root
3.密码设置好后 切换到root用户 su root
4.修改ssh配置文件,允许密码登录
 vim /etc/ssh/sshd_config 
将 passwordAuthentication no 改为  passwordAuthentication yes
将PermitRootLogin 改为yes 此处表示允许root登录(当然如果使用其它用户登录可以保持这项为no,但记得赋予新用户有sudo权限方便修改恢复配置)

#其它参数说明:
# 是否让 sshd 去检查用户家目录或相关档案的权限数据,
# 这是为了担心使用者将某些重要档案的权限设错,可能会导致一些问题所致。
# 例如使用者的 ~.ssh/ 权限设错时,某些特殊情况下会不许用户登入
#StrictModes no

# 是否允许用户自行使用成对的密钥系统进行登入行为,仅针对 version 2。
# 至于自制的公钥数据就放置于用户家目录下的 .ssh/authorized_keys 内
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile      %h/.ssh/authorized_keys

5 重启 ssh service sshd restart

********************************************************
附录2:更新替换AWS密钥/证书(以 AWS ubuntu举例)


1.在aws后台生成并下载密钥,然后将密钥保存到自己电脑。

2.执行ssh-keygen -y,会提示要求输入密钥路径, 复制密钥路径,回车得到public key,例如
ssh-rsa AAAAB3NzaC1yc2EAAAADAQA231BAQCMASwerewg23XvhyGzydp0V234lP/fyfuhsHKMECZydc5ewytvTq0mqYTfjKBS++PeBpEL1Zx/ilEYCmgY6omTrIMtG8s1jf/lAk0l9++f2ldp/w2U86seARyRxVEexxxyuwJJDASDHNiEbshXQ6M49nUsE6tfETG3sFl+XDeva0lkNkssA4JDU+eivPRGma3XcBAXvsUsD8VkKQJvudrpJDSjjncdjYOVd2Wcrcj5Li8MmLvIkEX1pmqTT6O6oUfEtCdpVi4tCwTXV5ydU8UtjJDSGDFSJgbY9Unve4LgjgoWF677FdUpvVFD1NPoLH

3.利用以前的密钥/用户名密码登录服务器,将上面第二步的public key粘贴到~/.ssh/authorized_keys。 
比如: aws ubuntu系统默认用户名ubuntu位置在/home/ubuntu/.ssh/authorized_keys,如没有.ssh目录则新建目录, 
然后将旧的public key注释或者删除。

4.注意将上面3所在目录和文件修改为正确的权限
chmod 600 /home/ubuntu/.ssh/authorized_keys
chmod 700 /home/ubuntu/.ssh
chmod 700 /home/ubuntu

4.然后你就可以利用新的密钥文件(.pem后缀文件)登录服务器了 
例如:ssh -i /path/my-key-pair.pem [email protected]

ssh如何通过跳板机直接访问到后端服务器(Mac&Linux&Windows解决方案)

 linux, ssh  ssh如何通过跳板机直接访问到后端服务器(Mac&Linux&Windows解决方案)已关闭评论
9月 212018
 

记录下,转自:https://my.oschina.net/foreverich/blog/657075

前言

如果公司的服务器在外网,一般会设置一个跳板机,访问公司其他服务器都需要从跳板机做一个ssh跳转,外网的服务器基本都要通过证书登录的。于是我们面临一个情况,本机ssh->跳板机->目标机器。如果直接在跳板机上放置公私钥对,并将跳板机上的公钥放到目标机器上,这样可以直接登录。但这样会有一个问题,跳板机上的root权限的用户可以获取普通用户的公私钥对,就算对私钥设置了密码,但是从安全角度来看,这样还是失去了保障,失去了服务器的一部分安全性。

如何来解决这个问题呢,其实ssh协议本身是支持秘钥转发的,不需要在跳板机上放置公私钥。

Linux(Mac)下有如下两种方式:

方式一:

从linux客户端的ssh跳转时,执行命令

ssh [email protected]跳板机ip

然后在跳板机上跳转到目标机器

ssh [email protected]目标机器ip

跳板机ip和目标机器ip,username账户下已经在相应的 .ssh/authorized_keys 加入了公钥,配置是没有问题了,但是我们会遇到一个Pubkey Unauthorization的错误,因跳板机没有username的私钥。问题总是会有,解决方法也总是有,ssh是有转发密钥的功能,从本机跳转到跳板机时可以把私钥转发过去。

正确做法是,在本机linux客户端执行命令 ssh -A [email protected]跳板机ip

-A表示转发密钥,所以跳转到跳板机,密钥也转发了过来

接下来我们再在跳板机执行命令 ssh [email protected]目标机器ip

另外可以配置本机客户端的默认配置文件,修改为默认转发密钥:

修改ssh_config(不是sshd_config,一般在/etc或者/etc/ssh下):

把 #ForwardAgent no 改为 ForwardAgent Yes

方式二:

ssh [email protected]目标机器ip -p 22 -o ProxyCommand=’ssh -p 22 [email protected]跳板机ip -W %h:%p’

也可以修改配置文件 ~/.ssh/config , 若没有则创建:

Host tiaoban #任意名字,随便使用 HostName 192.168.1.1 #这个是跳板机的IP,支持域名 Port 22 #跳板机端口 User username_tiaoban #跳板机用户 Host nginx #同样,任意名字,随便起 HostName 192.168.1.2 #真正登陆的服务器,不支持域名必须IP地址 Port 22 #服务器的端口 User username #服务器的用户 ProxyCommand ssh [email protected] -W %h:%p



Host 10.10.0.* #可以用*通配符 Port 22 #服务器的端口 User username #服务器的用户 ProxyCommand ssh [email protected] -W %h:%p

配置好后, 直接 ssh nginx 就可以登录 192.168.1.2 这台跳板机后面的服务器。 也可以用 ssh [email protected] 来登录10.10.0.27, 10.10.10.33, …. 等机器。

windows SecureCRT密钥转发

windows下SecureCRT配置转发,需要做以下设置

输入图片说明

使用ssh命令实现翻墙访问google等网站

 linux  使用ssh命令实现翻墙访问google等网站已关闭评论
12月 092015
 

本机做代理机命令如下:

ssh -qTfnN -D 9999 [email protected]

passwd: xxxx   输入密码

说明:

55.188.123.144 为远端可访问google的机器

lee为55.188.123.144登陆用户

9999为代理端口

q Quiet mode. 安静模式,忽略一切对话和错误提示。
T Disable pseudotty allocation. 不占用 shell 了。
f Requests ssh to go to background just before command execution. 后台运行,并推荐加上 n 参数。
n Redirects stdin from /dev/null (actually, prevents reading from stdin). f 推荐的,不加这条参数应该也行。
N Do not execute a remote command. 不执行远程命令,专为端口转发度身打造

代理设置如下: 

如firefox ->首选项 -> 网络设置 -> socks主机 : 127.0.0.1 端口:9999

linux使用ssh-keygen设置ssh无密码登录

 linux, ssh  linux使用ssh-keygen设置ssh无密码登录已关闭评论
10月 172014
 

记录下,模拟本机o-u-u用户在192.168.0.125机器上使用o-u-u用户ssh登陆时免密码登陆。

1        本机创建ssh密钥

[email protected]:~$ ssh-keygen  -t rsa

按提示操作,提示密码时直接回车表示不设置密码。

2        拷贝密钥(第一步中产生的带.pub后缀的文件)到“被登陆机192.168.0.125

[email protected]:~$ scp      ~/.ssh/id_rsa.pub   [email protected]:~/.ssh/id_rsa.pub

上传时需要输入密码。

3.   将id_rsa.pub添加到.ssh/authorzied_keys文件里。

 [email protected]:~$   cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

4       ssh  [email protected]192.168.0.125 这样就实现无密码登陆

 

注意:操作中可能还会不成功,大多是权限问题,按下面操作:

[ [email protected]192.168.0.125 ~]$ chmod 700 /home/o-u-u/.ssh
[ [email protected]192.168.0.125 ~]$ chmod 600 /home/o-u-u/.ssh/authorized_keys

切记不要将权限扩大为777,这样反而不能自动自动登陆

 

 

如何解决本地用户与远程用户不一致问题?

修改本地登录用户到~/.ssh/config文件,如果没有自己建一个,内容如下:

Host hostname1 

    user lili 

Host fili 

    user luoluo 

Host hostname 

    user nmnm

 

另一个更简单到方法

ssh-copy-id 是一个小脚本,可以使用这个脚本完成以上工作,这个脚本在linux系统里一般都有

 

Linux(Ubuntu, Fedora)下SecureCRT 破解(Insufficient privileges, please switch the root account. at ./securecrt_linux_crack.pl 解决)

 ubuntu  Linux(Ubuntu, Fedora)下SecureCRT 破解(Insufficient privileges, please switch the root account. at ./securecrt_linux_crack.pl 解决)已关闭评论
9月 162014
 

以下描述过程:

操作系统: Linux (Ubuntu, Fedora) MacOSX
相关软件: SecureCRT

操作过程:

操作过程都在终端中执行.
Ubuntu 的破解 :

下载程序:

运行破解 /usr/bin/SecureCRT要填写真实的SecureCRT路径

 

破解完成

填写输出的注册信息, 并运行SecureCRT 查看注册信息:

查询破解信息

 

 

注: 程序只提供测试, 请测试完成后删除程序, 需要使用请购买正版软件, 谢谢.


破解过程中可能会出现这样的错误:

Insufficient privileges, please switch the root account. at ./securecrt_linux_crack.pl line 82.

即使切换到root也不行, 可以将目录下的SecureCRT文件cp到 /tmp目录下再运行pl脚本破解,破解后再copy回去

Permissions xxx for ‘/xx/.ssh/id_rsa’ are too open处理

 git  Permissions xxx for ‘/xx/.ssh/id_rsa’ are too open处理已关闭评论
6月 192013
 

git push 时出现下面提示:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0771 for '/home/ccc/.ssh/id_rsa' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /home/ccc/.ssh/id_rsa
Permission denied (publickey).
fatal: The remote end hung up unexpectedly

 

可试试通过下面命令解决:

cd ~/.ssh
chmod 700 id_rsa