Una de SSH

[Orestes Mas-2]

Hola,

Tinc un contenciós amb el SSH que m'està portant de cap. A veure si algú de
vosaltres hi veu la llum.

La cosa és senzilla d'explicar: vull connectar via ssh a un servidor, i vull
fer-ho sense password, és a dir amb clau ssh. Sé com fer-ho, i ho he fet
altres vegades: Em genero un parell de claus RSA pública/privada, i copio la
clau pública al fitxer .ssh/authorized_keys del servidor, però no hi ha
manera. SEMPRE EM DEMANA EL PASSWORD. Abans que feu les vostres hipòtesis,
deixeu-me dir el següent.

- No sembla un problema de permisos dels fitxers, atès que la cosa funciona
cap a altres servidors, i els fitxers implicats tenen els mateixos permisos
(700 el directori .ssh i 600 els fitxers implicats).

- Les claus estan ben generades. He repetit el procés diverses vegades, i amb
altres 2 servidors funciona sense problemes.

- No sembla cosa dels paràmetres del servidor SSH, perquè me'ls he repassat i
no hi veig res estrany o diferent als altres servidors.

- AQUESTA ÉS BONA: Si intento establir una sessió ssh per primer cop,
l'autenticació per clau falla i em demana el password, però un cop establida,
si provo d'establir-ne una segona des d'un altre terminal, ALESHORES
FUNCIONA!! És de bojos.

Si voleu els logs..., però no hi veig res estrany:

Quan no funciona:
debug1: Reading configuration data /home/orestes/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to xx.xx.xx.xx [xx.xx.xx.xx] port 22.
(**una mica de privacitat, que la llista és pública**)
debug1: Connection established.
debug1: identity file /home/orestes/.ssh/identity type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/orestes/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/orestes/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1
Debian-5ubuntu1
debug1: match: OpenSSH_5.1p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'xx.xx.xx.xx' is known and matches the RSA host key.
debug1: Found key in /home/orestes/.ssh/known_hosts:29
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/orestes/.ssh/identity
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /home/orestes/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/orestes/.ssh/id_dsa
debug1: Next authentication method: password
orestes@...'s password:


I quan funciona (és a dir amb una altra sessió establerta):
debug1: Reading configuration data /home/orestes/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config      
debug1: Applying options for *                              
debug1: Connecting to xx.xx.xx.xx [xx.xx.xx.xx] port 22.
debug1: Connection established.                              
debug1: identity file /home/orestes/.ssh/identity type 1      
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048      
debug1: identity file /home/orestes/.ssh/id_rsa type 1          
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/orestes/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1
Debian-5ubuntu1
debug1: match: OpenSSH_5.1p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'xx.xx.xx.xx' is known and matches the RSA host key.
debug1: Found key in /home/orestes/.ssh/known_hosts:29
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/orestes/.ssh/identity
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@...
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = ca_ES.UTF-8
(i aquí ve el prompt del bash)

No ho trobeu estrany? Algú té alguna idea?

--
 Orestes Mas Casals - UPC


--
To UNSUBSCRIBE, email to debian-user-catalan-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Sergi Tur Badenas]

En/na Orestes Mas ha escrit:
> Hola,
>
> Tinc un contenciós amb el SSH que m'està portant de cap. A veure si algú de
> vosaltres hi veu la llum.
>
>
> - No sembla un problema de permisos dels fitxers, atès que la cosa funciona
> cap a altres servidors, i els fitxers implicats tenen els mateixos permisos
> (700 el directori .ssh i 600 els fitxers implicats).

Has provat d'utilitzar la comanda ssh-copy-id [1]. És molt còmoda i et
fa tota la feina... Potser així et funciona... Jo abans de conèixer la
comanda tot ho feia a mà i de tant en tant tenia algun problema
(segurament per no seguir correctament algun pas)

[1]
http://acacha.org/mediawiki/index.php/Gesti%C3%B3_Remota._SSH,_RSYNC,_X-WINDOWS#ssh-copy-id

--
Sergi Tur http://acacha.org/mediawiki


--
To UNSUBSCRIBE, email to debian-user-catalan-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[rpb-3]

