The ssh command is used to connect to an ssh server. The syntax of the ssh command is ssh user@hostname. Replace user with a user on the SSH server. Replace hostname with the hostname or IP address of the SSH server.
For example, let's say server1.example.com is using OpenSSH and the sshd service is running.
[root@server1.example.com ~]# systemctl status sshd
● sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2024-05-13 09:46:40 CDT; 1 weeks 0 days ag
And john.doe exists on server1.
[root@server1 ~]# id john.doe
uid=1002(john.doe) gid=1002(john.doe)
And OpenSSH on server1 is configured to allow Password Authentication.
[root@server1 ~]# grep -i ^PasswordAuthentication /etc/ssh/sshd_config
PasswordAuthentication yes
And assuming that you do not have a firewall (such as iptables or firewalld) between the systems refusing SSH connections on port 22, you should be able to establish the SSH connection to server1.example.com john.doe with basic auth (username/password).
ssh john.doe@server1.example.com
The -v (verbose) flag can be used to see the authentication methods that the SSH server accepts.
ssh john.doe@server1.example.com -v
Something like this should be returned.
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
inline command
Here is an example of how you could issue an inline command.
]$ ssh john.doe@server1.example.com "ls -l /tmp"
-rw-r--r-- 1 root root 22 Oct 16 01:01 foo.txt
-rw-r--r-- 1 root root 104 Oct 16 13:00 bar.txt
Known hosts
Regardless if you are using a password or a public / private key pair for authentication, if the public certificate of the SSH server (server1 in this example) is not listed in the /etc/ssh/ssh_known_hosts or /home/username/.ssh/known_hosts file on the client, a prompt will appear stating The authenticity of host 'hostname (ip address)' can't be established. Entering "yes" will add the SSH to the client's known hosts. Refer to Understanding Known Hosts for a better understand of what known hosts are.
~]# ssh john.doe@server1.example.com
The authenticity of host 'server1 (192.168.0.5)' can't be established
DSA key fingerprint is BB37 83F2 5E3A 7A4C 6C84 F047 D97B DD4E 38BB 2082
Are you sure you want to continue connecting (yes/no)?
Password authentication
If the SSH server is configured to use password authentication, there will be a prompt to enter the password.
~]# ssh john.doe@server1.example.com
john.doe@server1 password:
For example, if the SSH server is using OpenSSH, the OpenSSH configuration file, which is typically located at /etc/ssh/sshd_config would have the following directive.
PasswordAuthentication yes
After entering the password, you will be connected to the SSH server. Once connected, the hostname command can be used to verify that you are connected to the SSH server. The hostname of the SSH server should be displayed (server1 in this example).
~]# hostname
server1
As long as the password entered is valid, the connection should be successful, and the last login date and time should be displayed. Also included will be the hostname of the host machine (server1.example.com in this example).
Last login: Thu Jan 26 13:05:01 2017 from server1.example.com
Public / private key pair authenticaiton
Instead of authenticating with a password, you can instead authenticate with a public certificate and private key. Refer to public key authentication with OpenSSH on Linux
If you do not specify the private key that should be used, by default, SSH will attempt certain default private keys. The ssh command with the -v (verbose) option will display the default private keys. ssh-keygen can be used to create the private key.
~]# ssh -v john.doe@server1.example.com
. . .
debug1: Trying private key: .ssh/id_rsa
debug1: Trying private key: .ssh/id_dsa
debug1: Trying private key: .ssh/id_ecdsa
debug1: Trying private key:.ssh/id_ed25519
sudo
If you will be using sudo, you may get this lovely response.
Sorry, you must have a tty to run sudo
The fix for this is usually real easily, which is simply to use the -t option to create a psuedo-tty on the target server. Refer to this article to learn about TTY.
ssh -t john.doe@server1.example.com "sudo command"
Did you find this article helpful?
If so, consider buying me a coffee over at