Chapter 9. 원격 접속과 파일전송
Remote Connection & File Transfer
INDEX
______________________________________________________
1. Introducing an Example Network
2. Remote Connection History
3. Remote Connection & File Transmission for System V
4. Remote Connection & File Transmission for BSD
5. Remote Connection & File Transmission for Securiy
______________________________________________________
1. 네트워크 관련 용어
■ LAN(Local Area Network)
A network that covers a small area, usually less than a few thousand feet or meters.
■ WAN(Wide Area Network)
A network that can span thousands of miles or kilometers.
[참고] LAN(근거리 통신망, Local Area Network)
LAN[랜]이란 300m 이하의 통신회선으로 연결된 PC, 메인프레임, 워크스테이션 들의 집합을
말한다. LAN은 컴퓨터 사이의 전류나 전파신호가 정확히 전달될 수 있는 거리, 즉 한 기관
의 빌딩 내에 설치된 컴퓨터 장비들을 직원들이 가장 효과적으로 공동 사용할 수 있도록
연결된 고속의 통신망이다.
1970년대 말에서 1980년초 제록스사의 한 연구소에서 LAN에 관한 중요한 업적이 이루어졌
다. 이 연구소에서 이더넷(Ethernet ; 공기가 없는 진공상태의 공간에 전파가 흘러갈 수
있는 물질이 존재한다고 가정하여 지은 독일어 단어 "에테르"에서 따온 말)이라고 이름을
붙인 컴퓨터 연결방법이 처음으로 실용화되었다.
[참고] WAN(광역 통신망, Wild Area Network)
WAN[왠]이란 지리적으로 흩어져 있는 통신망을 의미하는 것으로서 근거리통신망, 즉 LAN과
구별하여 보다 넓은 지역을 커버하는 통신구조를 나타내는 용어로 사용된다. 보통 LAN의
범위는 1개의 빌딩이나 학교, 연구소 및 생산공장 등의 일정 구역내인 것에 반해, WAN은
넓은 지역을 연결하는 네트웍를 지칭하는 것으로 지방과 지방, 국가와 국가, 또는 대륙과
대륙 등과 같이 지리적으로 완전하게 떨어져 있는 장거리 지역 사이를 연결하고 있는 통신
망이다.
광역통신망은 사설망일 수도 있고 임차한 망도 될 수 있지만, 이 용어는 보통 공공망까지
를 포함하는 개념을 내포하고 있다. 지역적으로 LAN과 WAN 사이에 위치하는 중간정도 크기
의 네트웍을 특히 MAN이라고 부른다.
2. 원격접속과 파일전송
Remote Connection & File Transmission History
-----------+----------+--------------+--------------
| System V | BSD | Linux
-----------+----------+--------------+--------------
Remote | telnet | rlogin, rsh | ssh
Connection | | |
| | |
File | ftp | rcp | scp, sftp
Transfer | | |
-----------+----------+--------------+--------------
[참고] 패킷 암호화에 대해서
위의 표에 있는 System V / BSD 계열의 모든 명령어는 패킷을 암호화 시키지 않는 단점을
가지고 있다. 그래서 원격 접속과 파일 전송을 할 때 패킷의 내용을 노출 시킬수 있게 된
다. 그래서 최근에는 ssh, scp, sftp 프로그램과 같이 패킷을 암호화 할수 있는 프로그램
을 권장하고 있다.
[EX] 패킷 암호화 실습
[TERM1] # snoop HOSTA HOSTB
[TERM2] # telnet HOSTB
3. 원격접속 & 파일전송 명령어(System V 계열)
Remote Connection & File Transmission for System V
■ telnet 명령어
■ ftp 명령어
(1). telnet CMD
____________________
telnet - user interface to a remote system using the TELNET
protocol
The telnet utility communicates with another host using the
TELNET protocol. If telnet is invoked without arguments, it
enters command mode, indicated by its prompt, telnet>. In
this mode, it accepts and executes its associated commands.
See USAGE, telnet Commands, below. If it is invoked with
arguments, it performs an open command with those arguments.
If, for example, a host is specified as @hop1@hop2@host, the
connection goes through hosts hop1 and hop2, using loose
source routing to end at host. If a leading ! is used, the
connection follows strict source routing. Note that when
telnet uses IPv6, it can only use loose source routing, and
the connection ignores the !.
Once a connection has been opened, telnet enters input mode.
In this mode, text typed is sent to the remote host. The
input mode entered will be either "line mode", "character at
a time", or "old line by line", depending upon what the
remote system supports.
In "line mode", character processing is done on the local
system, under the control of the remote system. When input
editing or character echoing is to be disabled, the remote
system will relay that information. The remote system will
also relay changes to any special characters that happen on
the remote system, so that they can take effect on the local
system.
In "character at a time" mode, most text typed is immedi-
ately sent to the remote host for processing.
In "old line by line" mode, all text is echoed locally, and
(normally) only completed lines are sent to the remote host.
The "local echo character" (initially ^E) may be used to
turn off and on the local echo. (Use this mostly to enter
passwords without the password being echoed.).
If the "line mode" option is enabled, or if the localchars
toggle is TRUE (the default in "old line by line" mode), the
user's quit, intr, and flush characters are trapped locally,
and sent as TELNET protocol sequences to the remote side. If
"line mode" has ever been enabled, then the user's susp and
eof are also sent as TELNET protocol sequences. quit is then
sent as a TELNET ABORT instead of BREAK. The options toggle
autoflush and toggle autosynch cause this action to flush
subsequent output to the terminal (until the remote host
acknowledges the TELNET sequence); and to flush previous
terminal input, in the case of quit and intr.
While connected to a remote host, the user can enter telnet
command mode by typing the telnet escape character (ini-
tially ^]). When in command mode, the normal terminal edit-
ing conventions are available. Pressing <RETURN> at the
telnet command prompt causes telnet to exit command mode.
(1-1). telnet 명령어 실행 모드
telnet Remote Connection Excution Mode
- 대화형 모드(Interractive Mode)
- 비대화형 모드(Noninterractive Mode)
■ telnet 명령어 실행 모드
(비대화형 모드) # telnet 172.16.8.254
(대화형 모드) # telnet
telnet> open 172.16.8.254
(1-2). 기본사용법
# telnet [호스트이름/아이피] [포트]
(telnet 명령어 사용법)
# telnet 172.16.8.254
# telnet 172.16.8.254 23 (/etc/services 정의)
# telnet solaris254 (/etc/hosts 정의)
[참고] 잘 알려진 서비스 포트(Well-kown Port Number, 0 ~ 1023, 0 ~ 65535)
------------------
포트 서비스명
------------------
20,21 FTP
22 SSH
23 TELNET
25 SMTP
53 DNS
67,68 DHCP(Bootp)
80 WEB
110 POP3
111 sunrpc
123 NTP
143 IMAP
------------------
[참고] telnet 명령어 수행시 암호를 잘못 입력한 경우
# telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SunOS 5.9
login: root
Password: <----- 암호 잘못 입력(암호: k)
Login incorrect
login: <Ctrl + ]> <----- Escape Charater 입력
telnet> quit <----- 'quit' 입력
[참고] telnet 연결 화면시 에러 메세지
■ 상대편 서버의 이름을 잘못 지정한 경우
■ 상대편 서버가 정상적으로 동작하지 않는 경우
■ 상대편 서버로 로그인시 암호가 틀린 경우
■ root 사용자로 로그인시 CONSOLE 변수가 지정이 잘못된 경우
■ 상대편 서버에서 TCP_Wrapper로 막고 있는 경우
■ 상대편 서버의 이름을 잘못 지정한 경우
서버의 도메인을 알수 없을 경우
- /etc/hosts 파일의 정의가 되지 않은 경우
- DNS 서버에 도메인 등록이 되어 있지 않은 경우
----------------------메세지----------------------
# telnet solaris250 <----- /etc/hosts 파일에 solaris250 없음
solaris254: Unknown host <----- 메세지 확인
--------------------------------------------------
■ 서버가 정상적으로 동작하지 않는 경우
- 서버의 아이피를 잘못 지정한 경우
- 서버가 Down 되어져 있는 경우
----------------------메세지----------------------
# telnet 172.16.8.250 <----- 172.16.8.250 아이피가 없음
Trying 172.16.8.250...
telnet: Unable to connect to remote host: Connection refused <----- 메세지 확인
--------------------------------------------------
(주의) 메세지를 받기 위해서는 약 10초~20초 정도를 기다려야 한다.
■ 암호가 틀린 경우
- 로그인시 사용자의 암호를 잘못 입력한 경우
----------------------메세지----------------------
# telnet solaris254
Trying 172.16.8.254...
Connected to solaris254
Escape charater is '^]'
SunOS 5.9
login: user01
Password: <----- 틀린 암호 입력(암호: 12345)
Login incorrect <----- 메세지 확인
--------------------------------------------------
■ root 사용자로 로그인시 CONSOLE 변수가 잘못 지정된 경우
----------------------메세지----------------------
# telnet 172.16.8.254
Trying 172.16.8.254...
Connected to 172.16.8.254.
Escape character is '^]'.
SunOS 5.9
login: root
Password: <----- 정상 암호 입력(암호: knit)
Not on system console <----- 메세지 확인
Connection to 172.16.8.254 closed by foreign host.
--------------------------------------------------
# vi /etc/default/login
......
[수정전]
#CONSOLE=/dev/console
[수정후]
CONSOLE=/dev/console
# telnet localhost
root 사용자로 로그인
(복구 작업)
# vi /etc/default/login
(이전 상태로 복원)
■ TCP_Wrapper에 의해 막힌 경우
# vi /etc/default/inetd
.....
[수정전]
ENABLE_TCPWRAPPERS=NO
[수정후]
ENABLE_TCPWRAPPERS=YES
# pkill -1 inetd
# echo "ALL: ALL" > /etc/hosts.deny
----------------------메세지----------------------
# telnet 172.16.8.254
Trying 172.16.8.254...
Connected to solaris254
Escape charater is '^]'
Connection to solaris254 closed by foreign host. <----- 메세지 확인
--------------------------------------------------
(복구 작업)
# vi /etc/default/inetd
-> 이전 상태로 복원
# rm /etc/hosts.deny
# pkill -1 inetd
(2). ftp CMD
____________________
The ftp command is the user interface to the Internet stan-
dard File Transfer Protocol (FTP). ftp transfers files to
and from a remote network site.
The host and optional port with which ftp is to communicate
may be specified on the command line. If this is done, ftp
immediately attempts to establish a connection to an FTP
server on that host. Otherwise, ftp enters its command
interpreter and awaits instructions from the user. When ftp
is awaiting commands from the user, it displays the prompt
ftp>.
-i Turns off interactive prompting during multiple file
transfers.
(2-1). ftp 명령어 사용법
# ftp [옵션] [호스트이름/아이피] [포트]
ftp> help
ftp> bin (solaris9 default)
ftp> ascii(solaris8 default)
ftp> hash
ftp> prompt
ftp> get filename
ftp> put filename
ftp> mget filename
ftp> mput filename
ftp> quit
ftp> bye
[참고] FTP Client Tools(GUI) - gftp
http://www.sunfreeware.com 다운 받아서 설치하면 된다.
(2-2). ftp 명령어 실습 1
=====HOSTA===== ======HOSTB======
/tmp/uploadfile =====> /tmp
/root <===== /tmp/uploadfile
=============== =================
[그림] 파일 업로드 / 다운로드
# mkfile 10m /tmp/test.solarisXXX
# mkdir /root
# ftp 172.16.8.254
root 사용자로 로그인
ftp> help
■ 업로드/다운로드 포인터 맞추기
■ 편리한 기능 설정
■ 업로드/다운로드
■ 확인 접속 해제
(a). 업로드/다운로드 포인터 맞추기(upload/download pointer)
ftp> lcd /tmp
ftp> cd /tmp
ftp> ls
[참고] 업로드/다운로드 포인터
===== HOSTA ===== ===== HOSTB =====
현재 디렉토리 ----------------> 홈디렉토리
(예) /test /
(b). 편리한 기능 설정(FTP function)
ftp> bin // unix 에서는 보통 bin mode로 동작하기 때문 맞추지 않으면 에러발생
ftp> ascii // text 형태로~
ftp> hash // 8k 단위로 # 표시
ftp> prompt // 대화형 모드
[참고] 파일 전송모드 설정(ascii/bin)
===== HOSTA ===== ===== HOSTB =====
전송모드
File(s) ------------------------>
- ASCII ASCII
- BINARY BINARY
* Binary Files
* Compress Files
* Archive Files
* Encyption Files
[참고] 해쉬 설정(hash)
===== HOSTA ===== ===== HOSTB =====
File(s)
500Mbytes ----------------------->
8k단위 #(Pound) 표시
[참고] 대화형 모드 ON/OFF(prompt)
===== HOSTA ===== ===== HOSTB =====
File(s)
file1, file2 ... ----------------->
업로드/다운로드(y/n)?
(c). 업로드/다운로드(upload/download)
ftp> put test.solarisXXX
ftp> get test.solarisXXX
ftp> mput test.*
ftp> mget test.*
ftp> ls [-al]
ftp> dir [-al]
ftp> bye
ftp> quit
[참고] 자동 파일 업/다운로드 스크립트
/root/shell/auto_ftp.sh
# rcp 172.16.8.254:/root/shell/auto_ftp.sh /test
-------------- auto_ftp.sh 설명 -------------------
#!/bin/ksh
#IP=172.16.8.254
IP=172.16.8.1
USERNAME=user01
PASSWD=user01
PORT=2121
#B_FILE=file_`date +'%m%d'`.tar.gz # Backup File
B_FILE=backup.`date +'%m%d'` # Backup File
ftp -n $IP $PORT << EOF // < redirect stdin , << here documentation
user $USERNAME $PASSWD
bin
hash
prompt
cd c:\a
lcd /root/test
put $B_FILE
EOF
----------------------------------------------------
(2-3). ftp 명령어 실습 2
===== Solaris Server ===== ===== Window Server =====
/source (소스)
|
V
/root/test/backup.0723 =========> c:\a
========================== =========================
[그림] Solaris Server에서 Window Server로 자동 백업 설정
Backup File : /root/test/backup.0723
Windows : 172.16.8.1
Solaris : 172.16.8.254
Windows Backup Directory : C:\a
Function 1) Solaris Backup (/source => /root/test/backup.0723)
Function 2) Solaris->Windows Backup(/root/test/backup.0723->C\a)
(Function1)
# tar cvf /root/test/backup.0723 /source
# crontab -e
0 5 * * 0 tar cvf /root/test/backup.`date +'%m%d'` /source
[EX1] 실습
# mkdir /source
# cp /etc/passwd /source
# cp /etc/hosts /source
# cd /test
# tar cvf backup.0121 /source
(Function2)
# crontab -e
0 6 * * 0 /root/shell/auto_ftp.sh
[EX2] 실습
UNIX Server --------> Window Server
# ftp IP 알ftp
|
+--> auto_ftp.sh
Windows) 알ftp 프로그램 실행 > "서버" > 적당한 정보 입력
* 서버 IP : 121.160.70.XXX
* 홈디렉토리 : c:\a
* [ ] ID 없이 접속 허용
* [ ] 읽기만 허용
* 아이디 / 비밀번호 : user01 / user01
* 포트 : 21
* 허용인원 : 5
UNIX )# vi /test/auto_ftp.sh
IP=121.160.70.148 --> 적당한 IP로 수정
.....
lcd /test # 정보 수정(/root/test -> /test)
cd c:\a # Delete a Line --> 라인 삭제
.....
# chmod 755 auto_ftp.sh
# ./auto_ftp.sh
[참고] UNIX <--> Window 서버 동기화
- auto_ftp.sh 스크립트 사용
- SAMBA 서버 이용
- rsync 서버 이용
(2-4). ftp 관련 파일
■ /etc/ftpd/ftpusers
■ /etc/shells
(a). /etc/ftpd/ftpusers
/etc/ftpd/ftpusers 파일안에는 한개의 라인당 한명의 사용자가 등록 될수 있으면 이 파
일에 등록된 사용자는 FTP로 접속할 수 없다. Solaris 9 버전부터 ftpusers 파일은
/etc/ftpd 디렉토리에 존재하지만 이전버전에서는(Solaris 8 버전 이하) /etc 디렉토리
하위에 존재했었다. 기본 설정 파일을 그대로 사용한다면 시스템 사용자(System Account)
는 FTP로 로그인 할 수 없다. 하지만 일반사용자(예: user01, user02...)는 FTP로 로그인
이 가능하다.
(FTP 서버 사용자 기본 정책)
- root 사용자는 FTP 서버에 접속 불가능
- 일반 사용자는 접속 가능(예: user01, user02....)
# cat /etc/ftpd/ftpusers
root
daemon
bin
sys
adm
lp
uucp
nuucp
.....
[EX] /etc/ftpd/ftpusers 파일 예
# vi /etc/ftpd/ftpusers
root <---- ENV_main.sh에 의해 삭제된 라인 등록
daemon
bin
sys
......
# ftp localhost
220 sun99 FTP server ready.
Name (localhost:root): root <----- root 사용자로 로그인
331 Password required for root.
Password: <----- root 사용자 암호 입력
530 Login incorrect. <----- 메세지 확인
Login failed.
# vi /etc/ftpd/ftpusers
daemon <----- root 사용자 라인 삭제
bin
sys
......
# ftp localhost
root 사용자로 로그인 --> 정상적인 접속이 됨
[참고] /etc/ftpd/ftpusers 파일을 사용한 보안 강화
/etc/ftpd/ftpusers 파일 활용 예
# awk -F: '{print $1}' /etc/passwd > /etc/ftpd/ftpusers
# vi /etc/ftpd/ftpusers
root
....
user01
...
user02
....
#ftpuser # FTP Upload User
....
[참고] /root/shell/ftpusers_limit.sh
(b). /etc/shells
/etc/shells 파일은 FTP 서버에 접속하여 명령어를 실행할때 사용할 수 있는 쉘을 정의 할
수 있다. 한개의 라인에 하나의 쉘을 정의한다. 이 파일은 솔라리스 기본 설치시 존재하지
않는다. 따라서 모든 사용자는 /etc/passwd 파일의 마지막 필드에 존재하는 쉘을 사용하여
FTP 작업을 할수 있다.
====== FTP Client ====== ======== FTP Server ========
# ftp Sever ----------------------> ID/PASS(인증)
user01 * /etc/passwd
user01:--------:/bin/ksh
* /etc/shells
/bin/ksh // FTP 로 접속시 할당 받을 쉘
.... // 다른 서비스도 정의한다.
======================== ============================
/etc/shell 파일의 정의 방식
# cat /etc/shells // 한라인에 한 개의 쉘
/bin/ksh
/bin/csh
/bin/sh
/usr/bin/ksh
.....
[EX] /etc/shells 파일 실습
# touch /etc/shells
# ftp localhost
Connected to localhost.
220 solaris254 FTP server ready.
Name (localhost:root): user01 <----- user01 사용자로 로그인
331 Password required for user01.
Password: <----- user01 사용자 암호 입력
530 Login incorrect. <----- 메세지 확인
Login failed.
ftp> quit <----- 'quit' 입력
# vi /etc/shells
/bin/ksh
# ftp localhost
user01 사용자 로그인
===> user01 사용자 로그인 가능
(시스템 복원)
# rm /etc/shells
4. 원격접속 & 파일전송 명령어(BSD 계열)
Remote Connection & File Transmission for BSD
■ rlogin 명령어
■ rsh 명령어
■ rcp 명령어
(1). r 명령어 동작원리
HOSTA ----> HOSTB
# telnet B Auth(ID/PASS)
# rlogin B Auth(/etc/hosts.equiv, ~/.rhosts) // 인증과 관련된 파일
/etc/hosts.equiv System wild Conf. // 전체 사용자
~/.rhosts System specific Conf. // 개인적인~
____________________ // 하지만 root는 둘다 제외된다.
HOSTA
HOSTA user01
+
/etc/hosts.equiv
~/.rhosts
---------------------
HOSTA
HOSTA +
HOSTA user01
+ user01
+ +
HOSTA ----> HOSTB
# rlogin B Auth(~root/.rhosts)
HOSTA
HOSTA user01
+ +
[EX] .rhosts 파일 생성
# cat > /.rhosts
+ +
<CRTL + D>
# cat /.rhosts
(2). rlogin CMD
____________________
rlogin establishes a remote login session from your terminal
to the remote machine named hostname.
Hostnames are listed in the hosts database, which may be
contained in the /etc/hosts and /etc/inet/ipnodes files, the
Network Information Service (NIS) hosts map, the Internet
domain name server, or a combination of these. Each host has
one official name (the first name in the database entry),
and optionally one or more nicknames. Either official host-
names or nicknames may be specified in hostname.
Each remote machine may have a file named /etc/hosts.equiv
containing a list of trusted hostnames with which it shares
usernames. Users with the same username on both the local
and remote machine may rlogin from the machines listed in
the remote machine's /etc/hosts.equiv file without supplying
a password. Individual users may set up a similar private
equivalence list with the file .rhosts in their home direc-
tories. Each line in this file contains two names: a host-
name and a username separated by a space. An entry in a
remote user's .rhosts file permits the user named username
who is logged into hostname to log in to the remote machine
as the remote user without supplying a password. If the name
of the local host is not found in the /etc/hosts.equiv file
on the remote machine, and the local username and hostname
are not found in the remote user's .rhosts file, then the
remote machine will prompt for a password. Hostnames listed
in /etc/hosts.equiv and .rhosts files must be the official
hostnames listed in the hosts database; nicknames may not be
used in either of these files.
For security reasons, the .rhosts file must be owned by
either the remote user or by root.
The remote terminal type is the same as your local terminal
type (as given in your environment TERM variable). The ter-
minal or window size is also copied to the remote system if
the server supports the option, and changes in size are
reflected as well. All echoing takes place at the remote
site, so that (except for delays) the remote login is tran-
sparent. Flow control using <CTRL-S> and <CTRL-Q> and
flushing of input and output on interrupts are handled prop-
erly.
(2.1) 명령어 사용법
// # rcp source destination
# rlogin hostname
# rlogin -l username hostname (-l : login name)
# rlogin username@hostname
[EX] rlogin 실습
# rlogin localhost
# rlogin 172.16.8.254
# exit
# rlogin -l user01 172.16.8.254
user01 사용자의 인증이 되어 있지 않기 때문에 로그인 시에 인증이 되어야 한다.
$ exit
rlogin : 미리 인증(예:~/.rhosts)이 되어 있지 않으면 접속할 당시에 패스워드를 통해
인증하게 된다.
rsh, rcp : 미리 인증이 되어 있지 않으면 명령어 수행이 되지 않는다.
(3). rsh CMD
____________________
rsh connects to the specified hostname and executes the
specified command. rsh copies its standard input to the
remote command, the standard output of the remote command to
its standard output, and the standard error of the remote
command to its standard error. Interrupt, quit, and ter-
minate signals are propagated to the remote command. rsh
normally terminates when the remote command does.
If you omit command, instead of executing a single command,
rsh logs you in on the remote host using rlogin(1).
rsh will not return the exit status code of command.
Shell metacharacters which are not quoted are interpreted on
the local machine, while quoted metacharacters are inter-
preted on the remote machine. See EXAMPLES.
If there is no locale setting in the initialization file of
the login shell (.cshrc, . . .) for a particular user, rsh
always executes the command in the "C" locale instead of
using the default locale of the remote machine.
(3-1). 명령어 사용법
# rsh hostname CMD
# rsh 172.16.8.254 hostname
# rsh 172.16.8.254 ls -l /tmp
# rsh 172.16.8.254 ls -l /root/docs
(4). rcp CMD
____________________
The rcp command copies files between machines. Each filename
or directory argument is either a remote file name of the
form:
hostname:path
or a local file name (containing no ":" (colon) characters,
or "/" (backslash) before any ":" (colon) characters).
The hostname can be an IPv4 or IPv6 address string. See
inet(7P) and inet6(7P). Since IPv6 addresses already contain
colons, the hostname should be enclosed in a pair of square
brackets when an IPv6 address is used. Otherwise, the first
occurrence of a colon can be interpreted as the separator
between hostname and path. For example,
[1080::8:800:200C:417A]:tmp/file
If a filename is not a full path name, it is interpreted
relative to your home directory on hostname. A path on a
remote host may be quoted using \, ", or ', so that the
metacharacters are interpreted remotely.
rcp does not prompt for passwords; your current local user
name must exist on hostname and allow remote command execu-
tion by rsh(1).
rcp handles third party copies, where neither source nor
target files are on the current machine. Hostnames may also
take the form
username@hostname:filename
to use username rather than your current local user name as
the user name on the remote host. rcp also supports Internet
domain addressing of the remote host, so that:
username@host.domain:filename
specifies the username to be used, the hostname, and the
domain in which that host resides. File names that are not
full path names will be interpreted relative to the home
(4-1). 명령어 사용법
# rcp file1 172.16.8.254:/tmp
# rcp 172.16.8.254:/tmp/file1 /tmp
# rcp -r dir1 172.16.8.254:/tmp
# rcp -r 172.16.8.254:/root/shell /root
# rcp 172.16.8.254:/root/* .
# rcp file1 user01@172.16.8.254:/tmp
[EX] rcp 실습
# rcp -r 172.16.8.254:/root/shell /root
# touch /root/test.solarisXXX
# rcp /root/test.solarisXXX 172.16.8.254:/tmp
# rsh 172.16.8.254 ls -l /tmp
[참고] .rhosts 파일 정책(Policy)
(a). 사용자 홈디렉토리에 .rhosts 파일을 정기적으로 지우는 정책
# find /export/home -name .rhosts -type f -exec rm {} \;
# crontab -e
0 6 * * * find /export/home -name .rhosts -type f -exec rm {} \;
(b). 사용자 홈디렉토리에 .rhosts 파일을 못 만들도록 하는 정책
user01 Home Directory : /export/home/user01
# cd /export/home/user01
# mkdir .rhosts (rwxr-xr-x root other)
# touch .rhosts/.notperm (rw-r--r-- root other)
# chmod 000 .rhosts
# chmod 000 .rhosts/.notperm
--------- /export/home/user01 ---------- (user01:other rwxr-xr-x)
.rhosts 디렉토리 생성(관리자) (root:other rwxr-xr-x)
|
+----------------> 디렉토리 삭제(사용자)
| # rmdir .rhosts
|
.rhosts/.notperm 파일생성(관리자) .rhosts (root:other rwxr-xr-x)
| +-- .notperm(root:other rw-r--r--)
|
+----------------> 디렉토리 삭제(사용자)
# rm -r .rhosts
(사용자 테스트)
# telnet localhost
user01 사용자로 로그인
$ touch .rhosts
touch: cannot change times on .rhosts
$ rmdir .rhosts
rmdir: directory ".rhosts": Directory not empty
$ rm -r .rhosts
rm: cannot read directory .rhosts: Permission denied
$ ls .rhosts
.rhosts: Permission denied
$ cd .rhosts
ksh: .rhosts: permission denied
[참고] 사용자의 환경파일의 내용을 수정하지 못하도록 관리자가 설정
사용자의 홈 : /export/home/user02
/export/home/user02 (root other rwxr-xr-x)
|
+--- .profile (root other rw-r--r--)
|
+--- work (user02 staff rwxr-xr-x)
# cd /export/home
# mv user02 user02.old
# mkdir /export/home/user02
# cd ~user02
# vi .profile
PATH=/bin:/sbin:/usr/bin:/usr/dt/bin:/usr/sbin
export PATH
cd work
# mkdir work
# chown user02:staff work
# telnet localhost
user02/user02
$ pwd
$ id
$ echo $PATH
$ vi ~/.profile
수정가능(X)
:wq!
5. 원격접속 & 파일전송 명령어 (암호화 방식)
Remote Connection & File Transmission for Securiy
■ ssh 명령어
■ scp 명령어
■ sftp 명령어
[SSH 에 대해서]
전형적인 TCP/IP Transport Layer 암호화 메커니즘을 사용하며, 이것은 암호화 엔진을 위
하여 대중적인 Blowfish 또는 정부 지원의 tripe-DES(Data Encryption Standard) 알고리
즘을 사용한다. 암호화 기술의 사용은 상호 작용 세션의 내용이 클라이언트 및 서버 이외
에는 누구에게도 알려지지 않게 한다. 세션 데이터 암호화뿐만 아니라, 식별 및 인증 과
정이 RSA 암호화 기술을 사용하여 암호화 된다. 이것은 사용자이름과 패스워드의 조합이
제 3자에 의해 sniff 될수 없음을 의미 한다.
[SSH 클라이언트 연결 수립과정]
(a). 클라이언트 연결을 요청하기 위해 서버 포트로 연결한다.(default port 22)
(b). 서버는 표준 public RSA 호스트 키(1024 bits)와 매시간 변경되는 다른 RSA 서버키
(768 bits)를 가지고 응답한다. 서버 키가 시간마다 변경되기 때문에, 한 세션의 트
래픽에 대한 키가 crack 되어도, historic 데이터는 여전히 암호화되어 이러한 공격
툴를 제한한다.
(c). 서버는 알지 못하는 호스트로부터 연결을 거부하도록 설정될 수 있지만 기본적으로
모든 클라이언트로 부터 연결을 허용한다.
(d). 만약 연결이 수용되면, 클라이언트는 256비트의 임의 번호로 구성되는 세션 키를 생
성하고 서버가 지원하는 암호화 알고리즘(tripe-DES or Blowfish)을 선택한다.
(e). 클라이언트 RSA를 사용하는 세션키를, 호스트 및 서버 키 모두를 사용하여 암호화하
고 암호화된 키를 서버로 돌려보낸다.
(f). 서버는 세션 키를 해독하여 클라이언트와 서버 사이의 암호화가 사용가능하게 된다.
(g). 만약 기본 인증메커니즘이 선택된다면, 클라이언트는 secure channel을 통해 서버에
대한 사용자 이름과 패스워드를 전달한다.
# ssh -l user01 172.16.8.254 sshd(22)
[client] --------- request connection (port 22) -----------> [server]
generate 256bit <-------- send 1024bit host key & server key -----------
client key (public RSA Key) (Time Based)
--------- send new key ----------->
<-------- request username/password ------------ secure channel
established
--------- send username/password ----------->
<-------- accept or reject connection ------------
[그림] ssh 클라이언트/서버 연결과정
다음 그림은 일반적인 암호화 방식을 나타낸다.
---------- HOSTA ----------- ---------- HOSTB -----------
전송
A ---> 암호화알고리즘 ---> " ----------------> " ---> 복호화알고리즘 ---> A
+3 /2 * 2 -3
A A
| |
Key Key
[그림] 일반적인 암호화 방식
(1). ssh CMD
____________________
ssh (Secure Shell) is a program for logging into a remote
machine and for executing commands on a remote machine. It
is intended to replace rlogin and rsh, and to provide secure
encrypted communications between two untrusted hosts over an
insecure network. X11 connections and arbitrary TCP/IP ports
can also be forwarded over the secure channel.
ssh connects and logs into the specified hostname. The user
must prove his or her identity to the remote machine using
one of several methods depending on the protocol version
used:
SSH protocol version 1
First, if the machine the user logs in from is listed in
/etc/hosts.equiv or /etc/shosts.equiv on the remote machine,
and the user names are the same on both sides, the user is
immediately permitted to log in. Second, if .rhosts or
.shosts exists in the user's home directory on the remote
machine and contains a line containing the name of the
client machine and the name of the user on that machine, the
user is permitted to log in. This form of authentication
alone is normally not allowed by the server because it is
not secure.
The second (and primary) authentication method is the rhosts
or hosts.equiv method combined with RSA-based host authenti-
cation. It means that if the login would be permitted by
$HOME/.rhosts, $HOME/.shosts, /etc/hosts.equiv, or
/etc/shosts.equiv, and if additionally the server can verify
the client's host key (see /etc/ssh_known_hosts in the FILES
section), only then is login permitted. This authentication
method closes security holes due to IP spoofing, DNS spoof-
ing, and routing spoofing.
Note to the administrator: /etc/hosts.equiv, $HOME/.rhosts,
and the rlogin/rsh protocol in general, are inherently
insecure and should be disabled if security is desired.
As a third authentication method, ssh supports RSA-based
authentication. The scheme is based on public-key cryptogra-
phy. There are cryptosystems where encryption and decryption
are done using separate keys, and it is not possible to
derive the decryption key from the encryption key. RSA is
one such system. The idea is that each user creates a
public/private key pair for authentication purposes. The
server knows the public key, and only the user knows the
private key. The file $HOME/.ssh/authorized_keys lists the
public keys that are permitted for logging in. When the user
logs in, the ssh program tells the server which key pair it
would like to use for authentication. The server checks if
this key is permitted, and if so, sends the user (actually
the ssh program running on behalf of the user) a challenge
in the form of a random number, encrypted by the user's pub-
lic key. The challenge can only be decrypted using the
proper private key. The user's client then decrypts the
challenge using the private key, proving that he or she
knows the private key but without disclosing it to the
server.
ssh implements the RSA authentication protocol automati-
cally. The user creates his or her RSA key pair by running
ssh-keygen(1). This stores the private key in
$HOME/.ssh/identity and the public key in
$HOME/.ssh/identity.pub in the user's home directory. The
user should then copy the identity.pub to
$HOME/.ssh/authorized_keys in his or her home directory on
the remote machine (the authorized_keys file corresponds to
the conventional $HOME/.rhosts file, and has one key per
line, though the lines can be very long). After this, the
user can log in without giving the password. RSA authentica-
tion is much more secure than rhosts authentication.
The most convenient way to use RSA authentication may be
with an authentication agent. See ssh-agent(1) for more
information.
If other authentication methods fail, ssh prompts the user
for a password. The password is sent to the remote host for
checking. However, since all communications are encrypted,
the password cannot be seen by someone listening on the net-
work.
SSH protocol version 2
When a user connects using the protocol version 2, different
authentication methods are available. At first, the client
attempts to authenticate using the public key method. If
this method fails, password authentication is tried.
The public key method is similar to RSA authentication
described in the previous section except that the DSA
algorithm is used instead of the patented RSA algorithm. The
client uses his private DSA key $HOME/.ssh/id_dsa to sign
the session identifier and sends the result to the server.
The server checks whether the matching public key is listed
in $HOME/.ssh/authorized_keys and grants access if both the
key is found and the signature is correct. The session iden-
tifier is derived from a shared Diffie-Hellman value and is
known only to the client and the server.
If public key authentication fails or is not available, a
password can be sent encrypted to the remote host for prov-
ing the user's identity. This protocol 2 implementation does
not yet support Kerberos or S/Key authentication.
Protocol 2 provides additional mechanisms for confidential-
ity (the traffic is encrypted using 3DES, Blowfish, CAST128
or Arcfour) and integrity (hmac-sha1, hmac-md5). Notice that
protocol 1 lacks a strong mechanism for ensuring the
integrity of the connection.
Login session and remote execution
When the user's identity has been accepted by the server,
the server either executes the given command, or logs into
the machine and gives the user a normal shell on the remote
machine. All communication with the remote command or shell
will be automatically encrypted.
If a pseudo-terminal has been allocated (normal login ses-
sion), the user can disconnect with ~., and suspend ssh with
~^Z. All forwarded connections can be listed with ~#. If the
session blocks waiting for forwarded X11 or TCP/IP connec-
tions to terminate, ssh can be backgrounded with ~&,
although this should not be used while the user shell is
active, as it can cause the shell to hang. All available
escapes can be listed with ~?.
A single tilde character can be sent as ~~ (or by following
the tilde by a character other than those described above).
The escape character must always follow a newline to be
interpreted as special. The escape character can be changed
in configuration files or on the command line.
If no pseudo tty has been allocated, the session is tran-
sparent and can be used to reliably transfer binary data. On
most systems, setting the escape character to "none" will
also make the session transparent even if a tty is used.
The session terminates when the command or shell in the
remote machine exits and all X11 and TCP/IP connections have
been closed. The exit status of the remote program is
returned as the exit status of ssh.
X11 and TCP forwarding
If the user is using X11 (the DISPLAY environment variable
is set), the connection to the X11 display is automatically
forwarded to the remote side in such a way that any X11 pro-
grams started from the shell (or command) will go through
the encrypted channel, and the connection to the real X
server will be made from the local machine. The user should
not manually set DISPLAY. Forwarding of X11 connections can
be configured on the command line or in configuration files.
The DISPLAY value set by ssh will point to the server
machine, but with a display number greater than zero. This
is normal behavior, because ssh creates a "proxy" X server
on the server machine for forwarding the connections over
the encrypted channel.
ssh will also automatically set up Xauthority data on the
server machine. For this purpose, it will generate a random
authorization cookie, store it in Xauthority on the server,
and verify that any forwarded connections carry this cookie
and replace it by the real cookie when the connection is
opened. The real authentication cookie is never sent to the
server machine (and no cookies are sent in the plain).
If the user is using an authentication agent, the connection
to the agent is automatically forwarded to the remote side
unless disabled on the command line or in a configuration
file.
Forwarding of arbitrary TCP/IP connections over the secure
channel can be specified either on the command line or in a
configuration file. One possible application of TCP/IP for-
warding is a secure connection to an electronic purse.
Another possible application is going through firewalls.
Server authentication
ssh automatically maintains and checks a database containing
identifications for all hosts it has ever been used with.
RSA host keys are stored in $HOME/.ssh/known_hosts in the
user's home directory. Additionally, the file
/etc/ssh_known_hosts is automatically checked for known
hosts. Any new hosts are automatically added to the user's
file. If a host's identification ever changes, ssh warns
about this and disables password authentication to prevent a
trojan horse from getting the user's password. Another pur-
pose of this mechanism is to prevent man-in-the-middle
attacks which could otherwise be used to circumvent the
encryption. The StrictHostKeyChecking option (see below) can
be used to prevent logins to machines whose host key is not
known or has changed.
(1-1). ssh 명령어 사용법
# ssh hostname
# ssh -l username hostname
# ssh username@hostname
(2). sftp CMD
_____________________
The sftp utility is an interactive file transfer program
with a user interface similar to ftp(1) that uses the ssh(1)
command to create a secure connection to the server.
sftp implements the SSH File Transfer Protocol as defined in
IETF draft-ietf-secsh-filexfer. There is no relationship
between the protocol used by sftp and the FTP protocol
(RFC959) provided by ftp(1).
(2-1). sftp 명령어 사용법
sftp 명령어는 ftp 명령어를 기반으로 만들어 졌기 때문에 명령어 형식이 거의 흡사하다.
# sftp 172.16.8.254
# sftp user01@solaris254
[EX] sftp 명령어 실습
# sftp 172.16.8.254
Connecting to 172.16.8.254...
The authenticity of host '192.168.1.200' can't be established.
RSA key fingerprint in md5 is: 66:2c:f0:80:41:26:f7:1f:5d:a3:be:8c:0d:9a:e5:e1
Are you sure you want to continue connecting(yes/no)? yes <----- 'yes' 입력
Warning: Permanently added '192.168.1.200' (RSA) to the list of known hosts.
root@192.168.1.200's password: <----- 암호 입력(암호: knit)
sftp > help <----- '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'
chown own path Change owner of file 'path' to 'own'
help Display this help text
get remote-path [local-path] Download file
lls [ls-options [path]] Display local directory listing
lmkdir path Create local directory
lpwd Print local working directory
ls [path] Display remote directory listing
lumask umask Set local umask to 'umask'
mkdir path Create remote directory
put local-path [remote-path] Upload file
pwd Display remote working directory
exit Quit sftp
quit Quit sftp
rename oldpath newpath Rename remote file
rmdir path Remove remote directory
rm path Delete remote file
!command Execute 'command' in local shell
! Escape to local shell
? Synonym for help
sftp > quit <----- 'quit' 입력
(3). scp CMD
_____________________
The scp utility copies files between hosts on a network. It
uses ssh(1) for data transfer, and uses the same authentica-
tion and provides the same security as ssh(1). Unlike
rcp(1), scp will ask for passwords or passphrases if they
are needed for authentication.
Any file name may contain a host and user specification to
indicate that the file is to be copied to/from that host.
Copies between two remote hosts are permitted.
(3-1). scp 명령어 사용법
scp 명령어는 rcp 명령어를 기반으로 만들어 졌기 때문에 명령어의 형식이 거의 흡사하다.
# scp /tmp/file1 172.16.8.254:/tmp
# scp -r /root/test 172.16.8.254:/tmp
# scp -r 172.16.8.254:/tmp /test
# scp -r file1 user01@172.16.8.254:/tmp
(4). ssh 관련 파일들
- $HOME/.ssh/known_hosts
- $HOME/.ssh/identity
- $HOME/.ssh/identity.pub
- $HOME/.ssh/id_dsa.pub
- $HOME/.ssh/config
- $HOME/.ssh/authorized_keys
- /etc/ssh/ssh_known_hosts
- /etc/ssh/ssh_config
- $HOME/.rhosts
- /etc/hosts.equiv
- /etc/ssh/shosts.equiv
- /etc/ssh/sshrc
- $HOME/.ssh/rc
- $HOME/.ssh/environment
$HOME/.ssh/known_hosts
Records host keys for all hosts the user has logged
into that are not in /etc/ssh_known_hosts. See
sshd(1M).
$HOME/.ssh/identity
$HOME/.ssh/id_dsa
Contains the RSA and the DSA authentication identity
of the user. These files contain sensitive data and
should be readable by the user but not accessible by
others (read/write/execute). Notice that ssh ignores a
private key file if it is accessible by others. It is
possible to specify a passphrase when generating the
key. The passphrase will be used to encrypt the sensi-
tive part of this file using 3DES.
$HOME/.ssh/identity.pub
$HOME/.ssh/id_dsa.pub
Contains the public key for authentication, that is,
the public part of the identity file in human-readable
form. The contents of the $HOME/.ssh/identity.pub file
should be added to $HOME/.ssh/authorized_keys on all
machines where you wish to log in using RSA authenti-
cation. The contents of the $HOME/.ssh/id_dsa.pub file
should be added to $HOME/.ssh/authorized_keys on all
machines where you wish to log in using DSA authenti-
cation. These files are not sensitive and can, but
need not, be readable by anyone. These files are never
used automatically and are not necessary. They are
provided only for the convenience of the user.
$HOME/.ssh/config
This is the per-user configuration file. The format of
this file is described above. This file is used by the
ssh client. This file does not usually contain any
sensitive information, but the recommended permissions
are read/write for the user and not accessible by oth-
ers.
$HOME/.ssh/authorized_keys
Lists the DSA keys that can be used for logging in as
this user. This file is not highly sensitive, but the
recommended permissions are read/write for the user
and not accessible by others.
/etc/ssh/ssh_known_hosts
Systemwide list of known host keys.
/etc/ssh_known_hosts contains RSA keys. This file
should be prepared by the system administrator to con-
tain the public host keys of all machines in the
organization and should be world-readable. The file
contains public keys, one per line, in the following
format, with fields separated by spaces: system name,
number of bits in modulus, public exponent, modulus,
and optional comment field. When different names are
used for the same machine, all such names should be
listed, separated by commas. See sshd(1M).
The canonical system name (as returned by name
servers) is used by sshd(1M) to verify the client host
when logging in. Other names are needed because ssh
does not convert the user-supplied name to a canonical
name before checking the key, to prevent someone with
access to the name servers from being able able to
fool host authentication.
/etc/ssh/ssh_config
Systemwide configuration file. This file provides
defaults for those values that are not specified in
the user's configuration file, and for those users who
do not have a configuration file.
This file must be world-readable.
$HOME/.rhosts
This file is used in .rhosts authentication to list
the host/user pairs that are permitted to log in.
(Notice that this file is also used by rlogin and rsh,
which makes using this file insecure.) Each line of
the file contains a host name (in the canonical form
returned by name servers), and then a user name on
that host, separated by a space. On some machines,
this file may need to be world-readable if the user's
home directory is on an NFS partition, because
sshd(1M) reads it as root. Additionally, this file
must be owned by the user and must not have write per-
missions for anyone else. The recommended permission
for most machines is read/write for the user and not
accessible by others.
Notice that, by default, sshd(1M) will be installed so
that it requires successful RSA host authentication
before permitting .rhosts authentication. If your
server machine does not have the client's host key in
/etc/ssh_known_hosts, you can store it in
$HOME/.ssh/known_hosts. The easiest way to do this is
to connect back to the client from the server machine
using ssh. This will automatically add the host key to
$HOME/.ssh/known_hosts.
$HOME/.shosts
This file is used exactly the same way as .rhosts. The
purpose for having this file is to be able to use
rhosts authentication with ssh without permitting
login with rlogin(1) or rsh(1).
/etc/hosts.equiv
This file is used during .rhosts authentication. It
contains canonical hosts names, one per line. (See
sshd(1M) for the full format description.). If the
client host is found in this file, login is automati-
cally permitted, provided that client and server user
names are the same. In addition, successful RSA host
authentication is normally required. This file should
only be writable by root.
/etc/ssh/shosts.equiv
This file is processed exactly as /etc/hosts.equiv.
This file may be useful to permit logins using ssh but
not using rsh or rlogin.
/etc/ssh/sshrc
Commands in this file are executed by ssh when the
user logs in just before the user's shell or command
is started. See sshd(1M) for more information.
$HOME/.ssh/rc
Commands in this file are executed by ssh when the
user logs in just before the user's shell or command
is started. See sshd(1M) for more information.
$HOME/.ssh/environment
Contains additional definitions for environment vari-
ables. See ENVIRONMENT VARIABLES.