믕이의 버그 생존일지

AWS EC2 또는 다른 서버에 SSH로 접속할 때, 비활성 상태로 인해 client_loop: send disconnect: Broken pipe 오류가 발생할 수 있습니다.

이런 오류는 유휴 상태(사용자가 명령을 입력하거나 데이터를 송수신하지 않는 상태)에서 연결이 자동으로 끊어질 때 발생합니다.

이러한 문제를 방지하기 위해서는 SSH 설정 파일에 주기적으로 서버에 신호를 보내도록 설정하여 연결을 유지할 수 있습니다.

설정 방법

1. SSH 설정 파일 열기(vi 또는 nano로 파일 열기)

vi ~/.ssh/config

2. 설정 추가 - 설정 파일이 없을 경우 새로 만들어서 추가하세요.

Host *
ServerAliveInterval 60
ServerAliveCountMax 3
TCPKeepAlive yes

• Host * : 모든 호스트에 대해 설정을 적용
• ServerAliveInterval 60 : 60초마다 서버에 신호를 보내 연결을 유지
• ServerAliveCounMax 3 : 서버가 응답하지 않으면 최대 3번까지 신호를 보내고 그 이후에도 응답이 없으면 연결 종료
• TCPKeepAlive yes : TCP 연결을 유지하도록 설정하고 네트워크 라우터가 유휴 연결을 강제로 종료하지 않도록 함

3. 파일 저장 및 종료

• ESC 키를 누른 후 :wq 명령어로 저장하고 편집기를 종료합니다.

이 설정을 적용하면 SSH 연결이 더 안정적으로 유지되며, ASW EC2와 같은 원격 서버에서 Broken Pipe 오류가 발생할 가능성이 줄어듭니다.

리눅스 서버에 Apache Tomcat을 설치한 후, 웹 브라우저에서 ip주소:8081(자신이 설정한 포트 번호)로 접속하면 톰캣 메인 화면은 정상적으로 표시됩니다.

하지만 Server Status, Manager App, Host Manager 등을 클릭하면 403 Access Denied 오류가 발생할 수 있습니다.

1. tomcat-users.xml 설정 변경

파일 경로

apache-tomcat-10.1.33/conf/tomcat-users.xml

 

설정 내용

vi 또는 nano 편집기로 파일을 열고 아래 내용을 추가합니다:

  <tomcat-users xmlns="http://tomcat.apache.org/xml"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
              version="1.0">
  
  <role rolename="admin"/>
  <role rolename="admin-gui"/>
  <role rolename="admin-script"/>
  <role rolename="manager"/>
  <role rolename="manager-gui"/>
  <role rolename="manager-script"/>
  <role rolename="manager-jmx"/>
  <role rolename="manager-status"/>
  <user username="admin" password="admin" roles="admin,manager,admin-gui,admin-script,manager-gui,manager-script,manager-jmx,manager-status"/>

 

이 설정은 Tomcat 서버의 tomcat-users.xml 파일에서 사용되는 사용자 및 역할(role)을 정의하는 부분입니다. Tomcat 사용자 인증을 설정하기 위해 사용되며, 주로 관리자 페이지나 애플리케이션 배포 및 관리에 대한 접근 권한을 설정하는 데 사용됩니다.

• role 태그: 사용자 역할을 정의합니다.
• user 태그: 사용자 계정과 비밀번호를 설정하고, 역할을 지정합니다.

Role 이름	설명
admin	관리자의 기본 역할입니다.
admin-gui	관리자 GUI 페이지에 접근할 수 있는 권한입니다.
admin-script	스크립트 기반 관리자 기능을 사용할 수 있는 권한입니다.
manager	관리자 역할의 일부지만, 구체적으로 세분화된 역할을 대신 사용합니다.
manager-gui	Manager GUI 페이지에 접근하여 애플리케이션을 배포하거나 관리할 수 있습니다.
manager-script	스크립트를 통해 애플리케이션 배포 및 관리 작업을 수행할 수 있습니다.
manager-jmx	JMX를 통해 Tomcat 서버를 모니터링할 수 있는 권한입니다.
manager-status	서버 상태 확인 페이지에 접근할 수 있는 권한입니다.

 

