个人工具

Quick HOWTO : Ch17 : Secure Remote Logins and File Copying/zh

来自Ubuntu中文

跳转至: 导航, 搜索


介绍

OpenSSH是最流行的文件传输和远程登录Linux应用程序之一,它提供了多种在客户端和服务器之间建立加密的远程终端和文件传输连接的方式。 OpenSSH Secure Copy (SCP) 和 Secure FTP (SFTP) 程序是FTP的安全替代品, 同时Secure Shell (SSH) 常常被用作是TELNET的一个默认替代程序。OpenSSH 并不局限于Linux系统; SSH 和 SCP 客户端可以运行在包括windows在内的绝大多数操作系统上。

SSH加密简介

数据加密通过使用特殊的数学算法来实现,这种算法把数据流中的数据分解以便使其对任何没有相应解密算法的人不可读。通过使用加密密钥,这种密钥被用来改进算法实施加密的方式,数据加密将会变得更加的可靠。只有当你拥有解密密码和相应的解密程序的时候你才能得到恢复原始数据。数据加密帮助人们阻止未授权的用户得到这些数据。SSH通过产生随机私有和公有密钥来实现加密过程。这些密钥通常只会生成一次,但是你还可以重置密钥,尽管这样会降低安全度。 如果要成功的传送加密数据,接收端首先必须拥有一份发送端的公共密钥拷贝。 以下是使用SSH进行数据传输的具体过程。

当你登陆到一个SSH服务器的时候,你将会被提醒在继续下一步之前是否下载服务器的公共密钥。同时你计算机上的SSH客户端密钥也将被上传到服务器。 这样一来,位于SSH连接端的每一台电脑都可以得到其他电脑的密钥,也就意味着这些电脑能够打开其他SSH连接端和“ 通道”发送的加密数据。

Linux中的SSH客户端用户接受到的所有公共密钥和提供这些的密钥的IP地址都存储在一个叫~/.ssh/known_hosts的文件中。当一个密钥和它相对应的IP地址不再匹配时,SSH就判断为出现了错误。 例如,当重新安装操作系统或是升级了SSH应用程序后,这些密钥可能会重置,从而使密钥和IP不匹配。当然,一些骇客行为也可以造成密钥的变更。 为了确保变更的安全性,你从服务器上获得的公有和私有密钥都存储在/etc/ssh/directory文件夹中。

注意: .ssh文件夹是一个隐藏文件夹,所有的隐藏文件夹名和隐藏文件名都以英文句号为前缀。ls -a命令能够显示指定文件夹中所有一般文件和隐藏文件。 ~/符号一般等同于你的个人文件夹并且它在能够被所有的Linux命令所识别。

Linux使用一些其他的密钥文件同样达到匿名登陆和使用SSH和SCP拷贝文件到远程服务器上的功能。这样,SSH连接就成功建立了,然后客户端将自动发送它的公用密钥以使服务器端在下次连接建立时能探测用户存储在个人文件夹中的密钥列表并核对密钥是否匹配。如果匹配,用户将允许登陆。这些文件在创建后同样被存储在你的~/.ssh文件夹中。 id_dsa和id_dsa.pub文件分别是你的私有和公有密钥,而authorized_keys文件存储着你从远程主机上接受的所有被授权的可以使用户匿名登陆他们帐户的公有密钥(更多将在以后讲述)。

开始OpenSSH

OpenSSH将会随Linux系统默认安装。 但是在Ubuntu或是Debian上,你不得不在开始安装系统后手动安装它。 在Ubuntu或是Debian中,使用 apt-get install ssh 命令就能激活SSH安装程序。

因为SSH和SCP是同一个应用程序的组成部分,所以他们共享配置文件以及由相同的启动脚本/etc/init.d/sshd控制。

在Fedora/Redhat中,你可以用chkconfig命令来配置SSH随机启动,而在Ubuntu/Debian中则是sysv-rc-conf命令。

[[email protected] tmp]# chkconfig sshd on

你可以通过运行sshd启动脚本,在系统启动后开启、终止和重启SSH。

[[email protected] tmp]# service sshd start
[[email protected] tmp]# service sshd stop
[[email protected] tmp]# service sshd restart

当你每次对配置文件进行修改后,请记住重新启动SSH进程以便配置生效。

