Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux caractères étranges via ssh (au terminal)

caractères étranges via ssh (au terminal)

45 réponses
Avatar
Une Bévue
Bonsoir,

je viens de passer en Linux 18 Sarah alias 16.04 LTS (Xenial Xerus) avec
XFCE. (Shell fish)

(avant j'étais en Ubuntu 14.04)

le problème que je rencontre quand je me connecte via ssh à un portable
sous macOS Sierra :

┬─[yt@d620:~]─[16-11-21 17:52:58]


╰─>$ ssh yt@mbp.local
Last login: Mon Nov 21 17:35:18 2016 from 192.168.0.48
]1337;RemoteHost=yt@mbp.local]1337;CurrentDir=/Users/yt]1337;ShellIntegrationVersion=2;shell=fish]1337;RemoteHost=yt@mbp.local]1337;CurrentDir=/Users/ytWelcome
to fish, the friendly interactive shell
Type help for instructions on how to use fish
type: Could not find 'acpi'
]133;D;0]133;A.-[yt@mbp.local:~]-[16-11-21 17:53:30]
'->$ ]133;Bexit
]133;C;
Connection to 192.168.0.41 closed.


les "]" devant 1337; (une escape séquence ?) ne sont pas visualisés
ainsi au terminal mais par un rectangle avec des petits chiffres illisibles.

il ne semble pas que ce soit un pb de police de caractère sur le
terminal que j'utilise (Guake), j'ai changé de police, ça ne change rien...
changer de terminal non plus : xfce4-terminal 0.6.3 donne la même chose
que guake.

