본문으로 바로가기

[Ubuntu] 우분투 ssh/rsa, sftp 설정

category 리눅스/Ubuntu 2013. 7. 29. 23:44

우분투 12.04 설치시 SSH를 설치했다면 바로 설정하면 된다.

설치하지 않았다면 아래와 같이 설치한다.

sudo apt-get install ssh-server

( 서버용이니 클라이언트는 필요없다. )

SSH 설정

sudo vi /etc/ssh/sshd_config

  # 포트설정
  Port 22  

  # 자동로그인파일무시
  IgnoreRhosts yes   

  # root로그인금지
  PermitRootLogin no   

  # sudo(관리자)그룹만로그인가능( 다른유저들도 ssh로그인을 가능하게 하려면 이부분 삭제 )
  AllowGroups sudo    

SFTP 설정

SSH서버를 사용하면 SSH를 이용한 FTP(SFTP)도 사용할 수 있다. 개인이 혼자 사용하는 서버라면 별다른 설정없이 기존의 계정으로 SFTP를 사용할 수 있고 다른 사용자들과 함께 사용하기 위해서는 SFTP를 chroot 하에 설정하여 사용할 수 있다.

SFTP 사용법

접속

sftp 사용자ID@호스트명

SFTP 명령어

  • get : 다운로드
  • mget : 다수의 파일을 다운로드
  • put : 업로드
  • mput : 다수의 파일을 업로드
  • ls : 접속한 SFTP의 파일 목록 출력
  • !ls : 로컬 서버의 파일 목록 출력
  • !{명령어} : 로컬 서버에서 실행

SFTP chroot 설정

정확한 설정법은 아직 모르겠다. 아래의 내용은 성공한 구성은 아니다. 참고만 하길...

1. SFTP 사용자들을 위한 전용 그룹 생성

sudo groupadd sftpusers

2. SFTP 사용자 추가

사용자 tiffiny의 로그인그룹을 sftpusers로 지정하고 shell 로그인이 불가능한 nologin 지정

sudo useradd -G sftpusers -s /sbin/nologin tiffiny

3. 패스워드 입력

sudo passwd tiffiny

우분투 12.04 에서는 /etc/default/useradd 의 설정내용이 SHELL 을 제외한 다른 부분들이 모두 주석처리 되어 있다. 그래서 인지 사용자를 추가해도 홈디렉토리및 기타파일들이 생성되지 않는다. 불필요한 파일들이 생성되지 않는 것은 좋으나 이것때문에 잠시 또 삽질을 하게 되었다.

4. 사용자 홈디렉토리 생성

sudo mkdir /home/tiffiny

5. 소유권설정 및 권한설정

우선 tiffiny 디렉토리 이하에 생성될 파일들에 대한 소유권을 위와 같이 설정

sudo chown -R tiffiny.sftpusers /home/tiffiny

각 사용자들의 홈 디렉토리 자체는 소유자 및 소유그룹이 모두 root여야 한다

sudo chown root.root /home/tiffiny

6. SSH 설정

sudo vi /etc/ssh/sshd_config

  Subsystem sftp internal-sftp
  Match group sftpusers
    ChrootDirectory /home/%u
    ForceCommand internal-sftp

위의 설정대로 해보았는데 안된다... 왜일까?

그 밖의 설정방법을 링크한다. > Centos SFTP설정

RSA key를 이용한 로그인

일반 패스워드를 사용하는 로그인 방식보다 rsa 키를 이용한 접속이 보다 보안에 좋다. 그리고 일단 한번 설정해 놓으면 편하다.

우선 ssh 서버설정에서 rsa키 사용에 대한 설정이 제대로인지 살펴본다.

sudo vi /etc/ssh/sshd_config 

  PubkeyAuthentication yes
  RSAAuthentication yes

authorized_keys 와 authorized_keys2 두개가 등장하여 구글링해보니 과거 OpenSSH 3.0 이하에서 authorized_keys2 존재를 발견할수 있었다. OpenSSH 쪽에서는 현재 모든 키를 authorized_keys 에 키를 작성하도록 하고 있으며 authorized_keys2는 단지 과거의 방식에 대한 대체수단일뿐 이며 이는 언제든지 지원하지 않을 수 있다는 것이다.

개인키는 클라이언트쪽에서 생성하고 서버쪽으로 공개키만을 전송하는 것이 보안상 좋다.

참고 : http://marc.info/?l=openssh-unix-dev&m=100508718416162&w=2