测试SSh的运行状态

你可以使用以下命令来测试SSH是否运行

[[email protected] tmp]# pgrep sshd

你应该可以看到一个正在运行的进程号。

/etc/ssh/sshd_config配置文件

SSH的配置文件是 /etc/ssh/sshd_config。SSH默认监视你所有的NICs并使用TCP端口22。 下面是一小段配置文件内容:

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

#Port 22
#Protocol 2,1

#ListenAddress 0.0.0.0
#ListenAddress ::

SSH 版本 1 和 2

SSH1版虽然在过去运行完善,但是最终还是出现了许多不足。最好的解决方法便是升级到SSH2版。在/etc/ssh/sshd_config配置文件的协议状态中设置2以使SSH2版能够在系统启动时默认运行,当然不要忘记重启SSH使你的改变生效。

#
# File: /etc/ssh/sshd_config
#

Protocol 2

怎么更改SSH监听的TCP端口

如果你担心骇客会通过常用的TCP端口入侵你的电脑,你可以把端口22改成任意一个与系统其他应用程序关联不大的端口,比如端口435。这只是一个最基本防御措施,事实上一些好的网络扫描程序能够探测到SSH运行端口的改变。 你需要按以下步骤设置:

1) 使用netstat加grep命令来确保你的系统没有使用435端口,grep命令用来过滤掉所有不包含435的字符串:

[[email protected] root]# netstat -an | grep 435
[[email protected] root]#

2)系统没有提示意味着我们可以进行下一步。在/etc/ssh/sshd_config文件端口设置行中改变端口号为435,并移除整个代码行前的#符号。如果端口435已经处于活动状态,重新设置一个端口号并再试一次。

Port 435

3) 重新启动SSH:

[[email protected] tmp]# service sshd restart

4) 确保SSH已经通过新的端口在运行:

[[email protected] root]# netstat -an | grep 435
tcp    0    0    192.168.1.100:435    0.0.0.0:*    LISTEN
[[email protected] root]#

在下面我们将学会怎样使用SSH登录系统。

使用SSH登录到一个远程终端

SSH的使用方法与TELNET十分相似。 从另外一个linux电脑登录远程终端,你可以使用ssh命令和-l跟随你要登录的用户名登录。如果没有使用-l你将会用正在使用的用户名登录。下面我们将用一个在你/etc/hosts文件列表里的名为smallfry服务器举几个例子。

如果你是根用户并且希望以smallfry登录,则使用如下命令:

[[email protected] tmp]# ssh smallfry

根用户也可以通过默认端口22以peter为用户名登录到Smallfry服务器:

[[email protected] tmp]# ssh -l peter smallfry

或者通过端口435以用户名@远程服务器名的登录格式登录:

[[email protected] tmp]# ssh -p 435 [email protected]

第一次登录

第一次登录远程主机的时候你将会收到如下提示:远程主机第一次和你的机器连接,建议你在本地存储一份远程主机的SSH身份识别密钥。具体将与如下示例相似:

[[email protected] tmp]# ssh smallfry
The authenticity of host 'smallfry (smallfry)' can't be established.
RSA key fingerprint is 5d:d2:f5:21:fa:07:64:0d:63:1b:3b:ee:a6:58:58:bb.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'smallfry' (RSA) to the list of known hosts. [email protected]'s password:
Last login: Thu Nov 14 10:18:45 2002 from 192.168.1.98
No mail.
[[email protected] tmp]#

密钥将被存储在~/.ssh/known_hosts文件中,当你再次登录远程主机是将不会再面对如上上信息。

因重装Linux而造成的SSH使用错误

如果远程主机上的Linux或是SSH被重新安装,识别密钥将会被重置,本地机器上的SSH客户端将会认为新的密钥与本地存储的密钥列表上的指定值不匹配。SSH客户端将会给出如下错误提示,警告用户可能正受到某种形式的网络攻击。

[[email protected] tmp]# ssh 192.168.1.102
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
5d:d2:f5:21:fa:07:64:0d:63:1b:3b:ee:a6:58:58:bb.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:2
RSA host key for 192.168.1.102 has changed and you have requested strict checking.
Host key verification failed.
[[email protected] tmp]#

