SSH(1)

명칭
ssh - OpenSSH SSH 클라이언트 (리모트 로그인 프로그램)

서식
ssh [-l 로그인명] 호스트명 | 유저@호스트명 [명령]

ssh [-afgknqstvxACNPTX1246] [-b bind 하는 주소] [-c 암호화 옵션] [-e 이스케이프 캐릭터] [-i identity 파일] [-l 로그인명] [-m MAC 지정] [-o 옵션] [-p 포트 번호] [-F 설정 파일] [-L 포트번호: 호스트: 호스트측포트번호] [-R 포트번호: 호스트: 호스트측포트번호] [-D 포트 번호] 호스트명 | 유저@호스트명 [명령]

해설
ssh (SSH 클라이언트)(은)는 리모트 머신에 로그인 하거나 리모트 머신상에서 명령을 실행하기 위한 프로그램입니다. 이것은 rlogin 와 rsh 를 옮겨놓기 위한 것으로, 안전하지 않은 네트워크 위에 있는, 2개의 신뢰되어 있지 않은 호스트간으로, 암호화된 안전한 통신을 제공합니다. X11 의 접속이나 임의의 TCP/IP 포트등도 안전한 통신로를 통해 전송 할 수 있습니다.

ssh (은)는 지정되었다 호스트명 에 접속해, 로그인합니다. 유저는 리모트 머신에 대해서, 본인인 것을 증명할 필요가 있습니다. 이것에는 프로토콜의 버젼에 응해 따분한가 방법중 하나를 사용합니다:

  SSH 프로토콜 버젼 1

최초로, 유저가 리모트 머신상의 /etc/hosts.equiv 혹은 /etc/ssh/shosts.equiv 에 기록되고 있는 머신으로부터 로그인해 와, 한층 더 그 유저의 이름이 양쪽 모두의 호스트로 같으면, 그 유저는 곧 바로 로그인이 허가됩니다. 다음에, .rhosts 혹은 .shosts 하지만 리모트 호스트상의 그 유저의 홈 디렉토리에 존재하고 있어, 거기에 클라이언트 호스트명과 그 호스트상에 있어서의 유저명이 기록되고 있다 행이 존재하면, 그 유저는 로그인이 허가됩니다. 이 형태의 인증은 보통, 이것 단체에서는 서버로부터 허가되지 않습니다. 안전하지 않기 때문입니다.

2번째의 인증 방법은 rhosts 또는 hosts.equiv (을)를 RSA 베이스의 호스트 인증과 조합해 사용하는 것입니다. 이것은, 만약 로그인이 $HOME/.rhosts, $HOME/.shosts, /etc/hosts.equiv, 혹은 /etc/ssh/shosts.equiv 그리고 허가되고 있어, 한층 더 서버측이 클라이언트의 호스트열쇠 ( FILES 섹션의 /etc/ssh/ssh_known_hosts (와)과 $HOME/.ssh/known_hosts 의 항을 참조)를 확인할 수 있는 경우에게만 로그인이 허가됩니다. 이 인증 방법을 사용하면(자) IP 사칭, DNS 사칭 및 경로 사칭에 의한 보안 홀을 막을 수가 있습니다. [관리자에: /etc/hosts.equiv (이)나 $HOME/.rhosts, 그리고 일반적인 rlogin/rsh 프로토콜은 본질적으로 위험하고, 보안를 생각한다면 금지하지 않으면 안됩니다]

3개째의 인증 방법으로서 ssh (은)는 RSA 베이스의 인증을 서포트하고 있습니다. 이 사용 방법은 공개열쇠암호 기술에 근거하고 있습니다: 암호 시스템 속에는, 암호화/복호화(decode)를 각각 다른 열쇠를 사용해 행할 수가 있어 한층 더 복호화(decode)용의 열쇠로부터 암호화용의 열쇠가 추측할 수 없는 것이 있습니다. RSA 는 이러한 암호 시스템의 하나로, 이하와 같은 아이디어로 인증을 행합니다. 우선 각 유저는, 인증을 위한 「비밀열쇠」 「공개열쇠」라고 불리는 열쇠의 대를 만듭니다. 서버는 공개열쇠를 알고 있습니다만, 비밀열쇠 쪽은 유저만이 알고 있는 것으로 합니다. $HOME/.ssh/authorized_keys 파일에는, 로그인이 허가되고 있는 공개열쇠의 일람이 쓰여져 있습니다. 유저가 로그인하고 말이야 있고, ssh 프로그램은, 그 유저가 어느 열쇠를 사용해 인증 하고 싶어할까를 서버에게 전합니다. 서버는 이 열쇠가 용서된다 물건인지 어떤지를 검사해, 만약 용서되고 있다면, 유저 (실제로는 유저를 위해서(때문에) 달리고 있다 ssh 프로그램)에 「챌린지 (도전)」라고 불리는 것을 보냅니다. 이것은 서버측에서 생성된 터무니없는 수로, 유저의 공개열쇠에 의해 암호화되고 있습니다. 이 챌린지는 유저가 가지고 있는 올바른 비밀열쇠에 의해서만 복호화(decode) 할 수가 있습니다. 유저측의 클라이언트는 이 때 챌린지를 비밀열쇠를 사용해 복호화(decode) 해 보이는 것 그리고, 비밀열쇠의 내용을 서버 측에 보이는 것 없이 , 그것을 가지고 있는 것을 서버에 대해 증명합니다.