Si que és estrany... suposo que deus haver mirat i remirat el
/etc/ssh/sshd_config de la banda del servidor... dono per suposat que
deus tenir:
RSAAuthentication yes
PubkeyAuthentication yes

Per provar, pots deshabilitar completament l'autenticació per
password, que si no recordo malament era posant:
PasswordAuthentication no

Comprova que la copia de la clau a authorized_keys sigui correcta.
Pots provar-ho amb
$ssh-copy-id -i id_rsa.pub user@host

T'envio el resultat de debugar les meves connexions per si et dóna alguna pista:

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/rpb/.ssh/identity
debug1: Offering public key: /home/rpb/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@...
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = ca_ES.UTF-8

Ricard


El 5 / setembre / 2009 18:10, Orestes Mas<orestes@...> va escriure:

> Hola,
>
> Tinc un contenciós amb el SSH que m'està portant de cap. A veure si algú de
> vosaltres hi veu la llum.
>
> La cosa és senzilla d'explicar: vull connectar via ssh a un servidor, i vull
> fer-ho sense password, és a dir amb clau ssh. Sé com fer-ho, i ho he fet
> altres vegades: Em genero un parell de claus RSA pública/privada, i copio la
> clau pública al fitxer .ssh/authorized_keys del servidor, però no hi ha
> manera. SEMPRE EM DEMANA EL PASSWORD. Abans que feu les vostres hipòtesis,
> deixeu-me dir el següent.
>
> - No sembla un problema de permisos dels fitxers, atès que la cosa funciona
> cap a altres servidors, i els fitxers implicats tenen els mateixos permisos
> (700 el directori .ssh i 600 els fitxers implicats).
>
> - Les claus estan ben generades. He repetit el procés diverses vegades, i amb
> altres 2 servidors funciona sense problemes.
>
> - No sembla cosa dels paràmetres del servidor SSH, perquè me'ls he repassat i
> no hi veig res estrany o diferent als altres servidors.
>
> - AQUESTA ÉS BONA: Si intento establir una sessió ssh per primer cop,
> l'autenticació per clau falla i em demana el password, però un cop establida,
> si provo d'establir-ne una segona des d'un altre terminal, ALESHORES
> FUNCIONA!! És de bojos.
>
> Si voleu els logs..., però no hi veig res estrany:
>
> Quan no funciona:
> debug1: Reading configuration data /home/orestes/.ssh/config
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug1: Connecting to xx.xx.xx.xx [xx.xx.xx.xx] port 22.
> (**una mica de privacitat, que la llista és pública**)
> debug1: Connection established.
> debug1: identity file /home/orestes/.ssh/identity type 1
> debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
> debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
> debug1: identity file /home/orestes/.ssh/id_rsa type 1
> debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
> debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
> debug1: identity file /home/orestes/.ssh/id_dsa type -1
> debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1
> Debian-5ubuntu1
> debug1: match: OpenSSH_5.1p1 Debian-5ubuntu1 pat OpenSSH*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: server->client aes128-cbc hmac-md5 none
> debug1: kex: client->server aes128-cbc hmac-md5 none
> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
> debug1: Host 'xx.xx.xx.xx' is known and matches the RSA host key.
> debug1: Found key in /home/orestes/.ssh/known_hosts:29
> debug1: ssh_rsa_verify: signature correct
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue: publickey,password
> debug1: Next authentication method: publickey
> debug1: Offering public key: /home/orestes/.ssh/identity
> debug1: Authentications that can continue: publickey,password
> debug1: Offering public key: /home/orestes/.ssh/id_rsa
> debug1: Authentications that can continue: publickey,password
> debug1: Trying private key: /home/orestes/.ssh/id_dsa
> debug1: Next authentication method: password
> orestes@...'s password:
>
>
> I quan funciona (és a dir amb una altra sessió establerta):
> debug1: Reading configuration data /home/orestes/.ssh/config
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug1: Connecting to xx.xx.xx.xx [xx.xx.xx.xx] port 22.
> debug1: Connection established.
> debug1: identity file /home/orestes/.ssh/identity type 1
> debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
> debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
> debug1: identity file /home/orestes/.ssh/id_rsa type 1
> debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
> debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
> debug1: identity file /home/orestes/.ssh/id_dsa type -1
> debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1
> Debian-5ubuntu1
> debug1: match: OpenSSH_5.1p1 Debian-5ubuntu1 pat OpenSSH*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: server->client aes128-cbc hmac-md5 none
> debug1: kex: client->server aes128-cbc hmac-md5 none
> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
> debug1: Host 'xx.xx.xx.xx' is known and matches the RSA host key.
> debug1: Found key in /home/orestes/.ssh/known_hosts:29
> debug1: ssh_rsa_verify: signature correct
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue: publickey,password
> debug1: Next authentication method: publickey
> debug1: Offering public key: /home/orestes/.ssh/identity
> debug1: Server accepts key: pkalg ssh-rsa blen 277
> debug1: Authentication succeeded (publickey).
> debug1: channel 0: new [client-session]
> debug1: Requesting no-more-sessions@...
> debug1: Entering interactive session.
> debug1: Sending environment.
> debug1: Sending env LANG = ca_ES.UTF-8
> (i aquí ve el prompt del bash)
>
> No ho trobeu estrany? Algú té alguna idea?
>
> --
>  Orestes Mas Casals - UPC
>
>
> --
> To UNSUBSCRIBE, email to debian-user-catalan-REQUEST@...
> with a subject of "unsubscribe". Trouble? Contact listmaster@...
>
>