---

2. context.xml 설정 변경

webapps 디렉터리로 이동 후, 다음 명령어로 context.xml 파일들을 찾습니다.

cd apache-tomcat-10.1.33/webapps
find . -name context.xml

 

아래와 같은 경로에서 context.xml 파일을 수정해야 합니다:

• ./docs/META-INF/context.xml
• ./examples/META-INF/context.xml
• ./host-manager/META-INF/context.xml
• ./manager/META-INF/context.xml

설정 변경

각 context.xml 파일을 열고 다음 내용을 수정합니다:

• vi docs/META-INF/context.xml
• vi examples/META-INF/context.xml
• vi host-manager/META-INF/context.xml
• vi manager/META-INF/context.xml

#이 부분을
allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" />

# 이렇게 변경(모든 IP 주소에 접근을 허용하는 설정)
allow=".*" />

---

3. 톰캣 재시작 및 접속 확인

설정을 변경한 후, 톰캣을 재시작합니다.

 

톰캣 재시작 명령어

apache-tomcat-10.1.33/bin/./shutdown.sh
apache-tomcat-10.1.33/bin/./startup.sh

 

포트 확인

톰캣이 정상적으로 실행되고 있는지 확인합니다.

netstat -ntpa | grep LISTEN

 

출력

tcp6       0      0 :::8081                 :::*                    LISTEN      25210/java

8081 포트가 LISTEN 상태라면 정상적으로 실행되고 있는 것입니다.

---

4. 결과 확인

웹 브라우저에서 ip주소:8081로 접속한 후 확인해 보세요. 이러한 알림 창이 뜰 경우 tomcat-users.xml에서 설정했던 username과 password를 입력하시면 됩니다.

• Server Status

• Manager App

• Host Manager

 

---

참고 블로그 : https://hwpform.tistory.com/129

문제 발생

- 깃풀(git pull)을 실행한 후, 로컬 서버 디렉토리에서 빌드하여 .war 파일을 생성하였고 .war 파일을 Tomcat 웹앱 디렉토리로 복사하려는데 다음과 같은 문제가 발생했습니다.

- SSH 키의 passphrase를 입력했지만 비밀번호가 일치하지 않는지 인증을 거부했다는 경고만 떴습니다.

* 패스프레이즈(passphrase)**는 개인 SSH 키를 생성할 때 설정한 비밀번호

해결방법

1. 경로 확인

먼저 /tmp/private_key.pem 경로에 실제로 파일이 존재하는지 확인해야 합니다.

경로가 올바른지, 그리고 해당 파일이 존재하는지 확인해보았지만 경로도 일치했고 파일도 존재했습니다.

2. 새로운 SSH 키 생성

여러 시도를 해봤지만 실패를 거듭하며 ssh키를 새롭게 생성하기로 결정했습니다.

ssh-keygen -t rsa -b 2048 -f ~/.ssh/키파일_이름

• -t rsa : RSA 알고리즘을 사용하여 키를 생성합니다.
• -b 2048 : 2048비트 길이의 키를 생성합니다.
• -f ~/.ssh/키파일_이름 : 키 파일의 저장 경로와 파일명을 지정합니다.

패스프레이스 입력
ssh 키를 생성하면 passphrase를 입력하라고 하는데 설정하지 않으려면 비워 두고 Enter를 누르시면 됩니다.
저는 보안을 위해서 입력을 하고 메모장에 잘 적어두었습니다.
참고로 5자리 이상을 입력하셔야 됩니다. 

키를 새롭게 생성하면 키 지문(Fingerprint) 과 랜덤 아트(Randomart) 이미지가 나타납니다.

---

3. 새롭게 생성된 공개 키 확인하기