ssh (은)는 RSA 의 인증 프로토콜을 자동적으로 행합니다. 유저는 ssh-keygen(1) (을)를 사용해 자신의 RSA 열쇠의 대를 만듭니다. 이 프로그램은 비밀열쇠를 유저의 홈 디렉토리내의 $HOME/.ssh/identity 파일에, 공개열쇠를 $HOME/.ssh/identity.pub 파일에 격납합니다. 유저는 다음에 이 identity.pub (을)를 리모트 머신상의 자신의 홈 디렉토리에 있다 $HOME/.ssh/authorized_keys 파일에 카피하지 않으면 안됩니다 ( authorized_keys 파일은 종래의 $HOME/.rhosts 파일에 상당해, 1행 마다 하나의 열쇠를 격납합니다. 각 행은 꽤 길어질 수도 있습니다). 이 후, 유저는 패스워드없이 로그인할 수가 있습니다. RSA 인증은 rhosts 인증보다 훨씬 안전합니다.

RSA 인증을 사용할 때에 가장 편리한 것은 「인증 에이전트」라고 불린다 물건을 사용하겠지요. 자세하게는 ssh-agent(1) 의 메뉴얼 페이지를 봐주세요.

만약 다른 인증 방법이 실패했을 경우, ssh (은)는 유저에게 패스워드를 요구합니다. 이 패스워드는 검사를 위해 리모트 호스트에 보내집니다만, 모든 통신은 암호화되고 있기 (위해)때문에, 네트워크를 도청하고 있는 무엇인가에 따라서 패스워드가 들켜 버리는 일은 없습니다.

  SSH 프로토콜 버젼 2

유저가 버젼 2 의 프로토콜로 접속했을 때에도, 같은 인증 방법이 사용할 수 있게 됩니다. 우선 클라이언트는 최초로 호스트 베이스 인증을 시험하려고 하겠지요. 이것은 PreferredAuthentications 의 기본값에 의합니다. 이 인증에 실패하면(자), 다음은 공개열쇠 인증을 시도합니다. 이것도 안되면 마지막에 키보드 인터랙티브 인증과 패스워드 인증을 시도합니다.

공개열쇠에 의한 방법은 전절에 쓰여져 있는 RSA 인증과 닮아 있어 RSA 또는 DSA 알고리즘을 사용할 수가 있습니다. 클라이언트는 자신의 비밀열쇠이다 $HOME/.ssh/id_dsa 또는 $HOME/.ssh/id_rsa (을)를 사용해 세션 식별자에 서명해, 이 결과를 서버에 보냅니다. 서버는 이것에 대응하는 공개열쇠가 $HOME/.ssh/authorized_keys 파일중에 존재하는지 어떤지 검사해, 만약 쌍방의 열쇠가 존재해, 게다가 그 서명이 올바르면 액세스를 허가합니다. 세션 식별자는 공유 Diffie-Hellman 치에 의해 주어집니다. 이 값을 알 수가 있는 것은 클라이언트와 서버 뿐입니다.

공개열쇠 인증이 실패하든가, 혹은 그것을 사용할 수 없었던 경우, 리모트 호스트에는 그 유저인 것을 증명하는 패스워드를 보낼 수가 있습니다.

더해, ssh 그럼 호스트간 인증이나 챌린지·리스폰스 인증도 서포트하고 있습니다.

한층 더 프로토콜 2 에서는, 은닉성 (통신은 3DES, Blowfish, CAST128 또는 Arcfour 에 의해 암호화됩니다) (이)나 데이터의 개찬을 막는 기구 (data integrity protection) (hmac-sha1, hmac-md5)(이)가 제공되고 있습니다. 프로토콜 1 에서는 통신 내용이 개찬되어 있지 않은 것을 프로텍션하는 것 같은 강력한 메카니즘은 존재하지 않기 때문에 주의해 주세요.

  로그인 세션과 리모트 실행

그 유저가 본인인 것이 확인할 수 있으면(자), 서버는 주어진 명령을 실행하든가, 혹은 유저를 그 머신에 로그인시켜 리모트 머신에서의 표준적인 쉘을 줍니다. 리모트 명령 혹은 쉘에 있어서의 모든 통신은 자동적으로 암호화됩니다.

가상 단말을 할당할 수 있고 있는 경우 (통상의 로그인 세션시), 유저는 이하의 이스케이프 캐릭터를 사용할 수가 있습니다.

가상 단말을 할당할 수 있지 않은 경우, 그 세션은 투과가 됩니다. 그 때문에, 바이너리 데이터에서도 확실히 전송 할 수 있습니다. 대부분의 시스템에서는, 비록 가상 단말을 할당할 수 있고 있는 경우에서도 이스케이프 캐릭터에 “none” (을)를 설정하는 것에 의해, 그 세션을 투과로 할 수가 있습니다.

세션은, 리모트 머신상의 명령나 쉘이 완료해, 모든 X11 나 TCP/IP 접속이 닫혀지면(자) 종료합니다. 이 때의 리모트 프로그램의 종료 상태가 ssh 의 종료 상태가 됩니다.

  이스케이프 캐릭터

가상 단말을 할당할 수 있고 있는 경우, ssh 에서는 이스케이프 캐릭터를 사용했다 기능이 몇개인가 서포트되고 있습니다.