--
To UNSUBSCRIBE, email to debian-user-catalan-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Oscar Osta Pueyo-2]

Hola,

El 6 / setembre / 2009 14:18, Ricard Pradell <rpbsant@...> ha escrit:

Si que és estrany... suposo que deus haver mirat i remirat el
/etc/ssh/sshd_config de la banda del servidor... dono per suposat que
deus tenir:
RSAAuthentication yes
PubkeyAuthentication yes

Per provar, pots deshabilitar completament l'autenticació per
password, que si no recordo malament era posant:
PasswordAuthentication no

Comprova que la copia de la clau a authorized_keys sigui correcta.
Pots provar-ho amb
$ssh-copy-id -i id_rsa.pub user@host

T'envio el resultat de debugar les meves connexions per si et dóna alguna pista:

debug1: Authentications that can continue: publickey

debug1: Next authentication method: publickey

debug1: Trying private key: /home/rpb/.ssh/identity
debug1: Offering public key: /home/rpb/.ssh/id_rsa

debug1: Server accepts key: pkalg ssh-rsa blen 277

debug1: read PEM private key done: type RSA

debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@...
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = ca_ES.UTF-8

Ricard


El 5 / setembre / 2009 18:10, Orestes Mas<orestes@...> va escriure:

> Hola,
>
> Tinc un contenciós amb el SSH que m'està portant de cap. A veure si algú de
> vosaltres hi veu la llum.
>
> La cosa és senzilla d'explicar: vull connectar via ssh a un servidor, i vull
> fer-ho sense password, és a dir amb clau ssh. Sé com fer-ho, i ho he fet
> altres vegades: Em genero un parell de claus RSA pública/privada, i copio la
> clau pública al fitxer .ssh/authorized_keys del servidor, però no hi ha
> manera. SEMPRE EM DEMANA EL PASSWORD. Abans que feu les vostres hipòtesis,
> deixeu-me dir el següent.
>
> - No sembla un problema de permisos dels fitxers, atès que la cosa funciona
> cap a altres servidors, i els fitxers implicats tenen els mateixos permisos
> (700 el directori .ssh i 600 els fitxers implicats).
>
> - Les claus estan ben generades. He repetit el procés diverses vegades, i amb
> altres 2 servidors funciona sense problemes.
>
> - No sembla cosa dels paràmetres del servidor SSH, perquè me'ls he repassat i
> no hi veig res estrany o diferent als altres servidors.
>
> - AQUESTA ÉS BONA: Si intento establir una sessió ssh per primer cop,
> l'autenticació per clau falla i em demana el password, però un cop establida,
> si provo d'establir-ne una segona des d'un altre terminal, ALESHORES
> FUNCIONA!! És de bojos.
>
> Si voleu els logs..., però no hi veig res estrany:
>
> Quan no funciona:
> debug1: Reading configuration data /home/orestes/.ssh/config
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug1: Connecting to xx.xx.xx.xx [xx.xx.xx.xx] port 22.
> (**una mica de privacitat, que la llista és pública**)
> debug1: Connection established.
> debug1: identity file /home/orestes/.ssh/identity type 1
> debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
> debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
> debug1: identity file /home/orestes/.ssh/id_rsa type 1
> debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
> debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
> debug1: identity file /home/orestes/.ssh/id_dsa type -1
> debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1
> Debian-5ubuntu1
> debug1: match: OpenSSH_5.1p1 Debian-5ubuntu1 pat OpenSSH*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: server->client aes128-cbc hmac-md5 none
> debug1: kex: client->server aes128-cbc hmac-md5 none
> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
> debug1: Host 'xx.xx.xx.xx' is known and matches the RSA host key.
> debug1: Found key in /home/orestes/.ssh/known_hosts:29
> debug1: ssh_rsa_verify: signature correct
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue: publickey,password
> debug1: Next authentication method: publickey
> debug1: Offering public key: /home/orestes/.ssh/identity
> debug1: Authentications that can continue: publickey,password
> debug1: Offering public key: /home/orestes/.ssh/id_rsa
> debug1: Authentications that can continue: publickey,password
> debug1: Trying private key: /home/orestes/.ssh/id_dsa
> debug1: Next authentication method: password
> orestes@...'s password:
>
>
> I quan funciona (és a dir amb una altra sessió establerta):
> debug1: Reading configuration data /home/orestes/.ssh/config
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug1: Connecting to xx.xx.xx.xx [xx.xx.xx.xx] port 22.
> debug1: Connection established.
> debug1: identity file /home/orestes/.ssh/identity type 1
> debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
> debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
> debug1: identity file /home/orestes/.ssh/id_rsa type 1
> debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
> debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
> debug1: identity file /home/orestes/.ssh/id_dsa type -1
> debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1
> Debian-5ubuntu1
> debug1: match: OpenSSH_5.1p1 Debian-5ubuntu1 pat OpenSSH*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: server->client aes128-cbc hmac-md5 none
> debug1: kex: client->server aes128-cbc hmac-md5 none
> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
> debug1: Host 'xx.xx.xx.xx' is known and matches the RSA host key.
> debug1: Found key in /home/orestes/.ssh/known_hosts:29
> debug1: ssh_rsa_verify: signature correct
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue: publickey,password
> debug1: Next authentication method: publickey
> debug1: Offering public key: /home/orestes/.ssh/identity
> debug1: Server accepts key: pkalg ssh-rsa blen 277
> debug1: Authentication succeeded (publickey).
> debug1: channel 0: new [client-session]
> debug1: Requesting no-more-sessions@...
> debug1: Entering interactive session.
> debug1: Sending environment.
> debug1: Sending env LANG = ca_ES.UTF-8
> (i aquí ve el prompt del bash)
>
> No ho trobeu estrany? Algú té alguna idea?
>
> --
>  Orestes Mas Casals - UPC
>
>
> --
> To UNSUBSCRIBE, email to debian-user-catalan-REQUEST@...
> with a subject of "unsubscribe". Trouble? Contact listmaster@...
>
>