cat ~/.ssh/키파일_이름.pub

명령어를 입력하면 아래와 같이 나올 텐데 전부 복사해 주세요.

ex ) ssh-rsa EAdoWKEFJO@#$NMASM ... ec2-user@아이피주소.AWS 리전.프라이빗 도메인

---

4. 기존 .pem 파일로 EC2 인스턴스에 로그인(이미 접속해 계시다면 다음 순서로 넘어가주세요)

먼저 기존의 .pem 파일을 사용하여 EC2 인스턴스에 로그인합니다.

ssh -i /path/to/your/origin_SSH_Key_file_name.pem ec2-user@your_ip_address

---

5. 새로 발급받은 SSH 공개 키를 EC2에 추가

EC2 인스턴스에 로그인한 후, 새로 생성한 SSH 키의 공개 키를 ~/.ssh/authorized_keys 파일에 추가해야 합니다.

   1. 공개 키를 EC2 인스턴스에 추가

echo "아까 복사한 공개키 붙여넣기" >> ~/.ssh/authorized_keys

 

  2. 파일 권한 수정: 보안을 위해 authorized_keys 파일의 권한을 600으로 설정합니다.

chmod 600 ~/.ssh/authorized_keys

---

6. 새 SSH 키로 로그인 테스트

ssh -i ~/.ssh/ssh_key_file_name username@your_ip_address

 접속 시 패스프레이즈를 입력하라는 메시지가 나오면 생성할 때 설정한 패스프레이즈를 입력해주세요.

로그인이 잘 되는걸 확인할 수 있습니다.

---

7. .war 파일을 EC2 인스턴스로 전송할 때 새 SSH 키 사용하기

새 SSH 키로 EC2 인스턴스에 접속한 후, scp 명령어를 사용하니 파일을 EC2 인스턴스로 전송할 수 있었습니다.