현재 서포트되고 있는 이스케이프 기능 (이스케이프 캐릭터는 디폴트의 ‘~’ (와)과 가정합니다) :

~.  접속을 자른다

~^Z ssh를 백그라운드에 이행 시킨다

~#  지금 전송 되고 있는 접속의 일람을 표시한다

~&  ssh를 백그라운드에 이행시켜, 전송 된 접속 혹은 X11 의 세션이 종료하는 것을 기다려 로그아웃 한다

~?  이스케이프 캐릭터의 일람을 표시한다

~C  명령행을 오픈한다 ( -L (이)나 -R 옵션을 사용하고 있어, 포트 전송을 추가하고 싶은 경우에 유효합니다)

~R  그 접속의 rekeying 를 요구한다 (SSH 프로토콜 버젼 2 로, 게다가 상대가 이것을 서포트하고 있을 때 마셔 유효)

치르다 기호 그 자체를 1회 입력하려면 ~~ (을)를 누르는지, 위에서 진술되고 있는 이외의 캐릭터를 치르다에 잇습니다. 이스케이프 캐릭터는, 항상 개행의 직후에 오지 않으면 특별한 캐릭터란 보여지지 않습니다. 이스케이프 캐릭터는, 설정 파일의 EscapeChar 설정 항목 혹은 명령행의 -e 옵션으로 변경할 수 있습니다.

  X11 와 TCP 의 전송

ForwardX11 항목이 “yes” (으)로 설정되어 있어 (또는 후의 -X 및 -x 옵션을 참조해 주세요), 유저가 X11 를 사용하고 있다 (환경 변수 DISPLAY 하지만 설정되어 있다) 경우, X11 디스플레이에의 접속은 자동적으로 리모트 측에 전송 됩니다. 즉, 쉘 (혹은 명령)로부터 기동된 X11 프로그램은 보는거야 암호화된 통신로를 대로, 본래의 X 서버에의 접속은 로컬 머신상으로부터 되게 됩니다. 유저는 DISPLAY (을)를 수동으로 설정해야 하지는 않습니다. X11 접속의 전송은 명령행 혹은 설정 파일에 의해 설정할 수 있습니다. X11 전송은, 보안를 위험에 처하는 것에 상당하는 일도 있으므로 주의해 주세요.

ssh 에 의해 설정되었다 DISPLAY 의 값은 서버머신상을 가리키게 되어 있습니다만, 디스플레이 번호는 0 보다 큰 값이 되어 있겠지요. 이것은 정상적인 상태입니다. ssh (은)는 암호화된 통신로를 개입시켜 접속을 전송 합니다. 그 때문에, 서버머신상에 X 서버의 “프록시” (을)를 만들므로 이렇게 됩니다.

또, ssh (은)는 서버머신상에서 Xauthority 정보를 자동적으로 준비합니다. ssh (은)는 이 때문에 랜덤인 인증 쿠키를 생성해, 서버측의 Xauthority 에 격납해, 접속이 전송 될 때는 모두 이 쿠키를 갖게한다 같게 합니다. 그리고 접속이 열릴 때, 이것이 진짜의 쿠키와 옮겨진다 같게 합니다. 진짜의 인증 쿠키가 서버 측에 보내지는 것은 결코 없습니다 (해, 암호화되지 않은 채로 쿠키가 보내진다 일도 없습니다).

유저가 인증 에이전트를 사용하고 있는 경우, 그 에이전트에의 접속은 그것이 명령행 혹은 설정 파일로 금지되지 않은 한, 자동적으로 리모트 측에 전송 됩니다.

안전한 통신로를 사용한 임의의 TCP/IP 접속에의 전송은, 명령행 혹은 설정 파일로 지정합니다. TCP/IP 전송의 응용으로서 하나는 전자 예금에의 안전한 접속이 생각됩니다. 그 밖에도 파이어 월을 또 있고로 접속하는 등의 사용 길이 있겠지요.

  서버 인증

ssh (은)는 지금까지 사용한 열쇠 모든 것이 들어가 있는 데이타베이스를 자동적으로 보관 유지해, 검사합니다. 이러한 쳐, 호스트열쇠는 유저의 홈 디렉토리에 있다 $HOME/.ssh/known_hosts 에 격납됩니다. 이것들에 가세해 /etc/ssh/ssh_known_hosts 도 기존의 호스트로서 자동적으로 검사됩니다. 새로운 호스트는, 유저측의 파일에 자동적으로 추가되어 갑니다. 만약 있는 호스트의 열쇠가 지금까지변했을 경우, ssh (은)는 경고를 발표해 패스워드 인증을 금지합니다. 이것은 트로이의 목마가 유저의 패스워드를 훔치는 것을 막기 (위해)때문입니다. 이 구조의 또 하나의 목적은, 어딘가 다른 장소에서 man-in-the-middle 공격이 행해져 암호화가 교묘하게 주고 받아져 버리는 것을 막는 것입니다. StrictHostKeyChecking 설정 항목은 호스트열쇠가 알려지지 않기도 하고, 그것이 변경되고 있었을 경우의 로그인을 막기 위해서(때문에) 사용됩니다.

옵션은 다음과 같습니다:

-a  인증 에이전트의 전송을 금지합니다.

-A  인증 에이전트의 전송을 허가합니다. 이것은 설정 파일에 의해 호스트 마다 지정하는 일도 가능합니다.