如果你确信连接错误的原因是由于系统重装所造成的,你可以编辑的~./ssh/known_hosts文件,移除所有与远程主机有关的信息。然后当你再次通过SSH同远程主机连接时,你将会收到提醒你添加新密钥到~./ssh/known_hosts文件的提示,接着一切访问将会正常化。

安装SSH后禁用Telnet

鉴于SSH在数据加密上的优势和它目前在Linux和Windows上良好广泛的兼容性,你应该优先考虑部署SSH。

SSH服务器不默认安装在Fedora操作系统中。如果你决定禁用一个处于活动状态的Telnet服务器,请参考第16章"Telnet, TFTP, and xinetd" 的具体步骤。

用SSH远程执行需要的命令

SSH一个很棒的功能就是它允许你在登录远程终端后执行单命令语句。你只要把需要远程执行的命令加上引号放在本地服务器ssh命令的末端。在下面的例子中,一个在smallfry服务器的用户想要知道在服务器bigboy上的内核信息,他只要远程运行uname -a 命令。这个命令返回了结果:内核版本信息2.6.8-1.521和这个服务器的名称bigboy。

[[email protected] tmp]# ssh 192.168.1.100 "uname -a"
[email protected]'s password:
Linux bigboy 2.6.8-1.521 #1 Mon Aug 16 09:01:18 EDT 2004 i686 i686 i386 GNU/Linux
[[email protected] tmp]#

这个功能非常有用。你可以和匿名登录一同使用在任何需要的时候了解远程服务器的运行状态 ,我们将会在以后的章节讲述匿名登录。 要了解更加精深详细的内容,比如如何构建像“MRTG”这样的监视程序,请浏览第22章," Monitoring Server Performance"。

SSH Tunneling

You already know that SSH creates an encrypted data session between a client and server. With SSH tunneling the server computer can also receive data from other computers on the client's network over the very same session. The client is configured to listen on a specified TCP port and all data received on that port will be automatically SSH encrypted and relayed to the remote server. It is for this reason that SSH tunneling is also called SSH port forwarding.

There are two types of forwarding:

Local Forwarding: Forwards traffic coming to a local port to a specified remote port. This is also known as outgoing tunneling, as the tunnel is established to the remote server.

Remote Forwarding: Forwards traffic coming to a remote port to a specified local port. This is also known as incoming tunneling, as the tunnel is established from the remote server.

As always it is best to explain these methodologies with some examples.

Local Forwarding

The syntax for local forwarding relies on the -L SSH command line qualifier which is configured like this:

-L bind-address:bind-port:remote-server-address:remote-port

Where the bind-address and bind-port are the IP address and TCP port on which the local computer will listen for connections from its neighbors. If the bind-address isn't listed, then the server will only accept connections from localhost. The remote-server-address and remote-port specify the same options for the remote server.

Note: Sometimes an intermediary relay host for the data can be used. In this case the data passes through an encrypted SSH connection for the part of the journey between the local server and the intermediary. The connection between the intermediary and remote host is not. This is not a security issue when forwarding SSH traffic, which is already encrypted, but it can be so when forwarding unencrypted data such as POP mail, SMTP mail or, telnet.
Intermediaries can be useful especially when the intermediary host is the only host on the local network with access to the remote host.

Here are some explanatory examples:

Example 1: The local computer forwards any connection to its NIC IP address on a specified port to a remote host.

[[email protected] ~]# ssh -L 192.168.1.100:9999:216.10.135.26:22  [email protected]
[email protected]'s password: 
Last login: Sat Mar 17 22:00:50 2007 from 192.168.1.201
[[email protected] ~]#

Here server bigboy is configured to forward any connections its NIC IP address of 192.168.1.100 receives on port 9999 to port 22 on server 216.10.135.26.

The outbound connection to 216.10.135.26 is managed by a separate shell process with the login credentials you specify. In this case the connection will be created on bigboy itself, 192.168.1.100, and will run as user root. This can be tricky, as after executing this command it will appear as if you have logged into bigboy all over again and nothing appears to be happening. Don't be fooled, the new login is shell is the master process for the connection that needs to be created. If you log out, the forwarding will be broken.

This can easily be tested. Using SSH to connect to bigboy on port 9999 actually logs you into the remote server web-003.

[[email protected] ~]# ssh -p 9999 [email protected]
[email protected]'s password: 
Last login: Sat Mar 17 21:56:03 2007 from home.my-web-site.org
[[email protected] ~]#

