SSH 为 Secure Shell 的缩写,由 IETF 的网络小组(Network Working Group)所制定;SSH 为建立在应用层基础上的安全协议。SSH 是目前较可靠,专为远程登录会话和其他网络服务提供安全性的协议。利用 SSH 协议可以有效防止远程管理过程中的信息泄露问题。
近来在复习防火墙管理工具iptables的基本使用方法,涉及到对端口添加或删除防火墙策略的内容,之前对ssh更改默认端口号及免密码登录的方法不熟悉,这次做一个基本的总结防止自己遗忘。
## 绑定本地端口 SSH可以让那些不加密的网络连接,全部改走SSH连接,从而提高安全性。 假定我们要让8080端口的数据,都通过SSH传向远程主机,命令就这样写: ```bash $ ssh -D 8080 user@host ``` SSH会建立一个socket,去监听本地的8080端口。一旦有数据传向那个端口,就自动把它转移到SSH连接上面,发往远程主机。可以...
# 介绍 SSH (安全 shell),是一个安全协议,同时也是安全地管理远程服务器时用的最多的方法。它提供了一种能够在客户端和服务器端建立安全传输和验证,以及执行远程命令的方法,而这里面使用了多种加密技术。 这篇文章我们会学习 SSH 使用的底层的加密技术以及其用于建立安全连接的具体方法,这些知识会对你理解不同层的...
1.创建ssh密钥并下载 2.改变ssh密钥权限 chmod 400 /Users/***/.ssh/nodeBlog 3.登入 ssh -i /Users/***/.ssh/nodeBlog root@193.112.12.82
原因: 在主机子系统每次成功ssh连接远程操作,都会把你每个你访问过计算机的公钥(public key)都记录在主机的目录/root/.ssh的known_hosts下,当下次访问相同子机服务器时,会核对公钥。如果公钥不同,会发出警告,避免你受到DNS Hijack之类的攻击。 解决方法: 打开终端输入 cd ~/.ssh rm known_hosts 然后重新登录即可!
ssh-keygen: generating new host keys: DSA /usr/local/openssh/sbin/sshd -t -f /etc/ssh/sshd_config @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0640 for '/etc/ssh/ssh_h...
# 错误提示: linux添加公钥的时候,出现下面的错误: ```bash $ sign_and_send_pubkey: signing failed: agent refused operation ``` # 解决方案: 执行以下代码添加代理即可: ```bash $ eval "$(ssh-agent -s)" $ ssh-add ```
首先要安装openssh-server,好像默认就安装好了 然而安装好后通过 service ssh --full-restart 也启动不成功 后来查了查发现,默认端口22要改一下 改完启动成功了,便windows里通过xshell连接127.0.0.1:{port}依然连不上,密码不对,在子系统中设置了也不管用 最后发现/etc/ssh/sshd_config里有个地方要改下 PermitRootL...
## 方案一:在客户端设置 方法很简单,只需在客户端电脑上编辑(需要root权限)/etc/ssh/ssh_config,并添加如下一行: ``` ServerAliveInterval 60 ``` 此后该系统里的用户连接SSH时,每60秒会发一个KeepAlive请求,避免被踢。 ## 方案二:在服务器端设置 如果有相应的权限,也可以在服务器端设置,即编辑/etc/ssh/sshd...
git pull 时可能出现这样的错误: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you ...
背景: 在公司连服务器一般要么是密码认证要么是publick key认证,或者认证之前还要连vpn啥的,连上服务器一般运维都不会给开发人员root权限,我平常使用的是SecureCRT, 经常有下载文件的需求,每次都需要打开session,然后右键连接sftp,如果一两台服务器还好,可每次都是十几二十台的服务器,每台都需要连sftp下载文件...
`ssh-keygen` -B -- show the bubblebabble digest of key -C -- provide new comment -D -- download key stored in smartcard reader -N -- provide new passphrase -P -- provide old passphrase -U -- upload key to smartcard reader -b -- specify number of bits in key -c -- change comment in private and pub...
本文给大家详细介绍了ssh密钥登录远程服务器流程和注意事项,以下是详细内容:
有时候我们需要批量发送ssh命令给服务器,但是有可能有些服务器是新加入的,还没有配置ssh免密,这个时候就会提示我们输入yes/no或者password等,expect脚本命令就是用于在提示这些的时候,自动为我们输入相应的文字
###登陆服务器 打开terminal ssh root@serverIP yes password ###记住服务器IP 右击terminal->新建远程连接
一、环境配置1、系统:CentOS release 5.6 IP:192.168.4.200 主机名:JW012、系统:CentOS release 5.9 IP:192.168.4.244 主机名:
You can easily mount remote server file system or your own home directory using special sshfs and fu
其实本身Linux已经很安全了,但是如果密码设置的不够复杂,如果说小写+数字共12位以下,你的SSH还用的默认端口,那强力一点的黑客用不上半小时,就能暴力破解你的密码。所以,最好的方法就是修改掉SSH的端口。一、修改文件:/etc/ssh/sshd_configPort 22 #在第三行或第四行,如果前面有井号,请删除,修改为65534以下即可可在远程连接中用vi命令,或sftp下载到本地修改,修改后使用以下命令重启ssh服务/etc/init.d/sshd restart #centos系统,重启ssh服务命令/etc/init.d/ssh restart #debian/ubuntu系统,重启ssh服务命令二、更加安全的设置,禁止ROOT登陆,采用小号登陆再切换ROOT(此方法不能用SFTP上传文件)useradd vpsmm #新建一个小号passwd vpsmm #给小号设置密码,需要输入完全相同的二次,注意提示vi /etc/ssh/sshd_config #修改的文件还是这个PermitRootLogin yes #把yes,改成no,保存退出,并重启SSH服务(上面有重启命令)切记,如果没有新建小号,或小号密码设置错误,你又禁了ROOT,那你只能重启系统或回滚快照,再也登陆不了。如果不是极度需要安全环境,并且,还需要使用SFTP管理文件,那改掉端口就行了。
背景在开篇之前,让我们先对 SSH 协议有个宏观的大致了解,这样更有利于我们对本文的加深了解。首先要提到的就是计算机网络协议,所谓计算机网络协议,简单的说就是定义了一套标准和规则,使得不同计算机之间能
SSH 端口转发功能能够将其他 TCP 端口的网络数据通过 SSH 链接来转发,并且自动提供了相应的加密及解密服务。其实这一技术就是我们常常听说的隧道(tunnel)技术,原因是 SSH 为其他 TCP 链接提供了一个安全的通道来进行传输。我们知道,FTP 协议是以明文来传递数据的。但是我们可以让 FTP 客户端和服务器通过 SSH 隧道传输数据,从而实现安全的 FTP 数据传输。更常见的情况是我们的应用经常被各种防火墙限制。常见的有禁止访问某些网站、禁用某类软件,同时你的所有网络行为都被监控并分析!同样的通过 SSH 隧道技术我们完全可以规避这些限制。如上图所示,通过 SSH 的端口转发, 应用程序的客户端和应用程序的服务器端不再直接通讯,而是转发到了 SSH 客户端及 SSH 服务端来通讯。这样就可以同时实现两个目的:数据的加密传输和穿透防火墙!在具体的使用场景中,端口转发又被细分为本地端口转发、远程端口转发、动态端口转发等。本文将详细的介绍其技术原理及使用方法。本地端口转发假设我们有一台主机 B,上面运行着 smtp 服务器,监听的端口号为 25,但是只监听了 localhost 网络接口。也就是说只有运行在主机 B 上的邮件客户端才能与 smtp 服务器建立连接。此时另外一台主机 A 上的邮件客户端如果想要通过主机 B 上的 smtp 服务器收发邮件该怎么设置呢?通过 SSH 的本地端口转发功能可以轻松的搞定这样的场景!假设两台主机上都安装了 SSH,我们可以使用主机 A 上的 SSH 客户端向主机 B 上的 SSH 服务器发起请求,建立一条执行端口转发的隧道:$ ssh -L 10025:localhost:25 HostB此命令的运行原理如下图所示(此图来自互联网):运行上面的命令后,SSH 客户端程序在主机 A 上监听了 localhost:10025(你可以用 1024 - 65535 之间的任意端口代替 10025,只要不与已有端口冲突就行)。所有在主机 A 上发往 10025 端口的消息都会通过 SSH 隧道转发到主机 B 上的 25 端口。接下来需要配置主机 A 上的邮件客户端程序,让它把消息发送到 localhost:10025。完成之后主机 A 上的邮件客户端就可以通过主机 B 上的 smtp 服务器收发邮件了。具体的数据包的流向为:1 邮件客户端把数据包发送到 localhost(主机 A) 的 10025 端口2 SSH 客户端把数据包加密并从主机 A 发送到主机 B 的 SSH 服务器3 SSH 服务器把数据包解密并发送到 localhost(主机 B) 的 25 端口从 smtp 服务器返回的数据包则是沿着原路返回以完成数据的双向传递。至此我们已经完成了一个最基本的本地端口转发 demo 的介绍。接下来让我们来聊一下究竟什么叫本地端口转发?在上面的 demo 中我们注意到一共有两对的客户端与服务器程序,分别是 smtp 应用的客户端和服务器与 SSH 的客户端和服务器。如果应用程序的客户端和 SSH 的客户端位于 SSH 隧道的同一侧,而应用程序的服务器和 SSH 服务器位于 SSH 隧道的另一侧,那么这种端口转发类型就是本地端口转发。需要使用 -L 选项来创建。前面的 demo 中应用程序的客户端和 SSH 客户端位于同一台主机上,应用程序的服务器端和 SSH 的服务器端也位于同一台主机上,真实的情况往往不是这样的:上图中的场景可能更符合真实情况(此图来自互联网)。应用程序的客户端和 SSH 客户端分别位于 SSH 隧道同一侧的两台不同的主机上,而应用的服务器端和 SSH 服务器分别位于 SSH 隧道另一侧的两台不同的主机上。此时我们需要使用下面的命令:$ ssh -g -L P:HostS:W HostB应用 -g 选项后主机 A 不仅会监听 localhost 的 P 端口,还能够监听所有网络接口的 P 端口,所以主机 C 上的应用客户端就可以把消息发送到主机 A 的 P 端口。接下来我们必须要介绍本地端口转发的命令格式了:ssh -L <local port>:<remote host>:<remote port> <SSH server host>SSH server host 是 SSH 服务器所在的主机,  remote host 和 remote port 则分别指应用程序服务器所在主机和监听端口。如果 remote host 指定为 localhost 则认为应用程序服务器和 SSH 服务器在同一台主机上。在结束本地端口转发之前还需要介绍另外两个选项,它们是 f 和 N。上面的命令在创建隧道的同时登录到远程主机,一般情况下我们不需要这个登录。况且一旦这个登录退出,隧道也会随之关闭。我们更期望的是能够创建在后台运行的隧道,这时就需要添加 f 和 N 选项。远程端口转发我们必须区别远程端口转发和本地端口转发,因为它们对应了不同的应用场景,当然使用的命令行选项也是不一样的。如果应用程序的客户端和 SSH 的服务器位于 SSH 隧道的同一侧,而应用程序的服务器和 SSH 的客户端位于 SSH 隧道的另一侧,那么这种端口转发类型就是远程端口转发。远程端口转发的结构如下图所示(此图来自互联网):所以,区分本地端口转发和远程端口转发主要是看 SSH 客户端与应用程序的哪一部分在 SSH 隧道的同一侧!远程端口转发的命令格式为:ssh -R <local port>:<remote host>:<remote port> <SSH server host>其它的细节两者基本也是一样的。但是远程端口转发不支持 -g 参数,这让我们很难实现类似下面的用例:内网中主机 A 上运行 Jenkins 服务器监听本机 8080 端口,并运行 SSH 客户端。外网中的主机 B 上运行 SSH 服务器。希望可以通过远程端口转发的方式在主机 A 和 B 之间建立隧道,然后外网的 Bitbucket 等代码管理服务可以通过 Webhook 的方式访问主机 B 从而触发 Jenkins 服务器中的 Build。这个问题的根源在于我们执行下面的远程端口转发命令后:$ ssh -R 18080:localhost:8080 HostB主机 B 只能监听 localhost 的 18080 端口:如何让 HostB 监听本机所有网络接口的 18080 端口呢? 需要通过修改 SSH 服务器的配置来实现这个功能!在 SSH 服务器的配置文件 /etc/ssh/sshd_config 中添加一行:GatewayPorts yes保存后重启 SSH 服务器,然后重新建立隧道:此时主机 B 已经可以接受外部 webhook 的调用了。动态端口转发相对于动态端口转发,前面介绍的端口转发类型都叫静态端口转发。所谓的 "静态" 是指应用程序服务器端的 IP 地址和监听的端口是固定的。试想另外一类应用场景:设置浏览器通过端口转发访问不同网络中的网站(比如在家里连接公司内网中的站点,哈哈)。这类应用的特点是目标服务器的 IP 和端口是未知的并且总是在变化,创建端口转发时不可能知道这些信息。只有在发送 HTTP 请求时才能确定目标服务器的 IP 和端口。在这种场景下静态端口转发的方式是搞不定的,因而需要一种专门的端口转发方式支持即 "动态端口转发"。SSH 动态端口转发是通过 Socks 协议实现的,创建动态端口转发时 SSH 服务器就类似一个 Socks 代理服务器,所以这种转发方式也叫 Socks 转发。动态端口转发的命令格式为:$ ssh -D <local port> <SSH Server Host>例如:$ ssh -D 11080 nick@xxx.xxx.xxx.xxx注意,命令中不需要指定目标服务器和端口号。执行上面的命令后 SSH 客户端就开始监听本机 localhost 的 11080 端口。你可以把本机上浏览器网络配置中的 Socks 服务器指定为 localhost:11080。然后浏览器中的请求会被转发到 SSH 服务器端,并从SSH 服务器端与目标站点建立连接进行通信。总结SSH 端口转发是一项非常实用的技术,灵活的使用它不仅可以解决工程项目中繁杂的网络问题,还能够给我们的生活添加乐趣!
从 Win10 1809 和 Windows Server 2019 开始 Windows 开始支持 OpenSSH Server。本文介绍一下其基本的概念和配置方法,本文演示用的环境为 Win10 1809(ssh 客户端)和 Windows Server 2019(ssh 服务器)。安装 OpenSSH ServerOpenSSH 客户端程序默认已经被系统安装好了,打开 Settings->Apps->Manage optional features 面板就可以看到:而 OpenSSH Server 默认没有安装,需要用户手动安装。点击上图中的 "Add a feature" 按钮,然后选择 OpenSSH Server,并点击 "Install" 按钮:开启服务安装完成后打开服务管理器,把 OpenSSH Authentication Agent 服务和 OpenSSH SSH Server 服务都设置为自启动,并启动这两个服务:监听端口启动服务后可以通过 netstat 命令查看 SSH Server 服务是不是已经开始监听默认的 22 号端口了:防火墙规则在安装 OpenSSH Server 的时候会在防火墙的入站规则中添加一条记录让防火墙放行对 22 号端口的访问:服务器端的配置文件目录服务器端的配置文件在 C:ProgramDatassh 目录中,注意 C:ProgramData 是一个隐藏目录:安装目录Windows 系统中 OpenSSH 的安装目录为 C:WindowsSystem32OpenSSH,不管是客户端程序还是服务器端程序都这这个目录中:OpenSSH 服务器端程序的默认配置文件 sshd_config_default 也在这个目录中。这个目录会被添加到 PATH 环境变量中:这样就可以在 PowerShell 中直接执行相关的命令而无需写出完整的路径。Win10 自带的 OpenSSH 客户端因为 SSH 客户端所在的目录被添加到了 PATH 环境变量中,在 PowerShell 中可以直接执行 OpenSSH 客户端的命令,比如 ssh:连接远程 Linux 主机使用 ssh 命令连接一下 Linux 主机,笔者的 Linux 主机为 Ubuntu16.04,可以连接,但是欢迎信息显示了两次:查看 ssh 命令的版本为 7.7.2.1:在另外一台机器上用个老一点的版本(7.6.0.0)试了试:没有发现重复输出欢迎信息的问题,判断可能是新版本引入的 bug。连接远程 Windows 主机当 Windows 系统中安装好 OpenSSH Server 并开始监听端口后就可以通过远程的客户端来连接了。连接远程 Windows 主机与连接远程 Linux 主机相同,下面是通过密码登录的方式(nick 是 Windows 系统中的一个本地用户):连接成功后默认的 shell 是 Windows Command shell (cmd.exe) 程序:在 Windows 系统中,PowerShell 已逐渐成为主流,我们可以把默认的 shell 设置为 PowerShell。其实就是在运行 OpenSSH Server 的 Windows 系统的注册表中添加一个配置项,注册表路径为 HKEY_LOCAL_MACHINESOFTWAREOpenSSH,项的名称为 DefaultShell,项的值为 C:WindowsSystem32WindowsPowerShellv1.0powershell.exe。我们可以以管理员身份启动 PowerShell,然后执行下面的命令完成注册表项的添加:> New-ItemProperty -Path "HKLM:SOFTWAREOpenSSH" -Name DefaultShell -Value "C:WindowsSystem32WindowsPowerShellv1.0powershell.exe" -PropertyType String -Force现在重新连接远程服务器,默认的 shell 已经变成了 PowerShell:通过秘钥认证方式登录前面我们介绍的 ssh 命令都是通过密码认证连接服务器的,下面介绍通过秘钥认证的方式登录服务器。ssh-keygen 命令ssh-keygen 命令用来生成公钥认证使用的秘钥对,创建的秘钥一般都和 ssh 客户端的配置一起保存在用户家目录下的 .ssh 目录中(与 Linux 系统中类似):执行 ssh-keygen 命令:> ssh-keygen默认情况下一路回车就可以了,使用默认的文件名称和存放目录:遗憾的是 Windows 下目前还没有提供 ssh-copy-id 命令,需要手动把用户的公钥添加到远程主机系统中的用户的  authorized_keys 文件中。具体在运行 OpenSSH Server 的主机上的操作步骤如下:在用户家目录下创建 .ssh 目录打开 PowerShell,进入用户的家目录,用 mkdir 命令创建 .ssh 目录:> cd ~> mkdir .ssh创建 authorized_keys 文件并加入公钥在 PowerShell 中执行 notepad .sshauthorized_keys 命令创建文本文件,把客户端的公钥复制到这个文件中并保存。把文本文件的名称修改为 authorized_keys:修改 ssh 服务的配置文件以管理员权限打开 PowerShell,执行命令 notepad C:ProgramDatasshsshd_config。注释掉配置文件中的最后两行然后保存:#Match Group administrators# AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys最后在服务管理器器中重启 OpenSSH SSH Server 服务,然后客户端就可以通过公钥认证的方式登录到远程服务器了。注意:一定不要用 Repair-AuthorizedKeyPermission 命令修复 .sshauthorized_keys 文件的权限。也不要以下面的方式创建 .sshauthorized_keys 文件:echo "publickey" > .sshauthorized_keysecho $null > .sshauthorized_keys总结OpenSSH 的支持让系统管理员有了一个方便的工具来管理 Windows 系统,相信 OpenSSH + PowerShell 的组合将成为管理 Windows 系统的黄金搭档。本文只是介绍了一些入门的概念,但给人的感觉是 Windows 上的 OpenSSH 工具尚需打磨(问题挺多的,按照文档配置个公钥认证就把人搞吐了)。参考:PowerShell/Win32-OpenSSHOpenSSH in Windows解决公钥认证问题
SSH 是 Linux 下进行远程连接的基本工具,但是如果仅仅用它来登录那可是太浪费啦!SSH 命令可是完成远程操作的神器啊,借助它我们可以把很多的远程操作自动化掉!下面就对 SSH 的远程操作功能进行一个小小的总结。远程执行命令如果我们要查看一下某台主机的磁盘使用情况,是不是必须要登录到目标主机上才能执行 df 命令呢?当然不是的,我们可以使用 ssh 命令在远程的主机上执行 df 命令,然后直接把结果显示出来。整个过程就像是在本地执行了一条命令一样:$ ssh nick@xxx.xxx.xxx.xxx "df -h"那么如何一次执行多条命令呢?其实也很简单,使用分号把不同的命令隔起来就 OK 了:$ ssh nick@xxx.xxx.xxx.xxx "pwd; cat hello.txt"第一条命令返回的结果: /home/nick这说明用这种方式执行命令时的当前目录就是登陆用户的家目录。第二条命令返回 hello.txt 文件的内容。注意,当命令多于一个时最好用引号括起来,否则在有的系统中除了第一个命令,其它都是在本地执行的。执行需要交互的命令有时候我们需要远程执行一些有交互操作的命令。$ ssh nick@xxx.xxx.xxx.xxx "sudo ls /root"$ ssh nick@xxx.xxx.xxx.xxx "top"这两条命令虽然提示的失败原因不同,但它们有一个共同点:都需要与用户交互(需要 TTY)。所以它们失败的原因也是相同的:默认情况下,当你执行不带命令的 ssh 连接时,会为你分配一个 TTY。因为此时你应该是想要运行一个 shell 会话。但是当你通过 ssh 在远程主机上执行命令时,并不会为这个远程会话分配 TTY。此时 ssh 会立即退出远程主机,所以需要交互的命令也随之结束。好在我们可以通过 -t 参数显式的告诉 ssh,我们需要一个 TTY 远程 shell 进行交互!添加 -t 参数后,ssh 会保持登录状态,直到你退出需要交互的命令。作为总结,我们看看 -t 参数的官方解释:"Force pseudo-terminal allocation.  This can be used to execute arbitrary screen-based programs on a remote machine, which can be very useful, e.g. when implementing menu services.  Multiple -t options force tty allocation, even if ssh has no local tty."好吧,更强悍的是我们居然可以指定多个 -t 参数!执行多行的命令有时候我们可能需要随手写几行简单的逻辑,这也没有问题,ssh 能轻松搞定!你可以用单引号或双引号开头,然后写上几行命令,最后再用相同的引号来结束。那么如果需要在命令中使用引号该怎么办?其实针对类似的情况有一条比较通用的规则,就是混合使用单双引号。这条规则在这里也是适用的:当我们在命令中引用了变量时会怎么样呢?请注意上图中的最后一行,并没有输出我们期望的 nick。这里多少有些诡异,因为如果变量没有被解释的话,输出的应该是 $name 才对。但是这里却什么都没有输出。对于引用变量的写法,可以通过下面的方式保证变量被正确解释:注意,我们在上图的命令中为 bash 指定了 -c 参数。远程执行脚本对于要完成一些复杂功能的场景,如果是仅仅能执行几个命令的话,简直是弱爆了。我们可能需要写长篇累牍的 shell 脚本去完成某项使命!此时 SSH 依然是不辱使命的好帮手(哈哈,前面的内容仅仅是开胃菜啊!)。执行本地的脚本我们在本地创建一个脚本文件 test.sh,内容为:lspwd然后运行下面的命令:$ ssh nick@xxx.xxx.xxx.xxx < test.sh通过重定向 stdin,本地的脚本 test.sh 在远程服务器上被执行。接下来我们我期望能为脚本 test.sh 传递一个参数,为了验证传入的参数,在 test.sh 文件的末尾添加两行:echo $0echo $1然后尝试执行下面的命令:$ ssh nick@xxx.xxx.xxx.xxx < test.sh helloworld$ ssh nick@xxx.xxx.xxx.xxx < "test.sh helloworld"下图显示了执行的结果:看来上面的方法都无法为脚本传递参数。要想在这种情况下(远程执行本地的脚本)执行带有参数的脚本,需要为 bash 指定 -s 参数:$ ssh nick@xxx.xxx.xxx.xxx 'bash -s' < test.sh helloworld在上图的最后两行,输出的是 "bash" 和 "helloworld" 分别对应 $0 和 $1。执行远程服务器上的脚本除了执行本地的脚本,还有一种情况是脚本文件存放在远程服务器上,而我们需要远程的执行它!此时在远程服务器上用户 nick 的家目录中有一个脚本 test.sh。文件的内容如下:lspwd执行下面的命令:$ ssh nick@xxx.xxx.xxx.xxx "/home/nick/test.sh"注意,此时需要指定脚本的绝对路径!下面我们也尝试为脚本传递参数。在远程主机上的 test.sh 文件的末尾添加两行:echo $0echo $1然后尝试执行下面的命令:$ ssh nick@xxx.xxx.xxx.xxx /home/nick/test.sh helloworld真棒,最后两行 "/home/nick/test.sh" 和 "helloworld" 分别对应 $0 和 $1。总结本文通过 demo 演示了 ssh 远程操作的基本方式。这些基本用法将为我们在更复杂的场景中完成各种艰巨的任务打下基础。
SSH 协议用于为 Git 提供远程读写操作,是远程写操作的标准服务。SSH协议语法格式对于拥有 shell 登录权限的用户账号,可以用下面的语法访问 Git 版本库:语法 1 : ssh://[<username>@]<server>[:<port>]/home/xxx/repo1.git语法 2 : [<username>@]<server>:/home/xxx/repo1.git注意 :SSH 协议地址格式可以使用两种不同的写法,第一种是使用 ssh:// 开头的标准的 SSH 协议 URL 写法,第二种是 SCP 格式的写法。SSH 协议标准的 URL 写法稍嫌复杂,但是对于非标准 SSH 端口(非 22)可以直接在 URL 中给出端口号。<username> 是服务器 <server> 上的用户账号,如果省略用户名,则会使用当前登录用户的用户名(配置和使用了主机别名的除外)。<port> 为SSH 协议端口,默认为 22。当使用了非默认端口时,最好使用语法1。当然使用语法2也可以实现,但是要通过 ~/.ssh/config 配置文件设置主机别名。路径 /home/xxx/repo1.git 是服务器中版本库的绝对路径。若用相对路径则是相对于 username 用户的家目录。如果采用口令 认证,必须在每次连接时输入口令。如果采用公钥认证,则不用输入口令。服务器架设方式比较SSH 协议有两种方式来实现 Git 服务。第一种是用标准的 SSH 账号访问版本库。即用户账号可以直接登录到服务器获得 shell。对于这种使用标准 SSH 账号的方式,直接使用标准的 SSH 服务就可以了。第二种实现方式是所有用户都使用同一个专用的 SSH 账号访问版本库,访问时通过公钥认证的方式。虽然所有用户用同一个账号访问,但可以通过在建立连接时所用的不同公钥来区分不同的用户身份。Gitolite 就是实现该方式的服务器软件。标准 SSH 账号和专用 SSH 账号这两种实现方式的区别: 标准 SSHGitolite账号每个用户一个账号所有用户公用同一个账号认证方式口令或公钥认证公钥认证登录到 shell是否安全性差好管理员需要 shell是否版本库路径相对路径或绝对路径相对路径授权方式操作系统中用户组和目录权限通过配置文件授权分支写授权否Gitolite路径写授权否Gitolite假设难易度简单复杂实际上,标准 SSH 也可以用公钥认证的方式实现使用用户公用同一个账号,不过这类似于把一个公共账号的登录口令同时告诉给多个人。具体操作如下:1.    在服务器端创建一个公共账号,例如 sparker。2.    管理员收集需要访问git服务的用户公钥。如 user1.pub,user2.pub。3.    使用 ssh-copy-id 命令将各个 git 用户的公钥远程加入服务器的公钥认证列表中。       3.1.     远程操作,可以使用 ssh-copy-id 命令。                 $ ssh-copy-id -i user1.pub sparker@server                 $ ssh-copy-id -i user2.pub sparker@server       3.2.     如果直接在服务器上操作,则直接将文件追加到 authorized_keys文件中。                 $ cat user1.pub >> ~sparker/.ssh/authorized_keys                 $ cat user2.pub >> ~sparker/.ssh/authorized_keys4.    在服务器端的 sparker 用户主目录下建立 git 库,就可以实现多个用户利用同一个系统账号(sparker)访问 git 服务了。这样做除了不必逐一设置账号,以及用户无须口令认证之外,标准 SSH 部署 git 服务的缺点一个也不少,而且因为无法区分用户,也就无法针对用户进行授权。SSH公钥认证为实现公钥认证,作为认证的客户端一方需要拥有两个文件,即公钥/私钥对。一般情况下,公钥/私钥对文件创建在用户家目录下的 .ssh 目录中。如果用户家目录中不存在 .ssh 目录,说明 SSH 公钥/私钥对尚未创建。可以用下面的命令创建:$ ssh-keygen该命令会在用户家目录下创建 .ssh 目录,并在其中创建两个文件:1.    id_rsa私钥文件,它是基于 RSA 算法创建的,一定要妥善保管不要泄露。2.    id_rsa.pub公钥文件,和 id_rsa 文件是一对儿,该文件作为公钥文件可以公开。创建了自己的公钥/私钥对以后,就可以使用下面的命令,实现无口令登录远程服务器 (即用公钥认证取代口令认证)。$ ssh-copy-id -i .ssh/id_rsa.pub <user>@<server>注意:该命令会提示用户输入 user 在 server 上的 SSH 登录口令。此命令执行成功后,再以 user 用户用 ssh 命令登录 server 远程主机时,不必输入口令即可直接登录。该命令实际上是将 .ssh/id_rsa.pub 公钥文件追加到远程主机 serve r的 user 家目录下的 .ssh/authorized_keys 文件中。检查公钥认证是否生效,通过 ssh 命令连接远程主机,正常的话应该直接登录成功。如果要求输入口令则表明公钥认证配置存在问题。如果 SSH 登录存在问题,可以通过查看服务器端的 /var/log/auth.log 文件进行诊断。SSH主机别名在实际使用中,有时需要使用多套公钥/私钥对,例如:1.    使用默认的公钥访问服务器的 git 账号,可以执行 git 命令,但不能进行 shell 登录。2.    使用特别创建的公钥访问服务器的 git 账号,能够获取 shell,登录后可以对 Git 服务器软件进行升级、维护等操作。3.    访问 Github 使用其他公钥(非默认公钥)。从上面的说明可以看出,用户可能拥有不止一套公钥/私钥对。为了创建不同的公钥/私钥对,在使用 ssh-keygen 命令时就需要通过-f参数指定不同的私钥名称。具体用法如下:$ ssh-keygen -f ~/.ssh/<filename>请将 <filename> 替换为有意义的名称。命令执行完毕后,会在 ~/.ssh 目录下创建指定的公钥/私钥对:文件 <filename> 是私钥,文件 <filename>.pub 是公钥。将新生成的公钥添加到远程主机登录用户家目录下的 .ssh/authorized_keys 文件中,就可以使用新创建的公钥建立到远程主机 <server> 的 <user> 账户的无口令登录。操作如下:$ ssh-copy-id -i .ssh/<filename>.pub <user>@<server>现在用户存在多个公钥/私钥对,那么当执行下面的 ssh 登录命令时,用到的是哪个公钥呢?$ ssh <user>@<server>当然是默认公钥 ~/.ssh/id_rsa.pub。那么如何用新建的公钥连接 server 呢?SSH 的客户端配置文件 ~/.ssh/config可以通过创建主机别名,在连接主机时选择使用特定的公钥。例如 ~/.ssh/config 文件中的下列配置:host abc     user git     hostname abc.xxx.com     port 22     Identityfile ~/.ssh/abc注意,hostname 也可以写成 IP。然后执行下面的 SSH 登录命令:$ ssh abc或者执行 git 命令:$ git clone abc:/home/abc/repo1.git虽然这两条命令各不相同,但是都使用了 SSH 协议,以及相同的主机别名:abc。参考上面在 ~/.ssh/config 文件中建立的主机别名,可以做出如下判断:1.    登录的SSH主机名为 abc.xxx.com。2.    登录时使用的用户名为 git。3.    认证时使用的公钥文件为 ~/.ssh/abc.pub。