je pense que c'est une sorte de banière venant du ssh de macOS Sierra
(je n'avais pas ça avant).

par ailleurs, côté macOS mon fichier /etc/ssh/ssh_config n'a pas
vraiment changé.

au cas où quelqu'un connaitrait ce genre de pb.
ou au moins une indication pour savoir où chercher.

Merci d'avance.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4 5
Avatar
Jo Engo
Le Mon, 21 Nov 2016 18:31:32 +0100, Une Bévue a écrit :


autrement (en 8bit) :
<null><esc>
Je ne peux pas dire plus.
--
<flynn`> est-ce qu'il existe un serveur FTP plus simple que wu-ftpd , et
tout aussi (ou plus ?) secure ?
Avatar
Une Bévue
Le 21/11/2016 à 20:41, Jo Engo a écrit :
autrement (en 8bit) :
<null><esc>
Je ne peux pas dire plus.

oui, ça doit être une "escape séquence"...
bon, ça vient du macOS Sierra.
autre problème, quand je me connecte en ssh à linux depuis macOS Sierra,
il y a toujours une demande de password, même si j'ai un :
PasswordAuthentification no
dans le fichier '/etc/ssh/ssh_config'
(la première fois que je m'y suis connecté, une fenêtre macOS m'a
demandé la passphrase, depuis, c'est toujours le pass)
quand je me connecte en ssh de linux à macOS, pas de pass demandé : j'ai
une fenêtre ssh-askpass au login qui me demande la passphrase.
Avatar
Bruno Ducrot
On 2016-11-21, Une Bévue wrote:
Bonsoir,
je viens de passer en Linux 18 Sarah alias 16.04 LTS (Xenial Xerus) avec
XFCE. (Shell fish)
(avant j'étais en Ubuntu 14.04)
le problème que je rencontre quand je me connecte via ssh à un portable
sous macOS Sierra :
┬─[:~]─[16-11-21 17:52:58]
╰─>$ ssh
Last login: Mon Nov 21 17:35:18 2016 from 192.168.0.48
]1337;RemoteHost=]1337;CurrentDir=/Users/yt]1337;ShellIntegrationVersion=2;shell=fish]1337;RemoteHost=]1337;CurrentDir=/Users/ytWelcome
to fish, the friendly interactive shell
Type help for instructions on how to use fish
type: Could not find 'acpi'
]133;D;0]133;A.-[:~]-[16-11-21 17:53:30]
'->$ ]133;Bexit
]133;C;
Connection to 192.168.0.41 closed.
les "]" devant 1337; (une escape séquence ?) ne sont pas visualisés
ainsi au terminal mais par un rectangle avec des petits chiffres illisibles.

Je ne connais pas fish, btw. Ca ne va pas être évident, pour moi, de
t'aider, mais je suppose qu'il y a un équivalent de PS1 ? Comment est
positionné la variable d'environnement TERM ?
En changeant le shell pour bash (par exemple), est-ce que tout rentre
dans l'ordre ?
il ne semble pas que ce soit un pb de police de caractère sur le
terminal que j'utilise (Guake), j'ai changé de police, ça ne change rien...
changer de terminal non plus : xfce4-terminal 0.6.3 donne la même chose
que guake.
je pense que c'est une sorte de banière venant du ssh de macOS Sierra
(je n'avais pas ça avant).
par ailleurs, côté macOS mon fichier /etc/ssh/ssh_config n'a pas
vraiment changé.

Je suppose que tu voulais écrire /etc/ssh/sshd_config. Ca se passe
dans les directives Banner et PrintMotd. Mais j'ai plutôt l'impression
que le problème provient du shell de ton utilisateur.
A plus,
--
Bruno Ducrot
A quoi ca sert que Ducrot hisse des carcasses ?
Avatar
Une Bévue
Le 22/11/2016 à 15:16, Bruno Ducrot a écrit :
Je ne connais pas fish, btw. Ca ne va pas être évident, pour moi, de
t'aider, mais je suppose qu'il y a un équivalent de PS1 ? Comment est
positionné la variable d'environnement TERM ?

# echo $TERM
xterm
En changeant le shell pour bash (par exemple), est-ce que tout rentre
dans l'ordre ?

rien de changé.
il ne semble pas que ce soit un pb de police de caractère sur le
terminal que j'utilise (Guake), j'ai changé de police, ça ne change rien...
changer de terminal non plus : xfce4-terminal 0.6.3 donne la même chose
que guake.
je pense que c'est une sorte de banière venant du ssh de macOS Sierra
(je n'avais pas ça avant).


bon entre-temps j'ai regardé le sshd_config sur mac, par défaut on a :
Banner none
par ailleurs, côté macOS mon fichier /etc/ssh/ssh_config n'a pas
vraiment changé.

Je suppose que tu voulais écrire /etc/ssh/sshd_config. Ca se passe
dans les directives Banner et PrintMotd. Mais j'ai plutôt l'impression
que le problème provient du shell de ton utilisateur.

ben non, malheureusement...
Avatar
Bruno Ducrot
On 2016-11-22, Une Bévue wrote:
Le 22/11/2016 à 15:16, Bruno Ducrot a écrit :
Je ne connais pas fish, btw. Ca ne va pas être évident, pour moi, de
t'aider, mais je suppose qu'il y a un équivalent de PS1 ? Comment est
positionné la variable d'environnement TERM ?

# echo $TERM
xterm
En changeant le shell pour bash (par exemple), est-ce que tout rentre
dans l'ordre ?

rien de changé.
il ne semble pas que ce soit un pb de police de caractère sur le
terminal que j'utilise (Guake), j'ai changé de police, ça ne change rien...
changer de terminal non plus : xfce4-terminal 0.6.3 donne la même chose
que guake.
je pense que c'est une sorte de banière venant du ssh de macOS Sierra
(je n'avais pas ça avant).


bon entre-temps j'ai regardé le sshd_config sur mac, par défaut on a :
Banner none
par ailleurs, côté macOS mon fichier /etc/ssh/ssh_config n'a pas
vraiment changé.

Je suppose que tu voulais écrire /etc/ssh/sshd_config. Ca se passe
dans les directives Banner et PrintMotd. Mais j'ai plutôt l'impression
que le problème provient du shell de ton utilisateur.

ben non, malheureusement...

Bon. Sous El Capitan, aucun soucis (mais tu l'as déjà écrit). Je vais
upgrader quand j'aurai le temps et surtout quand je serai chez moi, ce
soir, juste pour voir.
A plus,
--
Bruno Ducrot
A quoi ca sert que Ducrot hisse des carcasses ?
Avatar
Une Bévue
Le 22/11/2016 à 17:50, Bruno Ducrot a écrit :
Bon. Sous El Capitan, aucun soucis (mais tu l'as déjà écrit). Je vais
upgrader quand j'aurai le temps et surtout quand je serai chez moi, ce
soir, juste pour voir.

Tu veras sur le net il y a plein de "tuyaux" pour ce problème d'ssh,
mais je n'ai pas trouvé le bon.
Côté mac se connectant à linux, ça me demande toujours un mot de passe,
alors que j'ai une passphrase et que côté linux j'ai mis dans ma conf :
PasswordAuthentication no
Ce qui marche très bien dans l'autre sens : linux se connectant à mac
(les deux ordis sont côte-à-côte).
Sur linux il a suffit que je mette un ssh-add à l'ouverture de session,
j'entre ma passphrase t je n'en ai plus bessoin.
Avatar
Philippe Weill
Le 22/11/2016 à 18:07, Une Bévue a écrit :
Le 22/11/2016 à 17:50, Bruno Ducrot a écrit :
Bon. Sous El Capitan, aucun soucis (mais tu l'as déjà écrit). Je vais
upgrader quand j'aurai le temps et surtout quand je serai chez moi, ce
soir, juste pour voir.

Tu veras sur le net il y a plein de "tuyaux" pour ce problème d'ssh, mais je n'ai pas trouvé le bon.
Côté mac se connectant à linux, ça me demande toujours un mot de passe, alors que j'ai une passphrase et que côté linux j'ai mis
dans ma conf :
PasswordAuthentication no
Ce qui marche très bien dans l'autre sens : linux se connectant à mac (les deux ordis sont côte-à-côte).
Sur linux il a suffit que je mette un ssh-add à l'ouverture de session, j'entre ma passphrase t je n'en ai plus bessoin.

verifier sur le linux si il n'y a pas un repertoire de toute la chaine sur $HOME/.ssh avec un w pour le groupe ou other
verifier sur le mac si la clef privée est bien uniquement en rw
ssh -vvv peux etre ton ami
Avatar
Bruno Ducrot
On 2016-11-22, Une Bévue wrote:
Le 22/11/2016 à 17:50, Bruno Ducrot a écrit :
Bon. Sous El Capitan, aucun soucis (mais tu l'as déjà écrit). Je vais
upgrader quand j'aurai le temps et surtout quand je serai chez moi, ce
soir, juste pour voir.

Tu veras sur le net il y a plein de "tuyaux" pour ce problème d'ssh,
mais je n'ai pas trouvé le bon.

Et bien, je n'ai pas eu de problème :
:~$ uname -a
Linux poupinette 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux
:~$ ssh
Password:
Last login: Wed Nov 23 09:42:09 2016 from 192.168.1.15
~> uname -a
Darwin poupmac.poup 16.1.0 Darwin Kernel Version 16.1.0: Wed Oct 19 20:31:56 PDT 2016; root:xnu-3789.21.4~4/RELEASE_X86_64 x86_64
~> echo $SHELL
/usr/local/bin/fish
Tout ça sous xterm.
Côté mac se connectant à linux, ça me demande toujours un mot de passe,
alors que j'ai une passphrase et que côté linux j'ai mis dans ma conf :
PasswordAuthentication no
Ce qui marche très bien dans l'autre sens : linux se connectant à mac
(les deux ordis sont côte-à-côte).
Sur linux il a suffit que je mette un ssh-add à l'ouverture de session,
j'entre ma passphrase t je n'en ai plus bessoin.

Là je ne vois pas. Problème de droits du répertoire ~/.ssh peut-être ?
Un ssh -v (comme le suggère un intervenant) pourrait aider.
Ou bien un ~/.ssh/config qui override le défaut ?
A plus,
--
Bruno Ducrot
A quoi ca sert que Ducrot hisse des carcasses ?
Avatar
Une Bévue
Le 22/11/2016 à 19:00, Philippe Weill a écrit :
Le 22/11/2016 à 18:07, Une Bévue a écrit :
Le 22/11/2016 à 17:50, Bruno Ducrot a écrit :
Bon. Sous El Capitan, aucun soucis (mais tu l'as déjà écrit). Je vais
upgrader quand j'aurai le temps et surtout quand je serai chez moi, ce
soir, juste pour voir.

Tu veras sur le net il y a plein de "tuyaux" pour ce problème d'ssh,
mais je n'ai pas trouvé le bon.
Côté mac se connectant à linux, ça me demande toujours un mot de
passe, alors que j'ai une passphrase et que côté linux j'ai mis
dans ma conf :
PasswordAuthentication no
Ce qui marche très bien dans l'autre sens : linux se connectant à mac
(les deux ordis sont côte-à-côte).
Sur linux il a suffit que je mette un ssh-add à l'ouverture de
session, j'entre ma passphrase t je n'en ai plus bessoin.

verifier sur le linux si il n'y a pas un repertoire de toute la chaine
sur $HOME/.ssh avec un w pour le groupe ou other

non le w c'est pour user seulement :
┬─[:~]─[16-11-23 07:20:31]
╰─>$ lal .ssh
total 32
drwx------ 2 yt yt 4096 nov. 21 18:23 ./
drwxr-xr-x 37 yt yt 4096 nov. 23 09:11 ../
-rw------- 1 yt yt 381 nov. 21 18:23 config
-rw------- 1 yt yt 525 nov. 21 17:33 config_backup
-rw------- 1 yt yt 531 nov. 23 07:25 environment
-rw------- 1 yt yt 1766 nov. 16 13:58 id_rsa
-rw-r--r-- 1 yt yt 389 nov. 16 13:58 id_rsa.pub
-rw-r--r-- 1 yt yt 888 nov. 16 18:41 known_hosts
verifier sur le mac si la clef privée est bien uniquement en rw

pareil, c'est OK :
drwx------ 12 yt staff 408B 21 nov 19:06 .
drwxr-xr-x+ 106 yt staff 3,5K 23 nov 09:55 ..
-rw------- 1 yt staff 389B 16 nov 14:06 authorized_keys
-rw------- 1 yt staff 547B 22 nov 16:26 config
-rw------- 1 yt staff 740B 23 nov 11:06 environment
-rw------- 1 yt staff 1,7K 23 mar 2015 github_rsa
-rw-r--r-- 1 yt staff 402B 23 mar 2015 github_rsa.pub
-rw------- 1 yt staff 1,6K 21 nov 19:05 id_rsa
-rw------- 1 yt staff 1,7K 21 nov 19:05 id_rsa.bak
-rw-r--r-- 1 yt staff 394B 11 avr 2015 id_rsa.pub
-rw-r--r-- 1 yt staff 11K 16 nov 14:01 known_hosts
-rw------- 1 yt staff 1,5K 23 mar 2015 known_hosts.old
ssh -vvv peux etre ton ami

oui bonne idée !!!
┬─[:~]─[16-11-23 11:08:26]
╰─>$ ssh -vvv
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /home/yt/.ssh/config
debug1: /home/yt/.ssh/config line 1: Applying options for mbp.local
debug1: /home/yt/.ssh/config line 21: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "192.168.0.41" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 192.168.0.41 [192.168.0.41] port 22.
debug1: Connection established.
debug1: identity file /home/yt/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/yt/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2
debug1: match: OpenSSH_7.2 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.0.41:22 as 'yt'
debug3: hostkeys_foreach: reading file "/home/yt/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file
/home/yt/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 192.168.0.41
debug3: order_hostkeyalgs: prefer hostkeyalgs:
,,,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms:
,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms:
,,,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,,,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos:
,aes128-ctr,aes192-ctr,aes256-ctr,,,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc:
,aes128-ctr,aes192-ctr,aes256-ctr,,,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos:
,,,,,,,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc:
,,,,,,,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,,zlib
debug2: compression stoc: none,,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms:
,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms:
ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos:
,aes128-ctr,aes192-ctr,aes256-ctr,,
debug2: ciphers stoc:
,aes128-ctr,aes192-ctr,aes256-ctr,,
debug2: MACs ctos:
,,,,,,,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc:
,,,,,,,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,
debug2: compression stoc: none,
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm:
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: MAC:
<implicit> compression: none
debug1: kex: client->server cipher: MAC:
<implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp256
SHA256:Ip9VQ1a/3o4ZvU+gk8hPKqehiIrG1lBpm6qTZ9i6CGw
debug3: hostkeys_foreach: reading file "/home/yt/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file
/home/yt/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 192.168.0.41
debug1: Host '192.168.0.41' is known and matches the ECDSA host key.
debug1: Found key in /home/yt/.ssh/known_hosts:1
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/yt/.ssh/id_rsa (0x81a191d0), explicit, agent
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,keyboard-interactive
debug3: start over, passed a different list publickey,keyboard-interactive
debug3: preferred
gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/yt/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug2: input_userauth_pk_ok: fp
SHA256:CY0d9YVCRN/ukKaiAhGR02Xgx868uR1itgIL1j5Kc2U
debug3: sign_and_send_pubkey: RSA
SHA256:CY0d9YVCRN/ukKaiAhGR02Xgx868uR1itgIL1j5Kc2U
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.0.41 ([192.168.0.41]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype
want_reply 0
debug3: receive packet: type 91
debug2: callback start
debug1: Requesting authentication agent forwarding.
debug2: channel 0: request confirm 0
debug3: send packet: type 98
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug1: Sending environment.
debug3: Ignored env CLUTTER_BACKEND
debug3: Ignored env CLUTTER_IM_MODULE
debug3: Ignored env DBUS_SESSION_BUS_ADDRESS
debug3: Ignored env DEFAULTS_PATH
debug3: Ignored env DESKTOP_SESSION
debug3: Ignored env DISPLAY
debug3: Ignored env GDMSESSION
debug3: Ignored env GDM_XSERVER_LOCATION
debug3: Ignored env GEM_HOME
debug3: Ignored env GEM_PATH
debug3: Ignored env GLADE_CATALOG_PATH
debug3: Ignored env GLADE_MODULE_PATH
debug3: Ignored env GLADE_PIXMAP_PATH
debug3: Ignored env GNOME_KEYRING_CONTROL
debug3: Ignored env GNOME_KEYRING_PID
debug3: Ignored env GTK_IM_MODULE
debug3: Ignored env GTK_MODULES
debug3: Ignored env GTK_OVERLAY_SCROLLING
debug3: Ignored env HOME
debug3: Ignored env IM_CONFIG_PHASE
debug3: Ignored env INSTANCE
debug3: Ignored env JOB
debug1: Sending env LANG = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug1: Sending env LC_ADDRESS = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug1: Sending env LC_ALL = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug1: Sending env LC_COLLATE = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug1: Sending env LC_CTYPE = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug1: Sending env LC_IDENTIFICATION = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug1: Sending env LC_MEASUREMENT = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug1: Sending env LC_MESSAGES = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug1: Sending env LC_MONETARY = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug1: Sending env LC_NAME = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug1: Sending env LC_NUMERIC = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug1: Sending env LC_PAPER = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug1: Sending env LC_TELEPHONE = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug1: Sending env LC_TIME = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env LOGNAME
debug3: Ignored env LS_COLORS
debug3: Ignored env MANDATORY_PATH
debug3: Ignored env MDMSESSION
debug3: Ignored env MDM_LANG
debug3: Ignored env MDM_XSERVER_LOCATION
debug3: Ignored env NODE_PATH
debug3: Ignored env PATH
debug3: Ignored env PWD
debug3: Ignored env QT4_IM_MODULE
debug3: Ignored env QT_ACCESSIBILITY
debug3: Ignored env QT_IM_MODULE
debug3: Ignored env QT_LINUX_ACCESSIBILITY_ALWAYS_ON
debug3: Ignored env QT_STYLE_OVERRIDE
debug3: Ignored env SESSION
debug3: Ignored env SESSIONTYPE
debug3: Ignored env SESSION_MANAGER
debug3: Ignored env SHELL
debug3: Ignored env SHLVL
debug3: Ignored env SSH_AGENT_PID
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env TERM
debug3: Ignored env UPSTART_EVENTS
debug3: Ignored env UPSTART_INSTANCE
debug3: Ignored env UPSTART_JOB
debug3: Ignored env UPSTART_SESSION
debug3: Ignored env USER
debug3: Ignored env USERNAME
debug3: Ignored env WINDOWPATH
debug3: Ignored env XAUTHORITY
debug3: Ignored env XDG_CONFIG_DIRS
debug3: Ignored env XDG_CURRENT_DESKTOP
debug3: Ignored env XDG_DATA_DIRS
debug3: Ignored env XDG_MENU_PREFIX
debug3: Ignored env XDG_RUNTIME_DIR
debug3: Ignored env XDG_SEAT
debug3: Ignored env XDG_SESSION_COOKIE
debug3: Ignored env XDG_SESSION_DESKTOP
debug3: Ignored env XDG_SESSION_ID
debug3: Ignored env XDG_VTNR
debug3: Ignored env XMODIFIERS
debug3: Ignored env __fish_bin_dir
debug3: Ignored env __fish_datadir
debug3: Ignored env __fish_help_dir
debug3: Ignored env __fish_sysconfdir
debug3: Ignored env rvm_bin_path
debug3: Ignored env rvm_delete_flag
debug3: Ignored env rvm_path
debug3: Ignored env rvm_prefix
debug3: Ignored env rvm_ruby_string
debug3: Ignored env rvm_version
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Wed Nov 23 11:06:23 2016 from 192.168.0.48
]1337;RemoteHost=]1337;CurrentDir=/Users/yt]1337;ShellIntegrationVersion=2;shell=fish]1337;RemoteHost=]1337;CurrentDir=/Users/ytWelcome
to fish, the friendly interactive shell
Type help for instructions on how to use fish
type: Could not find 'acpi'
]133;D;0]133;A
Avatar
Une Bévue
Le 23/11/2016 à 09:57, Bruno Ducrot a écrit :
Et bien, je n'ai pas eu de problème :

Tant mieux pour toi.
:~$ uname -a
Linux poupinette 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux
:~$ ssh
Password:
Last login: Wed Nov 23 09:42:09 2016 from 192.168.1.15
~> uname -a
Darwin poupmac.poup 16.1.0 Darwin Kernel Version 16.1.0: Wed Oct 19 20:31:56 PDT 2016; root:xnu-3789.21.4~4/RELEASE_X86_64 x86_64
~> echo $SHELL
/usr/local/bin/fish
Tout ça sous xterm.

OK, c'est très clair.
Côté mac se connectant à linux, ça me demande toujours un mot de passe,
alors que j'ai une passphrase et que côté linux j'ai mis dans ma conf :
PasswordAuthentication no
Ce qui marche très bien dans l'autre sens : linux se connectant à mac
(les deux ordis sont côte-à-côte).
Sur linux il a suffit que je mette un ssh-add à l'ouverture de session,
j'entre ma passphrase t je n'en ai plus bessoin.


Là je ne vois pas. Problème de droits du répertoire ~/.ssh peut-être ?
Un ssh -v (comme le suggère un intervenant) pourrait aider.
Ou bien un ~/.ssh/config qui override le défaut ?

oui.
A plus,
1 2 3 4 5