You can then use the netstat and ps commands to verify that the shell process has been created and that the connection has been established.

[[email protected] ~]# netstat -an | grep 216.10.135.26
tcp   0   0   192.168.1.100:36342   216.10.135.26:22   ESTABLISHED 
[[email protected] ~]#

[[email protected] ~]# ps -ef | grep 216.10.135.26
root     22901 21955  0 13:59 pts/0    00:00:00 ssh -L 192.168.2.200:9999:216.10.135.26:222 -p 222 [email protected]
[[email protected] ~]#

Forwarding can be useful! Let's see some more examples.

Example 2: The local computer forwards any connection to localhost on a specified port, to a remote host via an intermediary server. Connection's to the local computer's NIC on the specified port is not allowed.

[[email protected] ~]# ssh -L localhost:9999:216.10.135.26:22 \
  [email protected] 
[email protected]'s password: 
[[email protected] ~]#

Here server smallfry is configured to local forward any connections its localhost IP address receives on port 9999 to port 22 on a remote server with an IP address of 216.10.135.26. Server bigboy is used as the intermediary.

[[email protected] ~]# ssh -p 9999 localhost
[email protected]'s password: 
Last login: Sat Mar 17 20:11:09 2007 from home.my-web-site.org
[[email protected] ~]#

You can use the netstat command on smallfry and bigboy to verify that connections have been established between bigboy and web-003, and smallfry and bigboy.

[[email protected] ~]# netstat -an | grep EST | grep 192.168.1.100
tcp   0   0   192.168.1.50:40679   192.168.1.100:22   ESTABLISHED 
[[email protected] ~]#
[[email protected] ~]# netstat -an | grep EST | grep 216.10.135.26 
tcp    0   0   192.168.1.100:56236  216.10.135.26:22   ESTABLISHED 
[[email protected] ~]#

SSH connections to the NICs of either bigboy or smallfry fail.

[[email protected] ~]# ssh -p 9999 192.168.1.100
ssh: connect to host 192.168.1.100 port 9999: Connection refused
[[email protected] ~]# ssh -p 9999 192.168.1.50 
ssh: connect to host 192.168.1.50 port 9999: Connection refused
[[email protected] ~]# 

The final example which follows discusses forwarding unencrypted protocols.

Example 3: The local computer forwards any POP mail queries to localhost directly to the remote POP mail server over an SSH tunnel.

[[email protected] ~]# ssh -L 9999:mailserver:110 [email protected]
[email protected]'s password: 
Last login: Sat Mar 17 20:11:09 2007 from home.my-web-site.org
[[email protected] ~]#

In this case an SSH connection is created to mailserver using a shell process owned by user root. The server mailserver then creates an unencrypted POP session (TCP port 110) to itself. The advantage of this configuration is that POP data never leaves the POP server unencrypted.

POP mail users on smallfry can then get their mail over the encrypted link by configuring localhost as the POP mail server in their mail client, and not mailserver.


Remote Forwarding

The syntax for local forwarding relies on the -R SSH command line qualifier which is configured like this:

-R bind-address:bind-port:remote-server-address:remote-port

The syntax is similar to that of the -L option. The bind-address and bind-port are the IP address and TCP port on which the local computer will listen for connections from its neighbors. If the bind-address isn't listed, then the server will only accept connections from localhost. The remote-server-address and remote-port specify the same options for the remote server and are from the remote server's perspective. If you specify localhost as the remote-server-address, SSH will be interpret it to mean the Internet IP address of the remote server.

This can be useful in a number of scenarios. For example, you cannot connect to your office workstation via VPN due to network maintenance, but during this time your workstation still has access to the Internet. Remote forwarding could provide you with access.

Here's another scenario. You are moving into a new Internet data center, all the network gear has been configured, but the installation of the data circuits has been delayed. This has caused the configuration of the servers to be delayed. If one server wired to your network can get access to a server on the Internet, via a wireless card, or otherwise, then remote access to the data center could be achieved using remote forwarding.

Example 1: The local computer forwards any connection to localhost on a specified port to a remote host. Forwarding occurs over a previously established connection from the remote host. If we revisit our scenario where VPN access will be down due to maintenance, the first thing to be done is to configure your workstation at work to establish a remote forwarding SSH session to your home server.

