[Résolu] Problèmes SSH

JujuLand · Le 06/01/2014, à 12:52

oui si l'authentification par clé ne fonctionne pas, alors il demande le mot de passe du user, si celui ci est désactivé alors tu as ton message:   Permission denied (publickey)

Cela veut donc dire que si on n'a pas la clé d'un utilisateur, celui-ci peut se connecter avec le mot de passe de l'utilisateur.
Vraiment pas top ...

A+

JujuLand · Le 06/01/2014, à 14:22

chmod 600 authorized_keys

Modif des droits + restart de sshd
Toujours mauvais ...

pas du tout, une option est prévue:  la ligne
PasswordAuthentication no
interdit une authentification avec mot de passe.

Oui, bien sûr, c'est bien ce que je veux, mais dans ton premier post tu dis :

si tu interdit l'authentification par mot de passe,  il faut alors spécifier la clé (et le chemin ou elle se trouve) dans la commande:

Et çà, çà ne fonctionne pas (je refait la clé ssh-keygen)

alain@Gramps-JujuLand:~$ ls -ail .ssh
total 36
10486241 drwx------   2 alain alain  4096 janv.  6 09:25 .
10485761 drwxr-xr-x 168 alain alain 12288 janv.  6 13:19 ..
10489946 -rw-------   1 alain alain   403 janv.  6 13:19 authorized_keys
10485885 -rw-------   1 alain alain  1766 janv.  6 13:19 id_rsa
10501955 -rw-r--r--   1 alain alain   403 janv.  6 13:19 id_rsa.pub
10489039 -rw-r--r--   1 alain alain    36 déc.   9 15:17 issue.net
10486674 -rw-r--r--   1 alain alain   444 janv.  5 20:12 known_hosts
alain@Gramps-JujuLand:~$ ssh -p 22192 -i /home/alain/.ssh/id_rsa alain@$LOCAL_IP
Bonjour ... Vous arrivez sur JujuLand
Permission denied (publickey).

Par contre si j'essaie avec la'adresse publique, j'ai un autre message (une piste ?)

alain@Gramps-JujuLand:~$ ssh -p 22192 -i /home/alain/.ssh/id_rsa alain@$PUBLIC_IP
Bonjour ... Vous arrivez sur JujuLand
Agent admitted failure to sign using the key.
Permission denied (publickey).

Après effacement de known_hosts, le deux connexions retournent cette erreur.
A+

Dernière modification par JujuLand (Le 06/01/2014, à 14:27)

JujuLand · Le 06/01/2014, à 15:05

En allant sur d'autres discussion sur ubuntu fr, après recherche des droits de .ssh et des fichier qui sont dessous, j'ai trouvé un post interessant,
J'ai donc arrêté le serveur, et l'ai relancé en ajoutant -D -d
Je n'ai rien remarqué sur le log de lancement du serveur, mais je le met quand même:

