SSH - Deister KB http://kb.deister.net/index.

php/SSH

SSH
De Deister KB

OpenSSH es un substituto seguro a protocolos obsoletos como son telnet y rsh. Desde hace ya algún tiempo, se ha convertido en el estándar
de-facto como servicio de login remoto para Linux, BSD y otras variantes *nix.

La mayoría de los sistemas Linux instalan OpenSSH como parte de su distribución. Aunque telnet y rsh todavia se incluyen, se desaconseja
su uso para el acceso remoto, siendo una mejor idea la utilización de protocolos seguros como los ofrecidos por OpenSSH.

Sin embargo, uno de los posibles problemas de OpenSSH es el exceso de complejidad. OpenSSH ofrece multitud de opciones tanto en el
cliente como en el servidor, y estas opciones hacen que el uso de OpenSSH pueda resultar algo complicado.

desde luego, el uso de OpenSSH puede ser tan sencillo o complejo como usted quiera. A continuación, intentaremos simplificarle el uso de
OpenSSH y al mismo tiempo obtener las ventajas de todas las características que ofrece.

Contenido
1 The Passwordless Entry... Utilización de claves públicas/privadas
2 Utilización de agentes
3 X and Port Forwarding
4 SSH desatendido
5 Configuración del cliente
6 Configuración del servidor
7 Configurar permiso de login para usuario root vía ssh
8 Denegar permiso de login vía ssh
9 Secure your SSH server with Public/Private key authentification
10 How-To: Customizing SSH client
11 Preguntas frecuentes
11.1 SSH sin preguntar clave
12 Problemas
12.1 /usr/bin/xauth: timeout in locking authority file homedir/.Xauthority
13 Conclusión

The Passwordless Entry... Utilización de claves públicas/privadas

Una de las mejores características de OpenSSH es su habilidad para usar claves publicas para conectar (login) con un servidor remoto.
OpenSSH encripta todo el tráfico, asegurándonos que el password enviado a través de la red está asegurado. Mediante el uso de claves, se
elimina la necesidad de enviar el password a través de la red para obtener acceso al sistema remoto. También es un sistema mucho más seguro
que la utilización de un password ya que alguien podría intentar acceder a un sistema remoto intentando enviar passwords mediante fuerza
bruta, o incluso podria llegar a conocer su password.

Por ejemplo, imagine que usted es el administrador de un determinado servidor. Normalmente accedera a dicho servidor mediante SSH para
realizar tareas de mantenimiento. Este servidor es tambien un servidor de correo del cual obtiene sus correos electrónicos. Mientras que usted
es lo suficientemente listo al conectar al servidor mediante SSH para proteger toda la información transmitida por la red, utiliza un cliente
POP3 normal y corriente para recuperar su correo electrónico. La mayoría de gente sabe que este no es un buen método ya que todo el tráfico
del protocolo POP3 se envia sin cifrar y el password de la cuenta POP3 se envia también sin encriptar y sin ningún tipo de seguridad. Como
la cuenta POP3 esta vinculada a su usuario de sistema operativo, obteniendo el password de la cuenta POP3 obtendriamos el password del
login de usuario quedando el acceso al servidor totalmente desprotegido.

Aunque este es el peor escenario de todos, puede demostrar que las ventajas de las claves SSH son obvias. El primer paso a dar para llegar a
tener conexiones SSH sin password es generar una pareja de claves: la pública y la privada. SSH utiliza tres tipos de clave: RSA1, RSA2 y
DSA. Se aconseja no usar en absoluto las claves de tipo RSA1 y por lo tanto deberian usarse claves de tipo RSA2 y DSA. Nosotros
preferimos el uso de claves DSA. La diferencia entre las claves RSA1 y RSA2 es el protocolo SSH que utilizan. Las claves RSA1 utilizan
SSH protocolo 1, y las claves RSA2 utilizan SSH protocolo 2. Las claves DSA solamente pueden utilizarse con SSH protocolo 2.

Para generar una pareja de claves DSA, ejecute (debe ser el usuario al que se le asigne la pareja de claves):