[[email protected] ~]# ssh -R localhost:9999:localhost:22 [email protected]
[email protected]'s password: 
Last login: Sat Mar 17 21:15:36 2007 from 216.10.135.26
[[email protected] ~]# ping localhost
PING bigboy (127.0.0.1) 56(84) bytes of data.
64 bytes from bigboy (127.0.0.1): icmp_seq=1 ttl=64 time=0.091 ms
64 bytes from bigboy (127.0.0.1): icmp_seq=2 ttl=64 time=0.082 ms
64 bytes from bigboy (127.0.0.1): icmp_seq=3 ttl=64 time=0.097 ms
64 bytes from bigboy (127.0.0.1): icmp_seq=4 ttl=64 time=0.078 ms

Here workstation work-001 creates an SSH session to server bigboy at home. It also tells bigboy to use this session to forward data to work-001 when bigboy receives SSH connections to localhost on port 9999. Remember, the remote-server-address of the -R option is from the remote server's perspective (work-001). If you specify localhost as the remote-server-address, SSH will be interpret it to mean the Internet IP address of the remote server.

We have setup a ping session to ensure that there is constant traffic between bigboy and work-001 over the connection so that any intermediary firewall doesn't kill it due to inactivity.

When you arrive home, all you have to do is SSH to localhost on your home system to gain access to your workstation at work.

[[email protected] ~]# ssh -p 9999 [email protected]
[email protected]'s password: 
Last login: Sun Mar 18 15:50:16 2007 from 65.115.71.35
[[email protected] ~]#

As you can see, remote forwarding can be both useful, convenient and productivity enhancing.

Example 2: The local computer forwards any connection to it's NIC on a specified port to a remote host. Forwarding occurs over a previously established connection from the remote host.

This is more fitting for our limited connectivity data center scenario. In this case the local computer can be accessed by anyone on the Internet and it will forward any SSH connections it receives on the specified port to the server in the data center with the wireless access. Here's how it's done:

  • Your local computer may be configured to only accept SSH connections for remote forwarding on the loopback localhost interface. Edit your sshd_config file and make sure the GatewayPorts setting is set to yes.
#
# File: /etc/ssh/sshd_config
#

GatewayPorts yes
Restart the SSH daemon to activate the setting.
[[email protected]  ~]# /etc/init.d/sshd restart
Stopping sshd: [  OK  ]
Starting sshd: [  OK  ]
[[email protected]  ~]#
  • The next step is to establish the remote port forwarding session. Set up a ping if you need constant activity on the link. In this case Internet server is netserver-001.my-web-site.org.
[[email protected] ~]# ssh -R netserver-001.my-web-site.org:9999:localhost:22 [email protected]
[email protected]'s password: 
Last login: Sat Mar 17 21:15:36 2007 from 216.10.135.26
[[email protected] ~]# ping localhost
PING netserver-001 (127.0.0.1) 56(84) bytes of data.
64 bytes from netserver-001 (127.0.0.1): icmp_seq=1 ttl=64 time=0.091 ms
64 bytes from netserver-001 (127.0.0.1): icmp_seq=2 ttl=64 time=0.082 ms
64 bytes from netserver-001 (127.0.0.1): icmp_seq=3 ttl=64 time=0.097 ms
64 bytes from netserver-001 (127.0.0.1): icmp_seq=4 ttl=64 time=0.078 ms
Here workstation datacenter-001 creates an SSH session to Internet server netserver-001. It also tells netserver-001 to use this session to forward data to datacenter-001 when netserver-001 receives SSH connections on any interface IP address (*) on port 9999.
  • Now it's time to test it. From our home server bigboy, we can SSH into server netserver-001 on port 9999 and get access to the data center.
[[email protected]~]# ssh -p 9999 [email protected]
[email protected] netserver-001.my-web-site.org's password: 
Last login: Sun Mar 18 15:50:16 2007 from 65.115.71.35
[[email protected] ~]#

Success! You have saved the day with your ingenuity.

Configuring Forwarding with GUI Clients

You won't always have SSH command line access for the servers at both end of a port forwarding connection. Sometimes a GUI is either easier to use, or is your only option.