scp -i /path/to/your/ssh/key /home/username/your-repository/build/libs/*SNAPSHOT.war username@your-ip-address:/home/username/apache-tomcat-10.1.31/webapps/

8. 전송된 파일 확인

전송이 완료되면 EC2 인스턴스에서 webapps 디렉토리로 이동하여 파일이 제대로 전송되었는지 확인할 수 있습니다

cd /home/username/apache-tomcat-10.1.31/webapps/
ls

스왑 파일을 사용하면 시스템의 물리적 메모리(RAM)가 부족할 때 디스크 공간을 임시 메모리처럼 사용하여 시스템 성능을 개선할 수 있습니다. 아래는 스왑 파일을 설정하는 방법을 단계별로 정리한 내용입니다.

1. 스왑 파일을 저장할 디렉토리 생성

먼저, 스왑 파일을 저장할 디렉토리를 생성합니다.

mkdir /swap_tmp

2. dd 명령어로 스왑 파일 생성

dd 명령어를 사용하여 2GB 크기의 스왑 파일을 생성합니다.

여기서 bs=1024는 블록 크기를 1KB로 설정하고, count=2097152는 1KB 크기의 블록을 2,097,152번 복사하여 2GB 파일을 만듭니다.

dd if=/dev/zero of=/swap_tmp/swapfile bs=1024 count=2097152

3. 생성된 스왑 파일 권한 설정

스왑 파일의 권한을 적절히 설정하여 다른 사용자가 파일을 읽거나 쓸 수 없도록 권한을 600으로 설정합니다.

chmod 600 /swap_tmp/swapfile

4. 스왑 파일을 스왑 영역으로 설정

생성된 파일을 스왑 영역으로 설정합니다.

mkswap /swap_tmp/swapfile

5. 스왑 활성화

스왑 파일을 활성화하여 시스템이 스왑 공간을 사용할 수 있도록 합니다.

swapon /swap_tmp/swapfile

6. 스왑 파일 상태 확인

스왑 파일이 정상적으로 활성화되었는지 확인하려면 아래 명령어를 사용합니다:

swapon --show

또는 free -h 명령어를 사용하여 메모리와 스왑 사용 상태를 확인할 수 있습니다.

7. 시스템 재부팅 시 자동 활성화 설정

시스템 재부팅 후에도 스왑 파일이 자동으로 활성화되도록 /etc/fstab 파일에 추가해야 합니다.

nano나 vi 편집기로 fstab 파일을 열고

nano /etc/fstab  #또는
vi /etc/fstab

파일의 마지막에 다음 줄을 추가합니다:

/swap_tmp/swapfile none swap sw 0 0

8. 스왑 비활성화 및 삭제 (선택사항)

스왑을 비활성화하려면 swapoff 명령어를 사용하고, 스왑 파일을 삭제하려면 rm 명령어를 사용합니다.

#스왑 비활성화
swapoff /swap_tmp/swapfile

#스왑 파일 삭제
rm /swap_tmp/swapfile

이 단계들을 완료하면, 스왑 파일이 정상적으로 설정되고, 시스템이 재부팅될 때마다 자동으로 활성화됩니다. 스왑 파일을 적절히 활용하면 시스템의 성능과 안정성을 향상시킬 수 있습니다.

1. AWS 관리 콘솔에 로그인

먼저 AWS 관리 콘솔에 로그인합니다.

• AWS Management Console에 접속하여 로그인을 진행합니다.

2. IAM 대시보드로 이동

• 서비스 검색창에 IAM을 검색한 후, IAM (Manage access to AWS resources) 서비스를 클릭합니다.

3. 사용자(User) 추가

• 왼쪽 메뉴에서 사용자(Users)를 클릭합니다.

• 사용자 추가(Create user)를 클릭합니다.

• 사용자 이름을 입력하고 다음으로 넘어갑니다. 

4. 권한 부여

• 권한 설정(Set permissions) 단계에서, 일반적으로 그룹에 사용자 추가(Add user to group)를 선택합니다.
  • 그룹을 사용하면 권한 관리가 간편하고, 이후 새로운 사용자가 추가되거나 기존 권한을 수정해야 할 때 일괄적으로 관리할 수 있습니다.

• 그룹생성(Create group)을 선택합니다.

• 이름을 부여한 뒤 사용자 그룹 생성(Create user group)을 선택하고 다음버튼을 눌러주세요.

5. 사용자 검토 및 생성

1. 권한을 설정한 후 다음: 태그(Next: Tags)를 클릭하여 사용자에 대한 태그를 추가할 수 있습니다. 이 단계는 선택 사항입니다.
2. 검토(Review) 페이지에서 설정이 올바른지 확인하고, 사용자 만들기(Create user)를 클릭합니다.

6. 액세스 키 발급

• 사용자가 생성되면 요약(Summary)에 액세스 키가 없다고 뜹니다.

• 보안 자격 증명(Security credentials)에 들어가서 밑으로 내리면 Access Keys가 보입니다. 액세스 키 만들기(Create access key)를 선택해 주세요.

• 사용할 용도에 맞게 액세스 키를 선택합니다.

• 액세스 키에 태그를 달아 관리할 수 있습니다(선택사항).

• 이 정보를 안전하게 저장해야 합니다. 비밀 액세스 키는 생성 이후 한 번만 표시되므로, 나중에 다시 확인할 수 없습니다.
  • 액세스 키 ID와 비밀 액세스 키를 복사해서 GitHub Secrets에 안전하게 저장해 주세요.

7. GitHub Secrets에 저장

GitHub 리포지토리에서 Secrets에 이 키를 저장하려면:

1. GitHub에서 해당 리포지토리로 이동합니다.
2. Settings > Secrets and variables > Actions를 클릭합니다.
3. New repository secret를 클릭하여 다음과 같이 키와 값을 입력합니다:
   • Name: AWS_ACCESS_KEY_ID
   • Value: 발급받은 액세스 키 ID
   • Name: AWS_SECRET_ACCESS_KEY
   • Value: 발급받은 비밀 액세스 키

8. 액세스 키 테스트

이제 GitHub Actions에서 이 키를 사용하여 AWS 리소스를 제어할 수 있습니다. 예를 들어, EC2 인스턴스를 시작하거나 종료하는 작업을 실행할 수 있습니다.

참고사이트 :

https://docs.aws.amazon.com/ko_kr/powershell/latest/userguide/creds-idc.html

https://hyunki99.tistory.com/94

EC2 인스턴스를 종료하거나 재시작할 때마다 퍼블릭 IP 주소는 변경됩니다.

이 문제를 해결하려면 Elastic IP를 사용하는 것이 좋습니다.

Elastic IP는 고정된 퍼블릭 IP로, 인스턴스를 종료하거나 재시작해도 IP 주소가 변경되지 않습니다.

1. Elastic IP 할당

• AWS 관리 콘솔에 로그인합니다.

• EC2 대시보드로 이동합니다.
• 왼쪽 메뉴에서 Elastic IPs를 클릭합니다.

• Allocate Elastic IP address 버튼을 클릭하여 새 Elastic IP를 할당합니다.

2. Elastic IP 연결:

• 할당된 Elastic IP를 선택한 후, Actions -> Associate Elastic IP address를 클릭합니다.

• Instance 또는 Network interface를 선택하고, 연결할 EC2 인스턴스를 선택합니다.
• Associate 버튼을 클릭하여 Elastic IP를 EC2 인스턴스에 연결합니다.

이렇게 설정하면, EC2 인스턴스를 재시작하거나 종료해도 Elastic IP는 고정되어 있어서 IP 주소가 변경되지 않게 됩니다.

이 IP를 GitHub Secrets에 추가하여 배포 작업에 사용할 수 있습니다.

*** 주의사항

Elastic IP를 사용할 때 EC2 인스턴스를 종료하면 요금이 발생하므로, 필요할 때만 Elastic IP를 할당하고 인스턴스를 종료할 때 해제하는 것이 좋은 방법입니다.

3. Elastic IP 해제:

1. AWS Management Console을 통한 해제 방법

• AWS 콘솔 로그인: AWS Management Console에 로그인합니다.
• EC2 대시보드로 이동: 왼쪽 메뉴에서 **"EC2"**를 클릭하여 EC2 대시보드로 이동합니다.
• Elastic IP 선택: 왼쪽 메뉴에서 "네트워크 및 보안" 아래에 있는 **"Elastic IP"**를 클릭합니다.

• Elastic IP 해제:
  • Elastic IP 목록에서 해제할 IP 주소를 선택합니다.
  • Actions에서 "Disassociate Elastic IP address" 버튼을 클릭합니다.
  • 팝업 창에서 "Disassociate"를 클릭하여 Elastic IP를 EC2 인스턴스에서 분리합니다.
  *** Elastic IP를 해제(Disassociate)하고 EC2 인스턴스와 연결되지 않으면 요금이 부과되지 않습니다. 즉, EC2 인스턴스에 할당되지 않은 Elastic IP에 대해서는 요금이 부과되지 않습니다.

       *** Elastic IP를 할당만 해놓고 EC2 인스턴스와 연결되지 않으면, 연결된 EC2 인스턴스가 없을 때는 요금이 부과됩니다.

• Elastic IP 할당 해제:
  • Elastic IP가 분리되면, 다시 "Elastic IP 주소" 목록에서 해당 IP를 선택하고 "Release Elastic IP addresses" 버튼을 클릭합니다.
  • 확인 창에서 "Release"를 클릭하여 Elastic IP를 AWS에서 해제합니다.
  • Elastic IP를 릴리즈하면 해당 IP는 영구적으로 사라지고, 새로운 IP를 할당받게 되므로, IP 주소가 변경됩니다.

* Elastic IP 분리 (Disassociate): EC2 인스턴스와 Elastic IP의 연결을 끊는 것.

* Elastic IP 릴리스 (Release): EC2 인스턴스와 연결을 끊은 후, 해당 Elastic IP를 AWS에서 완전히 해제하는 것.

0. application.properties 파일 수정

localhost 부분을 DB Server public 주소로 바꿔주기

spring.datasource.url=jdbc:oracle:thin:@DBServerPublicAddress:1521/xe

1. build.gradle 파일 수정

WAR 파일을 빌드하려면 build.gradle 파일에 war 플러그인을 추가하고, 필요한 의존성을 설정해야 합니다.

plugins { id 'war' }

2. WAR 파일 빌드

2-1. Gradle에서 WAR 파일 빌드

1) Window-Show View - Other... 클릭

2) Gradle - Gradle Tasks 클릭

3) 프로젝트 - build - war(우클릭) - Run Gradle Tasks 클릭

4) war파일이 생성됐는지 확인하기

프로젝트 루트 디렉토리의 build/libs 폴더에서 확인할 수 있습니다.

2-2. 터미널에서 WAR 파일 빌드

1) 터미널에서 프로젝트의 루트 디렉터리로 이동합니다.

ex) cd /Users/kim-eunji/Documents/STS4WorkSpace/Hairyz

2) 아래 명령어로 WAR 파일을 빌드합니다

./gradlew build

3) 만약 권한 문제가 발생하면, chmod 명령어로 권한을 추가합니다

chmod +x gradlew로 권한을 주면 됩니다.

chmod +x gradlew

./gradlew build

4) build/libs 폴더에 생성된 WAR 파일을 확인합니다.

cd build/libs

- 파일이 두개가 있는데 일반적으로 Hairyz-0.0.1-SNAPSHOT.war 파일이 최종 WAR 파일입니다.

   Hairyz-0.0.1-SNAPSHOT-plain.war : 일반적으로 원본 WAR 파일로, 추가적인 설정이나 패키징이 적용되지 않은 순수한 WAR 파일

   Hairyz-0.0.1-SNAPSHOT.war : 빌드 및 패키징 후 최종 WAR 파일, 일반적으로 배포용으로 사용

- 만약 파일 이름을 변경하고 싶다면, mv(move) 명령어를 사용합니다

   mv [원본 파일][새 파일 이름]

   ex) mv Hairyz-0.0.1-SNAPSHOT.war Hairyz.war

3. 로컬 시스템에서 EC2 서버로 WAR 파일 전송

1) scp 명령어로 EC2 서버에 파일 전송

* scp : "secure copy"의 약자로, 네트워크를 통해 원격 시스템 간에 파일을 안전하게 복사하는 명령어. SSH 프로토콜을 사용하여 데이터를 암호화된 상태로 전송하므로 보안성이 뛰어나다.

- EC2 인스턴스에 .war 파일을 전송하려면 scp 명령어를 사용합니다

ex) scp /Users/kim-eunji/Documents/STS4WorkSpace/Hairyz/build/libs/Hairyz.war ec2-user@<EC2_IP_ADDRESS>:/home/ec2-user/apache-tomcat-10.1.31/webapps/

- 만약 아래와 같이 뜬다면?

SSH 키 인증 문제로, EC2 인스턴스로 파일을 전송할 때 인증에 실패했음을 나타냅니다.

2) SSH 키 명시적으로 지정

scp가 자동으로 SSH 키를 인식하지 못하는 경우, -i 옵션을 사용하여 키를 명시적으로 지정합니다.

ex) scp -i /path/to/your-key.pem /Users/kim-eunji/Documents/STS4WorkSpace/Hairyz/build/libs/Hairyz.war ec2-user@<EC2_IP_ADDRESS>:/home/ec2-user/apache-tomcat-10.1.31/webapps/

- 파일 전송이 성공했을 경우

<로컬 터미널>

<웹서버 터미널>

4. Tomcat 서버 재시작

1) Tomcat 재시작

WAR 파일을 전송한 후, Tomcat을 재시작해야 배포가 적용됩니다.

cd /home/ec2-user/apache-tomcat-10.1.31/bin

./shutdown.sh

./startup.sh

5. 배포 확인

브라우저에서 배포 확인

- Tomcat이 재시작되면, 브라우저에서 다음 URL을 통해 배포된 웹 애플리케이션에 접근할 수 있습니다

- EC2 인스턴스의 IP 주소와 포트 번호, 웹 애플리케이션의 컨텍스트 경로를 사용하여 확인합니다.   

   EC2_IP_ADDRESS:포트번호/파일이름

   ex) http://<EC2-IP-ADDRESS>:8081/Hairyz

웹 애플리케이션 배포 시 발생할 수 있는 오류를 진단하려면 로그 파일을 확인하는 것이 중요합니다.

1. 로그 위치 확인

Tomcat 로그 파일은 logs 디렉토리 안에 저장됩니다. 기본적으로 catalina.out 파일에서 모든 출력 로그를 확인할 수 있습니다.

ex) cd apache-tomcat-10.1.31/logs

       ls -al 

2.로그 파일 읽기

tail -f 명령어를 사용해 실시간으로 로그를 확인할 수 있습니다.

tail -f catalina.out

2-1. tail -f 종료 방법

Ctrl + C 를 눌러서 tail -f 명령어를 종료할 수 있습니다.

3. 특정 날짜의 로그 확인

catalina.2024-11-07.log와 같은 날짜별 로그 파일을 통해 특정 시점의 문제를 추적할 수 있습니다.

ex) cat catalina.2024-11-07.log

Window에서는 putty와 WinScp로 서버에 원격으로 접속하고, 필요한 파일을 전송했었는데

Mac에서는 터미널만으로도 외부 서버에 원격으로 접속이 가능합니다.

1. 터미널을 켜기

2. AWS EC2 서버 생성 시 다운받았던 .pem 파일이 있는 위치로 이동

*** 경로를 모를 때 

1) 보기 - 경로 막대 보기

2) 오른쪽 클릭 - 경로 이름을 복사

3) 터미널에 복붙

ex) cd /Users/kim-eunji/Documents/Linux

4) 만약 permission denied: /Users/kim-eunji/Documents/Linux가 뜬다면?

 sudo su 입력(현재 사용자의 세션에서 root 사용자로 전환)

 비밀번호 입력

 sh-3.2#가 뜰텐데 현재 root 사용자로 로그인했음을 나타내는 것임으로 당황치 말기!

 3번부터 하면 되는데 만약 나오고 싶으면 exit 입력하고 나오면 됩니다.

3. .pem 파일의 권한 변경

chmod 600 키이름.pem

*** chmod 뒤에 숫자 세개의 의미는 나/그룹/전체에 대한 권한이다.

      권한의 종류는 read(4), write(2), execute(1) 인데 숫자의 합으로 조합의 권한을 나타낸다.

      600의 의미는 나에게만 읽고, 쓰기 권한이 있음을 의미한다(4+2 = 6).

4. AWS 서버에 접속하기

ssh -i ForLecture.pem ec2-user@아이피 주소

***만약 The authenticity of host ... can't be established.

이런식으로 서버의 신뢰성을 확인하는 경고메세지가 뜰 경우

신뢰할 수 있는 서버의 경우 yes를 입력하면 되지만, 서버의 안전성을 확신할 수 없을 경우는 고민해보시길...

5. 접속완료!

   ,     #_

   ~\_  ####_        Amazon Linux 2

  ~~  \_#####\

  ~~     \###|       AL2 End of Life is 2025-06-30.

  ~~       \#/ ___

   ~~       V~' '->

    ~~~         /    A newer version of Amazon Linux is available!

      ~~._.   _/

         _/ _/       Amazon Linux 2023, GA and supported until 2028-03-15.

       _/m/'           https://aws.amazon.com/linux/amazon-linux-2023/

참고 블로그 : https://professionalworker.tistory.com/242