Tag Info

Hot answers tagged

13

When you connect in something like this happens [user@an02-east ~]$ ps aux | grep ssh root 13789 0.0 0.0 98932 3888 ? Ss 03:16 0:00 sshd: user [priv] 502 13791 0.0 0.0 98932 1740 ? S 03:17 0:00 sshd: user@pts/0 root 15378 0.0 0.0 64728 1168 ? Ss 04:13 0:00 /usr/sbin/sshd So ssh is forking off a ...


8

It's possible to run 2 different SSH servers on 2 different ports, one refusing all connections while appearing in working order, while the other works fine. Why one would do that though is beyond me. Investing in a defense featuring IPS, IDS, firewall, the lot, seems to be the prudent approach, given enough funds. If you just want to refuse access to ...


5

You can also run Kippo https://github.com/desaster/kippo as an SSH honeypot, which simulates succesful login and you can log everything the user tries to do while "in" the server.


3

It sounds maybe like you want to run a SSH honeypot. There are lots to choose from depending upon the level of interaction you want. Kippo is a popular one. But unless you have a good reason for doing so, I agree with fuero that you should just use something like fail2ban or DenyHosts.


2

The old init system has been replaced by SystemD, with systemctl as the main interface to that system.


2

Possibly an IP address of your EC2 instance has changed, since you have restarted it. Check in Amazon EC2 console for new IP address.


2

No, it's not 'normal', but within the realm of being targetted. Check your logs for ssh login attempts. It looks like a bruteforce password attempt with your username. Please make sure ssh is disabled for root. And I hope you have a strong password. => actually, if you are using a key/cert to login, you should disable ssh logins with passwords, unless you ...


2

If you run a separate SSH server on port 22, you could set it to not allow any users to login by using the AllowUsers option in the sshd configuration file. The man page says: This keyword can be followed by a list of user name patterns, separated by spaces. If specified, login is allowed only for user names that match one of the ...


2

You could create another keypair, without a passphrase: $ ssh-keygen -t rsa -b 4096 -f ~/.ssh/cvs_rsa.id Then add the contents of ~/.ssh/cvs_rsa.id.pub to authorized_keys in the remote host. You should then be able to "ssh -i ~/.ssh/cvs_rsa.id user@remotehost" from your script. Note that when creating a key without a passphrase, anyone who has the ...


2

Run ssh with at least one -v option, and when you log out you will get something like: Transferred: sent 4288, received 4428 bytes, in 2.7 seconds


1

We see this behavior under either high load conditions or, more surprisingly, big file write conditions. You already ruled-out the high load. Let me explain the second scenario. This is a real scenario, and happened as recently as a few days ago: Assume large amounts of RAM, relative to disk write speed (32 GB RAM, 100 MB/sec) An application causes a ...


1

You shouldn't edit your /etc/passwd & /etc/group directly, please read up on what system tools to use (for adding users, changing password, modifying a user account, etc...) Also, I suspect you did more damage than just the kill -9 -1 (what where you trying to do with that!?), so I suggest you start with a fresh install again and carry on learning the ...


1

If the account you are using is named root (or something else rather common) and sshd is exposed to the internet, yes this within the normal range. You say you are using an ssh key for login. Is password authentication permitted? You could disable it. (If the account is root consider PermitRootLogin without-password.) Also, install fail2ban.


1

AFAIK OpenSSH doesn't have a support for that. <opinion>The probable reason behind that, that the OpenSSH guys favorize the minimal feature, maximal security concept which is quite visible on their other projects, too.</opinion> But it is not unconditionally a problem. You can do this by watching the system log, and setting up condition for ...


1

You can terminate all the shared sessions by issuing -O exit from the client side. ssh -O exit masterhostname Sadly there is no way to terminate a specific session and leave the others running. Sessions usually terminate naturally when the session is closed (EOF). Tunnels made using -L and -R are always listening for new sessions and there is no way to ...


1

try systemctl list-units sshd.service (actual service found by using systemctl list-units | grep ssh , no need for root by the way) Archemar@tatouin:~/> systemctl list-units sshd.service UNIT LOAD ACTIVE SUB DESCRIPTION sshd.service loaded active running OpenSSH Daemon LOAD = Reflects whether the unit definition was properly loaded. ...


1

Just replace ~/.ssh/google_compute_engine with the new key and use gcloud compute ssh as you normally would to get access to your VM instances; the key will be automatically propagated to the instances that don't already have it. If you want to remove the previous key(s), remove them from the metadata for all of the instances where it might have been used; ...


1

passwd -l myuser will effectively disable user password


1

Give them a password and don't tell them what it is.


1

I have resolved this. The problem was the public key for the problematic server had already been added as a "deploy key" to Gitlab for earlier unrelated testing. It was then deleted as a deploy key, but for some reason the key persisted in the Gitlab DB. Gitlab then let me re-add the same key to a test user without complaining that it already existed ...


1

From the AcceptEnv section in the sshd_config man page: "... The default is not to accept any environment variables." Red Hat may not have used the default in their package, but your version compiled from source may have used the default setting as listed in the man page.


1

@flurdy's answer is good as a one-off resolution. But if you often: launch new EC2 instances, start and stop EC2 instances, ..without using Elastic IPs (permanently attached to your servers) then you deal with new/changing IPs/hostnames of your instances all the time. If so then you may want to permanently stop SSH checking and storing server ...


1

This is a problem with ssh-copy-id; it also adds a key every time you run it. If you are automating the process, your authorized_keys file quickly gets cluttered with duplicate keys. Here is a Python program that avoids both problems. It runs from the control server and puts the keys from one remote server into another remote server. import subprocess def ...


1

If an SFTP client does not specify permissions for uploaded files, the OpenSSH SFTP server assigns newly created files permissions 0664. That's for default umask 0002, which you can change using -u switch as an answer by @JimB shows. If an SFTP client specifies the permissions, OpenSSH server uses the specified permissions (umask does not apply). Overview ...



Only top voted, non community-wiki answers of a minimum length are eligible