Bonjour,
J'utilisais un VPS 2018 SSD 1 qui me sers plus, je souhaite aujourd'hui le réinitialiser complètement. J'avais pour optique de suivre les guides OVH :
https://docs.ovh.com/fr/vps/debuter-avec-vps/ et https://docs.ovh.com/fr/vps/conseils-securisation-vps/
Globalement je suis bloqué à l'étape du changement de port SSH. Après moults essais, j'arrive à la situation simple suivante :
- Je réinstalle le VPS via le tableau de bord (debian 9 ou 10)
- Je reçois le mail initial avec de nouveaux accès root, je me connecte en SSH (putty ou commande DOS) sans souci
- Dans /etc/ssh/sshd_config, je modifie la ligne concernant le port, par défaut commentée. Je mets un port ~aléatoire, disons 49876, je sauvegarde
- Je lance la commande "systemctl restart sshd"
- J'attends un peu (même jusqu'à 1h), pour etre sûr je vérifie avec "service ssh status" que le service est "active (running)" et avec "Server listening on :: port 49876"
- J'essaye par ailleurs de me connecter en SSH (putty ou commande DOS) sur ce port "ssh root@MONIP -p 49876", je reçois une erreur "Connection timed out"
- Si je vais chercher le port 22 "ssh root@MONIP -p 22", je reçois une erreur "Connection refused" qui est bien attendue
- Si je vais remettre le port 22 dans mon fichier de config, je peux de nouveau ouvrir une connexion "ssh root@MONIP -p 22"
Absolument aucune autre modif sur ce VPS ré-installé, mais après quelque essais :
- Pas mieux si je fais une passe de apt-get update/upgrade avant tout
- Si j'envoie une grosse commande "reboot" après le changement de port, ca provoque juste la fermeture de la connexion initiale et donc je n'ai plus la main sur mon serveur, et donc aucune connexion SSH possible ensuite.
- Le KVM à l'air HS depuis plusieurs heures, pas moyen de me connecter par là.
Est-ce que j'ai raté quelque chose sur cette étape qui pourtant l'air simplissime ? Pourquoi ne puis-je pas me connecter sur le nouveau port SSH ?
Merci pour toute aide :)
Serveurs Privés Virtuels (VPS) - Problème d'accès SSH après changement de port
Related questions
- Perte de mot de passe
48537
26.05.2023 13:36
- Comment configurer/utiliser un SMTP depuis un VPS ?
47188
07.10.2019 10:49
- Je connais que le mutu et besoin de node js
46739
14.04.2017 13:34
- Qu'est-ce vcore?
45712
06.01.2017 19:20
- Envoi Email via SMTP (port 587) sur VPS Pro1
44775
27.01.2017 10:02
- [résolu] Serveur Mysql - hôte inconnu
42376
19.01.2017 16:21
- Mon VPS à Timed Out
42083
15.03.2017 22:50
- Délai de livraison VPS
41809
11.07.2018 15:15
- Problème avec statisitique Plesk
39246
29.03.2017 07:44
- Accès externe base de données
38749
18.07.2018 10:29
Bonjour,
Cela devrait fonctionner.
Je trouve bizarre que tu te connecte directement avec root (c'est debian le user par défaut). Donc je me dis que tu fais d'autres manips post install.
Peux tu donner le contenu de
>/etc/ssh/sshd_config
/etc/cloud/cloud.cfg
Et le résultat de
`iptables -L -n`
`netstat -anp | grep sshd`
Tout cela après les modif du fichier de conf SSHD et de son restart
```text Bonjour,
Après re-installation, je n'ai que root comme utilisateur, je ne sais meme pas si Debian existe, mais je ne fais vraiment aucune manip post-install (possiblement le processus OVH génère ca comme ca ?)
Pour sshd_config, je n'ai touché que le port
[details=Résumé]> # $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $
> # This is the sshd server system-wide configuration file. See
> # sshd_config(5) for more information.
> # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
> # The strategy used for options in the default sshd_config shipped with
> # OpenSSH is to specify options with their default value where
> # possible, but leave them commented. Uncommented options override the
> # default value.
> Port 49876
> #AddressFamily any
> #ListenAddress 0.0.0.0
> #ListenAddress ::
> #HostKey /etc/ssh/ssh_host_rsa_key
> #HostKey /etc/ssh/ssh_host_ecdsa_key
> #HostKey /etc/ssh/ssh_host_ed25519_key
> # Ciphers and keying
> #RekeyLimit default none
> # Logging
> #SyslogFacility AUTH
> #LogLevel INFO
> # Authentication:
> #LoginGraceTime 2m
> #PermitRootLogin prohibit-password
> #StrictModes yes
> #MaxAuthTries 6
> #MaxSessions 10
> #PubkeyAuthentication yes
> # Expect .ssh/authorized_keys2 to be disregarded by default in future.
> #AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
> #AuthorizedPrincipalsFile none
> #AuthorizedKeysCommand none
> #AuthorizedKeysCommandUser nobody
> # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
> #HostbasedAuthentication no
> # Change to yes if you don't trust ~/.ssh/known_hosts for
> # HostbasedAuthentication
> #IgnoreUserKnownHosts no
> # Don't read the user's ~/.rhosts and ~/.shosts files
> #IgnoreRhosts yes
> # To disable tunneled clear text passwords, change to no here!
> #PasswordAuthentication yes
> #PermitEmptyPasswords no
> # Change to yes to enable challenge-response passwords (beware issues with
> # some PAM modules and threads)
> ChallengeResponseAuthentication no
> # Kerberos options
> #KerberosAuthentication no
> #KerberosOrLocalPasswd yes
> #KerberosTicketCleanup yes
> #KerberosGetAFSToken no
> # GSSAPI options
> #GSSAPIAuthentication no
> #GSSAPICleanupCredentials yes
> #GSSAPIStrictAcceptorCheck yes
> #GSSAPIKeyExchange no
> # 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
> #AllowAgentForwarding yes
> #AllowTcpForwarding yes
> #GatewayPorts no
> X11Forwarding yes
> #X11DisplayOffset 10
> #X11UseLocalhost yes
> #PermitTTY yes
> PrintMotd no
> #PrintLastLog yes
> #TCPKeepAlive yes
> #PermitUserEnvironment no
> #Compression delayed
> #ClientAliveInterval 0
> #ClientAliveCountMax 3
> #UseDNS no
> #PidFile /var/run/sshd.pid
> #MaxStartups 10:30:100
> #PermitTunnel no
> #ChrootDirectory none
> #VersionAddendum none
> # no default banner path
> #Banner none
> # Allow client to pass locale environment variables
> AcceptEnv LANG LC_*
> # override default of no subsystems
> Subsystem sftp /usr/lib/openssh/sftp-server
> # Example of overriding settings on a per-user basis
> #Match User anoncvs
> # X11Forwarding no
> # AllowTcpForwarding no
> # PermitTTY no
> # ForceCommand cvs server
> PasswordAuthentication yes
> PermitRootLogin yes[/details]
cloud :
[details=Résumé]> ssh_pwauth: 1
> hostname: ***NOMSERVEUR***.ovh.net
> # The top level settings are used as module
> # and system configuration.
> # A set of users which may be applied and/or used by various modules
> # when a 'default' entry is found it will reference the 'default_user'
> # from the distro configuration specified below
> users:
> - default
> # If this is set, 'root' will not be able to ssh in and they
> # will get a message to login instead as the above $user (debian)
> disable_root: 0
> # This will cause the set+update hostname module to not operate (if true)
> preserve_hostname: false
> # This preverts apt/sources.list to be updated at boot time, which
> # may be annoying.
> apt_preserve_sources_list: true
> # Example datasource config
> # datasource:
> # Ec2:
> # metadata_urls: [ 'blah.com' ]
> # timeout: 5 # (defaults to 50 seconds)
> # max_wait: 10 # (defaults to 120 seconds)
> # The modules that run in the 'init' stage
> cloud_init_modules:
> - migrator
> - seed_random
> - bootcmd
> - write-files
> - growpart
> - resizefs
> - disk_setup
> - mounts
> - set_hostname
> - update_hostname
> - update_etc_hosts
> - ca-certs
> - rsyslog
> - users-groups
> - ssh
> # The modules that run in the 'config' stage
> cloud_config_modules:
> # Emit the cloud config ready event
> # this can be used by upstart jobs for 'start on cloud-config'.
> - emit_upstart
> - ssh-import-id
> - locale
> - set-passwords
> - grub-dpkg
> - apt-pipelining
> - apt-configure
> - ntp
> - timezone
> - disable-ec2-metadata
> - runcmd
> - byobu
> # The modules that run in the 'final' stage
> cloud_final_modules:
> - package-update-upgrade-install
> - fan
> - puppet
> - chef
> - salt-minion
> - mcollective
> - rightscale_userdata
> - scripts-vendor
> - scripts-per-once
> - scripts-per-boot
> - scripts-per-instance
> - scripts-user
> - ssh-authkey-fingerprints
> - keys-to-console
> - phone-home
> - final-message
> - power-state-change
> # System and/or distro specific settings
> # (not accessible to handlers/transforms)
> system_info:
> # This will affect which distro class gets used
> distro: debian
> # Default user name + that default users groups (if added/used)
> default_user:
> name: debian
> lock_passwd: True
> gecos: Debian
> groups: [adm, audio, cdrom, dialout, dip, floppy, netdev, plugdev, sudo, video]
> sudo: ["ALL=(ALL) NOPASSWD:ALL"]
> shell: /bin/bash
> # Other config here will be given to the distro class and/or path classes
> paths:
> cloud_dir: /var/lib/cloud/
> templates_dir: /etc/cloud/templates/
> upstart_dir: /etc/init/
> package_mirrors:
> - arches: [default]
> failsafe:
> primary: http://deb.debian.org/debian
> security: http://security.debian.org/
> ssh_svcname: ssh
> mount_default_fields: [~, ~, 'auto', 'defaults,nofail', '0', '2']
> manage_etc_hosts: true[/details]
iptables:
> Chain INPUT (policy ACCEPT)
> target prot opt source destination
> Chain FORWARD (policy ACCEPT)
> target prot opt source destination
> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination
netstat:
> tcp 0 0 0.0.0.0:49876 0.0.0.0:* LISTEN 1658/sshd
> tcp 0 64 IPSERVEUR:22 IP:PORT ESTABLISHED 1464/sshd: root@pts
> tcp6 0 0 :::49876 :::* LISTEN 1658/sshd
> unix 2 [ ] DGRAM 28112 1464/sshd: root@pts
> unix 2 [ ] STREAM CONNECTED 28057 1464/sshd: root@pts
> unix 3 [ ] STREAM CONNECTED 32401 1658/sshd
J'imagine que le reste de port 22 correspond a la session initiale en cours ```
Ça m'a l'air bon (Les fichiers de conf sont difficile à lire).
On peut voir des choses étrange tel la la connexion root autorisée...
C'est quelle image de Debian que tu installes ?
Bonjour,
le "permitRootLogin prohibit-password" ou "permitRootLogin witout-password" est normale, cela autorise la connexion root via clé SSH uniquement et c'est de base dans un Debian (du moins la dernière fois que j'ai regardé).
Et question qui tue, mais sur votre PC/Réseau vous autoriser bien ce port que vous avez défini sur le VPS ?
Cordialement, janus57
@Janus question qui tue en effet... J'ai testé avec un autre PC sur un autre réseau où je suis sûr que le pare-feu m'embête pas, ca marche tellement bien...
Merci d'avoir posé "la question bête" qui débloque tout :)
Bonjour,
de rien.
Si j'y est pensé c'est parce que en environnement d'entreprise les SSH restent sur le 22 car port standard qui est ouvert dans le firewall, car en règles générales seules les ports commun sont ouvert ( genre 21/22/80/110/143/443/445/587/993/995).
Cordialement, janus57