-b bind 하는 주소
    복수의 interface나 앨리어스(alias) 된 주소를 가진다 머신상에서, 사용하는 interface를 지정합니다.

-c blowfish|3des|des
    이 세션으로 사용되는 암호화의 방법을 지정합니다. 디폴트에서는 3des 하지만 사용됩니다. 이것이 안전이라고 생각되고 있기 (위해)때문입니다. 3des (트리플 des)(은)는 3개(살)이 다른 열쇠를 사용해 암호화-복호화(decode)-암호화를 행합니다. blowfish (은)는 고속의 블록 암호화 알고리즘으로, 꽤 안전하고, 3des 보다 쭉 고속으로. des (은)는, 3des 암호를 서포트하고 있지 않는, 이미 오래된 프로토콜 1 의 실장과 상호 운용하기 위해서 마셔 서포트되고 있습니다. des 암호는 약하기 때문에, 이 옵션을 사용하는 것은 추천할 수 없습니다.

-c 암호화 옵션
    프로토콜 버젼 2 에서는, 칸마로 단락지은 리스트에 의해, 암호화의 방법을 우선 순위를 붙여 지정할 수가 있습니다. 암호화에 대한 자세한 정보는 암호화 의 항을 봐 주세요.

-e ch|^ch|none
    가상 단말을 사용하는 세션에 있어서의 이스케이프 캐릭터를 지정합니다 (디폴트는 ‘~’ ). 이스케이프 캐릭터는 줄머리에 왔을 때 마셔 인식됩니다. 이스케이프 캐릭터의 후에 닷 (‘’). 하지만 왔을 경우 그 접속은 닫혀져 control-Z 가 왔을 경우에는 그 접속은 중지 됩니다. 이 이스케이프 캐릭터 자신이 계속되었을 때에는, 이 캐릭터가 1회만 보내집니다. 이스케이프 캐릭터를 “none” (으)로 지정하면(자) 모든 이스케이프 기능이 금지되어 세션은 완전하게 투과가 됩니다.

-f  ssh 하지만 명령을 실행하기 직전에, 백그라운드로 이행하도록 지시합니다. 이것은 ssh 에 패스워드 혹은 패스 프레이즈를 입력할 필요는 있지만, 그 명령 자체는 백그라운드에서 실행시키고 싶을 때에 편리합니다. 이것은 -n 옵션도 포함하고 있습니다. 리모트 사이트에서 X11 프로그램을 기동시키는 경우에는, ssh -f host xterm 등과 하는 것이 추천입니다.

-g  리모트 호스트가 전송 된 로컬인 포트에 접속하는 것을 허가합니다.

-i identity 파일
    RSA 인증 혹은 DSA 인증의 차이에 identity (비밀열쇠)를 읽는 파일을 지정합니다. 디폴트는, 프로토콜 버젼 1 의 경우 유저의 홈 디렉토리에 있다 $HOME/.ssh/identity , 프로토콜 버젼 2 의 경우는 $HOME/.ssh/id_rsa 및 $HOME/.ssh/id_dsa (이)가 되어 있습니다. identity 파일은 설정 파일에 의해, 호스트 마다 지정할 수도 있습니다. 복수의 It is possible to have multiple -i 옵션을 지정하는 일도 가능합니다. (설정 파일로 복수의 열쇠를 지정할 수도 있습니다. )

-I 스마트 카드 디바이스
    사용하는 스마트 카드 디바이스를 지정합니다. 인수에는, 유저의 RSA 비밀열쇠를 격납하는 스마트 카드와 ssh 하지만 통신하는데 사용하는 디바이스를 지정합니다.

-k  Kerberos 티켓 및 AFS 토큰의 전송을 금지합니다. 이것은 설정 파일에 의해, 호스트 마다 지정할 수도 있습니다.

-l 로그인명
    리모트 머신상에서 로그인하는 유저명을 지정합니다. 이것은 설정 파일에 의해, 호스트 마다 지정할 수도 있습니다.

-m MAC 지정
    프로토콜 버젼 2 에서는, 칸마로 단락지은 리스트에 의해, 사용하는 MAC (message authentication code, 메세지 인증 코드)를 우선 순위를 붙여 지정할 수가 있습니다. MAC 에 대한 자세한 정보는 MACs 의 항을 봐 주세요.

-n  표준 입력을 /dev/null (으)로부터 리디렉트 하도록(듯이) (즉 표준 입력으로부터의 읽기를 금지한 상태로) 합니다. ssh (을)를 백그라운드에서 달리게 할 때는, 이 옵션이 불가결합니다. 자주 있는 손으로서는, 리모트 머신상에서 X11 의 프로그램을 달리게 할 때 이것을 사용하는 것입니다. 예를 들어, ssh -n shadows.cs.hut.fi emacs & 그리고 emacs 를 시작하면(자), X11 접속은 암호화된 경로를 개입시켜 자동적으로 전송 됩니다. ssh 프로그램은 이 후 백그라운드로 이행하겠지요. (이것은 ssh 하지만 패스워드 혹은 패스 프레이즈를 신 있어 올 때는 사용할 수 없습니다. -f 옵션을 참조해 주세요. )

-N  리모트 명령을 실행하지 않습니다. 이것은 포트 전송만을 행하고 싶은 경우에 편리합니다 (프로토콜 버젼 2 마셔).

