≡ Menu

ssh

What To Do: Users Still Wants Telnet

TELNET ( TELecommunication NETwork ) is a network protocol used on the Internet or local area network (LAN) connections. It was developed in late 60s with RFC 15. Telnet is pretty old for login into remote system and it has serious security problem. Most admins will recommend using Open SSH (secure shell) for all remote activities. But you may find users who are still demanding telnet over ssh as they are comfortable with Telnet. Some users got scripts written in 90s and they don't want to change it. So what do you do when users demands telnet?

The problem with telnet

Telnet sends everything in clear text format including username and password. You can use tcpdump or snoop to see all information.

Secure telnet

You can install Kerberos enabled telnetd. Discussion related to Kerberos and secure telnet is beyond the scope of this blog post but I do recommend Kerberos Infrastructure HOWTO for further information. Following packages under Debian will install secure telnet including Kerberos server:
# apt-get install krb5-telnetd krb5-clients
CentOS / RHEL / Red Hat / Fedora Linux user need to install package called krb5-workstation:
# yum install krb5-workstation
You need to configure Kerberos server and Kerberos enabled telnet / ftp. Please see the man pages for further information.

Bottom line: migrate users to ssh

I highly recommend migrating your users to SSH and discarding telnet, ftp and all r* services. First, you need to educate users about telnet and insecure protocols. Once user(s) made aware of the problem, help them to migrate to SSH:

  • Disable telnet and force to use them ssh based tools
  • Explain basic ssh syntax
  • Explains password less login
  • Explain how to use ssh in scripts
  • Explain how to use sftp instead of ftp client
  • Explain how to use scp instead of rcp client

Reset Urchin When Prompt For a New Serial Key

Sometime Urchin may prompt for a new serial key for already configured and working system. You can reset Urchin easily and get rid of this problem.

First, log onto the server via SSH and as root user.

Once logged in type the following two commands to reset it:
# cd /usr/local/urchin/util/
# ./uconf-driver action=set_parameter recnum=1 ct_serial=0
# ./uconf-driver action=set_parameter recnum=1 ct_license=0

Generally service such as ssh, screen, expect, telnet etc use pty (pseudo-terminals) in master – slave mode for login and other purposes. If pty setting is too low many users will not able to login to system using ssh or other commands. In this tip I will explain how to increase the maximum number of pseudo-terminals.

pty man page defines pseudo-terminal as follows:

A pseudo-terminal is a pair of virtual character devices that provide a bidirectional communication channel. One end of the channel is called the master; the other end is called the slave. The slave end of the pseudo-terminal provides an interface that behaves exactly like a classical terminal. A process that expects to be connected to a terminal, can open the slave end of a pseudo-terminal and then be driven by a program that has opened the master end. Anything that is written on the master end is provided to the process on the slave end as though it was input typed on a terminal.

List the maximum number of Pseudo-terminals

Just run the following command to list / display the maximum number of Pseudo-terminals under Linux
$ cat /proc/sys/kernel/pty/max
Output:

1024

Increase the maximum number of Pseudo-terminals (PTY)

If you have large Linux installation such as University or ISP login service you need to increase the PTYs to allow more login sessions. Open kernel configuration file - /etc/sysctl.conf:
# vi /etc/sysctl.conf
Append following config directive (support 5120 ptys)
kernel.pty.max = 5120
Save and close the file. Reload the changes:
# sysctl -p
Verify that the new maximum number of pseudo-terminals value is changed, enter:
$ cat /proc/sys/kernel/pty/max

Further readings

=> Refer to sysctl, proc, and pty man pages for more information.

A shell variable may be assigned to by a statement using following syntax:
var=value

If value is not given, the variable is assigned the null string. In shell program it is quite useful to provide default value for variables. For example consider rsync.sh script:
#!/bin/bash
RSRC=$1
LOCAL=$2
rsync -avz -e 'ssh ' user@myserver:$RSRC $LOCAL

This script can be run as follows:
$ ./rsync.sh /var/www .
$ ./rsync.sh /home/vivek /home/vivek

It will sync remote /home/vivek directory with local /home/vivek directory. But if you need to supply default values for a variable you can write as follows:

#!/bin/bash
RSRC=$1
LOCAL=$2
: ${RSRC:="/var/www"}
: ${LOCAL:="/disk2/backup/remote/hot"}
rsync -avz -e 'ssh ' user@myserver:$RSRC $LOCAL

: ${RSRC:="/var/www"} ==> this means if the variable RSRC is not already set, set the variable to /var/www. You can also write same statement with following code:

if [ -z "$RSRC" ]
then
   RSRC="/var/www"
fi

You can also execute a command and set the value to returned value (output). For example if the variable NOW is not already set, execute command date and set the variable to the todays date using date +"%m-%d-%Y":

#!/bin/bash
NOW=$1
....
.....
: ${NOW:=$(date +"%m-%d-%Y")}
....
..


I've already written about howto log in, on your local system, and make passwordless ssh connections using ssh-keygen command. However, you cannot just follow these instructions over and over again, as you will overwrite the previous keys.

It is also possible to upload multiple public keys to your remote server, allowing one or more users to log in without a password from different computers.

Step # 1: Generate first ssh key

Type the following command to generate your first public and private key on a local workstation. Next provide the required input or accept the defaults. Please do not change the filename and directory location.
workstation#1 $ ssh-keygen -t rsa
Finally, copy your public key to your remote server using scp
workstation#1 $ scp ~/.ssh/id_rsa.pub user@remote.server.com:.ssh/authorized_keys

Step # 2: Generate next/multiple ssh key

a) Login to 2nd workstation

b) Download original the authorized_keys file from remote server using scp:
workstation#2 $ scp user@remote.server.com:.ssh/authorized_keys ~/.ssh

c) Now create the new pub/private key:
workstation#2 $ ssh-keygen -t rsa

d) Now you have new public key. APPEND this key to the downloaded authorized_keys file using cat command:
workstation#2 $ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

e) Finally upload authorized_keys to remote server again:
workstation#2 $ scp ~/.ssh/authorized_keys user@remote.server.com:.ssh/

You can repeat step #2 for each user or workstations for remote server.

Step #3: Test your setup

Now try to login from Workstation #1, #2 and so on to remote server. You should not be asked for a password:
workstation#1 $ ssh user@remote.server.com
workstation#2 $ ssh user@remote.server.com

Updated for accuracy.

Usually you run mysqldump to create a database copy and backups as follows:
[click to continue…]

HowTo: Tunneling VNC Connections Over SSH

Virtual Network Computing (VNC) is a desktop sharing system which uses the RFB (Remote FrameBuffer) protocol to remotely control another computer. It transmits the keyboard presses and mouse clicks from one computer to another relaying the screen updates back in the other direction, over a network.
[click to continue…]