--
To UNSUBSCRIBE, email to debian-user-catalan-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

En ocasions he tingunt problemes amb el fitxer ~/.ssh/know_host però a tu no es queixa pas...és bastant extrany. I des de un altre equip al mateix servidor? I des de el mateix equip a un altre servidor?

--
Salutacions,
Oscar Osta Pueyo

[Orestes Mas-2]

A Diumenge, 6 de setembre de 2009, Oscar Osta Pueyo va escriure:
> Hola,
>
> En ocasions he tingunt problemes amb el fitxer ~/.ssh/know_host però a tu
> no es queixa pas...és bastant extrany. I des de un altre equip al mateix
> servidor?

Tampoc no funciona, però això pot ser una mica enganyós, perquè el servidor és
a la feina i els diversos clients són a casa, on tinc un ADSL i per tant tots
els clients surten amb la mateixa IP.

> I des de el mateix equip a un altre servidor?

Això funciona bé, ja ho havia comentat. Amb altres dos servidors funciona
correctament des dels mateixos clients.

--
 Orestes Mas Casals - UPC


--
To UNSUBSCRIBE, email to debian-user-catalan-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Orestes Mas-2]

A Diumenge, 6 de setembre de 2009, Ricard Pradell va escriure:
> Si que és estrany... suposo que deus haver mirat i remirat el
> /etc/ssh/sshd_config de la banda del servidor... dono per suposat que
> deus tenir:
> RSAAuthentication yes
> PubkeyAuthentication yes