Most GUI clients will have SSH forwarding capabilities and it will be configurable on each of your saved connections, not globally. The options to do this should be found under the advanced properties or equivalent tab and with your new Linux command line knowledge, the setup should be relatively easy.

Troubleshooting SSH Port Forwarding

There can be many complications with SSH port forwarding, and they are mostly related to typographical errors. Here are a few symptoms that are easy to overcome:

  • If remote forwarding doesn't work from a remote server, but works from localhost, then make sure you have activated the GatewayPorts setting on your computer. If not, change it, restart the SSH daemon and try again.
  • If you get a message like this stating that the address is already in use, then you may have another port forwarding session already started on the port or the port you intend to use for forwarding is already in use by another application.
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 9999
Could not request local forwarding.
  • "Connection closed" messages like this one could be caused by typing in an incorrect forwarding address.
ssh_exchange_identification: Connection closed by remote host
  • If you are attempting remote forwarding using your server's NIC IP address and get this message, then it could be because the GatewayPorts setting has been disabled. With local forwarding, it could be caused by specifying an incorrect port on which the server should listen.
[[email protected] ~]# ssh -p 9999 192.168.1.100
ssh: connect to host 192.168.1.200 port 9999: Connection refused
[[email protected] ~]

SSH port forwarding is a very useful tool that can provide you with a great deal of versatility when administering your servers. It's always a good thing to remember.

SCP: A Secure Alternative to FTP

From a networking perspective, FTP isn't very secure, because usernames, passwords, and data are sent across the network unencrypted. More secure forms such as SFTP (Secure FTP) and SCP (Secure Copy) are available as a part of the OpenSSH package that is normally installed by default on RedHat and Fedora Core. Remember, unlike FTP, SCP doesn't support anonymous downloads like FTP.

The Linux scp command for copying files has a format similar to that of the regular Linux cp command. The first argument is the source file and the second is the destination file. When copying to or from a remote server, SCP logs in to the server to transfer the data and this therefore requires you to supply a remote server name, username, and password to successfully execute the command. The remote filename is therefore preceded by a prefix of the remote username and server name separated by an @ symbol. The remote filename or directory then follows separated by a colon. The format therefore looks like this:

[email protected]:filename
[email protected]:directoryname

For example, file /etc/syslog.conf on a server with IP address 192.168.1.100 that needs to be retrieved as user peter would have the format [email protected]:/etc/syslog.conf, the entire /etc directory would be [email protected]:/etc/.

Note: You can download an easy-to-use Windows SCP client called WinSCP from http://winscp.vse.cz/eng/

Copying Files To The Local Linux Box

If you understand how scp represents remote filenames, you can start copying files fairly easily. For example, to copy file /tmp/software.rpm on the remote machine to the local directory /usr/rpm use the commands

[[email protected] tmp]# scp [email protected]:/tmp/software.rpm /usr/rpm
[email protected]'s password:
software.rpm                      100% 1011    27.6KB/s   00:00
[[email protected] tmp]#

To copy the file /tmp/software.rpm on the remote machine to the local directory /usr/rpm using TCP port 435, use the commands

[[email protected] tmp]# scp -P 435 [email protected]:/tmp/software.rpm /usr/rpm
[email protected]'s password:
software.rpm                       100% 1011    27.6KB/s   00:00
[[email protected] tmp]#

Copying Files To The Remote Linux Box

Copying files to the local Linux server now becomes intuitive. For examples, to copy file /etc/hosts on the local machine to directory /tmp on the remote server

[[email protected] tmp]# scp /etc/hosts [email protected]:/tmp
[email protected]'s password:
hosts                             100% 1011    27.6KB/s   00:00    
[[email protected] tmp]#

To copy file /etc/hosts on the local machine to directory /tmp on the remote server via TCP port 435, use the commands

[[email protected] tmp]# scp -P 435 /etc/hosts [email protected]:/tmp
hosts                             100% 1011    27.6KB/s   00:00    
[[email protected] tmp]#

SFTP: Another Secure Alternative to FTP

OpenSSH also has the SFTP program, which runs over an encrypted SSH session but whose commands mimic those of FTP. SFTP can be more convenient to use than SCP when you are uncertain of the locations of the files you want to copy, because it has the directory browsing abilities of FTP. Unlike FTP, SFTP doesn't support anonymous logins.

Here is a sample login sequence that logs in, gets help on the available commands and downloads a file to the local server.