-o 옵션
    설정 파일과 같은 형식에서 옵션을 주고 싶을 때에 사용합니다. 이것은 명령행 옵션에서는 지정할 수 없는 옵션을 지정하고 싶을 때에 편리합니다.

-p 포트 번호
    리모트 호스트에 접속하는 포트를 지정합니다. 이것은 설정 파일에 의해, 호스트 마다 지정할 수도 있습니다.

-P  밖을 향한 접속을, 특권 포트가 아닌 포토로부터 치도록(듯이) 합니다. 이것은 파이어 월이 특권 포트로부터의 접속을 금지하고 있을 때 사용됩니다. 이 옵션을 지정하면(자), 낡은 서버에서는 RhostsAuthentication 및 RhostsRSAAuthentication 설정 항목이 오프가 되는 것에 주의해 주세요.

-q  조용한 모드. 모든 경고 메세지나 진단 메세지는 억제됩니다.

-s  리모트측에서 하부조직의 실행을 요구할 경우에 사용됩니다. 하부조직은 SSH2 프로토콜로 실현된 기능이며, 이것을 사용하면(자) SSH 를 다른 어플리케이션 (sftp 등)에의 안전한 통신로로서 이용할 수가 있습니다. 이 경우, 하부조직명은 리모트 명령로서 지정합니다.

-t  강제적으로 가상 단말을 할당합니다. 이것은 리모트 머신상에서 임의의 화면 베이스의 프로그램을 실행할 때 (예를 들어, 메뉴 서비스를 실장할 때 등) 에 매우 편리합니다. 복수의 -t (을)를 붙이면(자), 비록 ssh 하지만 로컬측에서의 단말을 가지고 있지 않은 경우에서도 강제적으로 가상 단말을 할당합니다.

-T  가상 단말의 할당을 금지합니다.

-v  장황 표시 모드. ssh 하지만 진행중의 디버그 메세지를 표시하도록(듯이) 합니다. 이것은 접속이나 인증, 설정의 문제를 디버그 할 경우에 도움이 됩니다. 복수의 -v 옵션을 붙이면(자) 출력이 증가합니다. 최대는 3개입니다.

-x  X11 의 전송을 금지합니다.

-X  X11 의 전송을 허가합니다. 이것은 설정 파일에 의해, 호스트 마다 지정할 수도 있습니다.

-C  모든 데이터를 압축하도록 지시합니다 (표준 입력, 표준 출력, 표준 에러 출력, 전송 된 X11 나 TCP/IP 접속을 포함한다). 압축에 사용되는 알고리즘은 gzip(1) (와)과 같은 것으로, “레벨” 하 CompressionLevel 설정 항목에 의해 제어할 수 있습니다. 압축은, 모뎀 그 외의 늦은 접속에 대해 필요합니다만, 고속의 네트워크에서는 속도가 저하할 뿐입니다. 이 기본값은 호스트간 마다 설정 파일에 쓸 수가 있습니다. Compression 설정 항목을 참조해 주세요.

-F 설정 파일
    유저 마다의 설정 파일에 다른 파일을 지정합니다. 설정 파일이 명령행으로부터 주어졌을 경우, 시스템 전체의 설정 파일 (/etc/ssh/ssh_config) (은)는 무시됩니다. 디폴트에서는, 유저 마다의 설정 파일은 $HOME/.ssh/config (이)가 되어 있습니다.

-L 포트 번호:호스트:호스트측 포토 번호
    주어진 로컬 (클라이언트) 호스트상의 포트가, 주어진 리모트 호스트상의 포트에 전송 되도록(듯이) 합니다 (로컬→리모트의 포트 전송). 이것은 로컬측에서 port 에 listen (접속 받아들이고) 용의 소켓을 할당하는 것으로 행해집니다. 이 포트를 향해 행해진 접속은 항상 안전한 통신로를 경유해 리모트 머신상에 도달해, 거기로부터 host 의 포트 hostport 에 접속되게 됩니다. 포트 전송은 설정 파일에 의해도 지정할 수 있습니다. 특권 포토를 전송 할 수 있는 것은 root 만입니다. IPv6 주소의 경우는, 지정한다 형식이 다릅니다: port/host/hostport

-D 포트 번호
    로컬 호스트 측에 둘 수 있는, 어플리케이션 레벨의 “동적인” 포트 전송을 지정합니다. 이것은 다음과 같이 실현되고 있습니다. 우선 로컬측에서 포트 번호 (을)를 listen 하는 소켓을 할당해 이 포트를 향해 접속이 쳐지면(자), 그 접속은 항상 안전한 통신로에 전송 되도록(듯이) 됩니다. 그리고, 여기서 어플리케이션 프로토콜이 사용되어 그 리모트 머신으로부터 어디로 접속할까를 결정할 수가 있습니다. 현재 SOCKS4 프로토콜이 사용되고 있어 ssh (은)는 SOCKS4 서버와 같이 대접합니다. 특권 포트를 전송 할 수 있는 것은 root 만입니다. 다이나믹 포트 전송은 설정 파일에서도 지정할 수 있습니다.