$ ssh-keygen -t dsa

1 de 10 21/06/2018 14:13
SSH - Deister KB http://kb.deister.net/index.php/SSH

Este comando generará por defecto una clave DSA de 1024 bits con la clave privada almacenada en ~/.ssh/id_dsa y la clave pública
almacenada en ~/.ssh/id_dsa.pub. Si desea generar una clave RSA, utilice "-t rsa" en lugar de los parametros mostrados anteriormente, y si
desea generar una clave RSA1, utilice "-t rsa1".

Se le preguntará por una clave (passphrase) para asegurar la clave privada.

$ ssh-keygen -p -f ~/.ssh/id_dsa

$ ssh-add -l id_dsa.pub
1024 61:ed:d2:82:35:b4:54:3d:92:26:f8:48:69:21:de:c3 /home/joe/.ssh/id_dsa (DSA)

Utilización de agentes
$ ssh-agent
$ ssh-add

# .bashrc

# User specific aliases and functions

# Source global definitions

if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi

/usr/bin/keychain -quiet ~/.ssh/id_dsa

. ~/.ssh-agent-${HOSTNAME}

X and Port Forwarding

Probablemente, una de las caracteristicas más interesantes de SSH es su habilidad para crear tuneles seguros para transportar protocolos
inseguros. Por ejemplo, se sabe que el protocolo POP3 es inseguro porque los passwords viajan por la red sin encriptar. Si dispone de acceso
a la shell del servidor POP3 del que va a recoger el correo, puede utilizar un tunel SSH para pasar los datos del protocolo POP3 a través del
SSH del equipo remoto al local. Algo similar ocurre con las aplicaciones X; puede conectarse a una máquina remota mediante SSH y ejecutar
una aplicación X en el sistema remoto, abriendose esta aplicación en display del equipo local.

Esta característica del SSH es extremadamente potente ya que permite utilizar protocolos inseguros de forma totalmente segura, sin tener que
abrir puertos adicionales en el firewall y sin tener que relajar la seguridad o utilizar tráfico de red no encriptado.

Por ejemplo, imagine que desea encapsular las conexiones a su servidor POP3 mediante SSH. Esto puede hacerse si dispone de una conexión
SSH a su servidor POP3. El primer paso es elegir un puerto local entre 1024 y 65535; que son los puertos que pueden utilizar los usuarios sin
privilegios de root. Por ejemplo, puede utilizar el puerto numero 10110. Cree un tunel SSH como este:

$ ssh -L10110:localhost:110 remotesystem

Esto crea un tunel que enlaza el puerto 10110 de localhost al puerto 110 del sistema remoto "remotesystem". Además abrirá una conexión
SSH normal al host remoto. Si utiliza la herramienta netstat, podrá ver que el puerto esta realmente abierto y escuchando las conexiones:

[user@mdkhost user]$ netstat -l --tcp -p|grep ssh

