ssh non utilizza più ~ / .ssh / config

Non posso scrivere nulla di ciò che sono stato in grado di fare. Dopo un po 'di ricerche ho scoperto che non sta leggendo ssh config dalla mia home directory.

$ ssh -xvvv server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
(...)

Quando sei su un computer identico di un amico, dove tutto funziona sembra così:

$ ssh -xvvv server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /Users/kuba/.ssh/config
(...)

Ha funzionato prima e non sono a conoscenza di nulla che avrei potuto fare per causare questo problema. Come è potuto accadere e come risolverlo?

Nel collegamento di documentazione indicato da Tike afferma che

A causa del potenziale abuso, questo file deve disporre di autorizzazioni rigorose: lettura / scrittura per l'utente e non accessibile da altri.

Le mie autorizzazioni sono:

$ ls -la ~/.ssh
total 80
drwx------+ 42 kuba  1029   1428 Jul  1 16:33 ..
-rwx------   1 kuba  1029   1528 May 15 13:07 config
(...)

Penso che il problema potrebbe essere con una confusione sulla home directory. Quando forzo il file di configurazione locale, inizia a funzionare e quindi inizia improvvisamente a leggere/nas/kuba

$ ssh -xvvvF ~/.ssh/config server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /Users/kuba/.ssh/config
debug1: /Users/kuba/.ssh/config line 1: Applying options for *
debug1: /Users/kuba/.ssh/config line 39: Applying options for bio
debug2: ssh_connect: needpriv 0
debug1: Connecting to XXXX [YYYY.YYY.YYY.YYY] port 22.
debug1: Connection established.
debug1: identity file /nas/kuba/.ssh/id_dsa type -1
                      ^^^^^^^^^^

Ma la mia home directory sembra essere ok:

$ cd ~; pwd
/Users/kuba
$ echo $HOME
/Users/kuba

Sembra che tu sia intrappolato tra ssh_config specifico dell'utente e globale.

Controlla le impostazioni di autorizzazione del file di configurazione ( ~/.ssh/config) del tuo utente e del tuo file di configurazione ( /etc/ssh/ssh_config) a livello di sistema per capire in maggiori dettagli.

Puoi leggere di più su questo qui . In pratica, tutti i file nella .sshdirectory basata sull'utente devono essere su 600 e il configfile su 644. È possibile impostare questo con i seguenti comandi nella directory home:

chmod 600 ~/.ssh/* 
chmod 644 ~/.ssh/config

controlla le autorizzazioni

ls -lsd ~/.ssh

e

ls -ls ~/.ssh/*

Se le autorizzazioni non sono valide, il client SSH non proverà a leggere da esso

Ho avuto lo stesso problema e sono stato in grado di risolverlo impostando il flag + x sul mio ~/.sshdir (0700), e impostando anche 0600 su ~/.ssh/config.

Per quello che vale, ho avuto lo stesso problema e l'ho risolto creando ssh per creare nuovamente la .sshcartella (basta rinominare sshed eseguire alcuni comandi ssh) e successivamente copiare i file necessari, con le autorizzazioni appropriate. (config con 600).

Apparentemente ssh diventa sospetto se la cartella .sshviene modificata in un modo che non approva ...

SSH non leggerà la configurazione locale se si trova su un filesystem montato su NFS. Vale la pena verificare perché tutte le autorizzazioni possono andare bene e SSH (almeno la versione 6.6) non ti darà alcuna indicazione del perché non sta leggendo la configurazione dell'utente. (Tuttavia, verrà letto da un volume NFS se si utilizza l' -Fopzione.)

Ho riscontrato lo stesso problema su MacOs. Osservando le informazioni di debug di un accesso manuale (ssh @), ho scoperto che apparentemente ssh pensava che la mia directory home fosse /srv/home/<userid>e stava cercando la .sshdirectory lì dentro, e ignorò quella in/Users/<userid>/.ssh/

Probabilmente ha a che fare con il lavoro di configurazione dei Mac in un modo specifico, ma consiglierei di verificarlo sshe il sistema operativo è d'accordo su dove si trova la home directory;)

Come indicato da "kasperd" nel suo commento alla domanda, si noti che sshnon cercherà necessariamente "$ {HOME} /. Ssh / config". Come è stato scoperto, è importante scavare più a fondo e apprendere dove si trovava la directory home al momento dell'accesso e prima che fosse affermata una nuova HOME.

Il suggerimento di esaminare l'output di è ssh -xvvvF ~/.ssh/config serverstato molto perspicace nell'aiutare a rispondere a questa stessa domanda. Dopo essersi trovato su un sistema in cui due nomi utente diversi hanno lo stesso UID nel file '/ etc / passwd', si è verificato questo problema. I due utenti hanno directory HOME diverse impostate in '/ etc / passwd'.

In tale scenario, si scopre che se si è connessi come secondo utente con un UID duplicato nel file '/ etc / passwd', sshutilizza la directory home del primo utente con un UID corrispondente dell'utente che esegue SSH comando.

Certo, questo caso d'uso è piuttosto strano e non aiuterà la maggior parte delle persone, ma in realtà è successo e questo Q / A ha aiutato a risolvere un problema.

Ciò è stato causato dalle impostazioni di autorizzazione del file.

Controlla le tue .sshautorizzazioni dir e file, controlla anche le impostazioni delle tue autorizzazioni home dir.

Per quanto mi riguarda, non voglio che gli altri vedano i miei file personali, quindi rimuovo il xpermesso della mia casa dir. Il che porta ssh a trovare le chiavi autorizzate nel percorso sbagliato.

Un modo per risolvere questo problema era impostare un altro percorso di autorità /etc/ssh/sshd_config, ad esempio:

AuthorizedKeysFile .ssh / authorized_keys / etc / ssh / authorized_keys

poi copia il tuo pub /etc/ssh/authorized_keys, ha funzionato per me.