Si, aquestes línies hi són, exactament com dius.
>
> Per provar, pots deshabilitar completament l'autenticació per
> password, que si no recordo malament era posant:
> PasswordAuthentication no

No m'atreveixo, perquè probablement aleshores em quedaré sense poder entrar-
hi.

> Comprova que la copia de la clau a authorized_keys sigui correcta.
> Pots provar-ho amb
> $ssh-copy-id -i id_rsa.pub user@host

Si, també m'ho ha dit el sergi. És una ordre molt útil i que acabo de provar
amb èxit amb altres parelles de client-servidor, però en aquest cas, res de
res.

Orestes.


--
To UNSUBSCRIBE, email to debian-user-catalan-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Sergi Tur Badenas]

En/na Orestes Mas ha escrit:

>
> Res. M'ha copiat exactament la mateixa clau que jo havia copiat abans a mà.
> Segueix sense funcionar.

Jo em vaig trobar un cop que no en funcionava (a l'Aula Linux de
l'ETSEIB) i era per que la home de l'usuari no estava a /home (o millor
dir que la home de tots els usuaris és /tmp). És el teu cas?

Ja se que es estrany però per alguna estranya raó qui manté aquella Aula
va decidir que els usuaris no tenien home, tots anaven a /tmp.

No se perquè ssh no deixa amb aquesta configuració... Segurament tema de
permisos de la HOME. Has mirat si la teva home i la carpeta ~/.ssh tenen
els mateixos permisos que una màquina on si et funcioni?

Salutacions,
--
Sergi Tur http://acacha.org/mediawiki


--
To UNSUBSCRIBE, email to debian-user-catalan-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lluis Gili]

i als logs del servidor surt alguna cosa? pots augmentar el LogLevel a veure
si dona alguna pista

A Diumenge, 6 de setembre de 2009, Orestes Mas va escriure:

> A Diumenge, 6 de setembre de 2009, Ricard Pradell va escriure:
> > Si que és estrany... suposo que deus haver mirat i remirat el
> > /etc/ssh/sshd_config de la banda del servidor... dono per suposat que
> > deus tenir:
> > RSAAuthentication yes
> > PubkeyAuthentication yes
>
> Si, aquestes línies hi són, exactament com dius.
>
> > Per provar, pots deshabilitar completament l'autenticació per
> > password, que si no recordo malament era posant:
> > PasswordAuthentication no
>
> No m'atreveixo, perquè probablement aleshores em quedaré sense poder
> entrar- hi.
>
> > Comprova que la copia de la clau a authorized_keys sigui correcta.
> > Pots provar-ho amb
> > $ssh-copy-id -i id_rsa.pub user@host
>
> Si, també m'ho ha dit el sergi. És una ordre molt útil i que acabo de
> provar amb èxit amb altres parelles de client-servidor, però en aquest cas,
> res de res.
>
> Orestes.

--
To UNSUBSCRIBE, email to debian-user-catalan-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Orestes Mas-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

A Dissabte 05 Setembre 2009 18:10:57, Orestes Mas va escriure:
> Hola,
>
> Tinc un contenciós amb el SSH que m'està portant de cap. A veure si algú de
> vosaltres hi veu la llum.
>
> La cosa és senzilla d'explicar: vull connectar via ssh a un servidor, i
> vull fer-ho sense password, és a dir amb clau ssh. Sé com fer-ho, i ho he
> fet altres vegades: Em genero un parell de claus RSA pública/privada, i
> copio la clau pública al fitxer .ssh/authorized_keys del servidor, però no
> hi ha manera. SEMPRE EM DEMANA EL PASSWORD. Abans que feu les vostres
> hipòtesis, deixeu-me dir el següent.