[[email protected] tmp]# sftp 192.168.1.200
Connecting to 192.168.1.200...
[email protected]'s password:
sftp> help
Available commands:
cd path                       Change remote directory to 'path'
lcd path                      Change local directory to 'path'
chgrp grp path                Change group of file 'path' to 'grp'
chmod mode path               Change permissions of file 'path' to 'mode'
...
...
sftp> ls
...
...
anaconda-ks.cfg
install.log
install.log.syslog
...
...
sftp> get install.log
install.log                        100%   17KB  39.4KB/s   00:00
sftp> exit
[[email protected] tmp]#

Using SSH and SCP without a password

From time to time you may want to write scripts that will allow you to copy files to a server, or login, without being prompted for passwords. This can make them simpler to write and also prevents you from having to embed the password in your code.

SCP has a feature that allows you to do this. You no longer have to worry about prying eyes seeing your passwords nor worrying about your script breaking when someone changes the password. You can configure SSH to do this by generating and installing data transfer encryption keys that are tied to the IP addresses of the two servers. The servers then use these pre-installed keys to authenticate one another for each file transfer. As you may expect, this feature doesn't work well with computers with IP addresses that periodically change, such as those obtained via DHCP.

There are some security risks though. The feature is automatically applied to SSH as well. Someone could use your account to log in to the target server by entering the username alone. It is therefore best to implement this using unprivileged accounts on both the source and target servers.

The example that follows enables this feature in one direction (from server bigboy to server smallfry) and only uses the unprivileged account called filecopy.

Configuration: Client Side

Here are the steps you need to do on the computer that acts as the SSH client:

1) Generate your SSH encryption key pair for the filecopy account. Press the Enter key each time you are prompted for a password to be associated with the keys. (Do not enter a password.)

[[email protected] filecopy]# ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key
(/filecopy/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in
/filecopy/.ssh/id_dsa.
Your public key has been saved in
/filecopy/.ssh/id_dsa.pub.
The key fingerprint is:
1e:73:59:96:25:93:3f:8b:50:39:81:9e:e3:4a:a8:aa
[email protected]
[[email protected] filecopy]#

2) These keyfiles are stored in the.ssh subdirectory of your home directory. View the contents of that directory. The file named id_dsa is your private key, and id_dsa.pub is the public key that you will be sharing with your target server. Versions other than RedHat/Fedora may use different filenames, use the SSH man pages to verify this.

[[email protected] filecopy]# cd ~/.ssh
[[email protected] filecopy]# ls
id_dsa  id_dsa.pub  known_hosts
[[email protected] .ssh]#

3) Copy only the public key to the home directory of the account to which you will be sending the file.

[[email protected] .ssh]# scp id_dsa.pub [email protected]:public-key.tmp

Now, on to the server side of the operation.

配置 - 服务器端

要把一台电脑当作SSH服务器,你需要做以下几步。

1) 以用户名filecopy登录smallfry。在你的个人文件夹里建立一个以.ssh命名的子目录并用cd命令进入建立的子目录中。

[[email protected] filecopy]# ls
public-key.tmp
[[email protected] filecopy]# mkdir .ssh
[[email protected] filecopy]# chmod 700 .ssh
[[email protected] filecopy]# cd .ssh

2) 用>>重定向符号和cat命令把public-key.tmp文件添加到authorized_keys尾部。 authorized_keys file文件包含一个所有链接终端公共密钥的列表,这些密钥允许你使用Smallfry无密码登录。RedHat/Fedora以外的其他Linux发行版可能使用不同的文件名,你需要使用SSH的帮助手册来确定文件名。

[[email protected] .ssh]# cat ~/public-key.tmp >> authorized_keys
[[email protected] .ssh]# rm ~/public-key.tm

从现在开始你就可以使用ssh和scp以filecopy为用户名无密码登录服务器bigbody到smallfry。

总结

大多数的Linux系统安全书籍都建议用户使用更为安全的SSH和SCP来代替TELNET和FTP。 尽管如此,由于能够提供简便的全球文件和TELNET访问FTP仍然广泛在世界上使用,而且在昂贵的网络设备上比SSH更容易部署。Consider all options when choosing your file transfer and remote login programs and select improved security whenever possible as the long term benefits eventually outweigh the additional cost over time.