Difference between revisions of "Linux Remote Shell Notes"

From Free Knowledge Base- The DUCK Project: information for everyone
Jump to: navigation, search
m (auto login ssh)
 
(21 intermediate revisions by one user not shown)
Line 1: Line 1:
 +
[[Secure Shell]] (SSH) and Telnet are the two most common remote management protocols.  The configuration of Telnet is a common practice, but it is advisable to use SSH. The reason for this is that Telnet data is sent in plain text in contrast to SSH, which encrypts the data.  Tools like wireshark and snort can be used to intercept unencrypted data over a LAN or extra network connection. 
 +
 +
telnet - You can install the old telnet server on your linux system and use it to connect sending your password as plain text and then work in a remote shell with everything being sent as plain text, in the event you wish to share everything you are doing with anyone listening with a packet sniffer at any point between you and the remote host.
 +
 +
ssh - SSH works by connecting a client program to an ssh server.  Use ssh as the modern secure alternative to telnet.  Connect to your linux host from another linux host or a host with a different operating system such as Microsoft Windows.  On Microsoft Windows you can use the free ssh client Putty to connect via ssh.
 +
 +
[[Netcat]] - netcat has been around a long time and should be harmless to have on your system unless you really open things up like a fool.
 +
 +
{{:CentOS_Linux_Distribution_Enable_Telnet}}
 +
 +
== telnet ==
 +
There are still safe and legitimate uses for this over four decade old connection protocol.
 +
 +
We've already mentioned the lack of security.  Quote, "''The telnet daemons (the process that sits on the server and processes your login) have had numerous vunerabilities and will continue to have them. Running telnetd is just one more old daemon waiting to be used to crack your machine!''" from the post [https://www.linuxquestions.org/questions/linux-networking-3/why-you-should-use-ssh-instead-of-telnet-388664/ Why you should use ssh instead of telnet].
 +
 +
There are times when telnet may be useful.  On a private LAN (no route to the Internet) or a connection between two machines only (ultra private LAN) the use of telnet is acceptable, quick, and convenient. 
 +
 +
Furthermore, exploration on exactly how ssh is more secure, and where it is not can find validation in the use of telnet.  One of the key advantages of SSH over telnet is that the server authenticates itself to the client before it collects credentials from the client.  Most sniffing occurs within the network itself and not outside of the router.  Common ssh installations ignore precautions that protect against external threats, making those networks no more secure when using ssh versus telnet. 
 +
 +
If there is no threat within the network itself, all traffic tunnelled to a remote network within a secure VPN, and concluding there is no internal threat within that remote network, telnet would offer no lessor security as compared to ssh in the described scenario.
 +
 +
== ssh - The [[Secure Shell]] ==
 +
The developer folks hated the "service" command so now we use the new systemctl (System Control) method to start the ssh server daemon.
 +
sudo systemctl start ssh
 +
 +
While Telnet was once widely used by administrators for remote management, it does not offer the security mechanisms like SSH, which establishes a secure connection from the host to the remote host. 
 +
 +
=== [[Secure Shell]] Support for Remote Login ===
 +
If the ssh server is not already installed, we will use [[apt-get]] to install. As root or using sudo do the following:
 +
apt-get install openssh-server openssh-client
 +
service ssh start
 +
 +
Note: Added 10/17/2016 old cyphers no longer configured, may cause connection problems with legacy ssh clients such as SecureCRT.  ref: https://blog.hqcodeshop.fi/archives/245-SSH-connection-fails.html
 +
 +
== Use telnet on Debian / Ubuntu / Mint ==
 +
You don't give a rats rear about security and you wish to use good old fashioned telnet (For Debian/Ubuntu/Mint).  Ok...
 +
Install the Telnet server
 +
sudo apt install xinetd telnetd
 +
Assign port
 +
sudo vi /etc/services
 +
Look for the line or add a line like
 +
telnet        23/tcp
 +
Restart xinetd
 +
 +