(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 *:ssh *:* LISTEN -
tcp 0 0 localhost.localdo:10110 *:* LISTEN 31295/ssh
[user@mdkhost user]$

Cuando salga de la shell SSH, la conexión reenviada (forwarded) también se cerrará. Sin embargo, antes de que salga de la shell, su cliente
email puede recuperar el correo POP3; no conectandose a remotesystem:110, sino conectandose a localhost:10110.

2 de 10 21/06/2018 14:13
SSH - Deister KB http://kb.deister.net/index.php/SSH

No siempre nos interesa tener una sesión de shell abierta, para reenviar el trafico de un puerto local a un puerto de un equipo remoto. Puede
querer usar el cron para recuperar sus correos y no quiere abrir una shell de SSH en el host remoto. Para conseguirlo, debe utilizar un
comando ssh adecuado. Existen dos formas distintas de conseguirlo: "reenvio persistente" o "reenvio temporal".

Con el método "reenvio temporal", podrá abrir el tunel durante un espacio corto de tiempo, simplemente para permitir a su cliente de correo
conectar al host remoto via este tunel. Por ejemplo:

$ ssh -f -L10110:localhost:110 remotesystem sleep 10

Esto indica a SSH que se ejecute en segundo plano (-f), abra el tunel y ejecute el comando "sleep 10". Normalmente, una vez este comando
termina, SSH terminará tambien la sesión. Sin embargo, si el programa de correo utiliza el tunel dentro de estos 10 segundos, SSH esperará a
que termine la conexión antes de salir. Esto le permite utilizar el tunel durante el tiempo en que esté activo su cliente de correo, pero no deja
el tunel abierto durante un espacio de tiempo prolongado. Por otro lado, si recupera el correo cada pocos minutos, puede ser más conveniente
mantener una conexión persistente. Puede conseguir esto, dando al comando sleep un número más alto de segundos, como por ejemplo
100000.

El reenvio de ventanas X11 funciona según el mismo principio. Para permitir reenviar los paquetes X11 debe asegurarse de que en el fichero
de configuración del cliente (/etc/ssh/ssh_config) tiene inicializado el parámetro ForwardX11 a "yes" en todos los equipos y que en el fichero
de configuración general (/etc/ssh/sshd_config), el parámetro X11Forwarding está también inicializado a "yes".

Cuando se conecta mediante ssh a un equipo remoto, puede ejecutar los programas X11 desde la linea de comandos, igual que si lo estuviera
haciendo desde una ventana xterm. En el equipo local, la variable DISPLAY se utiliza para decir a las aplicaciones X11 en que pantalla se van
a visualizar. En el equipo local la variable DISPLAY puede estar inicializada a ":0". En el equipo remoto, cuando se conecta mediante SSH, el
valor de la variable DISPLAY puede ser algo similar a "localhost:11.0". De nuevo, se utiliza el mecanismo "mágico" del reenvio que es
transparente a las aplicaciones que usted ejecute. Como en casi todas las cosas de *nix, hay diversos mecanismos para ejecutar aplicaciones
X11 remotas. La primera es seguramente la mas extendida, y se trata de conectar mediante SSH al sistema remoto y ejecutar el comando:

[user@mdkhost user]$ ssh user@remotesystem

[user@remotesystem user]$ gkrellm &

Este ejemplo muestra como conectar el equipo remoto "remotesystem" como usuario "user" y ejecutar gkrellm, un monitor gráfico del
sistema. Tenga en cuenta el carácter "&" al final del comando para indicar que la aplicación gkrellm se ejecute en segundo plano. Un sistema
más eficiente de lanzar gkrellm de forma remoto puede hacerse ejecutando:

[user@mdkhost user]$ ssh -f user@remotesystem gkrellm

Mediante este mecanismo, puede cerrar la aplicación xterm que ha utilizado para ejecutar ssh, dejando gkrellm ejecutandose en su pantalla
porque ssh se ejecuta en segundo plano. Si desea cerrar la conexión, cierre simplemente el programa o mate la conexión ssh.

SSH desatendido
Hay ocasiones en las que se desea utilizar una conexión SSH sin tener que entrar la palabra clave (passphrase). Un ejemplo de ello, podrian
ser los backups en equipos remotos mediante conexiones SSH, o la ejecución de comandos en equipos remotos a través del cron del equipo
local. En estos casos, puede querer crear un nuevo usuario especial para ejecutar estas tareas; un usuario que no pueda acceder al equipo local.

Por ejemplo, suponga que quiere ejecutar un backup cada noche utilizando rsync sobre ssh. Deberia crear un ususario con el nombre "backup"
o "mirror" o algo similar. Despues, crear una nueva pareja de claves SSH para este usuario con una palabra clave (passphrase) vacia. Copie
esta clave de usuario en el equipo remoto. Dependiendo de los permisos de los ficheros de los que quiera hacer backup, tal vez tenga que
añadir esta clave de usuario en el fichero de configuración del usuario root ~/.ssh/authorized_keys en la maquina remota. Tenga en cuenta de
que esto da al usuario acceso inmediato sin password al usuario root del equipo remoto!. Esto puede constituir un grave agujero de seguridad
si no configura las cosas adecuadamente.

Ahora que este usuario tiene acceso a la cuenta de root en el equipo remoto, puede escribir un script y asociarlo mediante una entrada en el
crontab para ejecutar el backup. Por ejemplo, podria ejecutar el script mostrado a continuación diariamente como el usuario "backup":

#!/bin/sh
RSYNC="/usr/bin/rsync -aP --quiet --delete -l -t -e ssh"

cd /data/backup/host
$RSYNC root@host:/etc .
$RSYNC root@host:/home .
...

3 de 10 21/06/2018 14:13
SSH - Deister KB http://kb.deister.net/index.php/SSH

De este modo, el script puede ser ejecutado por el usuario "backup" cada noche. Se ejecutará correctamente porque no hay ninguna palabra
clave (passphrase) definida en la clave privada del usuario, y la clave publica esta en el fichero authorized_keys del usuario root en el equipo
remoto. El siguiente paso es asegurar la cuenta del usuario backup. El primer paso es modifica rel fichero /etc/ssh/sshd_config y añadir esta
linea:

DenyUsers backup

Esto impide que nadie pueda acceder al sistema por esta cuenta a través de SSH. A continuación, edite el fichero /etc/passwd para desactivar
la posibilidad de acceso al sistema por esta cuenta a través de la consola. Para hacer esto, ejecute como root el programa vi /etc/passwd y
localize la linea correspondiente al usuario "backup".

El segundo campo "x", representa el password enmascarado, Sin embargo, podemos cambiar la "x" por un "*" lo que desactiva el login para
la cuenta.

backup:*:512:512:Backup User:/home/backup:/bin/bash

Al final lo que hemos conseguido es lo siguiente: el usuario "backup" no puede conectarse al sistema local ni via SSH ni mediante la consola
de comandos. Todavia puede utilizar "su" para cambiar a este usuario, que es por lo que mantenemos el password del usuario; usuarios que no
sean root, todavia tienen que suministrar el password para poder cambiar a "backup". Por ello, haga este password lo más críptico posible ya
que si tiene acceso como usuario root al sistema, no tendrá que recordar este password para cambiar al usuario "backup"

Configuración del cliente

La configuración del cliente se hace mediante la manipulación de tres ficheros:

/etc/ssh/ssh_config, que es el fichero de configuración de todo el sistema.

~/.ssh/config which que es la configuración SSH personal de cada usuario.
~/.ssh/authorized_keys que permite configurar las conexiones entrantes para este cliente.

Mandrake linux ofrece por defecto de un fichero de configuración que permite a los usuarios realizar el reenvio de paquetes X11. A
continuación mostramos el fichero de configuración de todo el sistema para poder hacer esto:

Host *
ForwardX11 yes
Protocol 2,1
StrictHostKeyChecking no

La pagina de man ssh_config(5) explica detalladamente cada opción. Básicamente, este fichero indica a SSH que permita el reenvio de
paquetes X11, que utilice por defecto el protocolo 2 y si este protocolo no está que intente con el 1 y que deshabilite la verificación estricta de
las claves de los equipos en cada conexión remota. A pesar de asignar el valor "no" a StrictHostKeyChecking, el sistema le avisará cada vez
que conecte a un servidor y este devuelva una clave distinta a la que tiene informada en el fichero ~/.ssh/known_hosts. Si es un poco
paranoico con la seguridad, aunque no quiere llegar al extermo, puede cambiar este valor de "no" a "ask".

Host [host]
options
...

Host [host2]
options
...

A continuación se muestra un ejemplo del fichero ~/.ssh/config:

Host devel
HostName myserver.mydomain.com
User special

Host otherserver.mydomain.com
User admin
ForwardAgent no
Port 220
ForwardX11 no

4 de 10 21/06/2018 14:13
SSH - Deister KB http://kb.deister.net/index.php/SSH

Host *.mydomain.com
ForwardAgent yes
Compression yes
<pre>

{| class="wikitable"
! Hostname
! User
! ForwardAgent
! ForwardX11
! Port
! Compression
! Protocol
! StrictHostKeyChecking
|-
| myserver.mydomain.com
|| special
|| yes
|| yes
|| 22
|| yes
|| 2,1
|| no
|-
| otherserver.mydomain.com
|| admin
|| no
|| no
|| 220
|| yes
|| 2,1
|| no
|-
| myhost.mydomain.com
|| user
|| yes
|| yes
|| 22
|| yes
|| 2,1
|| no
|-
| otherhost.otherdomain.com
|| user
|| no
|| yes
|| 22
|| no
|| 2,1
|| no
|}

<pre>
ssh-dss AAAAB3NxaC1kc3M...mc= user@somehost.com

command="/usr/bin/rsync" ...key...

command="/root/remote-rsync" ...key...

El contenido de /root/remote-rsync debe ser:

#!/bin/sh
if echo $SSH_ORIGINAL_COMMAND|grep -e "^rsync " >/dev/null 2>&1; then
$SSH_ORIGINAL_COMMAND
else
echo "No access. Sorry."

5 de 10 21/06/2018 14:13
SSH - Deister KB http://kb.deister.net/index.php/SSH

fi

rsync --server --sender -vlogDtpr --delete --partial . /etc

Configuración del servidor

Port 22
Protocol 2,1
HostKey /etc/ssh/ssh_host_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 600
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
RhostsAuthentication no
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PasswordAuthentication yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PAMAuthenticationViaKbdInt no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd yes
KeepAlive yes
UsePrivilegeSeparation yes
Compression yes
Subsystem sftp /usr/lib/ssh/sftp-server

AllowUsers joe
AllowUsers jim@remotehost.com

AllowGroups sshusers
DenyGroups users

Configurar permiso de login para usuario root vía ssh

Si la máquina tiene el servicio open-ssh activo, si se trata de un equipo que està en internet, conviene que no acepte acceso de login del
usuario root.

Para permitir o no el acceso, hay que editar el fichero /etc/ssh/sshd_config y modificar el valor del parámetro PermitRootLogin con el valor:

no: para denegar el acceso.

yes: para permitir el acceso.

Si la máquina tiene el servicio open-ssh activo, si se trata de un equipo que està en internet, conviene que no acepte acceso de login del
usuario root.

Denegar permiso de login vía ssh

En el título anterior se explica como prohibir el acceso al usuario root vía ssh. Si se desea que otro/s usuario/s tampoco puedan acceder es

6 de 10 21/06/2018 14:13
SSH - Deister KB http://kb.deister.net/index.php/SSH

suficiente añadir en el fichero /etc/ssh/sshd_config el parámetro DenyUsers con la lista de usuario/s a los que se les prohibe el acceso,
separados por un espacio.

DenyUsers jas informix

Esto es recomendable para máquinas que son accesibles desde internet y tienen aplicaciones de software con usuarios conocidos, como por
ejemplo informix, oracle, admin ...

Secure your SSH server with Public/Private key authentification

A neat feature of open SSH is to authenticate a user using a public/private key pair to log into the remote host. By doing so, you won’t be
prompted for the remote user’s password.

This tutorial will describe how to create a SSH public/private key pair, how to enable key based authentication and finally how to disable
password authentication.

Even though SSH is secured, there is tons of brute force attacks against SSH server which will attempt to gain access to your machine. By
using key based authentication and by disabling the standard user/password authentication, you will reduce the risk of having someone
gaining access to your machine.

This tutorial suppose that you already have your remote machine running a SSH server. If not, make sure your remote host has openssh
server.

1. Generating a SSH key public/private key pair: Before we can even authenticate to the remote machine using key based
authentication, we need to create a public/private key pair. To do so, simply trigger:

user@host$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX user@host

Mind that if you leave the passphrase empty, anybody getting you private key (/home/user/.ssh/id_rsa) will be able to connect to
your remote host.

I would recommend that you enter a passphrase, this passphrase will be use to “unlock” the key, mind that this passphrase is not
related to the remote user password.

By now, you should have id_rsa and id_rsa.pub in ~/.ssh directory.

id_rsa is the so called private key. id_rsa.pub is the public key, the one you are going to upload on your server in order to be able to
gain access to the remote machine using key authetication.

Do not share your private key, this key has to be your own, nobody but you will need to use it. The need of a passphrase will save
you a lot of trouble in case you lost it.

2. Adding the public key to the authorized key: In the first place, we need to upload the key to the remote machine:

user@host:~$ scp ~/.ssh/id_rsa.pub remoteuser@remotehost:~/

Now, the public key is uploaded, let’s add it to the authorized keys. To do so, we are going to connect to remotehost as remoteuser
and add the key at the end of file ~/.ssh/authorized_keys and delete it once added:

ssh remoteuser@remotehost
remoteuser@remotehost’s password:
remoteuser@remotehost:~$ cat id_rsa.pub >> ~/.ssh/authorized_keys

Now, we need to configure the remote SSH server to accept authentication by key pair. This is usually enabled by default. If not, the

7 de 10 21/06/2018 14:13
SSH - Deister KB http://kb.deister.net/index.php/SSH

next section will cover how to activate key based authentication.

3. Activating key based authentication on the server: To do so, we need to connect as root on the remote machine. This can be
achieved either by connecting to root directly:

ssh root@remotehost

Now open and edit /etc/ssh/sshd_config and make sure you have the following line:

RSAAuthentication yes
PubkeyAuthentication yes

Then reload your configuration:

$ service sshd restart

4. Disabling Authentication by password: In order to disable authentication by password, we need to connect as root on the remote
machine. On connected, go and edit /etc/ssh/sshd_config and make sure you have the following setting:

ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

and reload SSH configuration file:

$ service sshd restart

Now, open a new shell and connect the remote host using your private key:

user@host:~$ ssh remoteuser@remotehost

remoteuser@remotehost:~$

and check that you can’t connect without a key anymore:

$ cd ~/.ssh
$ mv id_rsa id_rsa.bck
$ ssh remoteuser@remotehost
Permission denied (publickey).
$ mv id_rsa.bck id_rsa

If you get rejected with Permission denied (publickey). it means it is all good and your ssh server is protected against brute-force
attacks.

5. Conclusion: By authenticating yourself using a public/private key pair and by disabling authentication by password you will
considerably reduce the chance an attacker gain access to your remote machine. It is wise to provide a passphrase when creating your
key pair, this way, even if somebody get a copy of your private key, you will reduce the risk of having him gaining access to your
remote machine.

How-To: Customizing SSH client

SSH is great. There is so many thing you can do with it other than just a remote secure shell like X forwarding, port forwarding, authenticate
using a private/public key, compress the transmitted stream….

If you have different account that you use on an every day basis, it becomes quickly cumbersome to type those lengthly command lines.

One could work around this by using aliases, the right way would be to use ~/.ssh/config

This tutorial will show some customization examples that should cover most ssh use cases.

8 de 10 21/06/2018 14:13
SSH - Deister KB http://kb.deister.net/index.php/SSH

All along this tutorial, the changes will be made in ~/.ssh/config and will therefore be available only for your user. If you wish to make
changes server wide, you will have to edit /etc/ssh/ssh_config .

1. A simple example: Most of your ssh connection might look like: $ ssh user1@server1.example.com By adding the following to your
~/.ssh/config :

Host server1
Hostname server1.example.com
User user1

You can shorten the typing to:

$ ssh server1

2. Adding Public/Private key authentication: If you identity file is named ~/.ssh/id_rsa or ~/.ssh/id_dsa , those file will be tried
automatically by ssh. In case you have different key files, you have to inform ssh about it with -i , which look like:

$ ssh -i ~/.ssh/id_rsa_server2 user2@server2.example.com

Adding the following to ~/.ssh/config :

Host server2
Hostname server2.example.com
User user2
IdentityFile ~/.ssh/id_rsa_server2

will allow you to type:

$ ssh server2

to get the same result.

3. Port Forwarding: Forwarding port with ssh requires a command line like:

$ ssh -L 8888:127.0.0.1:7777 -i .ssh/id_rsa_server3 user3@server3.example.com

The following in ~/.ssh/config :

Host server3
Hostname server3.example.com
User user3
IdentityFile ~/.ssh/id_rsa_server3
Localforward 8888 127.0.0.1:7777

will shorten the command to:

$ ssh server3

Preguntas frecuentes
SSH sin preguntar clave
En ocasiones, necesitará conectarse a otros equipos mediante SSH a través de scripts que realizan operaciones administrativas en los equipos
remotos. En estos casos, el problema es que SSH pregunta la clave de acceso y el script no puede seguir.

Para solucionar el problema, lo más adecuado utilizar autenticación por clave pública. Para ello hay que seguir los siguientes pasos:

1. desde la máquina desde la que vas a usar el cliente SSH deben generarse el par de claves privada/pública invocando ssh-keygen -t

9 de 10 21/06/2018 14:13
SSH - Deister KB http://kb.deister.net/index.php/SSH

rsa. Con eso tendrá en su directorio .ssh un fichero id_rsa con la clave privada, que se va a quedar ahí y no debe poder leer nadie más
que usted, y un fichero id_rsa.pub, que es la clave pública y hay que subir a los servidores a donde desee conectarse.
2. Sube con scp el fichero id_rsa.pub a la máquina a la que se quiera conectar. Conectese a eicha máquina y ejecute cat id_rsa.pub >>
/root/.ssh/authorized_keys. Con eso está indicando que quien se conecte con esa clave tendrá acceso garantizado. En el fichero
authorized_keys hay una línea por clave autorizada, de modo que si varias personas necesitan utilizar la cuenta puede tener cada uno
su clave y no hace falta compartirla. Además, podemos poner al comienzo de la línea opciones separadas por comas orientadas a
limitar la conexión vía SSH con esa clave. Por ejemplo si insertamos from="192.178.10.7",command="setup" sólo se podrán
conectar con esa clave usuarios desde la máquina 192.178.10.7 y no podrán ejecutar ningún otro comando (ni transferir archivos) que
no sea setup.
3. Asegúrese de que todos los permisos están fijados correctamente. Lo mejor es que al fichero .ssh sólo tenga acceso de lectura el
propio usuario y lo mismo a los ficheros que contiene.

Problemas
/usr/bin/xauth: timeout in locking authority file homedir/.Xauthority
Si se realiza una conexión SSH a través de CRT o PUTTY y se produce un tiempo de espera largo hasta que se realiza el login puede ser por
éste motivo

/usr/bin/xauth: timeout in locking authority file .Xauthority

Se soluciona con el siguiente comando

restorecon homedir
restorecon homedir/.Xauthority

Conclusión
Como seguramente ya habrá observado, OpenSSH no es un programa simple. Es un programa extremadamente configurable y potente. Para
obtener lo mejor de OpenSSH, deberá investigar en las págimas de ayuda (man pages) y en los ficheros de configuración; existe mucha
información oculta en estos documentos que le ayudara a administrar OpenSSH. Afortunadamente, este documento muestra algunas de las
caracteristicas más interesantes de OpenSSH y le sirva para darse una ligera idea de lo que puede llegar a hacer OpenSSH.

Por último, debe tener en cuenta de que cada vez que modifique el fichero de configuración sshd_config, debe asegurarse de que reinicia el
servicio sshd ejecutando como root el comando: "service sshd restart". Las modificaciones en los ficheros de configuración de usuario como
por ejemplo, ~/.ssh/authorized_keys y ~/.ssh/config no requieren la reiniciación del servicio.

Obtenido de «http://kb.deister.net/index.php?title=SSH&oldid=4827»

Esta página fue modificada por última vez el 11 jun 2013, a las 09:24.
Esta página ha sido visitada 11.940 veces.
Política de protección de datos
Acerca de Deister KB
Aviso legal

10 de 10 21/06/2018 14:13