Em sembla que ja ho tinc. És a dir, que tinc una possible explicació, tot i que no se m'acut la manera de comprovar-ho de forma simple.

Després de comprovar-ho tot a fons, i de determinar que tot sembla normal, aquesta insistència en no deixar-me connectar via clau pública sembla indicar que és perquè, malgrat tot, NO POT LLEGIR EL FITXER AUTHORIZED_KEYS.

Però no és un problema de permisos. Ja ho he comprovat. Aleshores he recordat vagament que fa temps em vaig trobar amb un cas relativament similar, i que aleshores la culpa era dels PAM, així que he comparat minuciosament la configuració del PAM en el servidor problemàtic i en un altre que no ho és.

Finalment ha resultat que no és el PAM, però aquí he trobat una possible explicació, perquè m'he adonat que en instal·lar el sistema en l'ordinador problemàtic, vaig optar per xifrar el directori /home amb ecryptfs.

Aleshores tot quadra. El contingut del /home/orestes no és llegible perquè està xifrat, i només esdevé llegible quan es munta amb la paraula de pas adient, i això només succeeix quan fem el login amb password, atès que aquest password és justament la paraula de pas que permet desxifrar i muntar el /home. Suposo que m'explico. I suposo que això també explica el notable temps d'espera que s'observa en l'intent de negociar la clau pública (deu fer intents de llegir el fitxer authorized_keys i al final abandona).

Suposo que per aconseguir fer funcionar el login amb clau pública en el meu cas caldria col·locar el fitxer authorized_keys en algun lloc no xifrat, i aconseguir que en fer un login satisfactori amb aquesta clau pública desxifrés i muntés el /home, però no tinc ni idea de com es deu fer això.

Penseu que tinc raó? Ho considereríeu un bug si fos així? O és un problema òbvi de solució estàndard?

Orestes.

[Jordi Funollet-2]

On Monday 07 September 2009 01:50:54 Orestes Mas wrote:
> Suposo que per aconseguir fer funcionar el login amb clau pública en el meu
> cas caldria col·locar el fitxer authorized_keys en algun lloc no xifrat, i
> aconseguir que en fer un login satisfactori amb aquesta clau pública
> desxifrés i muntés el /home, però no tinc ni idea de com es deu fer això.
>
> Penseu que tinc raó? Ho considereríeu un bug si fos així? O és un problema
> òbvi de solució estàndard?

La teva teoría em sona molt probable. Pots reconfigurar 'sshd' per a que
busqui el fitxer de les claus en una altra banda. Com ara,

   AuthorizedKeysFile  /etc/ssh_keys/%u/authorized_keys

Pots mirar les opcions que tens al man de 'sshd_config'.
--
##############################
### Jordi Funollet
### http://www.terraquis.net


--
To UNSUBSCRIBE, email to debian-user-catalan-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Orestes Mas-2]

A Dilluns 07 Setembre 2009 14:40:25, Jordi Funollet va escriure:

> On Monday 07 September 2009 01:50:54 Orestes Mas wrote:
> > Suposo que per aconseguir fer funcionar el login amb clau pública en el
> > meu cas caldria col·locar el fitxer authorized_keys en algun lloc no
> > xifrat, i aconseguir que en fer un login satisfactori amb aquesta clau
> > pública desxifrés i muntés el /home, però no tinc ni idea de com es deu
> > fer això.
> >
> > Penseu que tinc raó? Ho considereríeu un bug si fos així? O és un
> > problema òbvi de solució estàndard?
>
> La teva teoría em sona molt probable. Pots reconfigurar 'sshd' per a que
> busqui el fitxer de les claus en una altra banda. Com ara,
>
>    AuthorizedKeysFile  /etc/ssh_keys/%u/authorized_keys

Si, ja ho he vist. Resulta que això és un problema força habitual en gent que
s'inicia en el món de l'ecryptfs, i aquesta és la "solució" que molts
proposen.