alain@Gramps-JujuLand:~$ sudo /usr/sbin/sshd -d -D -p 22192
debug1: sshd version OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: read PEM private key done: type RSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: private host key: #1 type 2 DSA
debug1: read PEM private key done: type ECDSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.ECDSA-256
debug1: Checking blacklist file /etc/ssh/blacklist.ECDSA-256
debug1: private host key: #2 type 3 ECDSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: rexec_argv[2]='-D'
debug1: rexec_argv[3]='-p'
debug1: rexec_argv[4]='22192'
Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 22192 on 0.0.0.0.
Server listening on 0.0.0.0 port 22192.
debug1: Bind to port 22192 on ::.
Server listening on :: port 22192.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from 192.168.1.192 port 42416
debug1: Client protocol version 2.0; client software version OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: permanently_set_uid: 123/65534 [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: client->server aes128-ctr hmac-md5 none [preauth]
debug1: kex: server->client aes128-ctr hmac-md5 none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user alain service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
Address 192.168.1.192 maps to gramps-jujuland, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
debug1: userauth_send_banner: sent [preauth]
debug1: userauth-request for user alain service ssh-connection method publickey [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: test whether pkalg/pkblob are acceptable [preauth]
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: temporarily_use_uid: 1000/1000 (e=0/0)
debug1: trying public key file /home/alain/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /home/alain/.ssh/authorized_keys, line 1
Found matching RSA key: 5f:bb:e0:80:e6:b0:2b:e9:d0:3e:21:f0:fe:fe:4b:04
debug1: restore_uid: 0/0
Postponed publickey for alain from 192.168.1.192 port 42416 ssh2 [preauth]
Connection closed by 192.168.1.192 [preauth]
debug1: do_cleanup [preauth]
debug1: do_cleanup

Par contre, le log de connexion donnera peut-être la raison:

alain@Gramps-JujuLand:~$ ssh -vv -p 22192 alain@192.168.1.192
OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.192 [192.168.1.192] port 22192.
debug1: Connection established.
debug1: identity file /home/alain/.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/alain/.ssh/id_rsa-cert type -1
debug1: identity file /home/alain/.ssh/id_dsa type -1
debug1: identity file /home/alain/.ssh/id_dsa-cert type -1
debug1: identity file /home/alain/.ssh/id_ecdsa type -1
debug1: identity file /home/alain/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 79:c3:e2:de:dc:69:d0:82:7a:3d:53:2a:81:38:a2:bc
debug1: Host '[192.168.1.192]:22192' is known and matches the ECDSA host key.
debug1: Found key in /home/alain/.ssh/known_hosts:2
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server                                      <<<< c'est pas çà qui bloque ?
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/alain/.ssh/id_rsa (0x7f0449fa21c0)
debug2: key: /home/alain/.ssh/id_dsa ((nil))
debug2: key: /home/alain/.ssh/id_ecdsa ((nil))
Bonjour ... Vous arrivez sur JujuLand
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/alain/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp 5f:bb:e0:80:e6:b0:2b:e9:d0:3e:21:f0:fe:fe:4b:04
Agent admitted failure to sign using the key.
debug1: Trying private key: /home/alain/.ssh/id_dsa
debug1: Trying private key: /home/alain/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

A+

Dernière modification par JujuLand (Le 06/01/2014, à 15:05)

JujuLand · Le 06/01/2014, à 16:22

J'avais modifié le sshd_config en commentant la ligne PasswordAuthentication no pour des besoins immédiats,
J'étais dur une connexion ssh en train de travaille rsur un ordi distant, j'ai essayé de me connecter chez moi depuis l'ordi distant, et il ma demandé ma passphrase, et comme j'étais en session ssh, il me l'a demandé en mode console, pas de fenêtre, ce qui semble normal.
Donc, çà voudrait dire que le mécanisme fonctionne.
Depuis, j'ai fait la connexion demandée, et il passe, mais me demande le mot de passe.

Bonjour ... Vous arrivez sur JujuLand
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/alain/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp 5f:bb:e0:80:e6:b0:2b:e9:d0:3e:21:f0:fe:fe:4b:04
Agent admitted failure to sign using the key.
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
alain@127.0.0.1's password:

il est bizarre qu'en local, il me demande le password, et en mode distant, il me demande la passphrase, non ?
Voici le authorized_keys

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDcAkMIhYHJ+75XN1sTV6GCDUhBmjHY6orcM4nkuIpih+zYc2qa3U94UVh5fnNztGIdZpE9AI955JPdJaHjf/dK92B7kNMwcCEAvXLWajTvkWwdV+pF2ZuWLQVhlx2qWUU/H8yplaayOCbx/W/WoSg8LQvycRxZt/toRvf5v6zwCj9FS1mpZGH3n1Zs4TLHbLXkLwWRCCF9nfU0xxxaZBCt4KFxbnkw5/i3wInw9KUDxmh0ByVrrCQlLyNP/tfPPMGmoQqNFc+Vnj9sCUrWB+sWNK2KJmANcSCrPTviDU/tWObplYItZ6AsbqLazz/Ng6suyEwV3myLG2q4GP6t6kmf alain@Gramps-JujuLand
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDYFTQToWHZmlY93WY3CVgT0mho+6R//C7TsLd/cMsQ6Z1vmtg6MiwRy0dxDrDuDo2700nnbqx0XzWpp887sTi4B4XL8v6Ldc866+u8MNRdGgCnnhDJ9AnmXfTQzRvHbk9M338QyYbbeN8DIeo0F0UrXNOsHCzNsQl+4X2DSZbSTfy8KAc2NyrLC0R06Dt9mnL+NZF436WVpcHhU1socvMGLp1liah4Nfmhb3fx17BTeZI1V6FuVJImLCvs6VDbMhIjxBx0G4ZXn9EFh6MlPY+P759wI0cJPpITf8FjfCNgHyWxC/5198yPnPJmO624H2dsgvFeLigPla/na+GROc7p christian@tedy-X75VCP

et le id_rsa.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDcAkMIhYHJ+75XN1sTV6GCDUhBmjHY6orcM4nkuIpih+zYc2qa3U94UVh5fnNztGIdZpE9AI955JPdJaHjf/dK92B7kNMwcCEAvXLWajTvkWwdV+pF2ZuWLQVhlx2qWUU/H8yplaayOCbx/W/WoSg8LQvycRxZt/toRvf5v6zwCj9FS1mpZGH3n1Zs4TLHbLXkLwWRCCF9nfU0xxxaZBCt4KFxbnkw5/i3wInw9KUDxmh0ByVrrCQlLyNP/tfPPMGmoQqNFc+Vnj9sCUrWB+sWNK2KJmANcSCrPTviDU/tWObplYItZ6AsbqLazz/Ng6suyEwV3myLG2q4GP6t6kmf alain@Gramps-JujuLand

A+

JujuLand · Le 06/01/2014, à 16:32

Bon, en cherchant l'erreur 'Agent admitted failure to sign the key', sur google, j'ai trouvé cette page qui m'a résolu le problème :
http://idealogeek.fr/2013/erreur-ssh-agent/

Comme il est dit sur cette page, c'est bien suite à un écrasement de la clé publique (ssh-keygen) que c'était arrivé

On aura appris quelque chose ...

De plus, maintenant, çà passe sans avoir à fournir le chemin de la clé, puisquelle se trouve dans le dossier par défaut.

Merci
A+

Dernière modification par JujuLand (Le 06/01/2014, à 16:42)

JujuLand · Le 07/01/2014, à 09:59

si tu fais une capture de paquets avec wireshark, tu constatera qu'avec ip publique attribuée par ton fai, c'est l'adresse de la box qui re-reroute directement, box=fai, donc elle sait mais si tu fais le test connecté à un vpn ou proxy internet, le test est bien réel, la connexion est bien initialisée depuis le net forcément.

Donc, le test ne vaut pas grand chose,..
Pourtant, il me semble que la connexion est plus longue.
Mais, pour ce que je vais en faire, je ne vais pas pousser le vice jusqu'à monter un proxy ... un vpn est une autre histoire ...

La seule chose qui me reste à faire, est la connexion vino sécurisée, je n'ai pas trop compris le moyen d'utiliser ssh avec.

Merci
A+

JujuLand · Le 07/01/2014, à 11:44

J'avais vu cette option X, mais j'avais probablement lu çà en diagonale, et j'avais zappé ce param X11Forwarding.
Moi aussi, je trouve lourdinge de rapatrier tout le bureau, d'autant que je suis en 512 ko

Dès que j'ai un moment, j'essaie le ssh -x

Merci
A+

JujuLand · Le 07/01/2014, à 16:20

Mes essais précédents ne fonctionnaient pas, probablement parce que je mettais -x et non -X
Et X11 mérite bien un grand X, car c'est absolument génial !!!
L'essayer, c'est l'adopter...

Mais çà n'empêche que vino+ssh m'est indispensable pour que l'utilisateur que je dépanne puisse en même temps profiter de ce que je fais (je limiterai évidemment au minimum : 512 oblige!).

Juste une astuce, pour stopper le serveur ssh depuis la connexion: faire un kill en sudo.

Concernant la connexion ssh, juste une petite question, pour confirmer ce que je pense.
Je fais une modif dans le sshd_config distant, suivi d'un sudo service ssh restart
La connexion n'est pas coupée.
Pour bénéficier de la nouvelle config, dois-je me déconnecter et me reconnecter ?
Voici un ps avant et après un restart

alain@aupeix-GX723:~/.ssh$ ps -aef|grep sshd
root      3135     1  0 14:58 ?        00:00:00 /usr/sbin/sshd
root      3139  3135  0 14:58 ?        00:00:00 sshd: alain [priv]
alain     3141  3139  0 14:58 ?        00:00:02 sshd: alain@pts/1
alain     3742  3142  0 15:15 pts/1    00:00:00 grep --color=auto sshd
alain@aupeix-GX723:~/.ssh$ sudo service ssh restart
[sudo] password for alain: 
 * Restarting OpenBSD Secure Shell server sshd                                                                                    [ OK ] 
alain@aupeix-GX723:~/.ssh$ ps -aef|grep sshd
root      3139     1  0 14:58 ?        00:00:00 sshd: alain [priv]
alain     3141  3139  0 14:58 ?        00:00:02 sshd: alain@pts/1
root      3762     1  0 15:15 ?        00:00:00 /usr/sbin/sshd
alain     3766  3142  0 15:15 pts/1    00:00:00 grep --color=auto sshd

Je pense que deux process tournent, non ?

A+

Dernière modification par JujuLand (Le 07/01/2014, à 16:21)

JujuLand · Le 07/01/2014, à 17:50

Confirmation, il faut bien se déconnecter et se reconnecter.
D'ailleurs, le process sur lequel repose la connexion n'a plus de père, même si la connexion fonctionne toujours.

A+

Dernière modification par JujuLand (Le 07/01/2014, à 17:54)

JujuLand · Le 14/01/2014, à 23:00

Un truc marrant lors de tentative d'ouvrir un partage bureau depuis une connexion ssh:
On y arrive, mais çà ne donne pas ce qu'on pourrait penser:

Ceci pour des raisons d'affichage X11 ne fonctionne qu'avec l'option -X
Après connexion :
- vérifier si la connexion est autorisée par: gsettings get org.gnome.Vino enabled
- nécessaire la changer par : gsettings set org.gnome.Vino enabled true
- lancer le partage par : /usr/lib/vino/vino-server &
Ensuite sur le client lancer remmina et essayer la connexion.

Elle fonctionne, mais la visualisation à priori surprenante est en fait non l'écran du serveur, mais l'ecran du serveur à travers l'écran du client.
Ceci doit, je pense s'expliquer qu'au moment du lancement de vino-server, il y a un reroutage de l'écran X11 vers la fenêtre du client.
Je ne maitrise pas totallement le phénomène, et mon explication est certainement légèrement fausse, mais je n'ai pas résisté à partager ce que çà donne.

Funny .... https://www.dropbox.com/s/6v4ge2hx0k9xh … C3%A9o.png

A+

Dernière modification par JujuLand (Le 14/01/2014, à 23:01)

moissan · Le 28/05/2014, à 00:24

ce sujet est intéressant !

a tu encore l'image du lien precedent ? elle n'est plus dans dropbox

un petit detail auquel on ne pense pas quand on a encore une ligne telephonique classique : ressortir un bon vieux modem 56K ... sur ma ligne france telecom il y a toujours l'accés libre sans abonnement mais facturé a la minute de connection : ça permet de connecter un ordinateur en passant par une vraie adresse ip differente de l'adsl ... bien sur sans illusion sur le debit : ça doit etre lent mais si ça marche c'est vraiment la preuve que ça supporte le cas le plus pourri

Dernière modification par moissan (Le 28/05/2014, à 00:25)

JujuLand · Le 28/05/2014, à 09:07

Non, malheureusement, j'ai effacé il y a quelque jours cette image ...

Concernant le bas débit:
J'ai ouvert, il y a fort longtemps plusieurs accès libres à mon nom et pour différentes raisons (associations,...). A l'époque, je travaillais à France Télécom, et j'avais un forfait de taxe qui me permettait de ne pas m'inquiéter de la facture.
Maintenant, je suis à la retraite, et mes comptes sont toujours ouverts. Je ne m'en sers plus pour la connexion (plus de forfait), mais j'ai pour chaque accès libre 100 Mo de dispo pour mes sites web, car l'accès en upload se fait sur les comptes mails de chaque accès, et sous condition d'être connecté à un compte orange (adsl).
Bon à savoir ...

Concernant ce thread, malheureusement, certains posts ont disparu (je ne comprends pas trop pourquoi).
Concernant le moyen de distinguer entre connexions locales et distantes, je me suis trompé de thread, il s'agit de celui-là:
http://forum.ubuntu-fr.org/viewtopic.php?id=1469031

Voilà, si quelqu'un a une idée sur une éventuelle possibilité ...
Merci

A+

Bybeu · Le 12/06/2014, à 00:39

Tous les fichiers dans ~/.ssh doivent être en -rw------- (600), sauf "." (.ssh lui même, qui doit-être en 700)
Si tu as plusieurs clés tu aurais peut-être avantage à déplacer tes options spécifiques de /etc/ssh/ssh_config vers le fichier ~/.ssh/config à créer, comme ça en cas de mise à jour de OpenSSH, pas de grouille

Dernière modification par Bybeu (Le 12/06/2014, à 00:44)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 06/01/2014, à 12:52

Re : [Résolu] Problèmes SSH

#27 Le 06/01/2014, à 14:22

Re : [Résolu] Problèmes SSH

#28 Le 06/01/2014, à 15:05

Re : [Résolu] Problèmes SSH

#29 Le 06/01/2014, à 16:22

Re : [Résolu] Problèmes SSH

#30 Le 06/01/2014, à 16:32

Re : [Résolu] Problèmes SSH

#31 Le 07/01/2014, à 09:59

Re : [Résolu] Problèmes SSH

#32 Le 07/01/2014, à 11:44

Re : [Résolu] Problèmes SSH

#33 Le 07/01/2014, à 16:20

Re : [Résolu] Problèmes SSH

#34 Le 07/01/2014, à 17:50

Re : [Résolu] Problèmes SSH

#35 Le 14/01/2014, à 23:00

Re : [Résolu] Problèmes SSH

#36 Le 28/05/2014, à 00:24

Re : [Résolu] Problèmes SSH

#37 Le 28/05/2014, à 09:07

Re : [Résolu] Problèmes SSH

#38 Le 12/06/2014, à 00:39

Re : [Résolu] Problèmes SSH

Pied de page des forums