-R 포트 번호:호스트:호스트측 포토 번호
    주어진 리모트 (서버) 호스트상의 포트가, 주어진 로컬 호스트상의 포트에 전송 되도록(듯이) 합니다 (리모트→로컬의 포트 전송). 이것은 리모트측에서 port 에 listen (접속 받아들이고) 용의 소켓을 할당하는 것으로 행해집니다. 이 포트를 향해 행해진 접속은 항상 안전한 통신로를 경유해 로컬 머신상에 도달해, 여기로부터 host 의 포트 hostport 에 접속되게 됩니다. 포트 전송은 설정 파일에 의해도 지정할 수 있습니다. 특권 포토를 전송 할 수 있는 것은, 리모트 머신상에 root 로서 로그인하고 있을 때 뿐입니다. IPv6 주소의 경우는, 지정하는 형식이 다릅니다: port/host/hostport

-1  ssh 하지만 프로토콜 버젼 1 만을 사용하도록(듯이) 강제합니다.

-2  ssh 하지만 프로토콜 버젼 2 만을 사용하도록(듯이) 강제합니다.

-4  ssh 하지만 IPv4 주소만을 사용하도록(듯이) 강제합니다.

-6  ssh 하지만 IPv6 주소만을 사용하도록(듯이) 강제합니다.

설정 파일
한층 더 ssh (은)는, 설정 정보를 유저마다의 설정 파일 및, 시스템 전체에 걸치는 설정 파일로부터 취득합니다. 이 파일의 형식과 설정 항목은 ssh_config(5) 그리고 설명되고 있습니다.

환경 변수
ssh (은)는 보통 이하의 환경 변수를 설정합니다:

DISPLAY
    환경 변수 DISPLAY (은)는 X11 서버의 장소를 나타내고 있습니다. 이것은 ssh 에 의해, “hostname:n” 그렇다고 하는 형태의 값이 자동적으로 설정됩니다. 여기서 hostname 의 부분은 쉘이 달리고 있는 호스트를 나타내고 있어 n 는 n 1 의 정수입니다. ssh (은)는 X11 접속을 안전한 통신로로 전송 하기 위해서, 이 특별한 값을 사용합니다. X11 의 접속이 안전하지 않게 되어 버리기 (위해)때문에, 유저는 환경 변수 DISPLAY (을)를 스스로 설정해야 하지는 않습니다 (또, 그것을 해 버리면(자) 유저는 인증에 필요한 쿠키를 손으로 카피해야 하게 됩니다).

HOME
    유저의 홈 디렉토리의 패스명이 설정됩니다.

LOGNAME
    환경 변수 USER (와)과 같습니다. 이것은, 이 변수를 사용하는 시스템으로 호환성을 유지하기 위해서(때문에) 설정됩니다.

MAIL
    유저의 메일 박스의 패스명이 설정됩니다.

PATH
    디폴트의 PATH 입니다. 이것은 ssh 의 컴파일시로 지정됩니다.

SSH_ASKPASS
    패스 프레이즈를 입력하고 말이야 있고, ssh 하지만 단말로부터 기동되고 있으면(자) ssh (은)는 패스 프레이즈를 그 단말로부터 요구합니다. ssh 하지만 제어할 수 있는 단말을 가지지 않고, 환경 변수 DISPLAY 및 SSH_ASKPASS 하지만 설정되어 있는 경우, ssh 하 SSH_ASKPASS 에 의해 지정되는 프로그램을 기동해, X11 윈도우를 사용해 패스 프레이즈를 요구합니다. 이것은 ssh (을)를 .Xsession (이)나 거기에 비슷하는 스크립트로부터 호출할 때에 특히 도움이 됩니다. (머신에 따라서는, 이것이 잘 움직이기 위해서(때문에)는 표준 입력을 /dev/null 에 리디렉트 할 필요가 있을지도 모릅니다)

SSH_AUTH_SOCK
    인증 에이전트와 통신하는데 사용되는 Unix 도메인 소켓의 패스를 나타내고 있습니다.

SSH_CLIENT
    접속의 말단에 있는 클라이언트의 식별자입니다. 이 변수에는 스페이스에서 단락지어진 3개의 값이 들어가 있는: 클라이언트의 IP 주소, 클라이언트의 포트 번호, 및 서버의 포토 번호입니다.

SSH_ORIGINAL_COMMAND
    강제 명령이 실행되면(자), 이 변수에는, 원래 지정되어 있던 명령행의 값이 들어옵니다. 여기로부터 본래의 인수를 꺼낼 수가 있습니다.

SSH_TTY
    현재의 쉘 혹은 명령에 할당할 수 있고 있는 tty 의 이름 (단말장치에의 패스)(으)로 설정됩니다. 현재의 세션이 단말을 가지지 않는 경우, 이 변수는 설정되지 않습니다.

TZ  demon가 기동했을 때, 현재의 시간대를 나타내는 타임 존 변수가 설정되어 있으면(자), 그것이 여기에 들어갑니다 (즉 demon는 그 값을 신규의 접속에 건네줍니다).

USER
    로그인하고 있는 유저명으로 설정됩니다.

이것들에 가세해, ssh 하 $HOME/.ssh/environment 파일을 읽어들여, “VARNAME=value” 그렇다고 하는 형식의 행을 환경 변수에 추가합니다.

관련 파일

$HOME/.ssh/known_hosts
    유저가 로그인한 것이 있는 호스트 모든 호스트열쇠를 보관 유지합니다 ( /etc/ssh/ssh_known_hosts 에 있는 것을 제외한다). sshd(8) 도 봐 주세요.

