ssh

Client connection tools in the openssh suite

Supplementary instructions

ssh command is a client connection tool in the openssh suite, which can implement secure remote login to the server using the ssh encryption protocol.

grammar

ssh(options)(parameters)

Options

-1: Force the use of ssh protocol version 1;
-2: Force the use of ssh protocol version 2;
-4: Force the use of IPv4 addresses;
-6: Force the use of IPv6 addresses;
-A: Enable authentication proxy connection forwarding function;
-a: Turn off the authentication proxy connection forwarding function;
-b: Use the address specified by the local machine as the source IP address of the corresponding connection;
-C: Request compression of all data;
-F: Specify the configuration file of the ssh command;
-f: Execute ssh command in the background;
-g: allows remote hosts to connect to the forwarding port of the host;
-i: Specify the identity (private key) file;
-l: Specify the login username to connect to the remote server;
-N: Do not execute remote commands;
-o: Specify configuration options;
-p: Specify the port on the remote server;
-q: Silent mode;
-X: Enable X11 forwarding function;
-x: Turn off the X11 forwarding function;
-y: Enable trusted X11 forwarding function.

Parameters

• Remote host: Specify the remote ssh server to connect to;

• Command: The command to be executed on the remote ssh server.

Example

# ssh username@remote server address
ssh user1@172.24.210.101
#Specify port
ssh -p 2211 root@140.206.185.170

# ssh family
ssh -p 22 user@ip #The default user name is the current user name, and the default port is 22
ssh-keygen # Generate ssh public key + private key for the current user
ssh-keygen -f keyfile -i -m key_format -e -m key_format # key_format: RFC4716/SSH2(default) PKCS8 PEM
ssh-copy-id user@ip:port # Copy the current user's public key to ~/.ssh/authorized_keys of the server that requires ssh, and then you can log in without a password

Connect to remote server

ssh username@remote_host

Connect to the remote server and specify the port

ssh -p port username@remote_host

Connect to remote server using key file

ssh -i path/to/private_key username@remote_host

Execute remote commands locally

ssh username@remote_host "command"

Copy files locally to remote server

scp path/to/local_file username@remote_host:/path/to/remote_directory

Copy files from remote server to local

scp username@remote_host:/path/to/remote_file path/to/local_directory

Forward local port to remote server

ssh -L local_port:remote_host:remote_port username@remote_host

Forward the remote server port to the local

ssh -R remote_port:local_host:local_port username@remote_host

Behind the story

Why the port number of SSH (Secure Terminal) is 22 is not a coincidence, there is a story that I (Tatu Ylonen, the designer of the SSH protocol) has not told.

The story of setting the SSH protocol port number to 22

I wrote the original version of the SSH protocol in the spring of 1995, when telnet and FTP were in widespread use.

At that time, I designed the SSH protocol to replace the two protocols telnet (port 23) and ftp (port 21), and port 22 was idle. I chose the number sandwiched between the telnet and ftp ports as a matter of course. I feel that although the port number is a small thing, there seems to be some belief in it. But how on earth do I get that port number? I never own a port number, but I know a few people who do!

Obtaining the port number was actually quite simple at that time. After all, the Internet was not very big at that time, and it was the early days of the Internet explosion. Port number allocation is done by IANA (Internet Assigned Numbers Authority). At that time, this organization was equivalent to Internet pioneers Jon Postel and [Joyce K. Reynolds](https://en.wikipedia.org/wiki/Joyce_K ._Reynolds) general existence. Jon co-wrote several major protocol standards, such as IP (RFC 791), ICMP (RFC 792), and TCP (RFC 793), some of which you should have heard of.

I can say that I am in awe of Mr. Jon, who has co-authored almost every major Internet standards document (Internet RFC)!

In July 1995, just before I released ssh-1.0, I sent an email to IANA:

(LCTT Translation: The WKS record type in the DNS protocol means "well-known business description". It is a DNS record type similar to A and MX. It is used to describe the services provided by a certain IP. It is rarely used at present. See: https://docs.oracle.com/cd/E19683-01/806-4077/dnsintro-154/index.html ).

The next day, I received an email from Joyce:

That’s it! SSH port is officially used 22! ! !

At 2:21 AM on July 12, 1995, I announced the final beta version of SSH to my testers at Helsinki University of Technology. At 5:23 pm that day, I announced the ssh-1.0.0 version to the testers. On July 12, 1995, at 5:51 pm, I sent an SSH (Secure Terminal) announcement to the [email protected] mailing list. I also sent it to several newsgroups and mailing lists. and some people discussing related topics on the Internet.

How to change the port number of the SSH service

The SSH server runs on port 22 by default. However, it can also run on other ports if required for some reason. For example, to facilitate testing and use, or to run multiple different configurations on the same host. Of course, in rare cases, it is possible to run it without root privileges, such as in some cases where it must be run on an unprivileged port (port number greater than or equal to 1024).

The port number can be changed to Port 22 in the configuration file /etc/ssh/sshd_config. You can also run sshd with the -p option. SSH clients and the sftp program can also use the -p option.

Configure SSH protocol to traverse the firewall

SSH is one of the few protocols that is generally allowed through firewalls. A common practice, especially in smaller or more technical organizations, is to not restrict outbound SSH connections, while inbound SSH connections are usually restricted to one or a few servers.

Outbound SSH connections

Configuring outbound SSH connections in your firewall is easy. If you want to completely restrict outgoing connections, just create a rule that allows TCP port 22 to go out. If you want to limit the destination addresses, you can limit the rule to only allow access to external servers that your organization places in the cloud or springboard servers that protect that cloud.

Backchannel is risky

In fact, although it is possible to not restrict outbound SSH connections, it is risky. The SSH protocol supports channel access. The original idea was to set up an SSH service on an external server to listen for connections from everywhere, forward incoming connections to the organization, and allow this connection to access an internal server.

This is of course very convenient in some scenarios. Developers and system administrators often use it to open a channel that they can access remotely, such as when using a laptop at home or while traveling.

However, generally speaking, these practices are against security policies. Skipping the protection controls of firewall administrators and security teams is undoubtedly against security policies, such as these: PCI, HIPAA, NIST SP 800-53, etc. It can be used by hackers and foreign intelligence agencies to leave backdoors within organizations.

CryptoAuditor is a product that can control access through a firewall or a group of cloud servers. This product can be used with the Universal SSH Key Manager to gain access to host keys to decrypt SSH sessions in scenarios where firewalls are enabled and block unauthorized forwarding.

Inbound SSH access

Here are a few things to say about inbound access:

Configure the firewall and forward all connections to port 22 only to a specific internal network IP address or a DMZ host. Run CryptoAuditor or a springboard on this IP to control and audit all connections to the organization. Use different ports on the firewall to access different servers. Only allow connections to SSH services after logging in using a VPN (Virtual Private Network) such as IPsec protocol.

Restrict SSH access via iptables service

iptables is a host firewall built into the Linux kernel. Typically configured to protect servers from access to ports that are not explicitly opened.

If iptables is enabled on the server, use the following command to allow incoming SSH access. Of course, the command needs to be run as root.

iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT

If you want to permanently save the rules created by the above command, in some system versions, you can use the following command:

service iptables save