Permettre à un nouvel utilisateur de se connecter via ssh

8

On m'a donné un serveur à utiliser pour certains calculs. On m'a donné le mot de passe root et ils m'ont dit de me créer un compte.

J'ai accédé au serveur en utilisant ssh root@host et en saisissant le mot de passe root. J'ai ensuite créé un utilisateur avec sudo useradd -m mynameet défini un mot de passe. Puis je me déconnecte et essaie de faire sshssh myname@host

Immédiatement après avoir inséré mon mot de passe, mes connexions sont fermées:

Connection to host closed by remote host.
Connection to host closed.

J'ai essayé de regarder dans les fichiers host.deny et host.allow, mais ils ne semblent pas être modifiés (ils sont commentés avec #)

Ensuite, j'ai essayé de chercher etc/ssh/sshd_config, mais je ne sais pas exactement quoi chercher. Voici quelques paramètres qui semblent pertinents:

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

Quel pourrait être le problème? Notez que je n'essaye pas de me connecter en utilisant les clés ssh, l'insertion du mot de passe est très bien. Comment puis-je faire fonctionner cela?

Modifier Voici le contenu de tout le fichier sshd_config:

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

Edit 2 Voici la sortie de la tentative de connexion avecssh -vv username@host

OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "host_name" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to host_name [ip_address] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /localhome/username/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /localhome/username/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /localhome/username/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /localhome/username/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /localhome/username/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /localhome/username/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /localhome/username/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /localhome/username/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2 pat OpenSSH* compat 0x04000000
debug2: fd 5 setting O_NONBLOCK
debug1: Authenticating to host_name:22 as ‘username_on_server’
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
[…]
debug1: Server host key: [serverkey]
debug1: Host 'host_name' is known and matches the ECDSA host key.
debug1: Found key in /localhome/username/.ssh/known_hosts:5
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /localhome/username/.ssh/id_rsa ((nil))
debug2: key: /localhome/username/.ssh/id_dsa ((nil))
debug2: key: /localhome/username/.ssh/id_ecdsa ((nil))
debug2: key: /localhome/username/.ssh/id_ed25519 ((nil))
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /localhome/username/.ssh/id_rsa
debug1: Trying private key: /localhome/username/.ssh/id_dsa
debug1: Trying private key: /localhome/username/.ssh/id_ecdsa
debug1: Trying private key: /localhome/username/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
username_on_server@host_name's password: <——- Here I inserted my password
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
Authenticated to host_name ([ip_address]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: channel 0: free: client-session, nchannels 1
Connection to host_name closed by remote host.
Connection to host_name closed.
Transferred: sent 1736, received 1388 bytes, in 0.0 seconds
Bytes per second: sent 9760471.5, received 7803879.3
debug1: Exit status -1

Modifier 3 le .profile du nouvel utilisateur sur le serveur

# if running bash
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
        . "$HOME/.bashrc"
    fi
fi

# set PATH so it includes user's private bin directories
PATH="$HOME/bin:$HOME/.local/bin:$PATH"
Fourmi
la source
2
- Avez-vous créé un mot de passe pour myname (à l'aide de passwd) ou défini une clé publique dans ~ / .ssh / authorized_keys? - qu'y a-t-il dans sshd_config pour AllowUsers?
tonioc
1
Essayez ssh -vvv pour voir si vous pouvez voir des messages d'erreur. Vérifiez également les journaux de messages sur le serveur
Raman Sailopal
2
tonioc est correct. Vous avez besoin 1. d'un mot de passe défini sur le compte pour le déverrouiller, et 2. de la configuration de l'authentification par clé publique pour cet utilisateur. Il semble que la boîte accepte uniquement l'authentification par clé publique. Voir comment PasswordAuthenticationest commenté?
Patrick
@Patrick - cette ligne commentée montre simplement le paramètre par défaut. Pour le passer à NO, vous devez le décommenter. Il est donc probable qu'il accepte les mots de passe et, en fait, dans la question d'origine, Ant indique qu'il s'est connecté à la racine utilisateur et à un mot de passe.
EightBitTony
1
Utilisez ssh -vv myname@hostet si vous ne voyez pas le problème dans la sortie, ajoutez la sortie (formatée) à votre question.
EightBitTony

Réponses:

1

Assurez-vous que le répertoire personnel de l'utilisateur avec lequel vous essayez de vous connecter a été créé, que la propriété est également votre utilisateur et que ~ / .ssh est défini sur chmod 700. Vérifiez également / var / log / secure pour toutes les erreurs pendant vous essayez de vous connecter.

bootbeast
la source
0

La ssh -vvsortie semble indiquer que l'authentification par mot de passe a été acceptée, il semblerait donc que tout va bien jusqu'à présent, mais il se passe quelque chose juste après cela qui ferme la session. Choses que je voudrais vérifier:

  1. Cela semble évident, mais comme il s'agit d'un nouvel utilisateur, avez-vous vérifié que le shell de connexion est défini sur quelque chose de valide? (c'est-à /bin/bash- dire et non nologinou nottyetc.)
  2. Plus long, mais vérifiez tout ce qui est bizarre dans ~ / .bashrc, ~ / .profile, etc. qui pourrait être tenté de s'exécuter à la connexion. Comme @ceving le suggère ci-dessus, vous pouvez essayer une session ssh qui n'exécute pas le .profile dans votre shell de connexion.
Christopher Hunter
la source