Many enterprises use Secure Shell (SSH) accessible jump servers to access business-critical systems. Administrators first connect to a jump server using SSH, possibly through a VPN, before connecting to the target system. This method usually works great as long as an administrator sticks with command-line administration. It gets a bit more tricky when an administrator wants to break out of the command-line realm and use a web-based interface instead.
Let's look at the following scenario: Bob is a system administrator at Securecorp, and he just got an alert indicating that a database cluster consisting of sirius.securecorp.io and orion.securecorp.io is performing poorly. For an initial analysis, he usually uses the RHEL8 web console. The firewall doesn't allow him to connect directly to this system from his workstation, but he can go through a jump server called bastion.securecorp.io.
[ You might also enjoy: 6 essential SSH guides for sysadmins ]
SSH command-line access to the database cluster is straightforward:
[bob@workstation ~]$ ssh bastion.securecorp.io
[bob@bastion ~]$ ssh sirius.securecorp.io
[bob@sirius ~]$
[bob@workstation ~]$ ssh bastion.securecorp.io
[bob@bastion ~]$ ssh orion.securecorp.io
[bob@orion ~]$
But what if Bob wants to access the RHEL8 web console of sirius.securecorp.io and orion.securecorp.io? There are multiple ways to achieve this goal using SSH, all involving port forwarding of some sort.
Disclaimer: In some organizations, security policies do not allow port forwarding. To make sure that you don't breach any rules, please consult with your IT security representative.
SSH port forwarding
Using SSH, Bob opens a TCP tunnel for both systems, pointing to the web console port (9090) for sirius.securecorp.io and port 9091 for orion.securecorp.io.
[bob@workstation ~]$ ssh -L 9090:sirius.securecorp.io:9090 bastion.securecorp.io
[bob@bastion ~]$
[bob@workstation ~]$ ssh -L 9091:orion.securecorp.io:9090 bastion.securecorp.io
[bob@bastion ~]$
Bob can now point his local workstation's browser to https://localhost:9090 to access the web console for sirius.securecorp.io, and https://localhost:9091 to access the web console for orion.securecorp.io.
This approach might work well in certain cases but has its limitations:
- TLS certificate validation: The local browser is unhappy because, in most cases, the certificate Common Name doesn't match with the hostname in the address bar (localhost), so the certificate validation fails.
- Redirects: When the website you are accessing redirects you to another URL, the connection fails because port forwarding is only valid for exactly this web server. This situation might be a problem when using single sign-on (SSO), for instance.
Start a browser on the jump server
Bob would also be to start a browser such as Firefox on the jump server and display it locally on his workstation. SSH provides a feature called X forwarding, which can be used in this situation.
[bob@workstation ~]$ ssh -X bastion.securecorp.io
[bob@bastion ~]$ firefox https://sirius.securecorp.io:9090 &
[bob@bastion ~]$ firefox https://orion.securecorp.io:9090 &
Using this method, the browser process runs on the jump server, and the connections to the web consoles of sirius.securecorp.io and orion.securecorp.io are allowed. Only the rendering of the browser window happens on Bob's workstation.
While this approach solves some problems of plain SSH port forwarding, it also has limitations:
- Performance: This method usually performs rather poorly because the graphical output has to be transferred from the jump server to the workstation through the network, which is very inefficient.
- Prerequisites: A browser such as Firefox needs to be installed on the jump server, and an X server needs to be running on the workstation.
Enter dynamic port forwarding
Having explored the previous two approaches and learned about their disadvantages, it would be great to have a third option, which brings us the best of both worlds:
- The workstation's browser can be used.
- Connectivity and DNS name resolution should be the same as on the jump server.
To achieve this, SSH provides a feature called dynamic port forwarding, which leverages the SOCKS protocol. In this configuration, SSH acts as a SOCKS proxy, relaying all relevant traffic through the SSH connection. For this to happen, the client (in our example, it is the browser) needs to be SOCKS-aware.
Bob can initiate an SSH session with dynamic port forwarding as follows:
[bob@workstation ~]$ ssh -D 1080 bastion.securecorp.io
[bob@bastion ~]$
After that, the browser on Bob's workstation needs to be made SOCKS-aware. The Firefox configuration can be accomplished like this:
- Point the browser to about:preferences.
- In the General tab, scroll down at the bottom, and click on Settings... in the Network Settings section.
- In the Connection Settings window, choose Manual proxy configuration, specify localhost for SOCKS Host, 1080 as Port, and select SOCKS v5.
- In the same window, select Proxy DNS when using SOCKS v5.
Bob can now point the browser to https://sirius.securecorp.io:9090 and https://orion.securecorp.io:9090 to analyze the performance problems of his two database servers using the RHEL8 web console. He can also access any other internal resources as if the browser was running on bastion.securecorp.io.
Note: Port 1080 is the IANA registered port for SOCKS, but the connection can use any other port. The numbers in the SSH and browser configuration have to match.
Personally, I found it useful to create a separate browser profile so it is not necessary to constantly switch between proxy configurations. A new profile can be created by passing the -P
switch to the firefox
command, launching the Profile Manager. I called my profile Jump. After creating a new profile, an empty configuration is created. In this profile, I applied the configuration as described above while leaving my default profile untouched.
After creating the profile, Firefox can be launched with the following command:
[bob@workstation ~]$ firefox -P Jump
Another helpful tip is to create a host-specific configuration for dynamic port forwarding in your ~/.ssh/config
file. For example:
[bob@workstation ~]$ cat ~/.ssh/config
Host bastion
Hostname bastion.securecorp.io
User bob
DynamicForward 1080
[ A free course for you: Virtualization and Infrastructure Migration Technical Overview. ]
Wrap up
There are many ways to connect to internal systems using a jump server and the possibilities outlined above are by no means exhaustive. In my experience, though, SSH provides you with a very powerful tool kit, which in most cases is available and ready to go without many hurdles. Dynamic port forwarding is one of these tools and it has helped me to be more productive in specific situations, so please give it a try yourself.
저자 소개
I am a Red Hat Certified Engineer who first dipped his toes in the world of Linux and open-source software around the year 2000. Since 2005, I have been working in a professional setup with Red Hat products in various roles. In 2019, I had the opportunity to join Red Hat as a consultant in Switzerland, helping our customers deploying and leveraging the power of RHEL, Ansible Automation, and OpenShift.
When not at work, I am exploring countries and cultures around the globe, or grab my photography gear and head out looking for some beautiful pictures.
유사한 검색 결과
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.