일부 사람들이 주장하는 것만 큼 유용하지는 않지만, 많은 무차별 강제 로그인 시도가 SSH가 다른 곳에서 수신 대기하는지 확인하기 위해 스캔하는 대신 기본 포트만 사용하기 때문에 최소한 로그 파일에 미치는 영향을 줄입니다. 일부 공격은 다른 곳에서 SSH를 검색하므로 은색 총알이 아닙니다.

서버가 단지 프로젝트의 요구를 충족시키는 것이 아니라 일종의 공유 호스트가 될 경우, 기본이 아닌 포트를 사용하는 것은 사용자에게 반복해서 설명해야하기 때문에 힘들 수 있습니다. 잊어 버렸을 때 클라이언트 프로그램이 포트 22에 연결하지 못한 경우

비표준 포트에서 SSH의 또 다른 문제점은 제한적인 발신 필터 세트가있는 클라이언트가 발생하는 경우입니다.이 필터는 예를 들어 포트 22, 53, 80과 같은 필터 만 허용하므로 사용자 정의 포트에 연결할 수 없습니다. 443은 새로운 발신 연결의 대상이됩니다. 이것은 흔하지 않지만 확실히 들어 본 적이 없습니다. 비슷한 문제로, 일부 ISP는 P2P 연결 및 스로틀 (또는 블록)을 숨기려고 시도하는 것으로 일반적으로 예상되는 포트 (포트 443 또는 HTTPS, 22의 경우 등) 이외의 포트에서 암호화 된 트래픽을 볼 수 있습니다. 불편한 연결.

편의상 표준 포트에 SSH를 개인적으로 유지합니다. 일반적인 예방 조치 (강력한 암호 / 키 정책, 루트 로그인 제한 등)를 취하는 한 걱정할 필요가 없으며 무차별 대입 공격에 부딪 칠 때 로그 파일 증가 문제는 다음과 같은 도구를 사용하여 완화 할 수 있습니다. fial2ban으로 지정된 시간 간격에 잘못된 인증 자격 증명을 너무 많이 제공하는 호스트를 일시적으로 차단합니다.

선택한 포트가 무엇이든, 22에서 멀어지면 1024 미만인지 확인하십시오. 기본 구성의 대부분의 유닉스 유사 설정에서는 루트 (또는 루트 그룹의 사용자) 만 1024 이하의 포트에서 청취 할 수 있습니다. 그러나 모든 사용자는 더 높은 포트에서들을 수 있습니다. 더 높은 포트에서 SSH를 실행하면 불량 (또는 해킹 된) 사용자가 SSH 데몬을 중단하고 자체 또는 프록시로 교체 할 가능성이 높아집니다.

답변