== use SSH to execute a remote command ==
 +
{{:Secure Shell - use SSH to execute a remote command}}
  
 
== auto login ssh ==
 
== auto login ssh ==
 +
{{:Secure Shell - auto login ssh}}
 +
 +
== shells that don't die when connection is lost ==
 +
The two most common solutions are "screen" and "tmux."  Screen has been around longer, tmux has some additional capabilities, and both will keep your terminal session alive even if your connection is lost. 
 +
=== Screen - Virtual Terminals From Console ===
 +
Multiple virtual terminals from one terminal (like a remote shell), with the ability to detach processes and leave them running even when you disconnect. 
 +
* [[Screen - Virtual Terminals From Console]]
 +
=== tmux, the shell that doesn't die ===
 +
{{:Tmux_terminal_multiplexer}}
 +
 +
== Remote File Copy via SSH ==
 +
SCP - Secure Copy Protocol
 +
* see: [[Remote_File_Copy_from_the_Linux_Command_Prompt#SCP_-_Secure_Copy_Protocol|Remote File Copy from the Linux Command Prompt with SCP]]
 +
 +
== login and non-login shell ==
 +
The .bash_profile is executed for login shells, while .bashrc is executed for interactive non-login shells.
 +
 +
When you login (type username and password) via console, either sitting at the machine, or remotely via ssh: .bash_profile is executed prior to the initial command prompt.
  
The OpenSSH ssh utility doesn't accept a password on the command line or on its standard input. I believe this is a deliberate decision on the part of the OpenSSH developers. You have these options available to you:
+
When you are logged into your machine already and open xterm in your desktop environment then .bashrc is executed prior to seeing a prompt. The .bashrc is also run when you start a new bash instance by typing /bin/bash in a terminal.
  
    Use an SSH key for authentication, instead of a password.
+
== Related Pages ==
    Use sshpass, expect, or a similar tool to automate responding to the password prompt.
+
* [[Remote File Copy from the Linux Command Prompt]]
    (ab)Use the SSH_ASKPASS feature to get ssh to get the password by running another program, described here or here, or in some of the answers here.
+
    Get the SSH server administrator to enable host-based authentication and use that. Note that host-based authentication is only suitable for certain network environments. See additional notes here and here.
+
    Write your own ssh client using perl, python, java, or your favorite language. There are ssh client libraries available for most modern programming languages, and you'd have full control over how the client gets the password.
+
    Download the ssh source code and build a modified version of ssh that works the way you want.
+
    Use a different ssh client. There are other ssh clients available, both free and commercial. One of them might suit your needs better than the OpenSSH client.
+
  
=== sshpass ===
 
  
Install the sshpass utility so that you can automate ssh login including password.
+
[[Category:Computer_Technology]]
apt install sshpass
+
[[Category:Linux]]
Now you can automate the login process
+
sshpass -p "mysecretpass" ssh -o StrictHostKeyChecking=no nicolep@192.168.100.10
+
Custom port example:
+
sshpass -p "mysecretpass" ssh -o StrictHostKeyChecking=no nicolep@192.168.100.10:9600
+

Latest revision as of 16:29, 24 July 2020

Secure Shell (SSH) and Telnet are the two most common remote management protocols. The configuration of Telnet is a common practice, but it is advisable to use SSH. The reason for this is that Telnet data is sent in plain text in contrast to SSH, which encrypts the data. Tools like wireshark and snort can be used to intercept unencrypted data over a LAN or extra network connection.

telnet - You can install the old telnet server on your linux system and use it to connect sending your password as plain text and then work in a remote shell with everything being sent as plain text, in the event you wish to share everything you are doing with anyone listening with a packet sniffer at any point between you and the remote host.

ssh - SSH works by connecting a client program to an ssh server. Use ssh as the modern secure alternative to telnet. Connect to your linux host from another linux host or a host with a different operating system such as Microsoft Windows. On Microsoft Windows you can use the free ssh client Putty to connect via ssh.

Netcat - netcat has been around a long time and should be harmless to have on your system unless you really open things up like a fool.

Want to install telnet?

telnet server is not recommended for security reasons, plain text over tcp/ip

# yum install telnet telnet-server -y

How about telnet client? It is not installed by default.

#yum intall telnet -y

The package is Package telnet.i686

Enable TELNET as ROOT on GUEST CentOS system

Simply edit the file /etc/securetty and add the following to the end of the file:

pts/0
pts/1
pts/2
pts/3
pts/4
pts/5
pts/6
pts/7
pts/8
pts/9

This will allow up to 10 telnet sessions to the server as root. note: Just one is probably fine

ref: http://www.idevelopment.info/data/Unix/Linux/LINUX_TelnetFTPAsRoot.shtml

telnet

There are still safe and legitimate uses for this over four decade old connection protocol.

We've already mentioned the lack of security. Quote, "The telnet daemons (the process that sits on the server and processes your login) have had numerous vunerabilities and will continue to have them. Running telnetd is just one more old daemon waiting to be used to crack your machine!" from the post Why you should use ssh instead of telnet.

There are times when telnet may be useful. On a private LAN (no route to the Internet) or a connection between two machines only (ultra private LAN) the use of telnet is acceptable, quick, and convenient.

Furthermore, exploration on exactly how ssh is more secure, and where it is not can find validation in the use of telnet. One of the key advantages of SSH over telnet is that the server authenticates itself to the client before it collects credentials from the client. Most sniffing occurs within the network itself and not outside of the router. Common ssh installations ignore precautions that protect against external threats, making those networks no more secure when using ssh versus telnet.

If there is no threat within the network itself, all traffic tunnelled to a remote network within a secure VPN, and concluding there is no internal threat within that remote network, telnet would offer no lessor security as compared to ssh in the described scenario.

ssh - The Secure Shell

The developer folks hated the "service" command so now we use the new systemctl (System Control) method to start the ssh server daemon.

sudo systemctl start ssh

While Telnet was once widely used by administrators for remote management, it does not offer the security mechanisms like SSH, which establishes a secure connection from the host to the remote host.

Secure Shell Support for Remote Login

If the ssh server is not already installed, we will use apt-get to install. As root or using sudo do the following:

apt-get install openssh-server openssh-client 
service ssh start

Note: Added 10/17/2016 old cyphers no longer configured, may cause connection problems with legacy ssh clients such as SecureCRT. ref: https://blog.hqcodeshop.fi/archives/245-SSH-connection-fails.html

Use telnet on Debian / Ubuntu / Mint

You don't give a rats rear about security and you wish to use good old fashioned telnet (For Debian/Ubuntu/Mint). Ok... Install the Telnet server

sudo apt install xinetd telnetd

Assign port

sudo vi /etc/services

Look for the line or add a line like

telnet        23/tcp

Restart xinetd

use SSH to execute a remote command

You'll need to be able to ssh with automated password or enter the password each time you run the command.

Execute a remote command on a host over SSH:

ssh nicolep@192.168.100.10 'reboot'

The example above will reboot the remote computer.

Multiple commands

ssh nicolep@192.168.100.10 'uptime; df -h'

Show the kernel version, number of CPUs and the total RAM:

ssh root@192.168.100.10 << EOF
uname -a
lscpu  | grep "^CPU(s)"
grep -i memtotal /proc/meminfo
EOF

Here is how Nicole can execute her script on the remote computer

ssh nicolep@192.168.100.10 'bash -s' < nicolejob.sh

Nicole's script is local on her machine, and she executed it on the remote host.

auto login ssh

There is a key authentication system that can be used with OpenSSH. The OpenSSH ssh utility doesn't accept a password on the command line or on its standard input, except for prompting the user for password requiring manual interaction. By using the key authentication system you will not be prompted for a password.

OPTIONS FOR SSH AUTOMATED

  1. Use an SSH key for authentication, instead of a password.
  2. Use sshpass, expect, or a similar tool to automate responding to the password prompt.
  3. Use the SSH_ASKPASS feature to get ssh to get the password by running another program.
  4. Use the insecure host-based authentication, sometimes common on private networks.
  5. Use a custom or modified ssh client adapted from source code, or one that allows for stored password.

sshpass

Install the sshpass utility so that you can automate ssh login including password.

apt install sshpass

Now you can automate the login process

sshpass -p "mysecretpass" ssh -o StrictHostKeyChecking=no nicolep@192.168.100.10

Custom port example:

sshpass -p "mysecretpass" ssh -o StrictHostKeyChecking=no nicolep@192.168.100.10:9600

public key authentication

BEFORE MAKING NEW KEY PAIRS: Try to Find an Existing Secure Shell Key Pair. See if you already have a .ssh under your home directory. If you already have a key pair then you should not need to make a new key pair.

In the source host run this only once:

ssh-keygen -t rsa 

Now you've generated the public key. It needs to be copied onto the remote host.

ssh-copy-id -i ~/.ssh/id_rsa.pub nicolep@192.168.100.10

add identities to the ssh-agent – the authentication agent on the local host.

ssh-add

now press ENTER to every field

ssh-copy-id nicolep@192.168.100.10

expect

Example script

#!/usr/bin/expect

set timeout 15

set cmd [lrange $argv 1 end]
set password [lindex $argv 0]

eval spawn $cmd
expect "assword:"
send "$password\r";
interact

Another example

#!/usr/bin/expect -f
#  ./ssh.exp password 192.168.100.10 id
set pass [lrange $argv 0 0]
set server [lrange $argv 1 1]
set name [lrange $argv 2 2]

spawn ssh $name@$server
match_max 100000
expect "*?assword:*"
send -- "$pass\r"
send -- "\r"
interact

And finally, a more elaborate example can be found here:

shells that don't die when connection is lost

The two most common solutions are "screen" and "tmux." Screen has been around longer, tmux has some additional capabilities, and both will keep your terminal session alive even if your connection is lost.

Screen - Virtual Terminals From Console

Multiple virtual terminals from one terminal (like a remote shell), with the ability to detach processes and leave them running even when you disconnect.

tmux, the shell that doesn't die

tmux is a terminal multiplexer. It lets you switch easily between several programs in one terminal, detach them (they keep running in the background) and reattach them to a different terminal.

tmux may be detached from a screen and continue running in the background, then later reattached.

  1. ssh into the remote machine
  2. start tmux by typing tmux into the shell
  3. start the process you want inside the started tmux session
  4. leave/detach the tmux session by typing Ctrl+b and then d


The tmux and GNU screen utilities have many similarities. tmux is considered more modern.

Each session is persistent and will survive accidental disconnection (such as ssh(1) connection timeout) or intentional detaching (with the ‘C-b d’ key strokes). tmux may be reattached using:

tmux attach

Example tmux commands include:

refresh-client -t/dev/ttyp2 

rename-session -tfirst newname 

set-window-option -t:0 monitor-activity on 

new-window ; split-window -d 

bind-key R source-file ~/.tmux.conf \; \ 
	display-message "source-file done"

Or from sh(1):

tmux kill-window -t :1 

tmux new-window \; split-window -d 

tmux new-session -d 'vi /etc/passwd' \; split-window -d \; attach

Remote File Copy via SSH

SCP - Secure Copy Protocol

login and non-login shell

The .bash_profile is executed for login shells, while .bashrc is executed for interactive non-login shells.

When you login (type username and password) via console, either sitting at the machine, or remotely via ssh: .bash_profile is executed prior to the initial command prompt.

When you are logged into your machine already and open xterm in your desktop environment then .bashrc is executed prior to seeing a prompt. The .bashrc is also run when you start a new bash instance by typing /bin/bash in a terminal.

Related Pages