$HOME/.ssh/identity, $HOME/.ssh/id_dsa, $HOME/.ssh/id_rsa
    인증을 위한 identity (비밀열쇠 및 공개열쇠)가 격납되고 있습니다. 각각, 프로토콜 1 의 RSA 인증용, 프로토콜 2 의 DSA 인증용, 프로토콜 2 의 RSA 인증용입니다. 이러한 파일에는 타인에게 보여져선 안 되는 데이터가 들어가 있기 (위해)때문에, 그 유저에게는 읽을 수 있어도, 타인으로부터는 액세스 할 수 없게 해 주세요 (읽어들여/기입/실행 속성 모두). Note that ssh (은)는, 타인에게 액세스 할 수 있게 되어 있다 identity 파일은 무시할테니 주의해 주세요. 열쇠를 작성할 경우에 패스 프레이즈를 지정하는 일도 가능합니다. 이 패스 프레이즈는 파일중을 볼 수 있어야 하는 것이 아닌 부분을, 3DES 를 사용해 암호화하는데 이용됩니다.

$HOME/.ssh/identity.pub, $HOME/.ssh/id_dsa.pub, $HOME/.ssh/id_rsa.pub
    인증을 위한 공개열쇠입니다 (여기에는 identity 파일의 공개할 수 있는 부분이 가독형식에서 격납되고 있습니다). $HOME/.ssh/identity.pub 파일의 내용은, 프로토콜 버젼 1 의 RSA 인증을 사용해 로그인하고 싶은 모든 머신상의 $HOME/.ssh/authorized_keys 파일에 포함되어 있을 필요가 있습니다. 또, $HOME/.ssh/id_dsa.pub 및 $HOME/.ssh/id_rsa.pub 파일의 내용도 같이 프로토콜 버젼 2 의 RSA/DSA 인증을 사용해 로그인하고 싶은 모든 머신상의 $HOME/.ssh/authorized_keys 파일에 포함되어 있을 필요가 있습니다. 이러한 파일은 볼 수 있어도 괜찮기 때문에, 타인이 읽을 수 있도록(듯이) 해 두어도 괜찮습니다 (가, 별로 그렇게 할 필요는 있습니다). 이러한 파일이 자동적으로 사용되는 것은 결코 없습니다. 또, 필요하지도 않습니다. 이것들은 다만 단지 유저의 편의를 도모하기 위해서(때문에) 제공되고 있습니다.

$HOME/.ssh/config
    유저마다의 개인용 설정 파일입니다. 이 파일의 형식과 설정 항목은 ssh_config(5) 그리고 설명되고 있습니다.

$HOME/.ssh/authorized_keys
    이 유저의 로그인에 사용되는 공개열쇠 (RSA/DSA)의 일람입니다. 이 형식은 sshd(8) 의 메뉴얼로 설명되고 있습니다. 이 파일의 가장 간단한 형식은 .pub 공개열쇠 파일과 같은 것입니다. 이것은 특별히 볼 수 있어 맛이 없다고 하는 것은 아닙니다만, 할 수 있으면 이 유저로부터는 읽기/쓰기가 가능해, 타인으로부터는 액세스 불가능한 퍼미션으로 설정해 두는 것이 좋을 것입니다.

/etc/ssh/ssh_known_hosts
    시스템 전체의 known_hosts 파일입니다. 이 파일은 시스템 관리 책임자에 의해 준비되어 그 조직내에서 사용되는 모든 머신용의 공개 호스트열쇠를 격납하게 되어 있을 것입니다. 이 파일은 누구라도 읽을 수 있게 되지 않으면 안됩니다. 이 파일은 1행 마다 다음과 같은 형식에서 공개열쇠를 격납하고 있습니다 ( 각 필드는 스페이스에서 단락지어집니다): 시스템명, 공개열쇠 및 옵션으로서 코멘트용 필드. 동일한 머신에 몇개의 다른 이름이 사용되고 있는 경우는, 그것들은 모두 칸마로 단락지어 열거할 필요가 있습니다. 이 형식은 sshd(8) 메뉴얼 페이지로 설명되고 있습니다.

    sshd(8) 하지만 로그인시에 클라이언트측의 호스트를 검증하는 차이에는, 시스템의 별명 (네임서버가 돌려주는 canonical name)이 사용됩니다. 이외의 이름이 필요한 것은 다음과 같은 이유에 의합니다. ssh (은)는, 열쇠를 검사하기 전에 유저의 지정한 이름을 (DNS 적으로) 정식적 것에 변환한다, 라고 하는 것을 하지 않습니다. 왜냐하면 만약 무엇인가가 네임서버에 장치를 넣으면, 이것을 사용해 호스트 인증을 속이는 것이 가능하게 되어 버리기 때문입니다.

/etc/ssh/ssh_config
    시스템 전체에 걸치는 설정 파일입니다. 이 파일의 형식과 설정 항목은 ssh_config(5) 그리고 설명되고 있습니다.

/etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_rsa_key
    이것들 3개의 파일에는 호스트 비밀열쇠가 격납되고 있습니다. 이것들은, RhostsRSAAuthentication (rhosts-RSA 인증) 및 HostbasedAuthentication (호스트 베이스 인증) 그리고 사용됩니다. 프로토콜 버젼 1 으로 RhostsRSAAuthentication (을)를 사용하는 경우, 호스트열쇠는 root 밖에 읽을 수 없기 때문에 ssh (을)를 setuid root 해 둘 필요가 있습니다. 프로토콜 버젼 2 의 경우, ssh 하 HostbasedAuthentication 의 호스트열쇠의 액세스에 ssh-keysign(8) (을)를 사용합니다. 이것으로, 이 인증 방법을 사용할 때도 ssh (을)를 setuid root 해 둘 필요가 없어집니다. 디폴트에서는 ssh (은)는 setuid root 되고 있지 않습니다.