Però només és una solució a mitges: Efectivament et permet fer el login al
sistema amb clau pública, però quan entres segueixes sense tenir muntat el teu
directori /home, cosa que cal fer manualment amb l'ordre "ecryptfs-mount-
private" (la qual et demana el password).

Com que això és empipador, haig de mirar si es podria muntar automàticament el
/home xifrat tot just després d'haver fet el login amb clau pública. Al
capdavall la clau pública és potser més segura que el password per assegurar
que l'usuari és qui diu ser...

Seguiré investigant.

Orestes.


--
To UNSUBSCRIBE, email to debian-user-catalan-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jordi Funollet-2]

On Monday 07 September 2009 18:46:13 Orestes Mas wrote:
> Com que això és empipador, haig de mirar si es podria muntar automàticament
> el /home xifrat tot just després d'haver fet el login amb clau pública. Al
> capdavall la clau pública és potser més segura que el password per
> assegurar que l'usuari és qui diu ser...

man pam_exec
--
##############################
### Jordi Funollet
### http://www.terraquis.net


--
To UNSUBSCRIBE, email to debian-user-catalan-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jaume Sabater-2]

El Sunday 06 September 2009 17:51:16 Orestes Mas va escriure:
> > Per provar, pots deshabilitar completament l'autenticació per
> > password, que si no recordo malament era posant:
> > PasswordAuthentication no
>
> No m'atreveixo, perquè probablement aleshores em quedaré sense poder
> entrar- hi.

Deixa't un telnetd obert mentre proves...

--
Jaume Sabater


--
To UNSUBSCRIBE, email to debian-user-catalan-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Oscar Osta Pueyo-2]

Hola,

El 7 / setembre / 2009 18:46, Orestes Mas <orestes@...> ha escrit:

A Dilluns 07 Setembre 2009 14:40:25, Jordi Funollet va escriure:

> On Monday 07 September 2009 01:50:54 Orestes Mas wrote:
> > Suposo que per aconseguir fer funcionar el login amb clau pública en el
> > meu cas caldria col·locar el fitxer authorized_keys en algun lloc no
> > xifrat, i aconseguir que en fer un login satisfactori amb aquesta clau
> > pública desxifrés i muntés el /home, però no tinc ni idea de com es deu
> > fer això.
> >
> > Penseu que tinc raó? Ho considereríeu un bug si fos així? O és un
> > problema òbvi de solució estàndard?
>
> La teva teoría em sona molt probable. Pots reconfigurar 'sshd' per a que
> busqui el fitxer de les claus en una altra banda. Com ara,
>
>    AuthorizedKeysFile  /etc/ssh_keys/%u/authorized_keys

Si, ja ho he vist. Resulta que això és un problema força habitual en gent que
s'inicia en el món de l'ecryptfs, i aquesta és la "solució" que molts
proposen.

Però només és una solució a mitges: Efectivament et permet fer el login al
sistema amb clau pública, però quan entres segueixes sense tenir muntat el teu
directori /home, cosa que cal fer manualment amb l'ordre "ecryptfs-mount-
private" (la qual et demana el password).

No sé si pot servir, però, si en lloc de encriptar la partició home amb clau ho fas amb el certificat que has generat, mira aquest enllaç, https://answers.launchpad.net/ecryptfs/+question/46288 

--
Saludos,
Oscar Osta Pueyo

[Jordi Funollet-2]

On Tuesday 08 September 2009 16:51:24 Jaume Sabater wrote:
> El Sunday 06 September 2009 17:51:16 Orestes Mas va escriure:
> > > Per provar, pots deshabilitar completament l'autenticació per
> > > password, que si no recordo malament era posant:
> > > PasswordAuthentication no
> >
> > No m'atreveixo, perquè probablement aleshores em quedaré sense poder
> > entrar- hi.
>
> Deixa't un telnetd obert mentre proves...

...o un altre sshd corrent en un port diferent del 22.
--
##############################
### Jordi Funollet
### http://www.terraquis.net


--
To UNSUBSCRIBE, email to debian-user-catalan-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...