$HOME/.rhosts
    이 파일은 .rhosts 인증으로 사용되는, 로그인이 허가된 호스트명과 유저의 대의 일람입니다. (이 파일은 rlogin 와 rsh 에서도 사용되므로, 안전하지는 않습니다. ) 파일중의 각 행은 호스트명 (네임서버가 돌려주는 정식적 형식의 것) 및 그 호스트에서의 유저명을 스페이스에서 단락지어 격납합니다. 유저의 홈 디렉토리가 NFS 파티션상에 있는 것 같은 머신에서는, 이 파일은 누구라도 읽어들여 가능하지 않으면 안됩니다. 왜냐하면 sshd(8) (은)는 이것을 root 로서 읽기 때문입니다. 더해, 이 파일은 그 유저의 소유가 아니면 안되어, 다른 사람이 기입해 가능해서는 안됩니다. 대부분의 머신에 있어서의 추천 되는 퍼미션은, 그 유저가 읽고 쓰기 가능해, 다른 사람은 액세스 불가능이라는 것입니다.

    디폴트에서는, sshd(8) 그리고 .rhosts 인증이 허가되려면 , 우선 RSA 호스트 인증에 성공하는 것이 필요하게 되어 있습니다. 서버머신이 /etc/ssh/ssh_known_hosts 의 안에 그 클라이언트의 호스트열쇠를 가지고 있지 않은 경우는, $HOME/.ssh/known_hosts 파일에 격납됩니다. 이렇게 하는데 가장 간단한 방법은, 서버머신으로부터 ssh 를 사용해 클라이언트 머신에 다시 접속하는 것 입니다. 이렇게 하는 것에 의해, 그 호스트열쇠가 자동적으로 $HOME/.ssh/known_hosts 에 추가됩니다.

$HOME/.shosts
    이 파일은 .rhosts (와)과 완전히 똑같이 다루어집니다. 이 파일은, rlogin (이)나 rsh(1) 그럼 로그인할 수 없게 하면서, ssh 그리고 rhosts 인증을 사용할 수 있도록(듯이) 하기 위해서 있습니다.

/etc/hosts.equiv
    이 파일은 .rhosts 인증 그리고 사용됩니다. 여기에는 정식적 호스트명이 각 행에 기재되어 있습니다 (이 형식의 완전한 설명은 sshd(8) 메뉴얼 페이지에 있습니다). 이 파일에 클라이언트 호스트가 실려 있으면(자), 클라이언트측과 서버측의 유저명이 같은 경우에 로그인은 자동적으로 허가됩니다. 보통은 RSA 호스트 인증이 성공하고 나서가 아니면 안됩니다. 이 파일은 root 만이 기입할 수 있도록(듯이) 해 두어야 합니다.

/etc/ssh/shosts.equiv
    이 파일은 /etc/hosts.equiv (와)과 완전히 똑같이 다루어집니다. 이 파일은 ssh (을)를 사용하지만, rsh/rlogin 는 사용하지 않는 유저의 로그인을 허가하는데 편리합니다.

/etc/ssh/sshrc
    이 파일의 명령은, 유저가 로그인해 쉘 (혹은 커멘드) 하지만 개시하기 직전에 ssh 에 의해 실행됩니다. 보다 자세한 정보에 대해서는 sshd(8) 메뉴얼 페이지를 봐 주세요.

$HOME/.ssh/rc
    이 파일의 명령은, 유저가 로그인해 쉘 (혹은 명령)(이)가 개시하기 직전에 ssh 에 의해 실행됩니다. 보다 자세한 정보에 대해서는 sshd(8) 메뉴얼 페이지를 봐 주세요.

$HOME/.ssh/environment
    환경 변수의 추가 정의를 격납합니다. 위의 환경 변수 시에를 봐 주세요.

진단
ssh (은)는 종료 상태로서 리모트 명령의 종료 상태를 돌려줍니다. 에러가 발생했을 경우는 255 를 돌려줍니다.

저자
OpenSSH 는 Tatu Ylonen 에 의한, 프리인 오리지날판 ssh 1.2. 12 릴리스로부터 파생한 것입니다. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt 및 Dug Song 가 많은 버그를 제거해, 새로운 기능을 다시 추가해 OpenSSH 를 만들었습니다. SSH 프로토콜 버젼 1.5 및 2.0 의 서포트는 Markus Friedl 의 공헌에 의하는 것입니다.

일본어 번역
니이야마 유스케 (yusuke at cs . nyu . edu) 2002/6/24 (for 3.3p1)

당메뉴얼 페이지는 씨의 호의에 의해 FreeBSD 일본어 메뉴얼에 수록하고 있습니다. 번역에 대한 의견, 지적이 있으면 니이야마씨 (yusuke at cs . nyu . edu), 및 FreeBSD jpman 프로젝트 <man-jp@jp.FreeBSD.org> 까지 전송해 주세요.

관련 항목
rsh(1), scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), telnet(1), ssh_config(5), ssh-keysign(8), sshd(8) T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen, SSH Protocol Architecture, draft-ietf-secsh-architecture-12.txt, January 2002, work in progress material.